If poker was "about" chance you wouldn't see the same top players every year in the finals of every major competition. The chance aspect is why poker is so interesting. But in the long run (ie, 100 games played with the same players), a great poker player will beat an average one 95% of the time.
I thought racket was the holy grail due to the macro system but my real metamorphosis came after learning Haskell. I realize now that my previous preference for Clojure was because I was stuck in prototyping mode.
Once you truly understand your problem domain then types trump macros.
So while I owe a huge debt to Clojure/Racket for rescuing me from my java nightmare, and introducing me to other approaches like Erlang, it was Haskell/Purescript that matured me the most as a programmer.
It was so worth the (considerable) effort, because it has generalized the very nature of computation in a way that just never happened for me in all my years with lisp.
“Types trump macros” is a nice way to put it. Macros are amazing for creating new languages, but a good type system with strong case matching and sum types is just incredible to work with.
I was in the process of creating my own language in racket. It was going to codify everything I had learned over the years into powerful abstractions and target JavaScript.
Halfway though I realized I was inventing a shittier Purescript.
Dsls are mostly masturbation. Custom syntax? Custom evaluation semantics? I always regret it after like cocaine.
The only thing macros are reasonable for is custom bindings.
Most people are not qualified to invent dsls. Myself included. And the people who are qualified don't need "language oriented programming" ala racket. They can spin up a lexer which is the least complicated part of the task anyway.
As for types, they have a HUGE power to weight ratio. All of my efficiency gains in Clojure due to macros were forfeited 10x over hunting down null pointer exceptions at runtime.
I still love Racket. And I still prototype in Clojure. But Haskell brings you closer to math. Closer to category theory.
Most programmers don't need new symbols and semantics. They need a deeper understanding of combinatorial logic.
Racket DSLs aren't the same as 'spinning up a new lexer' at all.
Making DSLs is hard, and being a PLT expert does not make one an expert at language implementation. Those are completely different skills (see Brady's reimplementation of Idris on Chez Scheme and the reason for it).
Racket allows people with new ideas to prototype them efficiently by easily implementing a compiler that would've been an interpreter otherwise.
In my experience most dsls are not of the quality of Typed Racket or Scribble. And many of the good languages designed in Racket could be just as well designed if they targeted LLVM. And for 99% of the programmers I've hired they'd be better spending their time further understanding the existing abstractions and research in the many great languages that already exist rather than halfbaking their own because it's so easy and tempting.
As I said, I like Racket. And I agree with you it's a nice environment for playing with new language ideas. But most of those ideas are bad and are just incidental complexity. And the 1 of 100 languages that are great ideas and needed by the world are better off spun out with their own parser and toolchain without being so tied to Dr Racket and Chez Scheme.
Types also complect, as Rich Hickey points out. Data is just data. When you constrain it with types you lose something. Witness the pain of making JSON fit the type system in a lot of statically typed languages.
In my experience it's the exact opposite. Good design is precisely about constraints.
A good type system like Haskell's gains you much more than it costs. Sure Json and Clojure are open and flexible, but this is not what you want when you understand your problem and can specify the types are Ohms -> Volts -> Amps etc, instead of just Number Number Number.
Specifying them after in spec or typed racket was just not the same and always rang similiar to unit tests after the fact.
Haskell types is like having a pair programmer sitting beside me. For systems that I have in production that have been ported from Clojure to Purescript the reduction in bugs, refactorability and overall confidence is something I didn't know I was missing until I did.
I understand Hickey's point in his Maybe Not talk, either you have the data or you don't. But at the end of the day, Clojurescript apps subject my users to blank screens and subtle "undefined is not a function" bugs, whereas the Purescript compiler forces ME to diligently deal with those unexpected possible scenarios before I ever ship.
> Witness the pain of making JSON fit the type system in a lot of statically typed languages.
In something like Java, sure. But Java is to static types as BASIC is to structured programming: the execution is so primitive that reasonable people can be misled into rejecting the concept if that's all they know.
Here's a completely painless encoding of JSON in Haskell:
`data Value = JObject (Map Text Value) | JArray (Vector Value) | JString Text | JNumber Double | JBool Bool | JNull`
