5 ms·

I usually don't respond to anything which I feel is just another "language war" provocation, but whenever I see these type of reviews I'm mystified. I've develo

by placebo 10y ago

I usually don't respond to anything which I feel is just another "language war" provocation, but whenever I see these type of reviews I'm mystified. I've developed in many languages and frameworks, both well known and lesser known - decades of client and server side of C/C++, Javascript, Lua, Java, Python, PHP, Perl, Lisp. Pascal (just to name a few) in projects of all sizes, and not once did I have the thought "this language sucks". I think there are a few reasons for this: 1) Even after all these years, I'm still passionate and excited at the ability to sculpt logic, regardless of the "material" I need to use. 2) A "keep it simple" approach - no way to overemphasise this. Know the advantages and limitations of the language and stick to what works. Keeping things simple should be like a fractal - existing at all levels of abstraction. 3) I'm very wary of hype. New, shiny and trendy does not necessarily mean better, especially when the hype is in conflict with keeping things simple. I find that when you understand the playing field, mark the areas to avoid and keep things as simple as possible, the elegance of the design and implementation usually makes the advantage of language X over Y insignificant, and I feel that blaming failure on the language used is like blaming a bad novel on the word processor used to write it.

stormbeta 10y ago
The article doesn't appear to be blaming Javascript as a language, but rather the Node.js ecosystem as a server platform. Not all tools are appropriate for all niches. The author made it clear they don't have an issue with Javascript as a whole or even with Node.js necessarily, but rather the use of Node.js as a major server platform or as a platform for large applications.
- qwer 10y ago
  All of his arguments actually apply to all of javascript, and are not actually specific to node.js though.
  - adevine 10y ago
    But there is a good argument that your server components (or at least a good portion of them) should be built in a language that requires some more up front work because it makes maintenance easier down the line.
    - krisdol 10y ago
      There is a good argument to be had on the same topic for the front end. Arguably more so.
  - ctide 10y ago
    Not really. These things aren't pain points in the browser the way they are in Node. I have never felt the need for an ORM in the browser. I have never dealt with client-side code that was using so many libraries I had to worry about whether exceptions would be handled via exceptions, or the first argument of the callback, or rejected promises. No one (at least, no one I know) is installing node modules like isArray to use in the browser. Yes, these things _could_ technically apply to the browser, but it's not commonplace. In the node world, these are all things you deal with consistently.
    - girvo 10y ago
      > No one (at least, no one I know) is installing node modules like isArray to use in the browser. Erm, well, considering the adoption rate of Browserify and Webpack, I'm going to disagree with you there. Especially considering React's momentum practically requiring some form of module builder.
      - esailija 10y ago
        Startup speed is terrible with that approach, each browserified module adds like 10x more code as boilerplate than something like isArray implementation would take. Then every module dependency is resolved dynamically at runtime, which will also quickly become a performance problem even when you aren't using micromodules.
        Klathmon 10y ago
        I haven't touched browserify, but with webpack what you said could not be more false... Webpack doesn't bundle at runtime, it doesn't add any amount of code overhead per module that I can easily measure, and it doesn't trash startup speed.
        nilliams 10y ago
        Same goes for browserify. You can have lots of tiny modules and (watchify especially) is fast to re-build. And yeah perf of 'require' statements at run-time is a non-issue.
eksemplar 10y ago
I didn't get the impression he hated the language or even the node.js ecosystem. Love or hate for languages have no real place in production. I work at a place with 5000 employees and I sometimes work with technologies I'm not fond of because they are the right choice for the job. Things like long term support, stability and security rate in how mature different technologies are for production. Considering a lot of the problems the author ran into with node.js aren't secret, I think he might actually have liked it quite a bit to go on to try it in production for a full year.
_yosefk 10y ago
Keeping it simple works wonders but you can't do it alone. A language with a culture of making things complex so as to achieve some standard of perfection, and/or with many developers simply not knowing how to stay out of trouble and not being able to tell what's fragile and what's trustworthy, will make it harder to "keep it simple." I agree that when programming mostly alone one can get by very nicely in any reasonably popular language since its popularity necessarily means that it's workable in the areas where it's typically used. I disagree that languages can not get in your way if you know what you're doing once you're not doing it alone.
pron 10y ago
No language is good enough to make a boring job pleasurable[1]; no language[2] is bad enough to ruin the pleasure of interesting job. [1]: At least, not for long. [2]: created in the past thirty/forty years
- morgante 10y ago
  C++ is 30 years old and it certainly has made interesting projects horrible.
