Hacker News new | ask | show | jobs
by weavejester 9 days ago
> Programming language syntax scarcely matters. It does to some extent but we the programmers tend to over-romanticize it. The runtime and its properties are the much better thing to optimize for.

I'm not sure I understand this argument. Java and Clojure share a runtime, but an idiomatic Java codebase is going to have a very different architecture and design to an idiomatic Clojure codebase. Conversely, a codebase written in Go may end up looking very similar to a codebase written in Java, despite using different runtimes.

1 comments

I mean runtime guarantees and features. In this case: effortless / near-invisible concurrency and parallelism.

As mentioned, I did like Clojure. I'd switch to it if it was running inside the Erlang runtime (like Elixir does).

To be clear, I'm not questioning your choice of runtime or language. I'm just curious why you think that "Programming language syntax scarcely matters", as to me that seems the same as saying "How a codebase is architectured and designed scarcely matters".
I don't see how the latter follows from the former? The former is much bigger and more abstract; syntax is just one of the vehicles to try and codify it.

F.ex. if you have an universal construct of green threads / fibers then 7 PLs could express it 7 different ways, yet underneath they'd all be the same.

The programming language informs the design of the system. As I said in my earlier comment, an idiomatic Java codebase is going to be designed very differently to an idiomatic Clojure codebase, even if they both intend to solve the same problem.
But that's still not a function of the syntax per se; Java has no immutability encoded in its runtime, hence it does not offer it as a syntax either.
Scala has no immutability encoded in its runtime either (as it's the same as Java), but yet syntactically it's immutable in practice. Will the JRE technically allow a val to be edited through some third party thread inspecting your code and messing with memory? Sure. But it's not a reasonable fear in any real world environment, where I cannot remember, in 15+ years of professional scala, a case where anything I expected to be immutable (everything) to be mutated under me. Nowadays people using in in an FP style don't even think of the physical threads, as green thread libraries are taking care of all the scheduling.

So focusing on the runtime's guarantees doesn't seem like a practicality focused argument to me.

But syntax must necessarily include what it's representing, no? For instance, `{:a 1}` represents an immutable map in Clojure, in the same way that `42` represents an immutable integer in Java.
Those differences are not due to the syntax, they're due to much deeper things like the differing type system.
I'm not sure I agree. Certainly there are differences other than syntax, but that doesn't mean syntax is irrelevant. For instance, would Clojure programmers use maps as much if there was no syntax for map literals?

Syntax determines what parts of a language are within easy reach, and therefore affects how programmers use the language. Tools that a syntax make easy are used often; tools that syntax makes hard are used infrequently. This indirectly impacts how a piece of software is designed.

I can't endorse it because I've never used it, but: https://zread.ai/clojerl/clojerl/12-clojure-to-erlang-code-g...