What’s your take on Hickey’s talk titled “Maybe Not” which fundamentally criticizes static types? Is there a middle ground where some form of static typing makes sense in a Clojure-esque world?
Rich has many great ideas and he founded Clojure. I respect him deeply. On typing, however, we do not agree entirely.
For a practical example of a Clojure-like language with a completely static type system (with affine typing), see Carp. https://github.com/carp-lang/Carp
I don't see why there can't be a Carp mode in jank, with bridges in place to connect the Clojurey world from the Carpy world. This would allow jank users to develop interactively to start with, figure out their shapes, use the REPL, etc. Then, if they want, they can lock down some parts of the code for both performance and correctness gains.
Been a while since I've watched/read it, but I remember the ideas in Maybe Not being quite interesting.
To me, the really important idea wasn't a criticism of static types in general.
Instead it was the idea that static typing in most (all?) mainstream implementations conflates concepts that should be separate, specifically the shape of the information that we have (e.g. what fields of what types), and whether a particular bit of information is available and required (e.g. nullability).
He contends that the former belongs in our usual "type definition", whereas the latter relates instead to a given context. For example, my PassportForm type always has a date-of-birth field in its _shape_, but whether it's statically required/present to exist depends on whether we're at a HTTP API boundary, an internal domain function boundary, writing into a database.
It sounded like that kind of "nullability masking" was intended as a feature of Spec, but I don't get the impression it was ever implemented.
I need to watch this video, but I'd argue that the debate is over on typing. You can make all the theoretical ideas you want, but JS and Python have added typing, it has been received enthusiastically and it has been beneficial. Real world results out rank any philosophical views.
That doesn't mean they're appropriate for all programming languages (it is nice in Python when knocking up a quick and dirty script to not bother with types) but for general purpose languages, types add too much value.
I don’t think Rich was criticizing static types as much as saying that they aren’t giving you as much benefit as you think they are and that they complicate program evolution over time.
They might not give much execution benefit and they may indeed complicate program evolution, but they DO aid readability, document-ability and refactoring!
If you need confidence in the operation of a function you make code testable. If you need it to execute in Repl you need to make code Replable and I am not joking.
Heh. Hickey once debated with me at length about visual neuroscience, a subject I have a master's degree in and he doesn't. At no point did this stop him from confidently asserting things.
I have to wonder if "Maybe Not" is similar, since he's not actually an expert in types, either afaik.
Well, at least I know how to form an argument that is not ad hominem. Remind me who you are next time 'KingMob' so I don't waste my time chatting with you again.
I'd personally say typing or not is a style choice, but your criticism here seems to be that Hickey doesn't have a visual neuroscience Master's degree which seems a bit arbitrary.
If your argument is you are an expert but Hickey is not, criticising him on his language design skills seems like a logical mistake. He's one of the foremost language designers of the current era. "Maybe Not" is a speech by an expert talking in his field of expertise.
If your argument is that his confidence is unfounded, again, he's an expert talking in his area. He can reasonably take a confident attitude in that, even if he has unfounded confidence in other fields he isn't an expert in. Lots of experts do that, it is a well founded stereotype of smart people.
He doesn't need to be an expert in implementing types to judge whether they are a good language feature.
The point of my story that you're missing is that Hickey's confidence in giving a talk shouldn't be confused with knowing what he's talking about.
> "Maybe Not" is a speech by an expert talking in his field of expertise.
Writing a dynamically-typed language does not mean he's an expert in types.
> He doesn't need to be an expert in implementing types to judge whether they are a good language feature.
Hah! Love it.
Asimov: "There is a cult of ignorance in the United States, and there has always been. The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"
> Writing a dynamically-typed language does not mean he's an expert in types.
That isn't a reasonable criticism here. To take it to the extreme, it wouldn't be accepted that someone has to be an expert in homeopathy before deciding they want to disregard the approach. It is up to experts to proactively demonstrate the worth of their domain - he's a language design expert and he's saying that he doesn't think the people formalising the type system have proven it generally powerful for designing new languages.
He's not claiming to be an expert in types, in "Maybe Not" he's specifically arguing that in programming languages they are an attempt to solve a problem where we should be looking for a stronger approach. And in this case, that approach is open schemas.
> Whereas type systems are complex enough... [t]hat suggests expertise is warranted
Well no hang on. Homeopathy is very complex; quackery typically is. You can't use complexity as a defence here [0].
You justified rejecting homeopathy by saying that it can be dismissed with expertise in an unrelated field; so you have to accept that a non-expert can dismiss a field based on general knowledge in other domains. Which is almost exactly what Rich was doing in Maybe Not; except he is actually a domain expert in the area he was talking from. It was a long talk about how he, with his official world-renowned language designer hat on, is not convinced types can demonstrate the strongest advantage in programming and isn't including them in his language [1].
Now that is a very easy opinion to disagree with and I doubt Rich is even particularly dogmatic about the idea, but it is an expert opinion being delivered by an expert who is supremely qualified in his field.
[0] And, as an aside, I'm not going to pursue it but you're attempting to justify dismissing a medical belief based on knowledge in an unrelated field - physics.
[1] Although, as he is proud to point out, if you want a new language feature in Clojure you can add it in a library - as Ambrose has with Typed Clojure.
But it's not complex at all; a better word is "elaborate". And it doesn't matter how elaborate a system spun from incorrect premises is, if the premises fall, the whole thing does, and homeopathy's premises are easily dismissed.
Very basic tenets of homeopathy involve things like excessive dilution to the point that mere molecules of an active ingredient remain, but which somehow attach "memories" to water molecules to achieve their effects.
Atomic physics points out that this is nonsense. And medical knowledge is under-girded by physics, obviously, so it's not unrelated.
----
We can keep torturing the analogy if you like, but at the end of the day, Hickey's experience is not in static typing. His original background was in C++/Java, which have much simpler type systems, unlike Haskell/ML/Rust/Scala/Swift/etc.
Many people in the static typing world seem to think his criticism is just not that deep or subtle. Unnamed union types exist, existed at the time of Maybe Not, and just represent a different set of tradeoffs than named wrapper ones like Maybe. (Mostly around being explicit.)
It plays well at the conj, but most Clojurians are also inexperienced with modern type systems.
Being an expert in type theory or language design is not particularly relevant either. The most relevant expert would be the lowly maintenance developer.
https://youtu.be/YR5WdGrpoug?si=4mI8doBX6jj6PJkk