Hacker News Reader

Comment by userbinator | Hacker News Reader

I'm a fan of using the least number of language features to get the job done.

Some people seem to love doing the opposite, which IMHO is the biggest problem with the software industry --- there's a huge number of developers who think that the more complex (or in their words, "structured") software is, and the more latest language features it has, is somehow better than the simple "deprecated" stuff that's been working for decades.

I've come to the conclusion that a lot of new language features are there only for the benefit of trendchasers and worshippers of planned obsolescence, and not the users nor the developers on their side.

View on HN

I think the biggest problem with the software industry is all the people who insist that everything that everyone else does is the biggest problem with the software industry.

I guess that set includes me now ¯\_(ツ)_/¯

> I've come to the conclusion that a lot of new language features are there only for the benefit of trendchasers and worshippers of planned obsolescence, and not the users nor the developers on their side.

What are your thoughts on aync/await then (available in Python/JavaScript etc.)?

> What are your thoughts on aync/await then (available in Python/JavaScript etc.)?

Not the OP, but I find it hard to have an absolute opinion on this - IMO some recent additions to javascript significantly decrease cognitive load.

async/await is a great example of this (vs then/catch/finally chains), and also:

* spreading of arrays, props, and more arguably args * shortcutting prop/value pairs, e.g. { x:x } as { x }

Some stuff it seems are more confusing, e.g.

* similar but subtly different things like for/of vs for/in vs forEach vs iterating Object.keys(), Object.values(), Object.entries() * what are generators and the yield keyword for?

> what are generators and the yield keyword for?

Generators are great for memory intensive data structures (ie. large lists), as they provide lazy evaluation to languages that are designed to evaluate eagerly. Generators can be considered to be a first step towards coroutines if you will, as the subroutines are the ones yield-ing control back to the event loop - David Beazley has a great talk[0] on it, coding an event loop live from scratch.

> similar but subtly different things like for/of vs for/in vs forEach vs iterating Object.keys(), Object.values(), Object.entries()

Array.forEach[1] is the oldest of that bunch, Object.keys[2] came later, for...in[3]/for...of[4] after that, and Object.values[5]/Object.entries[6] are the newest addition. I personally prefer the new way here.

EDIT: for...in[3], then Array.forEach[1], then Object.keys[2], then the rest it seems.

[0]: https://youtu.be/MCs5OvhV9S4?t=1072 (video)

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[3]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[4]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[5]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[6]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Complexity in javascript is probably more like the fact that there are three different ways of constructing classes. Async/await has it's own pitfalls but at least it is adding new functionality.

JavaScript has multiple ways to blueprint objects, yes, but that isn't really what GP stated. I consider the class keyword as way more beneficial than just being for "trendchasers and worshippers".

The only pitfall with async/await is all the existing I/O-intensive code where blocking your runtime wasn't seen as a problem that waisted unnecessary resources (yet). Must be This Tall to Write Multi-Threaded Code[0] comes to mind.

[0]: https://bholley.net/blog/2015/must-be-this-tall-to-write-mul...

I agree, class syntax is better. If javascript had been designed today, I imagine that would be the _only_ way to blueprint objects.

My thoughts can be summed up in 4 words: "stay away from async".

Several decades of experience debugging race conditions and other obscure concurrency bugs have taught me that the benefits of async code are rarely worth it, and more often than not add unnececessary overhead both at runtime and in development.

Funny thing is, humans have a huge bias towards traditions that seems to have reversed in the last century or so.

My take is that consumerism did a number on our psyche.

Reply on news.ycombinator.com