dunkelheit 10y ago
You are a lucky person if you have used so many languages and never missed a thing in a language you are using at the moment that is readily available in some other language you have used in the past and that would make everything so much simpler! For example the OP got fed up with Python and switched to Node. Now he is fed up with Node and switching back. I can say that focusing on the downsides of the tool I am currently using and the upsides of the tool I am not using is a fairly common thought pattern for me too. Of course the way to combat it is to remember that it is very rare for some tool to be strictly superior to others and just focus on the task at hand. Choice is a very dangerous thing. When reading the book "Coders at work" I was struck by how primitive some of the old computing environments were. But that did not stop those people from doing amazing things with them. I now think that was partially to their advantage because they were freed from choosing the language/framework and so could concentrate on doing, you know, actual stuff.
astrobe_ 10y ago
> I feel that blaming failure on the language used is like blaming a bad novel on the word processor used to write it. Sure. If you're a good novelist you can write something great even on a keyboard with a broken 'e' key (btw, your 'I' key is about to break; you should replace it asap). But novelists don't have deadlines and when the novel is done, they usually don't take reader requests to change this or that part of the story. "The advantages and limitations", what works and what doesn't, "areas to avoid" are precisely the point of that kind of review.
- teh_klev 10y ago
  > But novelists don't have deadlines and when the novel is done I hate to "well actually" you :) , but a great number of authors have contracts that demand one or two novels a year over a fixed period of time. I know Iain Banks did with his publisher, he mentioned it at a one of his readings of a new but yet unpublished novel I was lucky to attend back in 2007'ish. > they usually don't take reader requests to change this or that part of the story. Even well known authors are reigned in by their editors and proof readers, and sometimes things have to be changed.
- placebo 10y ago
  > (btw, your 'I' key is about to break; you should replace it asap). haha - touché, point taken :-) Deadlines seem like a great excuse for compromising quality. Sure, life is complicated, the boss is demanding, the mortgage has to be paid, the children need to be supported etc. etc. but compromising quality and enthusiasm (they usually are correlated) because of the "terror" of a deadline will just leave you at the mercy of the next "terror", only this time you'll even have even less enthusiasm to fix the spaghetti. Doesn't sound like an enjoyable existence. Of course, very few people have the privilege of never having to compromise, but it's never black or white and there are many more degrees of freedom to choose the path with more quality than are implied. >"The advantages and limitations", what works and what doesn't, "areas to avoid" are precisely the point of that kind of review. The "area to avoid" in the review is Node.js and considering that large and impressive projects have been written in it, it seems that this is another case of throwing the baby out with the bathwater.
AhmadH 10y ago
It's more like hundreds of thousands of writing teams from different cultures and levels of experience sprung up to write collaborative epics in Latin because it had suddenly become cool to do so while bringing the language to the modern world by inventing a new vocabulary and arguing on the correct pronunciation of everything.

by placebo 10y ago

stormbeta 10y ago

The article doesn't appear to be blaming Javascript as a language, but rather the Node.js ecosystem as a server platform. Not all tools are appropriate for all niches. The author made it clear they don't have an issue with Javascript as a whole or even with Node.js necessarily, but rather the use of Node.js as a major server platform or as a platform for large applications.

qwer 10y ago
All of his arguments actually apply to all of javascript, and are not actually specific to node.js though.
- adevine 10y ago
  But there is a good argument that your server components (or at least a good portion of them) should be built in a language that requires some more up front work because it makes maintenance easier down the line.
  - krisdol 10y ago
    There is a good argument to be had on the same topic for the front end. Arguably more so.
- ctide 10y ago
  Not really. These things aren't pain points in the browser the way they are in Node. I have never felt the need for an ORM in the browser. I have never dealt with client-side code that was using so many libraries I had to worry about whether exceptions would be handled via exceptions, or the first argument of the callback, or rejected promises. No one (at least, no one I know) is installing node modules like isArray to use in the browser. Yes, these things _could_ technically apply to the browser, but it's not commonplace. In the node world, these are all things you deal with consistently.
  - girvo 10y ago
    > No one (at least, no one I know) is installing node modules like isArray to use in the browser. Erm, well, considering the adoption rate of Browserify and Webpack, I'm going to disagree with you there. Especially considering React's momentum practically requiring some form of module builder.
    - esailija 10y ago
      Startup speed is terrible with that approach, each browserified module adds like 10x more code as boilerplate than something like isArray implementation would take. Then every module dependency is resolved dynamically at runtime, which will also quickly become a performance problem even when you aren't using micromodules.
      - Klathmon 10y ago
        I haven't touched browserify, but with webpack what you said could not be more false... Webpack doesn't bundle at runtime, it doesn't add any amount of code overhead per module that I can easily measure, and it doesn't trash startup speed.
        nilliams 10y ago
        Same goes for browserify. You can have lots of tiny modules and (watchify especially) is fast to re-build. And yeah perf of 'require' statements at run-time is a non-issue.

