5 ms·

I have never really understood people‘s aversion to parentheses. Many languages require them in ad-hoc ways to groups expressions. For S-expressions, you give u

by bmitc 4y ago

I have never really understood people‘s aversion to parentheses. Many languages require them in ad-hoc ways to groups expressions. For S-expressions, you give up some mild convenience and looks for extremely consistent semantics.

krapp 4y ago
It's not so much an aversion to parentheses as an aversion to nothing but parentheses. Other languages use other brackets to indicate different contexts, but s-expressions can more difficult to read. The idiom of putting all of your end parens on a single line doesn't help. And for most people, the mild convenience of readability is preferable to the consistent semantics.
- kazinator 4y ago
  > The idiom of putting all of your end parens on a single line doesn't help. Yes it does; doing it any other way is strictly worse regardless of where you stand on parentheses as such.
- pfdietz 4y ago
  I don't think the syntax has anything to do with the outcome. Some people like to complain about it, but it's just meaningless noise.
  - krapp 4y ago
    No, disagreements with your opinions are not just meaningless noise.
    - pfdietz 4y ago
      It's not meaningless because I disagree with it, it's meaningless because it had nothing to do with why Lisps didn't take over.
- Oreb 4y ago
  What’s the problem with having the end parens on a single line? I never understood why languages with curly brace syntax don’t do the same. A line of code containing nothing but a curly brace seems like a waste of screen real estate to me. It contains absolutely no information (the end of the block can be seen by indentation anyway).
  - krapp 4y ago
    One could just as easily write s-expressions using whitespace, so why bother with parens at all? Because the human brain is a pattern-matching organ and sometimes redundancy in a signal is useful. I've never understood the lispers' insistence that saving "screen real estate" is a primary concern. Source code is meant to be read, and the more easily code is read, the more utility is has.
    - Oreb 4y ago
      Source code is indeed meant to be read, and at least to me, low information density seriously hurts readability. I prefer both Python-style indentation based syntax and multiple parens at the end of the line over C-style syntax with closing braces alone on a line. If I write code in a language with curly brace syntax and I don’t have to share the code with others, I prefer to use multiple closing braces on the same line – like Lisp parens – because of improved readability.
    - pfdietz 4y ago
      Parens allow an editor to create the proper indentation. You can think of Lisp's paren syntax as the syntactic analogue of Lisp's very simple static type system. To get macros to work with a conventional grammar's complexity is much more annoyingly complex.
