Strong static type systems are helpful when you are working in a closed system where you control all the data and nothing can go wrong or change. They really start to crumble when you get partial updates, data that is “correct” 99% of the time, types that are 99 (or even 100%) the same but called different things by different subcomponents/libraries. And the real world is messy. Hickey talks about in one of his previous jobs of radio programming and writing rules for when songs can be played when. It starts off simple, but as time goes on the rules become more complex. They get to the point where you spend as much time refactoring and abstracting your rules to handle every possible combination as you do actually changing the rules. Sometimes you don’t care about all of the intermediate types, you just want to ensure contracts at certain points of the program. In between, you don’t care or its banal to type. Implementing serialization often falls in this category - a general purpose JSON/SQL/NoSQL serializer can handle these trivialities without having to create a UserResponse type that is created from a User domain object that is transformed from a UserDAO. I think the gradual typing you get with Typescript and spec/malli is the ideal situation, you can define the parts you want, and handle the mismatch then. Otherwise, you don’t care what data is in your map

> I think the ML, and even more so, Haskell, are extremely interesting type systems and languages. But, personally, I haven't found their type systems to be sufficiently expressive or sufficiently dynamic for my needs. I like dynamic polymorphism, I like heterogeneous collections. [snip] I don't think the benefits of those type systems outweigh their costs, for me. And, Haskell is already doing a brilliant job in delivering that kind of solution. https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd697f#why-did-you-choose-to-make-your-language-a-lisp-dynamically-typed-as-opposed-to-ml?, from Rich Already Answered That

> What are some good responses to the last frame? Nothing, really. People that like static typed languages usually (usually meaning almost certainly, especially considering the wording "drastically") don't like any argument on contrary. This is a fruitless discussion, honestly, one that I had way too many times, and never got any meaningful result from it. Usually I like this paper: https://arxiv.org/pdf/1901.10220.pdf, and they will probably link another, and then other people will link others that contradict the one they linked, and that gets into an infinite loop until the point everything starts to escalate to personal attacks :man-shrugging:

I would ask them to give some examples of program correctness due to static type systems i guess.

I like to avoid paper-tennis by steering the conversation to trade-offs of one approach versus the multiple alternatives. Like, if correctness is the goal, why stop at static types? Why not insist every e-commerce web app is formally verified? Then we can talk about what nice things dynamic lisps bring to the table.

i think the guy Will is tearing apart in this meme is more a Language Guy than a Static Types Guy - he’s hoping (based mostly on vibes) that the right programming language features will solve all his problems. so he flits about from language to language in response to what seems Cool on reddit or hacker news this week. but no programming language will solve all your problems.

Programming has always been beset by social trends based on grand promises of “just adopt X methodology, and bugs will be a thing of the past.” OOP comes to mind as another prominent example. NoSQL. Many others. Static typing is more of that. Unfortunately, I agree that for most advocates (not all) of static typing, it’s not worthwhile to debate the matter with them; they’ve pre-decided that static is the way to go, they feel good about being on Team Static, and their only interest is one way missionary activity to YOU, not hearing any rational objections to static typing.

A more fruitful approach is to introduce the merits of dynamic typing, and its benefits over static, to younger developers who have not yet formed any strong opinions either way. Right now, 99% of the outreach and education is being conducted by Team Static.

Is it really that different from Clojurians who call things they dislike "easy but not simple" or repeat other Rich Hickey statements without thinking much about them? e.g. "proliferation of types" is brought up a lot against static typing (it even happened in this thread), but it seems people just parrot what RH states rather than recognizing this is a fault of so-called "nominal typing", not static typing in general. Languages with "structural types" and strong type inference, like OCaml, let you write a good deal of functional code without having to write much types, if at all (unlike Java, TypeScript, etc.). Yet OCaml comes out with better type safety than both languages. without any DTO nonsense or ClassButAnOptionalFieldIsNowRequired. Likewise, people often claim dynamic types offer "quick prototyping", but the arguments given, if any are given, always reference statements Rich made 15 - 20 years ago that don't really hold true today. For instance, if I am prototyping something and need a priority queue or trie, Python provides these data structures out-of-the-box, whereas Clojure doesn't. So in this situation, Python offers faster prototyping. Dynamic typing doesn't offer much w.r.t. prototying IMO; what matters is the standard library and tooling (debugger, inspector, REPL, etc.) Overall, I feel that the Lisp community is too proud about their own specific Lisp dialect. There's always a figure they seemingly worship. Common Lispers cling to their frozen-in-time ANSI specification. Clojurians immediately accept and paste RH quotes. Schemers often idolize some notion of "simplicity" and "pureness" in programming language design. So on, so forth. People even in this very slack are sometimes downright disrespectful of non-Clojure users. I wont name names, but someone in an earlier post in #off-topic literally stated that Java programmers are "mediocre" and "churn mindless boilerplate" because Java allows such people to thrive. But using Clojure apparently means we are all enlightened and so better than Java devs /s.

