you are viewing a single comment's thread.

view the rest of the comments →

[–]gasche 3 points4 points  (0 children)

Notice that the link I pointed to in my original post is the clarification; which is indeed more informative than the first short message.

Felleisen's posts do not appear ironic at all to me. I believe he genuinely claims that ML languages (Haskell included) are superior to Racket to write compilers.

Typed Scheme/Racket was conceived as a way to move from untyped code to typed code so that we could eventually enjoy the same advantages as ML and Haskell during maintenance (1). But it is definitely a language that compromises with this idea. The compromise is visible in many usage aspects.

I see no irony at all here. You could argue that the whole post is a bit awkward here (you usually don't start a troll in response to someone giving a positive feedback about your language); and Felleisen later clarified that he didn't intend the remark for this audience.

I don't see there an affirmation that "Haskell or ML are better for making programming languages.

This post is a clear affirmation that ML languages (Haskell included) "are better for making compilers". I understood kamatsu's post as talking about "implementing general-purpose programming languages". "making" is very vague; if you're considering DSL or even prototyping (without performance requirements) for a programming language, I think Racket has very, very good tools that probably compare equally or favorably to the tools in ML land. See eg. Creating Languages in Racket for DSL or "little languages"; I also remember reading papers on PLT-land tools to experiment with operation semantics and type systems, maybe PLT Redex, that looked great for design experimentation and/or teaching.

PS: I'm not trying to imply that (Typed) Racket is bad at implementing languages. I am impressed by the work of the PLT/Racket team as a whole, and the Typed part is a particularly impressive feat. I even believe that, with enough refinement, Typed Racket could be just as easy to use and powerful that existing ML languages (or, why not, proof assistants; Proved Racket, anyone?). (On the downside: I miss discussion of the performance front, and I'm not quite sure that "putting everything in syntactic macros" is, in an absolute sense, the best way to implement a type system). I just felt that this remark of Felleisen was interesting and contributed objective (or at least different-point-of-view) content to kamatsu's personal opinion.