eksemplar 10y ago

I didn't get the impression he hated the language or even the node.js ecosystem. Love or hate for languages have no real place in production. I work at a place with 5000 employees and I sometimes work with technologies I'm not fond of because they are the right choice for the job. Things like long term support, stability and security rate in how mature different technologies are for production. Considering a lot of the problems the author ran into with node.js aren't secret, I think he might actually have liked it quite a bit to go on to try it in production for a full year.

_yosefk 10y ago

Keeping it simple works wonders but you can't do it alone. A language with a culture of making things complex so as to achieve some standard of perfection, and/or with many developers simply not knowing how to stay out of trouble and not being able to tell what's fragile and what's trustworthy, will make it harder to "keep it simple." I agree that when programming mostly alone one can get by very nicely in any reasonably popular language since its popularity necessarily means that it's workable in the areas where it's typically used. I disagree that languages can not get in your way if you know what you're doing once you're not doing it alone.

pron 10y ago

No language is good enough to make a boring job pleasurable[1]; no language[2] is bad enough to ruin the pleasure of interesting job. [1]: At least, not for long. [2]: created in the past thirty/forty years

morgante 10y ago
C++ is 30 years old and it certainly has made interesting projects horrible.

dunkelheit 10y ago

You are a lucky person if you have used so many languages and never missed a thing in a language you are using at the moment that is readily available in some other language you have used in the past and that would make everything so much simpler! For example the OP got fed up with Python and switched to Node. Now he is fed up with Node and switching back. I can say that focusing on the downsides of the tool I am currently using and the upsides of the tool I am not using is a fairly common thought pattern for me too. Of course the way to combat it is to remember that it is very rare for some tool to be strictly superior to others and just focus on the task at hand. Choice is a very dangerous thing. When reading the book "Coders at work" I was struck by how primitive some of the old computing environments were. But that did not stop those people from doing amazing things with them. I now think that was partially to their advantage because they were freed from choosing the language/framework and so could concentrate on doing, you know, actual stuff.

astrobe_ 10y ago

> I feel that blaming failure on the language used is like blaming a bad novel on the word processor used to write it. Sure. If you're a good novelist you can write something great even on a keyboard with a broken 'e' key (btw, your 'I' key is about to break; you should replace it asap). But novelists don't have deadlines and when the novel is done, they usually don't take reader requests to change this or that part of the story. "The advantages and limitations", what works and what doesn't, "areas to avoid" are precisely the point of that kind of review.

teh_klev 10y ago
> But novelists don't have deadlines and when the novel is done I hate to "well actually" you :) , but a great number of authors have contracts that demand one or two novels a year over a fixed period of time. I know Iain Banks did with his publisher, he mentioned it at a one of his readings of a new but yet unpublished novel I was lucky to attend back in 2007'ish. > they usually don't take reader requests to change this or that part of the story. Even well known authors are reigned in by their editors and proof readers, and sometimes things have to be changed.
placebo 10y ago
> (btw, your 'I' key is about to break; you should replace it asap). haha - touché, point taken :-) Deadlines seem like a great excuse for compromising quality. Sure, life is complicated, the boss is demanding, the mortgage has to be paid, the children need to be supported etc. etc. but compromising quality and enthusiasm (they usually are correlated) because of the "terror" of a deadline will just leave you at the mercy of the next "terror", only this time you'll even have even less enthusiasm to fix the spaghetti. Doesn't sound like an enjoyable existence. Of course, very few people have the privilege of never having to compromise, but it's never black or white and there are many more degrees of freedom to choose the path with more quality than are implied. >"The advantages and limitations", what works and what doesn't, "areas to avoid" are precisely the point of that kind of review. The "area to avoid" in the review is Node.js and considering that large and impressive projects have been written in it, it seems that this is another case of throwing the baby out with the bathwater.

AhmadH 10y ago

It's more like hundreds of thousands of writing teams from different cultures and levels of experience sprung up to write collaborative epics in Latin because it had suddenly become cool to do so while bringing the language to the modern world by inventing a new vocabulary and arguing on the correct pronunciation of everything.