4 ms·

And now, he'll make a whole different set of good and bad choices to potentially regret later.

by lghh 6y ago

gen220 6y ago
such is the curse of having the audacity to develop software :)
- lghh 6y ago
  Not necessarily. I prefer trying to improve what we have verses making a new thing every time we have a relatively minor disagreement, even if that disagreement is with our past self. EDIT: I'd like to add that clearly he is able to spend his time as he wishes.
  - gen220 6y ago
    I generally agree. Although, some of these are pretty "opinionated" breaking changes (promises all the way down, package manager changes). It would be hard to convince the whole node community that these upgrades are worth the risk forking in a python 2/3-esque way. Forcing TS is a change node could adopt in the next major version if everybody agreed, but the node community might be too big and diverse at this point, to make such an opinionated switch.
  - uryga 6y ago
    afaik modifying node doesn't make sense here – it'd be so incompatible that it'd effectively be "a new thing" anyway
- nkozyra 6y ago
  Sure, but there's a tendency to start over when the development gets hard to maintain or support instead of just fixing the mistakes. This really feels like the fundamental response in the js world and why we see much churn.
  - polishdude20 6y ago
    But isn't this an inherent problem in software development that is really super hard to not do? Let's say you are deciding how to make node when it was first conceived and how it would work. You've made decisions about how the thing fundamentally works. Then after using it and developing for it many years and after having millions of critical software projects dependant on it, you slowly start to see the shortcomings of the software that you could only see at this stage. The problem is that these shortcomings come from a false assumption or solution to the fundamental problems you had to solve when making node. Now, the only way to fix node is to change how it fundamentally works. But if you do that, millions of users' code will break. So, do you require everyone now to fix their broken code and potentially piss everyone off? Or do you give people a choice? Stick with node if you aren't noticing any of those fundamental problems you found, or switch to the new thing on your own time? It's a question of how to affect the least number of people in the least negative way.
    - nkozyra 6y ago
      I think the answer is a break in backwards compatibility on a major version release. People in JS/frontend world are willing to drop the world for the latest new thing, I see this as less jarring than, say, Python 2 -> Python 3.
      - alessioalex 6y ago
        > People in JS/frontend world are willing to drop the world for the latest new thing Except there aren't any breaking changes in JavaScript, are there? Even in Node if anything is deprecated that is done over time in many years.
      - haack 6y ago
        I find it amusing that you use the example of Python 2 -> Python 3, a breaking change in a widely used language, that has famously been very difficult and long for organisations to deal with. Compare that with javascript which has never had a breaking change. On top of that Typescript is a backwards compatible superset of javascript. More to the point, Ryan has a humble explanation of what regrets he has about Node.js[1], why they exist and in some cases why there isn't an easy fix. The point that I assume you're making, that sometimes it is better to spend significant energy to fix something, rather than throwing the baby out with the bath water, is a good one. However I'd suggest this is not one of those cases. [1] https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA
pulposus 6y ago
Good that it’s called Deno, not Done!

And now, he'll make a whole different set of good and bad choices to potentially regret later.

by lghh 6y ago

And now, he'll make a whole different set of good and bad choices to potentially regret later.

gen220 6y ago

such is the curse of having the audacity to develop software :)

lghh 6y ago
Not necessarily. I prefer trying to improve what we have verses making a new thing every time we have a relatively minor disagreement, even if that disagreement is with our past self. EDIT: I'd like to add that clearly he is able to spend his time as he wishes.
- gen220 6y ago
  I generally agree. Although, some of these are pretty "opinionated" breaking changes (promises all the way down, package manager changes). It would be hard to convince the whole node community that these upgrades are worth the risk forking in a python 2/3-esque way. Forcing TS is a change node could adopt in the next major version if everybody agreed, but the node community might be too big and diverse at this point, to make such an opinionated switch.
- uryga 6y ago
  afaik modifying node doesn't make sense here – it'd be so incompatible that it'd effectively be "a new thing" anyway
nkozyra 6y ago
Sure, but there's a tendency to start over when the development gets hard to maintain or support instead of just fixing the mistakes. This really feels like the fundamental response in the js world and why we see much churn.
- polishdude20 6y ago
  But isn't this an inherent problem in software development that is really super hard to not do? Let's say you are deciding how to make node when it was first conceived and how it would work. You've made decisions about how the thing fundamentally works. Then after using it and developing for it many years and after having millions of critical software projects dependant on it, you slowly start to see the shortcomings of the software that you could only see at this stage. The problem is that these shortcomings come from a false assumption or solution to the fundamental problems you had to solve when making node. Now, the only way to fix node is to change how it fundamentally works. But if you do that, millions of users' code will break. So, do you require everyone now to fix their broken code and potentially piss everyone off? Or do you give people a choice? Stick with node if you aren't noticing any of those fundamental problems you found, or switch to the new thing on your own time? It's a question of how to affect the least number of people in the least negative way.
  - nkozyra 6y ago
    I think the answer is a break in backwards compatibility on a major version release. People in JS/frontend world are willing to drop the world for the latest new thing, I see this as less jarring than, say, Python 2 -> Python 3.
    - alessioalex 6y ago
      > People in JS/frontend world are willing to drop the world for the latest new thing Except there aren't any breaking changes in JavaScript, are there? Even in Node if anything is deprecated that is done over time in many years.
    - haack 6y ago
      I find it amusing that you use the example of Python 2 -> Python 3, a breaking change in a widely used language, that has famously been very difficult and long for organisations to deal with. Compare that with javascript which has never had a breaking change. On top of that Typescript is a backwards compatible superset of javascript. More to the point, Ryan has a humble explanation of what regrets he has about Node.js[1], why they exist and in some cases why there isn't an easy fix. The point that I assume you're making, that sometimes it is better to spend significant energy to fix something, rather than throwing the baby out with the bath water, is a good one. However I'd suggest this is not one of those cases. [1] https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA

pulposus 6y ago

Good that it’s called Deno, not Done!