4 ms·

Racket (and PLT Scheme before it) has always been a bunch of languages, keeping a few different syntaxes and semantics around isn't anything new. I don't get wh

Racket (and PLT Scheme before it) has always been a bunch of languages, keeping a few different syntaxes and semantics around isn't anything new. I don't get why having another take on the surface syntax should cause all that much anxiety.

kamaal 7y ago
Because you are not exactly running Rhombus as a side toy language, but as a successor to Racket. This requires Rhombus to eventually replace Racket. Anything less than this and it makes Rhombus a non-successor to Racket. While at the same time much needed resources to make Racket win, will go to making Rhombus happen. Even if Rhombus comes along, it won't have any of the current Racket goodness to begin with. Rhombus will take years to just exist. Meanwhile precious resources for improving Racket to a better Racket over the years will be taken by Rhombus. Net result is a stagnated Racket, and a non-attractive Rhombus. Plus C based languages have their winners already. Racket is a kind of a winner in the Lisp family. With Clojure it makes the only other choice. Now if you change the syntax, you are going after users who don't really care what you have to offer, at the same time, you are taking away what your existing users like.
- manthideaal 7y ago
  It seems you learned from the decline of Perl, so you have the experience of a warrior. But Rhombus represents the hope of a better future for Racket, so another step in this fight should be to embrace the future and learn from the past, I don't know how.
