On Wed, Jul 26, 2017 at 12:14 PM Florian Bösch <[email protected]> wrote:
> On Wed, Jul 26, 2017 at 9:00 PM, T.J. Crowder < > [email protected]> wrote: >> >> keeping it alive and healthy beyond its browser-limited existence. >> > > Many languages (including Python and Perl) concluded that at some point > things have to be "cleaned up". > You have not addressed my points about the difficulty of removing things on the Web. Citing Perl and Python implies you want opt-in versioning, which I had proposed for ES4 back in the day. before I wised up ;-). A couple of points: 1. Perl 5 vs. 6 and Python 2 vs. 3 are not great precedents. I think they are counterexamples even given the ability with Unix command line tools to be installed and used on single systems or in cloud settings without the huge coordination problem posed by the Web. Perl and Python have forked, and split their communities between versions. The Python rift may heal, but these forks have real and high costs. I know, we use Python at Brave in our build system. 2. Opt-in versioning on the Web is an anti-pattern, as discussed at length on es-discuss. The better way, dubbed 1JS, is to let old forms fall into disuse while carefully extending the language with new syntax and semantics that compose well with the existing surface language, using a kernel semantics approach. This is still TC39's settled conviction as best foot forward. The track record of languages that never cleaned up isn't... great. You > could consider things like RPG, Cobol, Fortran, etc. "alive" because > they're still used. But in any other sense of the word they aren't. > Those languages forked and some modernized (I remember Fortran 77). Those are all quite a bit older than JS. I would also suggest they are for the most part stunning successes. We've learned a lot from them. But the point of order here is whether JS can even be forked as Perl and Python have been. Another point to discuss is what you mean by "isn't... great." Aesthetics aside, keeping compatibility maximizes utility. There is risk of "painting into a corner", making conflicts in the kernel semantics or surface language over time, or just making a kitchen sink language. These are not _malum in se_ but costs to be traded off for benefits. If the aesthetic or Platonic ideal approach prevails, almost any successful language is not "alive" because it is messy. But that's false: C is still alive, C++ is quite alive, etc. I suggest being precise about costs vs. benefits and avoiding vague or counterfactual metaphorical judgments ("isn't... great", not "alive"). /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
