3 ms·

I've worked with programs in half a dozen Lisp dialects and everyone who claims Lisp is hard to understand because of the syntax is wrong. The only reason I cou

by sedachv 16y ago

I've worked with programs in half a dozen Lisp dialects and everyone who claims Lisp is hard to understand because of the syntax is wrong. The only reason I could work with so many dialects and so many programs is because the syntax is uniform. If you think you have an idea for how to "improve" Lisp syntax that involves an ambiguous infix grammar, please stop trolling and go write some Python.

silentbicycle 16y ago
Some people seem to have a hard time with deeply nesting languages. Anecdotally, they seem to prefer "chaining" constructs, like "someObj.method(arg).otherMethod(arg2).om3(a4).om4(a5)". I'm fine with heavily nested Lisp-y code, but chaining code feels very awkward to me. Self and Prolog both have well-designed, completely unambiguous grammars. People interested in syntax design (or "fixing" Lisp) would do well to look at those, rather than trying to force a pseudo-Python syntax on Lisp. Python's grammar has too many edge cases. (Lua's syntax is also quite simple, though not as much as Self's.) In the end, clear semantics are at least as important as a good syntax. Lisp has very clear semantics. So do ML and Erlang, another language which has a bit of a quirky syntax.
- sedachv 16y ago
  "Anecdotally, they seem to prefer "chaining" constructs, like "someObj.method(arg).otherMethod(arg2).om3(a4).om4(a5)". " The thing with fluent interfaces is they're identical to nested Lisp code, except they read left to right instead of right to left. I suspect writers of Hebrew and Arabic would find chaining to be more confusing than nested Lisp code for that reason. Also worth noting is that a popular style of indenting chained fluent calls is by splitting them by lines, like: someObj.method(arg) .otherMethod(arg2) .om3(a4) .om4(a5); That's not that different from formatting Lisp code.

by sedachv 16y ago

silentbicycle 16y ago

Some people seem to have a hard time with deeply nesting languages. Anecdotally, they seem to prefer "chaining" constructs, like "someObj.method(arg).otherMethod(arg2).om3(a4).om4(a5)". I'm fine with heavily nested Lisp-y code, but chaining code feels very awkward to me. Self and Prolog both have well-designed, completely unambiguous grammars. People interested in syntax design (or "fixing" Lisp) would do well to look at those, rather than trying to force a pseudo-Python syntax on Lisp. Python's grammar has too many edge cases. (Lua's syntax is also quite simple, though not as much as Self's.) In the end, clear semantics are at least as important as a good syntax. Lisp has very clear semantics. So do ML and Erlang, another language which has a bit of a quirky syntax.

sedachv 16y ago
"Anecdotally, they seem to prefer "chaining" constructs, like "someObj.method(arg).otherMethod(arg2).om3(a4).om4(a5)". " The thing with fluent interfaces is they're identical to nested Lisp code, except they read left to right instead of right to left. I suspect writers of Hebrew and Arabic would find chaining to be more confusing than nested Lisp code for that reason. Also worth noting is that a popular style of indenting chained fluent calls is by splitting them by lines, like: someObj.method(arg) .otherMethod(arg2) .om3(a4) .om4(a5); That's not that different from formatting Lisp code.