Oh, about interactive development: that's sure, CL shines here. Objects get updated (lazily) after a class change, we can install Quicklisp libraries without restarting the image, etc. It's very smooth.
I think most developers cannot be trusted to make these mistakes, I wouldn't call it "careless or lazy". Languages exist with tools baked into them to prevent slip ups. Why wouldn't you want to take advantage of that tooling?
Also, as a result of this comment section, this is the second time in the past week that I've seen the suggestion to use 3rd party typechecking/static analysis tooling in a dynamic language, which (to me) brings up the question: Do you really want a dynamic language, or do you just want the ability to be careless intermittently? There is no shame in saying "I just want to get happy-path code working quickly". There is joy in getting happy path working quickly. I just think, as a codebase in a dynamic language grows, codebases seem to build lots of tooling to make that dynamic language less dynamic.
I think this is getting closer to the interesting questions. It's often a good thing that when the product matures and moves more into maintenance mode, you can then incrementally add the kinds of rigidness that suits the needs of that. Clojure has excellent support for these in the schema style data validation tools of spec, malli, etc.
If you had a rigid system and slow turnaround from the start, you might not have gotten off the ground to get that far.
I always see people say this and on the surface it seems to make sense, but I also always wonder what "rigid system" they're talking about. It's much, much faster to make big changes in every phase of a project in Haskell for me than it is in Elixir, so this is the perspective I'm seeing this from. This hypothetical/straw man "rigid system" is hard to fathom.
*Haskell and Rust get a lot of flack because of their compilers being difficult for beginners to work with. I don't necessarily think this is actually an issue - for a sufficiently skilled Rust or Haskell dev, I doubt most compiler errors feel like a "fight".
That's certainly true of my experience. I prefer to have the compiler there guiding me (My reference points are poorly-typed languages like C, Java and C++, and the dynamically-typed language Python. I've never used Clojure.).
Also, it's not just the amount of work, it's the complexity of the language. Clojure is really simple, so you don't h ave to spend much of your cognitive capacity juggling things related to the language or operating a mental simulation of the type system.
In that sense I really do get off the ground much, much faster in Clojure. In fact, it's my favorite language for prototyping and the whole interactive execution model of the REPL makes we want to learn Emacs and do everything in some kind of lisp, rather than awk, sed, bash, dash, whatever.
I think the key ingredient for me with Haskell is to know when to stop. You can be very productive even as an intermediate Haskell user if you restrict yourself to the features with the highest return on investment. Everything else can be done later. But I also know that it's very tempting to stress out over these details.
As a very late conclusion to my various comments in this thread: if I got better at taming type related errors in Clojure I could very well see it being my go-to language for everything.
Haskell/Rust - Immediately
Java/C#/Go - Relatively quickly
Dynamic Languages - Whenever you decide it becomes important
Even though Clojure is not a statically typed language, it does have a type system.
Here's an example what Clojure.Spec lets you do. When I was working for a fintech company, we built a suite of specs for a ledger. Based on those specs we could generate data. And it wasn't just some set of key/value pairs with completely randomized numbers. It would generate "a proper" ledger, where every number in a transaction depends on other transactions.
We used that generated data to render UI locally and on the non-prod environments.
Using the same specs we build data validators, we re-used the specs to validate data in the input fields in the UI. Which is totally bonkers. How the heck you achieve code re-use between completely incompatible ecosystems - in our case, JVM and Javascript? Even Nodejs doesn't always let you re-use code between backend and the front. Clojure allows you.
Using the same specs, we've built property based/generative tests.
I've never experienced the joy of creating such robust, predictable, and reliable software with any other (statically typed or otherwise) language before.
I'm not saying you cannot build a similar thing (or even better) with Scala or Haskell (or some other PL). The simplicity of how Clojure allows you to write things like that - just incomparable.
> Even Nodejs doesn't always let you re-use code between backend and the front.
This is not true. Check out Lodash. It's a dependency of pretty much every FE and BE NPM package that exists. Ignoring rendering libraries like React, client side JS and backend JS are "just" JS.
> I've never experienced the joy of creating such robust, predictable, and reliable software with any other (statically typed or otherwise) language before.
I think you should definitely keep doing the things that bring you joy!
Respectfully, as someone who spent over a decade building front-end apps, I'd say: the code re-use between js in the browser and js in node still feels limited in comparison with Clojure/Clojurescript approach.
I'm not talking about utility libraries.
Code re-use is just one of the aspects. When choosing a tool, especially a tool like a programming language, one needs to take "a holistic approach". Clojure is not a silver bullet. Neither is Haskell, Rust, or any other PL.
I like Clojure today, because today it makes sense for me to use it. For the projects I build. I'm sure, someday, it stops making sense for me to use it, and I will move onto something else.
You can use all sorts of arguments for people to try something else today, assuming they are just misinformed - either about Clojure or the other PLs (you're preaching about).
I can assure you though, most Clojuristas I know - didn't end up using Clojure by accident. It's a deliberate choice. After trying many other options.
Though it's telling how little static checking by type systems is leveraged eg in LLVM, so even in closed systems the assurance payoff for static checking doesn't necessarily get good bang for the buck.
Eg working with web based services, your code tends to communicate a lot with other services, and a very large % of bugs that make it further out than your dev laptop come from those interfaces. Making these part of the closed world of the static type system is done in some places but most static language users elect not to do it, preferring programmable checks in form of schemas or tests. Which I think tells something.
I tend to think of static vs dynamic as a mindset question, where our bias of loss aversion rears its head. It's an attractive idea to hedge your risks by usign a static language even if it only catches the trivial bugs and slows you down, because statically found bugs are a falsifiable observation, wheras making programming easier, faster and more fun[1] in general doesn't leave hard evidence unless you run duplicate trial projects just for science.
[1] For some personalities, you might derive more fun and satisfaction in the mathematical certainty of static languages. Or you might be in a work environment where you don't have room to find fun anyway. Or maybe you don't even like programming. Yet others find fun indispensable: fun is necessary for keeping up morale.
Are you actually suggesting that "most static language users elect" to not decode at the boundaries of their system because it somehow is favorable to not do so? This does not match my perception of things, neither the "most are not decoding" part nor the "it's fine to not decode into a known good structure" part.
> It's an attractive idea to hedge your risks by usign a static language even if it only catches the trivial bugs and slows you down, because statically found bugs are a falsifiable observation, wheras making programming easier, faster and more fun[1] in general doesn't leave hard evidence unless you run duplicate trial projects just for science.
What an incredible straw man you've built up, but then you just let it sit there and don't even burn it up.
Since I'm not here to convince anyone, I can say your straw man is the opposite of my experience. I've never been able to prototype and change a system in any phase of its lifetime faster than I've been in Haskell. Haskell has downsides, but speed of development and maintenance is one of its strong points.
> I tend to think of static vs dynamic as a mindset question, where our bias of loss aversion rears its head.
Yup, and when it comes to fun, I've never had more fun programming that in Haskell, where I let the compiler check the annoying fiddly bits so my brain is free to tackle the meaty problems!
I'm was thinking protocol meta systems like protobufs where you use tooling to enforce closed world style communication patterns in a networked world.
By falsifiable I meant that it's an observation that could be shown to be false, if it was false. So a concept from philosophy of science, not an assertion.
My dream programming language is basically a statically typed Clojure.
I've on and off poked at trying to make something like that (parsed using instaparse, type checked in Clojure, compiled to C++ using https://github.com/arximboldi/immer for the data structures), but haven't had the time to really get anywhere with it. Plus, even if I succeeded, I wouldn't have the rich Clojure (and by extension, Java and Javascript) ecosystem.
https://github.com/clojure/core.typed
To me, it's one of the great testaments to the power of Lisp that you can bolt on a static type system after the fact.
We'll often do it at the level of namespaces, where a namespace will describe a particular workflow or data transformation, and namespaces tend to be 500 lines or less. It's a similar idea to microservice architecture without the overhead of having to actually split the application up into separate processes.
We'll also often pull out code into libraries when we notice it being generally useful outside the original use case.
I find that there are a lot of benefits to structuring your code using small components instead of monolithically as tt's easier to reason about and reuse. Any large application can, and in my opinion, should be broken down into small parts that are then composed.
It does take more discipline to work with a dynamic language, but once you develop a process then it can be very effective. It's also worth noting that immutable by default plays a huge role here. With Clojure it's natural to create truly isolated components while it takes a lot more discipline in an imperative language where things are passed by reference creating implicit coupling.
This is what I run into. But that's not exactly a dynamic language problem. It's more of a data-oriented programming (in the Clojure sense) problem.
I'm coming to the opinion that data-oriented programming techniques only make sense inside a fairly tightly bounded context. One that's small enough that you can see and understand the whole thing at once. As soon as you've got ad-hoc data structures crossing logical boundaries, you lose the ability to keep track of it all, and it becomes very difficult to ensure everyone's interacting with these ad-hoc types in a compatible manner.
Incidentally, this is also exactly why I dislike JSON for APIs. I'd much rather share data across boundaries using data structures with explicit, nominal, static types. Like what you get in gRPC.
Anyway, my Clojure experience is limited, but I think this is why I have an easier time letting Python code get big than I did Clojure. With Python, I've got myself into some problems with data oriented programming, too. But with Python, it was easy (and idiomatic) to walk that back and switch to using dataclasses.
Yes, all dynamic languages have this problem. I have transitioned to statically typed languages and it has been very peaceful so far :)
I realize that data-oriented programming is more likely to happen in dynamic languages. But correlation is not causation.
Yes, sure, we can say that no true Scotsman would use a static language that way. But I think that's maybe missing the point. If you can dismiss this practice in static languages by just saying, "Well, maybe you shouldn't do that," why not also apply the same dismissal to dynamic languages?
That said, there's a specific subset of dynamic languages that make it more difficult to do your domain modeling any other way. Clojure and JavaScript belong in this group. I'm not sure of other examples. Basically, if the type system has been set up such that everything is either a map or a glorified map, you aren't left with a whole lot of other options. But not every dynamic language does that.
In Python, for example, I always use dataclasses for data. As long as I'm being good about this, I don't actually need to explicitly write unit tests to verify that types are being handled properly. MyPy's got my back. And, even if I'm not using it, unit tests for covering actual behavior will typically blow up with a type error in about the same amount of time that it takes a static language's compiler to detect one.
Are there any open source Clojure projects that are structured this way? I'd like to see a working example.
I'm not saying this doesn't happen in Java or Go but the static typing enables easier code exploration. That makes code bases more readable to newcomers.
A sort of enforced distinction between (typed) interface and implementation.
In practice I always wound up needing to read code of functions to see what types (or keyword argument!) they expected.
- PHP without phpstan/psalm/phan
All bad ideas, modern tooling can detect errors in your code before you finish your code expression, but you do need to go out of your way to setup it up
Most people do not and then complain about types instead of talking about static analysis
If you are ever coding Clojure you should be following this: https://github.com/clj-kondo/clj-kondo/blob/master/doc/edito...
Static types are a form of static analysis. One that is deeply integrated into the language and compiler, which gives obvious advantages such as machine-checked documentation, custom invariants and error messages (expected a Currency but got a Country), better code generation, better tooling (IDE pop-ups, fast incremental checking) etc. Other forms of static analysis are of course useful too.
A value of type "User" can be either "LoggedInUser", "Admin" or "NotLoggedIn", and each of those can have data attached to it. Now I can write functions that only work on specific versions of this and the compiler will remind me to handle every possible variation. If I've narrowed it down to "this function only takes Admin", then the compiler will prevent me from passing the wrong type to it.
It's little things like being able to wrap a "String" in a so-called "newtype": "newtype SpecialString = SpecialString String". Now a function can happily accept three string arguments, but if each one is wrapped in a special type you can't mix them up. Or saying something is a "NonEmptyList" and now I can rest assured that it'll always have values.
If any of these can be achieved reliably (<-- important!) in Clojure then I apologize for my lack of knowledge!
It's intermediate representation is statically typed, but the language itself has dynamic semantics.
That said, we have almost every trick and tool up our sleeves that static languages have (in various stages of development). Check out https://github.com/aviatesk/JET.jl if you want static typechecking of julia code.
The most comparison is core.typed, which literally just adds static (gradual) typing to Clojure. That said, I think that's a misleading comparison, and less useful than it is for TypeScript.
If you're willing to relax the definition to "static analyzers that find similar issues to what TypeScript might find", there are a few that require very little input (but are less powerful in finding these types of bugs, more powerful in finding others) like e.g. clj-kondo or spectrum.
One fundamental challenge is that the idea that you should mostly just pass data around, ideally maps, and those maps should be open for extension, is very core to Clojure. You get a lot of benefits from that, but the idea that anyone can add stuff and that's OK also makes it difficult to detect that some accesses are _not_ OK.
(note that Lisp is flexible enough that a type system can be written as a library)
There's also this for run-time checking (i.e., you won't get any help at compile-time, but functions called with bad values will fail in very clear ways): https://github.com/plumatic/schema
Unfortunately I am too lazy and careless to use Clojure in any serious capacity though. I really need a Haskell or Rust compiler to remind me of all my silly mistakes. I can't be trusted to get to the same level of confidence through unit tests or linting or spec or malli.
I actually tried using Clojure for a little web project (~3k LoC in both Haskell and Clojure) and any refactor that included maps that were passed around in many different routes (think authorization, logging, DB) ended up with me chasing down rather weird type errors. Basically the equivalent of can't call X on undefined in JS.
In Haskell I spent at least the same amount of time trying to make various monads play nicely together. Think using IO, Maybe, Either, etc. in the same route handler without having your code be indented ever further to the right.
But the difference is that once I've invested that time I'm very confident in my code, whereas in Clojure there's always this lingering sense of impending doom because surely there's some code path that I haven't thought about.