musicale 4y ago
> I have never really understood people‘s aversion to parentheses A common refrain from Lisp family language enthusiasts. (Personally I prefer Smalltalk-style "conversational" syntax to Lisp-style or C-style syntax, yet it's similarly unpopular.) For better or for worse, the vast majority of programmers seem to have voted with their feet for C-style syntax (C/C++/Java/JavaScript/etc.) and its variants (Python). In a C/C++/Java/JavaScript world, C syntax has a fair amount of leverage. It's a shame that Dylan didn't continue, as it seems to have taken a decent crack at adding algebraic syntax to Common Lisp - arguably realizing McCarthy's original vision of infix M-expressions as a more programmer-friendly syntax. I wonder how hard it would be to add a Dylan-style syntax layer to modern CL? Be that as it may, one can readily write Lisp/Scheme-style programs in JavaScript. See Crockford's "The Little JavaScripter."[1] The major omission/deficiency being macros for JavaScript syntax. [1] https://www.crockford.com/little.html https://www.crockford.com/little.html
- housel 4y ago
  (Open) Dylan is surviving just fine, and we expect to do a new release later this month.
  - wott 4y ago
    I haven't given a look at this language in a few years; is it still so that there are no enums, and that operators must be surrounded by spaces?
    - cgay 4y ago
      Yes. Making a macro for defining enums isn't that hard (there's one here: https://github.com/cgay/uncommon-dylan/blob/master/enum.dylan https://github.com/cgay/uncommon-dylan/blob/master/enum.dyla...). I, for one, welcome my whitespace-surrounded operator overlords, but if you really don't want that you're welcome to use function-call syntax for them.
  - dannymi 4y ago
    As a Guix developer (there's a lot of Scheme and Common Lisp in Guix :) ), every few years I check on Open Dylan but so far each time there was something missing that made me unable to package it for Guix (building it entirely from source). I've checked it a few minutes ago and Open Dylan's ./configure says to download a bootstrap compiler from https://opendylan.org/download/index.html https://opendylan.org/download/index.html first -- but there's no such bootstrap compiler there. Do you have some hints on how to package it?
lakecresva 4y ago
The syntax is consistent, I don't know about the semantics. The trade-off is that it becomes more difficult to glance at a piece of code and visually distinguish what's what.
layer8 4y ago
The syntactic consistency is at the same time its downfall: everything looks the same. (Functional languages like Haskell have a similar problem.) It’s more accommodating to human cognition if at least some part of the complexity and diversity of conceptual constructs in programming is represented in the syntax, meaning a certain range of different syntactic constructs that humans can attach meaning to. There is a sweet spot in syntactic diversity that matches the middle of the bell curve across programmers of how human cognition can absorb code. And that sweet spot isn’t on the more “spartan” side where Lisp resides. A different extreme are the more “cryptic” languages like APL and descendants. In a certain way, everything looks the same in those as well.
- bmitc 4y ago
  I can understand this argument. However, at the same time, S-expressions do allow for rather expressive function names not usually available in other languages. various arrows, question and other punctuation makes, etc. can make for some nice function names. I do agree with the sentiment to some degree though that it all looks the same. In an aesthetic sense, there is something I do like about it though. Being a fan of both ML and Scheme, I have actually been experimenting with a syntax that is a hybrid of the two. I’m still in the experimentation phase, but it’s an interesting exercise.
  - layer8 4y ago
    > expressive function names Yes, but those are effectively library conventions, not fixed properties of the language. Maybe more importantly, names aren’t a structural construct, like a for loop or a class definition. And, arguably, you can have similar syntax in other languages, like e.g. `!` in Rust or the type sigils ($, @) in Perl, except that here you can be sure of their semantics.
    - bmitc 4y ago
      The naming is enabled by the way S-expressions work and aren't merely convention. Handling such syntax in non-parenthetic languages is difficult because of the overlap with the other meaning of those infix operators in the language. For example, in F#, if I have a function named `string->number`, then the parser doesn't know if I mean `(string) - (>number)`, `(string-) > (number)`, `(string) -> (number)`, or the function `string->number`.
zshrdlu 4y ago
I've ever understood it either. I love s-expressions! But I suppose there must be something to the complaint. If you ask me I'd say Python's space-as-syntax is far more horrible, but doesn't get nearly the same amount of vitriol.
kazinator 4y ago
I've been working with Lisp for over twenty-two years and still got tripped up recently by something that was (if (condition) ;; <- must be when, not if! (do-this) (do-that)) Phony complaints about problems with editing parentheses and getting them to match are just trolling nonsense, but Lispers should acknowledge this kind of problem: when your editor has already helped you ensure that the code has valid syntax, everything is beautifully indented and compiles without diagnostics, but you have a mistake like this: parentheses being closed in the wrong place, not including something, or the wrong operator like the above. There are similar problems in other languages; no notation is perfect, and attempted cures for some of these problems can be worse than the diseases. GCC's relatively recent "misleading indentation" warning is a good example of a cure that has no downside (that I can quickly think of). It can catch code like: if (condition) do_this(); do_that(); // not part of the if statement, but indented deceptively No language save you from writing a program similar to the one you should be writing, but which is correct for a different set of requirements relative to what you want. Just verification and testing.
- jlokier 4y ago
  (if (condition) ;; <- must be when, not if! (do-this) (do-that)) I didn't find that to be a common problem when writing Emacs Lisp at least. The "misleading indentation" warning is relevant thre. If you enter the above code into Emacs, auto-indenting as you go, it will indent like this, making it obvious you meant `when`: (if (condition) (do-this) (do-that))

by bmitc 4y ago

krapp 4y ago

It's not so much an aversion to parentheses as an aversion to nothing but parentheses. Other languages use other brackets to indicate different contexts, but s-expressions can more difficult to read. The idiom of putting all of your end parens on a single line doesn't help. And for most people, the mild convenience of readability is preferable to the consistent semantics.

kazinator 4y ago
> The idiom of putting all of your end parens on a single line doesn't help. Yes it does; doing it any other way is strictly worse regardless of where you stand on parentheses as such.
pfdietz 4y ago
I don't think the syntax has anything to do with the outcome. Some people like to complain about it, but it's just meaningless noise.
- krapp 4y ago
  No, disagreements with your opinions are not just meaningless noise.
  - pfdietz 4y ago
    It's not meaningless because I disagree with it, it's meaningless because it had nothing to do with why Lisps didn't take over.
Oreb 4y ago
What’s the problem with having the end parens on a single line? I never understood why languages with curly brace syntax don’t do the same. A line of code containing nothing but a curly brace seems like a waste of screen real estate to me. It contains absolutely no information (the end of the block can be seen by indentation anyway).
- krapp 4y ago
  One could just as easily write s-expressions using whitespace, so why bother with parens at all? Because the human brain is a pattern-matching organ and sometimes redundancy in a signal is useful. I've never understood the lispers' insistence that saving "screen real estate" is a primary concern. Source code is meant to be read, and the more easily code is read, the more utility is has.
  - Oreb 4y ago
    Source code is indeed meant to be read, and at least to me, low information density seriously hurts readability. I prefer both Python-style indentation based syntax and multiple parens at the end of the line over C-style syntax with closing braces alone on a line. If I write code in a language with curly brace syntax and I don’t have to share the code with others, I prefer to use multiple closing braces on the same line – like Lisp parens – because of improved readability.
  - pfdietz 4y ago
    Parens allow an editor to create the proper indentation. You can think of Lisp's paren syntax as the syntactic analogue of Lisp's very simple static type system. To get macros to work with a conventional grammar's complexity is much more annoyingly complex.

musicale 4y ago

> I have never really understood people‘s aversion to parentheses A common refrain from Lisp family language enthusiasts. (Personally I prefer Smalltalk-style "conversational" syntax to Lisp-style or C-style syntax, yet it's similarly unpopular.) For better or for worse, the vast majority of programmers seem to have voted with their feet for C-style syntax (C/C++/Java/JavaScript/etc.) and its variants (Python). In a C/C++/Java/JavaScript world, C syntax has a fair amount of leverage. It's a shame that Dylan didn't continue, as it seems to have taken a decent crack at adding algebraic syntax to Common Lisp - arguably realizing McCarthy's original vision of infix M-expressions as a more programmer-friendly syntax. I wonder how hard it would be to add a Dylan-style syntax layer to modern CL? Be that as it may, one can readily write Lisp/Scheme-style programs in JavaScript. See Crockford's "The Little JavaScripter."[1] The major omission/deficiency being macros for JavaScript syntax. [1] https://www.crockford.com/little.html https://www.crockford.com/little.html

housel 4y ago
(Open) Dylan is surviving just fine, and we expect to do a new release later this month.
- wott 4y ago
  I haven't given a look at this language in a few years; is it still so that there are no enums, and that operators must be surrounded by spaces?
  - cgay 4y ago
    Yes. Making a macro for defining enums isn't that hard (there's one here: https://github.com/cgay/uncommon-dylan/blob/master/enum.dylan https://github.com/cgay/uncommon-dylan/blob/master/enum.dyla...). I, for one, welcome my whitespace-surrounded operator overlords, but if you really don't want that you're welcome to use function-call syntax for them.
- dannymi 4y ago
  As a Guix developer (there's a lot of Scheme and Common Lisp in Guix :) ), every few years I check on Open Dylan but so far each time there was something missing that made me unable to package it for Guix (building it entirely from source). I've checked it a few minutes ago and Open Dylan's ./configure says to download a bootstrap compiler from https://opendylan.org/download/index.html https://opendylan.org/download/index.html first -- but there's no such bootstrap compiler there. Do you have some hints on how to package it?

lakecresva 4y ago

The syntax is consistent, I don't know about the semantics. The trade-off is that it becomes more difficult to glance at a piece of code and visually distinguish what's what.

layer8 4y ago

The syntactic consistency is at the same time its downfall: everything looks the same. (Functional languages like Haskell have a similar problem.) It’s more accommodating to human cognition if at least some part of the complexity and diversity of conceptual constructs in programming is represented in the syntax, meaning a certain range of different syntactic constructs that humans can attach meaning to. There is a sweet spot in syntactic diversity that matches the middle of the bell curve across programmers of how human cognition can absorb code. And that sweet spot isn’t on the more “spartan” side where Lisp resides. A different extreme are the more “cryptic” languages like APL and descendants. In a certain way, everything looks the same in those as well.

bmitc 4y ago
I can understand this argument. However, at the same time, S-expressions do allow for rather expressive function names not usually available in other languages. various arrows, question and other punctuation makes, etc. can make for some nice function names. I do agree with the sentiment to some degree though that it all looks the same. In an aesthetic sense, there is something I do like about it though. Being a fan of both ML and Scheme, I have actually been experimenting with a syntax that is a hybrid of the two. I’m still in the experimentation phase, but it’s an interesting exercise.
- layer8 4y ago
  > expressive function names Yes, but those are effectively library conventions, not fixed properties of the language. Maybe more importantly, names aren’t a structural construct, like a for loop or a class definition. And, arguably, you can have similar syntax in other languages, like e.g. `!` in Rust or the type sigils ($, @) in Perl, except that here you can be sure of their semantics.
  - bmitc 4y ago
    The naming is enabled by the way S-expressions work and aren't merely convention. Handling such syntax in non-parenthetic languages is difficult because of the overlap with the other meaning of those infix operators in the language. For example, in F#, if I have a function named `string->number`, then the parser doesn't know if I mean `(string) - (>number)`, `(string-) > (number)`, `(string) -> (number)`, or the function `string->number`.

zshrdlu 4y ago

I've ever understood it either. I love s-expressions! But I suppose there must be something to the complaint. If you ask me I'd say Python's space-as-syntax is far more horrible, but doesn't get nearly the same amount of vitriol.

kazinator 4y ago

I've been working with Lisp for over twenty-two years and still got tripped up recently by something that was (if (condition) ;; <- must be when, not if! (do-this) (do-that)) Phony complaints about problems with editing parentheses and getting them to match are just trolling nonsense, but Lispers should acknowledge this kind of problem: when your editor has already helped you ensure that the code has valid syntax, everything is beautifully indented and compiles without diagnostics, but you have a mistake like this: parentheses being closed in the wrong place, not including something, or the wrong operator like the above. There are similar problems in other languages; no notation is perfect, and attempted cures for some of these problems can be worse than the diseases. GCC's relatively recent "misleading indentation" warning is a good example of a cure that has no downside (that I can quickly think of). It can catch code like: if (condition) do_this(); do_that(); // not part of the if statement, but indented deceptively No language save you from writing a program similar to the one you should be writing, but which is correct for a different set of requirements relative to what you want. Just verification and testing.

jlokier 4y ago
(if (condition) ;; <- must be when, not if! (do-this) (do-that)) I didn't find that to be a common problem when writing Emacs Lisp at least. The "misleading indentation" warning is relevant thre. If you enter the above code into Emacs, auto-indenting as you go, it will indent like this, making it obvious you meant `when`: (if (condition) (do-this) (do-that))