4 ms·

I am not sure one can compare some JS framework with a language that was already 8 years old when JS as a language appeared. By the time JS was invented, there

by jlg23 6y ago

I am not sure one can compare some JS framework with a language that was already 8 years old when JS as a language appeared. By the time JS was invented, there was already legacy perl code in production that needed to be maintained.

tomphoolery 6y ago
I don't see how that's relevant to software project management. The ways we release software and plan out roadmaps don't really have much to do with what language or framework the software was made in. Just because Ember is "some JS framework" doesn't mean it has no good ideas.
- richard_todd 6y ago
  To me it's really not about whether it's a good idea or not. What works for an 8-year-old project that has always done it that way, may not work for a 33-year-old project which has never done it that way. The latest perl will run a huge chunk of the perl 1.0 test suite unmodified. That's a long history of backwards compatibility. This sudden change in focus and project-management may really backfire on them.
- jlg23 6y ago
  > Just because Ember is "some JS framework" doesn't mean it has no good ideas. No, but time-scales matter. A good idea in a notoriously short lived ecosystem is not necessarily transferable to an environment in which one has to maintain 20 or 30 year old, mostly write-only code.
hibbelig 6y ago
I don't quite understand this point. Perl has a major version, Perl 5. They want to offer a new major version, Perl 7, now. If Ember has already release a couple of new major versions, then why not learn from it? Maybe the Ember approach doesn't fit Perl, but without taking a look we won't know. Also, based on the GP, it seems like Perl is planning something similar to what Ember has been doing: They are planning for Perl 7 to offer no new features, just change behavior. Then users can take their Perl 5 software and try it out with Perl 7 to see how much work it is to upgrade. Or they comb the source code to look for constructs that are deprecated.

by jlg23 6y ago

tomphoolery 6y ago

I don't see how that's relevant to software project management. The ways we release software and plan out roadmaps don't really have much to do with what language or framework the software was made in. Just because Ember is "some JS framework" doesn't mean it has no good ideas.

richard_todd 6y ago
To me it's really not about whether it's a good idea or not. What works for an 8-year-old project that has always done it that way, may not work for a 33-year-old project which has never done it that way. The latest perl will run a huge chunk of the perl 1.0 test suite unmodified. That's a long history of backwards compatibility. This sudden change in focus and project-management may really backfire on them.
jlg23 6y ago
> Just because Ember is "some JS framework" doesn't mean it has no good ideas. No, but time-scales matter. A good idea in a notoriously short lived ecosystem is not necessarily transferable to an environment in which one has to maintain 20 or 30 year old, mostly write-only code.

hibbelig 6y ago

I don't quite understand this point. Perl has a major version, Perl 5. They want to offer a new major version, Perl 7, now. If Ember has already release a couple of new major versions, then why not learn from it? Maybe the Ember approach doesn't fit Perl, but without taking a look we won't know. Also, based on the GP, it seems like Perl is planning something similar to what Ember has been doing: They are planning for Perl 7 to offer no new features, just change behavior. Then users can take their Perl 5 software and try it out with Perl 7 to see how much work it is to upgrade. Or they comb the source code to look for constructs that are deprecated.