5 ms·

The article recognizes that interop and backwards compatibility with existing systems is important for adoption and it does not try to impose a new clean room r

The article recognizes that interop and backwards compatibility with existing systems is important for adoption and it does not try to impose a new clean room replacement. This is IMHO a good strategy that has proven itself in other contexts. For example Kotlin/Clojure/Scala all started out focusing on interop with the base Java/JVM technology. They provide a new layer of modern language features that is still compatible with all the existing code without forcing a rewrite. Over time these new languages get adopted, some older libraries get a modern equivalent and that helps these languages to branch out into other areas: e.g. Kotlin Native, multiplatform and ClojureScript. A similar thing can be seen with Typescript. It started as a type layer on top of JavaScript, making it easy to interop with old JS code and over time lots of pure Typescript library equivalents have popped up. Now that the Typescript ecosystem is flourishing we see technology like Deno that slowly moves Typescript away from its JS base. For a post-POSIX shell to be adopted widely I think it will need to use a similar strategy. Edit: re-reading my own comment, I might have just advocated for an Embrace, Extend, Extinguish strategy.

pjmlp 5y ago
That only seems to work for a short period of time, eventually the platform adopts the most interesting features of the candidates to replacement, and they fade away while the large majority of platform users keeps coding away on the language used to write the platform.
- pxc 5y ago
  That's bad news for some new language authors, but not necessarily for programmers, right? These languages still succeed in pushing the norms language design forward, and that's pretty great for the users of programming languages.
  - pjmlp 5y ago
    True, the only issue is that dreams of taking over the world need to be refrained. The only platforms where new languages kind of took over, the move was forced by the company that owns the platform. However you are right, in every case even the system language for the platform got better.
pxc 5y ago
This is the kind of strategy that some next-gen shells take up, most notably Oil Shell. For my part, I think the old syntax sucks and has got to go, and if your new shell's language is good enough, people will want to deploy it where they might use it, just like any other scripting language.
- chubot 5y ago
  Yes I'm glad that message is getting through. Although I also want to add the other perspective: Oil from a clean slate. I'm working on "A Tour of Oil" doc that will show that Oil is not encumbered by much legacy at all. Even though it evolved from bash/OSH, and is in fact the same interpreter parameterized by some global options, it is a nice clean new language :) It's surprising how much language evolution was enabled by "shopt" options, principled parsing, and algebraic data types!
  - pxc 5y ago
    The new doc sounds exciting! I'm looking forward to giving it a read. I think the approach Oil takes is pretty cool. It just seems like a lot of work, and I'm much more interested in Oil than in OSH. I can see how it might make Oil attractive to Linux distros for choosing as a system shell, though, since it means they could just ship the one binary, and then offer experienced POSIX shell users OSH as an escape hatch while still presenting Oil as the preferred way to write scripts. It does also partially spare users from the problems Fish users face where CLI tools ship with scripts to initialize a bunch of env vars, and now suddenly you either need them to ship a Fish script, translate it yourself, or do some hacking where you run a BASH shell and mirror its env var changes. So I can see some benefits for sure, but to me those are less exciting than the new stuff. :D

pjmlp 5y ago

That only seems to work for a short period of time, eventually the platform adopts the most interesting features of the candidates to replacement, and they fade away while the large majority of platform users keeps coding away on the language used to write the platform.

pxc 5y ago
That's bad news for some new language authors, but not necessarily for programmers, right? These languages still succeed in pushing the norms language design forward, and that's pretty great for the users of programming languages.
- pjmlp 5y ago
  True, the only issue is that dreams of taking over the world need to be refrained. The only platforms where new languages kind of took over, the move was forced by the company that owns the platform. However you are right, in every case even the system language for the platform got better.

pxc 5y ago

This is the kind of strategy that some next-gen shells take up, most notably Oil Shell. For my part, I think the old syntax sucks and has got to go, and if your new shell's language is good enough, people will want to deploy it where they might use it, just like any other scripting language.

chubot 5y ago
Yes I'm glad that message is getting through. Although I also want to add the other perspective: Oil from a clean slate. I'm working on "A Tour of Oil" doc that will show that Oil is not encumbered by much legacy at all. Even though it evolved from bash/OSH, and is in fact the same interpreter parameterized by some global options, it is a nice clean new language :) It's surprising how much language evolution was enabled by "shopt" options, principled parsing, and algebraic data types!
- pxc 5y ago
  The new doc sounds exciting! I'm looking forward to giving it a read. I think the approach Oil takes is pretty cool. It just seems like a lot of work, and I'm much more interested in Oil than in OSH. I can see how it might make Oil attractive to Linux distros for choosing as a system shell, though, since it means they could just ship the one binary, and then offer experienced POSIX shell users OSH as an escape hatch while still presenting Oil as the preferred way to write scripts. It does also partially spare users from the problems Fish users face where CLI tools ship with scripts to initialize a bunch of env vars, and now suddenly you either need them to ship a Fish script, translate it yourself, or do some hacking where you run a BASH shell and mirror its env var changes. So I can see some benefits for sure, but to me those are less exciting than the new stuff. :D