Hacker News Reader

Comment by YuukiRey | Hacker News Reader

Clojure is the most enjoyable language I've ever used and I love the interactive development. I haven't written code in any other language that even comes close.

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.

View on HN

This looks like something Common Lisp does better, however I have too little Clojure experience to compare. CL (and SBCL in particular) does "good enough" static type checks, it throws warning at compile time (when we compile one function with a keystroke). We can also precise our function types gradually. It isn't a HM type system (Coalton[1] could be it) but it's already great (compared to no compile-time types at all).

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.

1: https://github.com/stylewarning/coalton

> 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 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.

> Do you really want a dynamic language, or do you just want the ability to be careless intermittently? [...] 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.

Yeah, it seems like programming language decision is, at least in part, a proxy for "At what point do you want to be held accountable for your program's correctness at runtime?"

Haskell/Rust - Immediately

Java/C#/Go - Relatively quickly

Dynamic Languages - Whenever you decide it becomes important

Whether you get strong assurance of correctness from static typing depends on your domain, are you're working with a closed-world app like a compiler, or a talking to the rest of the world a lot?

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.

I don't particularly want to argue with you. Using the phrase "falsifiable observation", and then referencing "fun" as an argument just doesn't really work for me. I appreciate that you like dynamic languages, but I will not take your "rest of the world" bait. To suggest that dynamic typesystems are as verifiably correct as static typesystems is verifiably incorrect.

Not sure if this needs clarifying or not from your message but:

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.

> 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.

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.

> 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.

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!

> 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

I'm was thinking protocol meta systems like protobufs where you use tooling to enforce closed world style communication patterns in a networked world.

It's a bit of an oversimplification, I think.

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.

I'm not familiar with Clojure Specs, but it definitely sounds exactly like the "Dynamic language implements type checking tooling to assert correctness", as referenced in the above post. The spec website just looks like type assertions as "validation" - what am I missing?

> 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!

> This is not true. Check out Lodash.

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.

Because you chose to bake environment information into your code, that does not mean nodejs doesn’t support client/server reuse. Respectfully.

I never said "it doesn't support", it's just not the same.

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.

> 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.

It's funny - I see that sentiment all the time ("Static typing is slower to get going with") and I kinda chuckle. In both static and dynamic languages, in the beginning, you're not doing anything silly. In both scenarios, you likely aren't writing your methods that accept strings and then immediately trying to pass them ints. For two developers of the same proficiency, competing to generate value in a static vs. dynamic language, I suspect the first 10 hours or so of building a project would progress pretty similarly. Compilers don't really fight with you until there's lots of hidden complexity.*

*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".

> 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.).

I don't have Elixir experience, but the natural way to get started in modeling data and state in Clojure quite obviously involves less ceremony and scaffolding than what you do in Haskell, and is less work to change around.

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.

I totally understand what you mean! At least I think I do. I have spent a significant amount of time going down the "type flex" rabbit hole. You can always make thinks a little safer, a little more concise, and so on.

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.

I've been using Clojure since the summer of 2009, started a startup with it, using it exclusively on one project right now... and I agree about static types. I love many many things about Clojure, its my favourite language to use and I find it very well designed over all. But proper first class static types are the one thing I wish it had.

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.

Do you know about the Typed Clojure project? More or less Racket's contract system, for Clojure:

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.

Yes, but it’s really not the same as first class static typing support. It also doesn’t help when none of the libraries you use have type annotations and when I last looked it was also quite slow.

I wrote Clojure for 4 years. I understand your pain points. Dynamic types are an impediment beyond a certain code size.

My experience with dynamic types comes from developing in Python. The projects I've seen were pretty healthy until a large enough part of the original team went away. Once enough people had to figure out their way by experimenting, the projects got messy.

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.

That might be true but good variable names and some terse but to the point comments are much more helpful in my experience.

I always really missed header files when working on Python.

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.

My team structures projects by breaking things up into small isolated components that can be reasoned about independently.

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.

``` breaking things up into small isolated components that can be reasoned about independently ``` - This is insufficient for the same reasons unit tests are not enough and you also need integration tests. The moment you cross namespace boundaries, you will end up not setting keys /entries in maps , missing logic etc and end up needing something like Spec/Schema....

> you will end up not setting keys /entries in maps

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.

> 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.

Yes, all dynamic languages have this problem. I have transitioned to statically typed languages and it has been very peaceful so far :)

To go at it from another angle: I'm working in a relatively large Java codebase that also likes to pass around generic ad-hoc data-structures such as maps. And I'm having exactly the same problem problems there. Static typing does nothing to help the situation.

I realize that data-oriented programming is more likely to happen in dynamic languages. But correlation is not causation.

IMHO Static typing => structure, not necessarily Map<String, String> (which is also a type). Shaping data is quite important and having an associative array doesn't necessarily means that the data is shaped.

Right. . . but, way up at the start of this, you specifically called out using associative arrays for all your data. And what I'm saying is that, while that's absolutely true, it's also technically an orthogonal question from whether you're working in a dynamic or static language.

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.

Humans are weak. The easier it is for them to do the wrong thing, they'll do it.

Sure, and my team uses Spec at component boundaries to define APIs for that reason. I actually prefer this approach to static typing because it makes it possible to add a specification at the level where it provides the most value, and it's much easier to express semantic constraints using this approach.

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.

> 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

Are there any open source Clojure projects that are structured this way? I'd like to see a working example.

- Clojure without clj-kondo

- 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...

I use kondo already, and while it's a nice tool it doesn't solve my problems.

Can you be more specific? There is a primitive type annotation checking system in there, kinds of mistakes not being caught will likely be of interest to Borkdude and others

The features of the Rust and Haskell type systems that are most useful to me are requiring me to handle every possible null value and modeling branching control flow with algebraic data types, including exhaustiveness checks for those.

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!

Yes, just use C with asan, msan, valgrind and frama-c. Why invest in types?

> then complain about types instead of talking about static analysis

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.

It seems like if a tool is so essential to successful development in a language, it should probably not be a 3rd party library but instead baked into the language tooling itself, no? (I have never used Clojure and am not trying to be inflammatory)

Check out Julia; It has built-in optional static typing, a fast JIT, it can be run interactively in the same style as Clojure, and it supports lisp-like macros.

I use & love Julia, but it doesn't have really static typing – it has runtime validation based on type annotations. For static typing to be useful, IMO, you need static typechecking, usually done at compile-time.

This is a common point of confusion for people. Julia has a useful and expressive type system, so people just assume it must be static but it's not, julia is dynamically typed.

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.

Is there something for clojure that TypeScript is for JavaScript?

Clojure has an optional type system: https://github.com/clojure/core.typed

(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

Hopeful new lispers beware that core.typed is not so easy to use as TypeScript, and slows things down quite a bit, and you will need to write a lot of type definitions for 3rd party code. Most (all I’ve seen) clojure shops instead rely on runtime type checking with Spec or Schema, both still popular

There are a few such things.

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.

What helps me with this inherent uncertainty is writing in a functional style (simple inputs and outputs, minimal functions) and using runtime tests to check for correctness. The key is to have the tests as far down the abstraction tree as possible. There's a performance hit, but you can use macros to keep it out of production.

I also like the racket contract system, it is very expressible. But comes with a performance penalty that i can't justify for anything inside a loop. Typed-racket might help but i haven't used much so not so sure.

Haskell or Rust is too far the spectrum ;), TS or Kotlin are a nice sweet spot.

Reply on news.ycombinator.com