5 ms·

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

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

pdimitar 4mo ago
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).
- weavejester 4mo ago
  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".
  - pdimitar 4mo ago
    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.
    - weavejester 4mo ago
      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.
      - pdimitar 4mo ago
        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.
        hibikir 4mo ago
        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.
        pdimitar 4mo ago
        You are citing a commendable exception (Scala) to tear down a bigger argument which is not exactly a fair discussion. Furthermore, if you trace my comments, you'll see that I had to choose PLs years ago (12+ to be precise). Things were quite different at the time. Java might have almost caught up today; back then we couldn't even be certain `synchronized` is stable all the time. Just saying. Scala did very well then, judging by your words. I could probably offer a loose analogy to Typescript as well; while it does compile to JS underneath, they added a stricter layer that makes programming in it more deterministic and stable. (Not the same thing because my main point was "runtime" but hey, show me a perfect analogy.) You are free to say your last sentence. I am free to disagree. My practice has shown me that runtimes bleed into syntax almost always. Exceptions exist, sure.
        weavejester 4mo ago
        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.
- jerf 4mo ago
  I can't endorse it because I've never used it, but: https://zread.ai/clojerl/clojerl/12-clojure-to-erlang-code-generation https://zread.ai/clojerl/clojerl/12-clojure-to-erlang-code-g...

pdimitar 4mo ago

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

weavejester 4mo ago
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".
- pdimitar 4mo ago
  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.
  - weavejester 4mo ago
    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.
    - pdimitar 4mo ago
      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.
      - hibikir 4mo ago
        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.
        pdimitar 4mo ago
        You are citing a commendable exception (Scala) to tear down a bigger argument which is not exactly a fair discussion. Furthermore, if you trace my comments, you'll see that I had to choose PLs years ago (12+ to be precise). Things were quite different at the time. Java might have almost caught up today; back then we couldn't even be certain `synchronized` is stable all the time. Just saying. Scala did very well then, judging by your words. I could probably offer a loose analogy to Typescript as well; while it does compile to JS underneath, they added a stricter layer that makes programming in it more deterministic and stable. (Not the same thing because my main point was "runtime" but hey, show me a perfect analogy.) You are free to say your last sentence. I am free to disagree. My practice has shown me that runtimes bleed into syntax almost always. Exceptions exist, sure.
      - weavejester 4mo ago
        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.
jerf 4mo ago
I can't endorse it because I've never used it, but: https://zread.ai/clojerl/clojerl/12-clojure-to-erlang-code-generation https://zread.ai/clojerl/clojerl/12-clojure-to-erlang-code-g...