3 ms·

A master can make good work with shit tools, but they'll still prefer to work with good tools. Syntax matters because it's part of the interface, and so it has

A master can make good work with shit tools, but they'll still prefer to work with good tools. Syntax matters because it's part of the interface, and so it has the ability to clarify or confound. Destructuring assignment; async/await instead of CPS (technically not exactly equivalent due to variable scope, but close enough in actual usage); pipe operators/macros instead of (third-function (second-function (first-function the-data))). None of these make the language more powerful but they do aid clarity and concision, as well as just making the language nicer to use.

simion314 7y ago
>Syntax matters I would say a good developer can make the code clear, I can make my ES5 code clearer then some bad ES7 code, most of the time clear code depends on how you name and split your code in logical and intuitive steps.
cryptica 7y ago
I'm a big fan of async/await and I can appreciate what it achieves in terms of helping to prevent coding errors. I've rewritten an entire open source WebSocket framework in async/await, so I know exactly what the benefits are. But in spite of that, in the grand scheme of things, I still think it doesn't really matter. The architecture of the project is much more important. I had been working on that project for 3 years but migrating it to async/await only took me about 2 months of casual after hours work. The reason it was so easy to migrate and that I didn't have to write the project again from scratch is precisely because the architecture was correct to begin with. When you think about code quality in terms of how much (or rather, how little) time it takes to maintain it to adapt to industry trends, architecture is by far the most important factor. Because even if everything changes from underneath you, a good architecture will survive the test of time. Any other metric to measure code quality is arbitrary and meaningless IMO. It's mind boggling that my previous comment received downvotes. I guess it reinforces the point that the author of the article is making. The average developer is incapable of understanding what is important. If people can't articulate what their goal is and they don't know what is important in order to achieve this goal, then there is zero chance that they will be able to make the right tradeoffs. Because there is no free lunch, every decision is a tradeoff. If, like for the vast majority of projects, there is a good chance that the requirements will change significantly in a year or two, then you need to know what really counts and architecture is one of those things that can stick if done correctly.

simion314 7y ago

>Syntax matters I would say a good developer can make the code clear, I can make my ES5 code clearer then some bad ES7 code, most of the time clear code depends on how you name and split your code in logical and intuitive steps.

cryptica 7y ago

I'm a big fan of async/await and I can appreciate what it achieves in terms of helping to prevent coding errors. I've rewritten an entire open source WebSocket framework in async/await, so I know exactly what the benefits are. But in spite of that, in the grand scheme of things, I still think it doesn't really matter. The architecture of the project is much more important. I had been working on that project for 3 years but migrating it to async/await only took me about 2 months of casual after hours work. The reason it was so easy to migrate and that I didn't have to write the project again from scratch is precisely because the architecture was correct to begin with. When you think about code quality in terms of how much (or rather, how little) time it takes to maintain it to adapt to industry trends, architecture is by far the most important factor. Because even if everything changes from underneath you, a good architecture will survive the test of time. Any other metric to measure code quality is arbitrary and meaningless IMO. It's mind boggling that my previous comment received downvotes. I guess it reinforces the point that the author of the article is making. The average developer is incapable of understanding what is important. If people can't articulate what their goal is and they don't know what is important in order to achieve this goal, then there is zero chance that they will be able to make the right tradeoffs. Because there is no free lunch, every decision is a tradeoff. If, like for the vast majority of projects, there is a good chance that the requirements will change significantly in a year or two, then you need to know what really counts and architecture is one of those things that can stick if done correctly.