3 ms·

This is such a undervalued benefit, once you've learned s-expressions, you can basically learn a bunch of languages without having to learn completely new synta

This is such a undervalued benefit, once you've learned s-expressions, you can basically learn a bunch of languages without having to learn completely new syntax. It'll be slightly different, with different idioms and names, but a hell of a lot easier than doing the same across every "It's like C but 50% of the syntax is different actually" language out there, which is most of them.

jurip 5mo ago
Is the syntax really the stumbling block for most languages? Would Rust's lifetimes or Swift's isolation rules be easier if they used more parens? Are the scoping rule differences between Emacs Lisp and Scheme easier to comprehend because the syntax is similar?
- embedding-shape 5mo ago
  Yes, a commonly occurring stumbling block for me is trying to use one language's syntax while actually programming in another, especially when it comes to all the Algol/C-like language, I probably mix things on a daily basis. The concepts would be easier to grok up front if they just used normal function calls instead of "And now for this special syntax that only exists for this particular feature" which just adds more things to remember, instead of just the concepts themselves.
- dragandj 5mo ago
  Yes it is, because as soon as programmers step out of the most basic language level (which is kinda similar in most mainstream languages) there's a bunch of wildly different concepts, with wildly different ways of writing them. Writing them in isolation might be manageable, but it's combining them effectively that gets hairy very quickly, unless one is very experienced in said language. But then, translating that to OTHER languages becomes a bar that is too high!
- iLemming 5mo ago
  [dead]
- lelanthran 5mo ago
  > Would Rust's lifetimes or Swift's isolation rules be easier if they used more parens? For me, certainly. But it's not a matter of adding parens, it's more removing extra syntax.
- bryanrasmussen 5mo ago
  well sometimes you get complaints in particular languages that someone has written code like they are a Java programmer, or their code is not rubyish enough, or pythonic enough, and so on. So often people coming from one linguistic syntactical style express themselves in that style which makes their code in the new language less understandable or maintainable.

jurip 5mo ago

Is the syntax really the stumbling block for most languages? Would Rust's lifetimes or Swift's isolation rules be easier if they used more parens? Are the scoping rule differences between Emacs Lisp and Scheme easier to comprehend because the syntax is similar?

embedding-shape 5mo ago
Yes, a commonly occurring stumbling block for me is trying to use one language's syntax while actually programming in another, especially when it comes to all the Algol/C-like language, I probably mix things on a daily basis. The concepts would be easier to grok up front if they just used normal function calls instead of "And now for this special syntax that only exists for this particular feature" which just adds more things to remember, instead of just the concepts themselves.
dragandj 5mo ago
Yes it is, because as soon as programmers step out of the most basic language level (which is kinda similar in most mainstream languages) there's a bunch of wildly different concepts, with wildly different ways of writing them. Writing them in isolation might be manageable, but it's combining them effectively that gets hairy very quickly, unless one is very experienced in said language. But then, translating that to OTHER languages becomes a bar that is too high!
iLemming 5mo ago
[dead]
lelanthran 5mo ago
> Would Rust's lifetimes or Swift's isolation rules be easier if they used more parens? For me, certainly. But it's not a matter of adding parens, it's more removing extra syntax.
bryanrasmussen 5mo ago
well sometimes you get complaints in particular languages that someone has written code like they are a Java programmer, or their code is not rubyish enough, or pythonic enough, and so on. So often people coming from one linguistic syntactical style express themselves in that style which makes their code in the new language less understandable or maintainable.