Hacker News new | past | comments | ask | show | jobs | submit login

Rich has to be my favorite thinker in this space, absolutely love his talks and the way he articulates things, and I often draw from his philosophies in my work

But, I've always been turned off to Clojure by the lack of static typing (I know spec exists, but it's not really the same thing). I did a little project once to try it out, and even there I found myself spending time debugging basic issues like passing the wrong number or wrong kinds of arguments to functions

Can somebody sell me on it? I feel like I'm the target audience




It's a matter of habit. Once you get used to it, you quickly know how or why it happens and where (especially when you follow the correct workflow, see below). Modern editors/IDEs help a lot with the typos and wrong number of args.

Some advice I would give myself when I started learning Clojure:

Think not in types, but in data. It's a different model that requires an 'aha' moment, but it's revelatory when you do get it.

If you come from an OO language, think not in objects (Elephant), but in information about objects (elephant's record, a map).

Clojure is best served REPL driven.

You can technically compile and execute, but this is not how the language shows its power. Here's how I use it:

I evaluate code in the REPL as I write it, reload definition on every change. Inside a `comment` block, I call the function I'm writing with the required arguments. I can quickly test how my function behaves in corner-cases. You then construct another function, which calls the first. You evaluate/execute the function as you write it.

So your program keeps growing, while you keep running/changing individual parts of it.

Once you get the hang of immutability and working with maps/collections, this process becomes very engaging because of the short feedback loop between thought and result.


yeah REPL driven development is pure joy. Even back when i was a JS developer i was developing a lot of my algos in devtools and then copying them to code.

It’s like having a conversation with your program while you are developing it.


I am myself not 100% sold on it, except immediately after any Rich talk (honestly, that man could sell me anything :D), but it was eye opening to me that static typing is not an end goal in itself -- it might be a local optimum, but there are many more things it can't express than it can.

Also, in case of Clojure you usually handle FP code with no side effects, written in a REPL-driven, interactive style. This combination is not as prone to typing errors in my opinion than "traditional" dynamic languages like Python and JS.

Another aspect might be the one being touched in the 'Maybe Not' talk: Static types operate on a closed-world basis, where the sum of all relevant code is available at the same time. While this is common for certain kinds of programs, it is not really true of systems which have to interoperate with services owned by different companies alltogether, having to support many different versions of other interfaces at the same time. In that case you want to be liberal in what you accept, and arguably, dynamic types are better fit for this job. I am not 100% sold on this part, mostly just reiterating what I've seen others claim, notably Oilshell's author is a big proponent of this thought.


I have the same reactions to his talks. Yet, long term, I've never been able to convince myself that clojure, common lisp or more popular ruby/python, are good choices for me in case of long running projects.

I'm not sure how being liberal in what you accept is at odds with static typing. Static typing is about encoding the rules and shapes of the data that your program *knows* how to work on. It's not preventing some other data that you don't care from existing alongside.

Even if I'm missing something, that doesn't change the fact that in most static typed languages you can fallback to some sort of "any" types. Seems to me it's better to have option to use static or dynamic types in the same program, instead of being forced to do *everything* in dynamically typed way.


Well, spec is there, so it is not only typed vs untyped but static types vs contracts. With the added ability to generate test data, I think the field is much more equal, but as I said, I also tend to fallback to statically typed languages, but that’s mostly just out of conform.


It is difficult to explain why, but there is actually a positive case to be made for dynamic typing. Their benefits are real but a lot less immediately apparent than the benefits of static typing. I think this article from Eric Normand captured some of it https://ericnormand.me/article/clojure-and-types. In my opinion languages like TypeScript where the type system is only a verification system and has no effect on the runtime, combined with its emphasis on structural types, existence of union/intersection types, etc, go a long way towards reducing the downsides of static types but not completely.


clj-kondo helps with catching those types of errors. it works really well

https://github.com/clj-kondo/clj-kondo


> I found myself spending time debugging basic issues like passing the wrong number or wrong kinds of arguments to functions

You'll get over that pretty fast. The bigger issue is looking at some code and wondering "just what in God's name is in that 10-level map and why?"


As someone who's written at least as much code in dynamically typed languages (Lisp, Clojure, Python) as static, I find this question interesting because I really don't know how we know what types to pass. I think a big part is naming and following conventions. But honestly, somehow, I don't think I've ever had problems figuring out or passing the wrong types to anything.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: