Comment by mrottenkolber | Hacker News Reader

Comment by mrottenkolber | Hacker News Reader

Parent Full thread

> I think you're mistaking the parent poster's argument. Immutability is at its most useful when it's the norm, rather than the exception. For this to work, the core language needs to very strongly encourage immutability, to the point where in-place mutability is considered something only useful for low-level performance tweaks.

I don't think so. What you are saying is you can only program in way X if your language forces you to, which is obviously wrong? I think people just are not used to using a language that doesn't force you to do anything at all (e.g. lisp).

You can only program in way X if your language _allows_ you to. What language allows you to program in any way and even lets you easily modifiy the language to do whatever you want? Lisp.

> The Clojure rationale page talks about separating languages from platforms, and this subject has come up often in talks and on the mailing list.

Then they made that up. ClojureScript is not the same as Clojure. They did a pretty horrible job at seperating their language from their platform. I know because I get Java stack traces all day. I also have to use inferior language primitives dues to Clojure's Java-centrism every day.

> I don't think so. What you are saying is you can only program in way X if your language forces you to, which is obviously wrong?

If you have a library that expects mutable data structures, that's going to be incompatible with a library that uses immutable data structures. The type signatures of the functions are going to be fundamentally different.

It's certainly possible to have a language without a consistent set of core data structures, but I'd argue that's considerably less useful. Enforcing a particular paradigm means you can interface between libraries without worrying about compatibility of data structures.

> Then they made that up. ClojureScript is not the same as Clojure. They did a pretty horrible job at seperating their language from their platform.

That's not quite what I meant. A particular implementation of Clojure is typically tied closely to the platform its hosted on. That's why Clojure and ClojureScript have marked differences, especially around concurrency.

What Clojure lacks, and deliberately so, is a platform of its own. There isn't an equivalent of the JVM in Clojure; there's no intermediate layer that sits between Clojure and the JVM, or ClojureScript and Javascript. The idea is that the language should adapt to its host, instead of trying to shoehorn everything through a universal interface that can't cope with every situation.

There's a pretty good argument that taking away features is what makes programming paradigms effective. You create restrictions (invariants, if you like) that enable the paradigm. Consider:

- Structured programming takes away GOTO - OOP takes away manual function pointer tables - FP takes away unrestricted mutation - Logic programming takes away explicit specification of execution order - etc.

None of this is about "forcing" you to do anything. It just appears that humans aren't very good at coding with unrestricted power over their machines, and it helps to simplify paradigms in a way that enables them to be effective at reading and writing higher level code.

If this wasn't the case we'd all still be programming in assembly.

Slightly tongue-in-cheek talk by Uncle Bob on the topic: - https://skillsmatter.com/skillscasts/2323-bobs-last-language

Better stacktraces would be better, sure, but there are good arguments on both sides whether it's better to separate the language from the platform or not.

I prefer a thin, readable compiler and core library over such abstractions. I don't mind the stacktraces, but I could see how some people might.

The fact that clojure is host-centric makes clojure and clojurescript compelling to java or javascript programmers at the expense of some aesthetics, and it also has performance implications.

Reply on news.ycombinator.com