As an aside, priority queues and tries, etc. do exist and are typically provided as libraries in Clojure, rather than core language elements. The main reason it runs on the JVM is transparent access to the huge amount of industrially tested Java libraries for such things.

Right. I first have to pause what I'm doing and add a dep rather than just start focusing on the problem. That was my point. The vastness of Python's stdlib are why e.g. its the de facto language of most coding interviews. If I need a PriorityQueue I don't fiddle with a requirements.txt, I simply type queue = PriorityQueue() and move on. Compared to languages without this data structure in its stdlib, Python is now letting me do things "faster". Dynamic typing didn't help with this, but the scope of the standard library did.

The lack of what you might call “standardized frameworks” in favor of a large number of small libraries that must be searched for and integrated DIY is indeed what I personally consider to be one of Clojure’s weaknesses

I personally find that the large general improvement in development speed outweighs that issue.

I actually don't disagree with this "Clojurians who call things they dislike 'easy but not simple'". In fact, at my current job, I ended up choosing Ruby instead of Clojure, and for now, I don't really want to be back to CLJ - basically, my last three jobs were jobs where I had to handle codebases full of macros, indirections, and other stuff - everything that I ended up not liking in my Ruby experience... ... with the exception that it wasn't really "familiar" like Rails. Rails is bad, but it's always "the same bad" - you know where to search to find things, etc; whereas a complicated, indirect Clojure codebase is a complete mystery and there's nowhere to look.

I once saw a keynote that said "programmers like to compare tools, now imagine this in another context, where a painter says to another look at my brush, is way better than anyone's" Which also mirrors my experience - so many discussions are based on "my language is better than yours because of this and that"...

painters love talking about their brushes tho

But I don't think they brag that they have a single brush that's better than every other brush that exists, right? 😄

@U0479UCF48H > Right. I first have to pause what I'm doing and add a dep rather than just start focusing on the problem. That was my point. add-lib allows you add a dep so you don't have to restart the repl. https://clojure.github.io/clojure/branch-master/clojure.repl-api.html#clojure.repl.deps/add-lib It's still a wip, but i works most times i care to use it.

I understand your wider point though.

> For instance, if I am prototyping something and need a priority queue or trie, Python provides these data structures out-of-the-box, whereas Clojure doesn't.... If I need a PriorityQueue I don't fiddle with a requirements.txt, I simply type queue = PriorityQueue() and move on. I'm not opposed to queues or tries in core (it's worth posting an ask.clojure) but (def q (java.util.PriorityQueue.)) is 100% idiomatic out-of-the-box Clojure, no fiddling with deps.edn.

something to upvote if you agree: https://ask.clojure.org/index.php/3821/add-queue-and-queue-to-clojure-core

https://clojure.atlassian.net/browse/CLJ-1078

Oh nice! I had only seen the original, it's great someone did a reproducibility study. So ya, even on this reproducibility study, Clojure and Haskell are the two languages that fared the best, both as statistically significant, as well as in their practical prediction model. Even though they show that the practical effect is so small, it probably wouldn't really be noticeable in practice, it is still noticeable statistical in significance. So it possibly debunks that language matters that much for defects in the first place. But also that static types seem to in any way affect defects. Given that the two languages Haskell and Clojure still being at the top, even if with a miniscule margin, what they share in common is not static types.

@U0DJ4T5U1 Things like renaming a field, or removing a field, or moving a method from one place to another, or deleting a class, changing what something returns, etc.

Thanks Didibus, good points.