- dTal 7y ago
  Racket is not like other languages. Racket is a language with first class support for building languages on top of it. And so no, Rhombus does not need to be a "successor" to Racket. It does not need to "replace" Racket. It will have all the current Racket goodness to begin with, because all of its semantics will come from Racket - they will be the same language. Nor will it steal valuable developer attention - a bug fixed in Rhombus is a bug fixed in Racket, anywhere except the syntax parser. They will share all core libraries. The whole point of Racket is that #langs are mutually compatible. And the stress test of using Racket in earnest for what it is actually designed for will make Racket better, not worse. Consider PyonR [0]. This is a similar and yet much more ambitious goal than Rhombus - Python as a Racket #lang, with 100% compatibility with Racket and Python including external modules. And yet, it's a one-man project, written as a thesis and now pretty much abandoned. Writing Rhombus, a mere surface syntax for Racket, should be much easier. The hard part isn't writing it, it's deciding what it should be. The Racket team are the only ones that I can see who are taking all the "write your own DSL" Lisp hype and actually trying to apply it in a structured way. [0] https://github.com/pedropramos/PyonR https://github.com/pedropramos/PyonR
  - logicchains 7y ago
    Would you say Rhombus is to Racket as ReasonML (https://reasonml.github.io/ https://reasonml.github.io/) is to OCaml?
    - wtetzner 7y ago
      I think it's a reasonable analogy, but I would say ReasonML is actually more than Rhombus in a sense. Rhombus doesn't require any external tooling, because Racket has support for implementing #lang's built in to it.
  - kamaal 7y ago
    Well PyonR is not a replacement for Racket. It's something totally a different project altogether. Rhombus is supposed to replace Racket. We could have PerlRacket or AwkRacket or RubyRacket and none of it should effect Racket, because you are using Racket as a language to build things, not exactly using RubyRacket as a replacement for Racket. This is how it rings to my ear. Racket as is, is in some way frozen when it comes to features and big changes. Rhombus is where the next set of awesomeness will happen. Lispers who happen to be core users of Racket have no use at the time for non-existent Rhombus, and its not Lispy so their whole use case ends here. Racket won't be continued to developed in the same breath as Rhombus, so Racket is also dead here. C based language devs have a lot of good stuff already, so they don't need Rhombus either. Eventually this could lead to the exact situation Perl was in the 2000s. The core development was frozen for 5+ years. The language usability just fell year over year. Perl 6 took forever to even start with the implementations. Pugs, then Neitza, then Rakudo. Eventually they came to a point, where they announced Perl 5 development would just run parallel as a separate project compared to Perl 6. By then a lot of dev mind share was lost to Python/Java. Now neither Perl 5 nor Perl 6 have significant mind share. Perl 5 certainly has lost a lot of its users. Also in general trying to be everything to everybody is a bad idea in general. Ask Parrot VM people. It doesn't work the way you expect. You won't solve anyone's specific problem, and it takes forever to get done.
    - wtetzner 7y ago
      > This is how it rings to my ear. Racket as is, is in some way frozen when it comes to features and big changes. Rhombus is where the next set of awesomeness will happen. You still seem to be misunderstanding how Racket and #lang's work. Rhombus and Racket will be the same language, but with different parsers. Big features of Rhombus will be added by adding those features to Racket. Languages in Racket are not developed independently of each other, they all share the underlying language machinery.

kamaal 7y ago

Because you are not exactly running Rhombus as a side toy language, but as a successor to Racket. This requires Rhombus to eventually replace Racket. Anything less than this and it makes Rhombus a non-successor to Racket. While at the same time much needed resources to make Racket win, will go to making Rhombus happen. Even if Rhombus comes along, it won't have any of the current Racket goodness to begin with. Rhombus will take years to just exist. Meanwhile precious resources for improving Racket to a better Racket over the years will be taken by Rhombus. Net result is a stagnated Racket, and a non-attractive Rhombus. Plus C based languages have their winners already. Racket is a kind of a winner in the Lisp family. With Clojure it makes the only other choice. Now if you change the syntax, you are going after users who don't really care what you have to offer, at the same time, you are taking away what your existing users like.

manthideaal 7y ago
It seems you learned from the decline of Perl, so you have the experience of a warrior. But Rhombus represents the hope of a better future for Racket, so another step in this fight should be to embrace the future and learn from the past, I don't know how.
dTal 7y ago
Racket is not like other languages. Racket is a language with first class support for building languages on top of it. And so no, Rhombus does not need to be a "successor" to Racket. It does not need to "replace" Racket. It will have all the current Racket goodness to begin with, because all of its semantics will come from Racket - they will be the same language. Nor will it steal valuable developer attention - a bug fixed in Rhombus is a bug fixed in Racket, anywhere except the syntax parser. They will share all core libraries. The whole point of Racket is that #langs are mutually compatible. And the stress test of using Racket in earnest for what it is actually designed for will make Racket better, not worse. Consider PyonR [0]. This is a similar and yet much more ambitious goal than Rhombus - Python as a Racket #lang, with 100% compatibility with Racket and Python including external modules. And yet, it's a one-man project, written as a thesis and now pretty much abandoned. Writing Rhombus, a mere surface syntax for Racket, should be much easier. The hard part isn't writing it, it's deciding what it should be. The Racket team are the only ones that I can see who are taking all the "write your own DSL" Lisp hype and actually trying to apply it in a structured way. [0] https://github.com/pedropramos/PyonR https://github.com/pedropramos/PyonR
- logicchains 7y ago
  Would you say Rhombus is to Racket as ReasonML (https://reasonml.github.io/ https://reasonml.github.io/) is to OCaml?
  - wtetzner 7y ago
    I think it's a reasonable analogy, but I would say ReasonML is actually more than Rhombus in a sense. Rhombus doesn't require any external tooling, because Racket has support for implementing #lang's built in to it.
- kamaal 7y ago
  Well PyonR is not a replacement for Racket. It's something totally a different project altogether. Rhombus is supposed to replace Racket. We could have PerlRacket or AwkRacket or RubyRacket and none of it should effect Racket, because you are using Racket as a language to build things, not exactly using RubyRacket as a replacement for Racket. This is how it rings to my ear. Racket as is, is in some way frozen when it comes to features and big changes. Rhombus is where the next set of awesomeness will happen. Lispers who happen to be core users of Racket have no use at the time for non-existent Rhombus, and its not Lispy so their whole use case ends here. Racket won't be continued to developed in the same breath as Rhombus, so Racket is also dead here. C based language devs have a lot of good stuff already, so they don't need Rhombus either. Eventually this could lead to the exact situation Perl was in the 2000s. The core development was frozen for 5+ years. The language usability just fell year over year. Perl 6 took forever to even start with the implementations. Pugs, then Neitza, then Rakudo. Eventually they came to a point, where they announced Perl 5 development would just run parallel as a separate project compared to Perl 6. By then a lot of dev mind share was lost to Python/Java. Now neither Perl 5 nor Perl 6 have significant mind share. Perl 5 certainly has lost a lot of its users. Also in general trying to be everything to everybody is a bad idea in general. Ask Parrot VM people. It doesn't work the way you expect. You won't solve anyone's specific problem, and it takes forever to get done.
  - wtetzner 7y ago
    > This is how it rings to my ear. Racket as is, is in some way frozen when it comes to features and big changes. Rhombus is where the next set of awesomeness will happen. You still seem to be misunderstanding how Racket and #lang's work. Rhombus and Racket will be the same language, but with different parsers. Big features of Rhombus will be added by adding those features to Racket. Languages in Racket are not developed independently of each other, they all share the underlying language machinery.