8 ms·

Totally not against solid critique. But it becomes a culture, a signal of intellectual superiority. Which is too easy. You can be, and I have been highly produc

Totally not against solid critique. But it becomes a culture, a signal of intellectual superiority. Which is too easy. You can be, and I have been highly productive in plain ole JavaScript. Same with Java, Same with Ruby, same with Python. Are the language debates irrelevant, absolutely not. But “Node.js is one of the worst things to happen to the software industry” Hey if it is then I fully submit that I'm just some stupid fool that should rage quit the internet and give up because.... Wait no that would be stupid.

richmarr 10y ago
Completely agree. I'd actually like to list the worst things (IMO) to happen to the software industry. (1) Marketing of computers at boys resulting in a generation of girls being excluded. (2) Software patents suffocating innovators. (3) DMCA & international equivalents (4) Daylight savings time. (5) A generation of programmers being taught that anything other than "OOP best practice" was heresy I'm sure there are plenty I'm missing. Does one particular programming environment deserve to be listed with that stuff? Personally I think it's a pretty ludicrous suggestion.
- paublyrne 10y ago
  Daylight savings time? What's the connection to the software industry?
  - ehnto 10y ago
    It has to be accounted for in time and date calculations and that poses a new set of challenges. It is also just one of many geographical, cultural, and temporal challenges that need to be addressed by any business system relying on accurate international dates and timing.
  - TeMPOraL 10y ago
    DST adds complexity to the already ugly mess timezones are. Timezones are literally driven by real-world politics, and they can be as messy as only humans can invent. See also: http://naggum.no/lugm-time.html http://naggum.no/lugm-time.html
  - typicalbender 10y ago
    Dealing with time-zones and daylight savings time (which countries have it and which don't) can be a very challenge and messy problem that is really easy to get wrong. Heres a pretty good video from computerphile on the subject https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY
    - wangchow 10y ago
      Spring forward, fall back!
      - zaphar 10y ago
        But not every country or even every part of every country...
    - collyw 10y ago
      Won't most mainstream languages have a built in library for that sort of thing these days?
      - dcornu 10y ago
        They do. The problem is that the rules of DST change over time (sometimes at the very last minute https://github.com/eggert/tz/commit/868f3528a9fd60491439ce457f6d68dc12ef425b https://github.com/eggert/tz/commit/868f3528a9fd60491439ce45...) and can lead to all sorts of date math bugs when comparing timestamps across timezones.
      - gregmac 10y ago
        Most do, but the problem is less about the library and more about understanding how to use it. For example, if you want an event to happen in 12 hours, and it happens to be 9pm the day before daylight savings time, do you schedule it using the timezone-aware API (so it happens at 9am, which is actually 13 hours away) or 8am (which is 12 hours, but non intuitive)? What about the event that's supposed to happen every 12 hours in perpetuity? What happens when the user/device is mobile, and crossing timezones? Which times do you use? What happens when you're scheduling something far in advance, and then the timezone definition itself changes (as happens a few times a year) between the time you scheduled the event, and the time something actually is supposed to happen? Does the event adjust for the new definition or follow original time? Luckily for many problem domains, the details around this don't matter too much, but this is just the tip of the iceberg with timezone challenges.
  - manarth 10y ago
    As well as adding to the already-confusing mess of timezones and date calculations, daylight savings can change frequently, and sometimes at very short notice. This year, Azerbaijan decided to cancel DST, and agreed the cancellation just 10 days before the scheduled clock change [1]. Egypt cancelled DST with even less notice - just 3 days! [2] [1] http://www.timeanddate.com/news/time/no-dst-azerbaijan.html http://www.timeanddate.com/news/time/no-dst-azerbaijan.html [2] https://www.washingtonpost.com/news/worldviews/wp/2016/07/06/egypt-cancelled-daylight-savings-time-three-days-before-it-was-due-to-start/ https://www.washingtonpost.com/news/worldviews/wp/2016/07/06...
  - PeterisP 10y ago
    Time and scheduling are a bit tricky, to say the least. It would help if there were some reasonable assumptions that you can make - for example, a day containing 24 hours. DST makes such assumptions not true.
  - sanderjd 10y ago
    Wow! You haven't run into DST issues in software yet?! How I envy you! If you work in the industry, you have a lot of fun unintuitive but sort of neat bugs to look forward to!
  - OldSchoolJohnny 10y ago
    Hah! You've had a very lucky programming career indeed if you can ask that question in all seriousness.
- michaelcampbell 10y ago
  null?
  - christophilus 10y ago
    Yes. Null belongs on any list of things the software industry got wrong.
    - HeavyStorm 10y ago
      Should be the first one.
- nulagrithom 10y ago
  Oh man, "OOP as gospel"... If there's one thing that I like about Node.js, it's that it made me actually think about when I should take an object oriented approach vs a functional approach.
- elijahparker 10y ago
  +1 daylight savings time -- it's behind countless bugs. You can add weird and split time zones to that, too
- DashRattlesnake 10y ago
  > (4) Daylight savings time. It's always annoys me whenever programmers complain about time zones and daylight savings time, because of the difficulty and inconvenience handling them in software. It's getting things backwards. Software should model the (human) world* ; the human world shouldn't be changed to model what's most convenient for software. * That doesn't mean you can't have a simpler model that you translate to/from.
  - richmarr 10y ago
    > Software should model the (human) world* ; the human world shouldn't be changed to model what's most convenient for software. Agreed, but my point is that daylight savings time is a huge human-world complexity that brings a marginal boost to some sectors. There are a ton of negative effects and I question whether there's a net benefit, even before all the software complexity needed to support it. https://en.wikipedia.org/wiki/Daylight_saving_time#Dispute_over_benefits_and_drawbacks https://en.wikipedia.org/wiki/Daylight_saving_time#Dispute_o...
devishard 10y ago
Instead of responding to the fact that JavaScript: 1. Has no adequate threading model. 2. Has no reasonable type system. 3. Has better alternatives on the server side. ...you're making it personal, and about the people. Look at your post; you're just accusing the critics of Node of feeling "intellectually superior". That's just an ad hominem attack. And you think that critics want you to rage quit the internet and give up? No, that's not what critics of Node want. Or at least, that's not what I want. What I want is for people to either acknowledge the problems with Node and fix them (unlikely), or start using better alternatives on the server side, and start investing more in WebAssembly and langauges targeting WebAssembly, so we don't have to use JavaScript any more. I want this because as long as Node/JavaScript are around, I have to either deal with those horrible tools, or not take those jobs. This isn't about feeling superior, it's about improving my life by using tools that aren't godawful.
- jamescostian 10y ago
  1. There are two built-in solutions to this (as well as a slew of other solutions in modules), the cluster module and the child process module: https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html and https://nodejs.org/api/child_process.html https://nodejs.org/api/child_process.html 2. JS's duck typing is thought to be a "feature" to some and a "bug" to others, so if you think it's a bug, use TypeScript or Flow. They'll give you "reasonable type system[s]" 3. Nice opinion
  - vonmoltke 10y ago
    > 1. There are two built-in solutions to this (as well as a slew of other solutions in modules), the cluster module and the child process module: https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html and https://nodejs.org/api/child_process.html https://nodejs.org/api/child_process.html Process spawning and threading are two different but related mechanisms. The former is much more expensive and hard to use with optimization techniques like pooling. It also forces message passing for IPC rather than shared memory. > 2. JS's duck typing is thought to be a "feature" to some and a "bug" to others, so if you think it's a bug, use TypeScript or Flow. They'll give you "reasonable type system[s]" Nothing that transcompiles into JavaScript can fix JavaScript's lack of a native integer.

richmarr 10y ago

Completely agree. I'd actually like to list the worst things (IMO) to happen to the software industry. (1) Marketing of computers at boys resulting in a generation of girls being excluded. (2) Software patents suffocating innovators. (3) DMCA & international equivalents (4) Daylight savings time. (5) A generation of programmers being taught that anything other than "OOP best practice" was heresy I'm sure there are plenty I'm missing. Does one particular programming environment deserve to be listed with that stuff? Personally I think it's a pretty ludicrous suggestion.

paublyrne 10y ago
Daylight savings time? What's the connection to the software industry?
- ehnto 10y ago
  It has to be accounted for in time and date calculations and that poses a new set of challenges. It is also just one of many geographical, cultural, and temporal challenges that need to be addressed by any business system relying on accurate international dates and timing.
- TeMPOraL 10y ago
  DST adds complexity to the already ugly mess timezones are. Timezones are literally driven by real-world politics, and they can be as messy as only humans can invent. See also: http://naggum.no/lugm-time.html http://naggum.no/lugm-time.html
- typicalbender 10y ago
  Dealing with time-zones and daylight savings time (which countries have it and which don't) can be a very challenge and messy problem that is really easy to get wrong. Heres a pretty good video from computerphile on the subject https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY
  - wangchow 10y ago
    Spring forward, fall back!
    - zaphar 10y ago
      But not every country or even every part of every country...
  - collyw 10y ago
    Won't most mainstream languages have a built in library for that sort of thing these days?
    - dcornu 10y ago
      They do. The problem is that the rules of DST change over time (sometimes at the very last minute https://github.com/eggert/tz/commit/868f3528a9fd60491439ce457f6d68dc12ef425b https://github.com/eggert/tz/commit/868f3528a9fd60491439ce45...) and can lead to all sorts of date math bugs when comparing timestamps across timezones.
    - gregmac 10y ago
      Most do, but the problem is less about the library and more about understanding how to use it. For example, if you want an event to happen in 12 hours, and it happens to be 9pm the day before daylight savings time, do you schedule it using the timezone-aware API (so it happens at 9am, which is actually 13 hours away) or 8am (which is 12 hours, but non intuitive)? What about the event that's supposed to happen every 12 hours in perpetuity? What happens when the user/device is mobile, and crossing timezones? Which times do you use? What happens when you're scheduling something far in advance, and then the timezone definition itself changes (as happens a few times a year) between the time you scheduled the event, and the time something actually is supposed to happen? Does the event adjust for the new definition or follow original time? Luckily for many problem domains, the details around this don't matter too much, but this is just the tip of the iceberg with timezone challenges.
- manarth 10y ago
  As well as adding to the already-confusing mess of timezones and date calculations, daylight savings can change frequently, and sometimes at very short notice. This year, Azerbaijan decided to cancel DST, and agreed the cancellation just 10 days before the scheduled clock change [1]. Egypt cancelled DST with even less notice - just 3 days! [2] [1] http://www.timeanddate.com/news/time/no-dst-azerbaijan.html http://www.timeanddate.com/news/time/no-dst-azerbaijan.html [2] https://www.washingtonpost.com/news/worldviews/wp/2016/07/06/egypt-cancelled-daylight-savings-time-three-days-before-it-was-due-to-start/ https://www.washingtonpost.com/news/worldviews/wp/2016/07/06...
- PeterisP 10y ago
  Time and scheduling are a bit tricky, to say the least. It would help if there were some reasonable assumptions that you can make - for example, a day containing 24 hours. DST makes such assumptions not true.
- sanderjd 10y ago
  Wow! You haven't run into DST issues in software yet?! How I envy you! If you work in the industry, you have a lot of fun unintuitive but sort of neat bugs to look forward to!
- OldSchoolJohnny 10y ago
  Hah! You've had a very lucky programming career indeed if you can ask that question in all seriousness.
michaelcampbell 10y ago
null?
- christophilus 10y ago
  Yes. Null belongs on any list of things the software industry got wrong.
  - HeavyStorm 10y ago
    Should be the first one.
nulagrithom 10y ago
Oh man, "OOP as gospel"... If there's one thing that I like about Node.js, it's that it made me actually think about when I should take an object oriented approach vs a functional approach.
elijahparker 10y ago
+1 daylight savings time -- it's behind countless bugs. You can add weird and split time zones to that, too
DashRattlesnake 10y ago
> (4) Daylight savings time. It's always annoys me whenever programmers complain about time zones and daylight savings time, because of the difficulty and inconvenience handling them in software. It's getting things backwards. Software should model the (human) world* ; the human world shouldn't be changed to model what's most convenient for software. * That doesn't mean you can't have a simpler model that you translate to/from.
- richmarr 10y ago
  > Software should model the (human) world* ; the human world shouldn't be changed to model what's most convenient for software. Agreed, but my point is that daylight savings time is a huge human-world complexity that brings a marginal boost to some sectors. There are a ton of negative effects and I question whether there's a net benefit, even before all the software complexity needed to support it. https://en.wikipedia.org/wiki/Daylight_saving_time#Dispute_over_benefits_and_drawbacks https://en.wikipedia.org/wiki/Daylight_saving_time#Dispute_o...

devishard 10y ago

Instead of responding to the fact that JavaScript: 1. Has no adequate threading model. 2. Has no reasonable type system. 3. Has better alternatives on the server side. ...you're making it personal, and about the people. Look at your post; you're just accusing the critics of Node of feeling "intellectually superior". That's just an ad hominem attack. And you think that critics want you to rage quit the internet and give up? No, that's not what critics of Node want. Or at least, that's not what I want. What I want is for people to either acknowledge the problems with Node and fix them (unlikely), or start using better alternatives on the server side, and start investing more in WebAssembly and langauges targeting WebAssembly, so we don't have to use JavaScript any more. I want this because as long as Node/JavaScript are around, I have to either deal with those horrible tools, or not take those jobs. This isn't about feeling superior, it's about improving my life by using tools that aren't godawful.

jamescostian 10y ago
1. There are two built-in solutions to this (as well as a slew of other solutions in modules), the cluster module and the child process module: https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html and https://nodejs.org/api/child_process.html https://nodejs.org/api/child_process.html 2. JS's duck typing is thought to be a "feature" to some and a "bug" to others, so if you think it's a bug, use TypeScript or Flow. They'll give you "reasonable type system[s]" 3. Nice opinion
- vonmoltke 10y ago
  > 1. There are two built-in solutions to this (as well as a slew of other solutions in modules), the cluster module and the child process module: https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html and https://nodejs.org/api/child_process.html https://nodejs.org/api/child_process.html Process spawning and threading are two different but related mechanisms. The former is much more expensive and hard to use with optimization techniques like pooling. It also forces message passing for IPC rather than shared memory. > 2. JS's duck typing is thought to be a "feature" to some and a "bug" to others, so if you think it's a bug, use TypeScript or Flow. They'll give you "reasonable type system[s]" Nothing that transcompiles into JavaScript can fix JavaScript's lack of a native integer.