A quick look at what Quicklisp has to offer for libraries should quickly convince people that fooling around with anything but Common Lisp would be very energy-consuming.
A quick look at what the job market has to offer (for those who interested in Lisp) should quickly convince people that learning anything but Clojure would be not only energy-consuming but also impractical.
I'm amused by the fact that when you criticize LISP's syntax, defenders always say the syntax doesn't matter and real Lisp programmers don't even see the parenthesis. But then you look at these implementations of Lisp-like variants of existing programming languages and the thing the developers are most enamored with is the repetitive, parenthesis-laden syntax of Lisp, while keeping the majority of the non-Lisp semantics in tact (adding just a few functional conveniences like first class functions).
I'm not even criticizing, most of these are hobby projects and you can code how you like. I just think it's funny how hard Lisp clings onto the parenthesis thing while claiming the parenthesis thing doesn't matter.
The thing that matters is that code is written as s-expressions, which has a simple textual serialization format with lists, symbols, numbers, strings, vectors and a bunch of other data types. Thus any Lisp form is automatically data: not simple strings or complex syntax trees.
This enables a bunch of stuff: code can be relatively easily treated as data. It allows easy code generation, transformations (-> macros), traversal (-> interpreters/compilers) or editing.
The parentheses are just a part of the s-expression textual syntax. The s-expressions then are used by basic operations like READ, MACROEXPAND, PRINT and EVAL. Additionally many of the primitive data functions can be used to manipulate code: first/rest, list, append, reverse, map, ...
You should look into Racket. Apart from getting some momentum due to the merger with Chez, it has a relatively big academic community backing it up.
And it's very different from other Lisps in the sense it's trying hard to be an ecosystem for language-oriented programming, which is probably taking the idea of macros to a new level.
I've used Common Lisp and Clojure for many years, but Racket looks more and more appealing to me.
The parentheses give you Macros, a completely uniform calling convention, and the "everything's an expression" programming style. These are arguably the things you cannot get from a non-lisp language. Almost everything else varies between lisp implementations.
The lack of syntax matters in the sense that once you don't have any you realise that it just gets in the way. Having lots of parentheses is a small price to pay for powerful tools so that's why "it doesn't matter". Non-lispers generally don't understand how lisp is different from their language of choice and therefore don't understand why the lack of syntax is an advantage.
Like the mainstream political arena, the most accurate explanations don't stick, but the most appealing ones do. The parentheses of Lisp's "function within the tuple" application disappear in the same way that other languages' function-before-the-tuple parenthesis disappear - it's not particularly noteworthy. "Don't even see the parenthesis" is talking past the real objection, which is that the depth of parenthesis in every other language does not matter - ie (expr) is equivalent to ((expr)). Whereas in Lisp they also mean another level of application.
I think an interesting synthesis is Haskell, where function calls are simply juxtaposition. Parenthesis are just grouping like most languages, but it ends up feeling quite Lispy.
Parenthesized sexprs are easy to parse (by both machines and humans) and Lisp text editors already have many convenient ways to work with them. There are though some interesting alternatives such as sweet-expressions[1] and wisp[2], but not too many people care about these.
I think the appeal of the syntax for those who get used to it is the regularity, like you said.
The advantage of the regularity isn't its human readability, but its ability to macro, no?
What I'd like to see is better tools for reading and editing such a regular syntax. Probably I should just learn emacs, but I'm thinking someone could make a more intuitive structured editor for LISP syntax. No need to mush around blobs of text when everything is nested lists.
It's not about syntax. It's about code being data and vice versa.
> Syntax, interestingly, complects meaning and order often in a very unidirectional way. Professor Sussman made the great point about data versus syntax, and it's super true. I don't care how many you really love the syntax of your favorite language. It's inferior to data in every way.
Yeah, I thought so too. I've been teaching myself Lisp as a side project, working through online tutorials and, more productively, Paul Graham's "ANSI Common Lisp", using SBCL and CLISP in a terminal window. OK, cool, try another Lisp, leverage my Python knowledge.
Took a look at the github of Pixie: "pre-alpha" and no docs whatever. Not for the student.
Hy is cleanly packaged, installed with pip3, has complete(ish) docs[1], great. So I installed it and started it, it puts up a REPL prompt, and I paste in one of the functions I've worked out:
(defun hello ()
(write-line "this is the prompt:")
(let ( (name (read-line)) )
(format t "Hello, ~A.~%" name)
)
)
Error message: "empty expressions are not allowed at top level"
Sorry? Exactly that usage, an empty expression when a function takes no argument, is used on (I just checked) page 20 of Graham. But ok, I try it without, "(defun hello" etc.
Error message: "NameError: name 'defun' is not defined"
You what? defun is introduced on page 14, and defined in the "Language Reference" Appendix of Graham. OK, wait, what does Hy use, if not defun? Search their tutorial chapter: "Define named functions with defn".
OK, this is a deal-breaker for somebody trying to learn (ahem) COMMON Lisp. Why would you do that, just arbitrarily change the probably third or fourth name a student learns after car, cdr and setv? And more importantly, if you have taken it on yourself to dick around with (ahem) Common Lisp at this basic point, what else have you changed that will break the examples in my textbook or online tutorial?
I have designed a programming language that borrows an important part of its architecture from Lisp(s) (maybe mostly Scheme, but also Kernel: http://klisp.org). However, I have always opposed to the concrete syntax of S-expressions (being mostly unable to be productive with it).
My arguments are not on the familiarity side (with the infix notation), but on the psychological one:
1. S-expressions are not the most simple, natural, or uniform surface form (as they claim); they do have syntactic sugar (quote, even lists themselves!, etc.), so why not to add some more sugar (but sufficiently abstract of course)?
2. Humans' brain has limited "stack" space (especially when closing parentheses); infix forms may "cascade" and do not consume the stack (equally machine on human, due to possibility of "tail recursion")
3. Lack of diverse "visual clues" for humans (note how most natural languages have 40-60 phonemes, and none less than 15)
4. S-expressions and homoiconicity are related but orthogonal features (so the homoiconicity argument is often not valid)
Having that said, when I finally managed to write a working 50+-lines program in Scheme, with "proper" indentation, I was just proud of it, and I said, "Wow, it looks cool!". But I am still on the side of the above rational arguments! My point is that as my experiment demonstrates, it is probably too easy to get on an emotional side of computer-human interaction once you accomplished something a bit challenging (like speaking in classic S-expressions)?
For me S-expressions feel like the most natural way to program because they compose naturally with zero ambiguity. Infix notation might be slightly clearer for simple expressions but it doesn't compose: As soon as you try to compose infix notation you have to add parens, depend on unstated precedence rules, or both. Lisp's philosophy is to just use parens everywhere, make everything composable, and have no precedence rules.
That said, I would hate to write Lisp code with Notepad. Fortunately nobody does this. In conjunction with a paren-matching, auto-indenting programmer's editor (which is roughly all of them these days), S-expressions are easy. A good editor is vital not just for writing Lisp programs but also for reading them.
I will not claim parentheses are mandatory. I find Haskell just as simple, unambiguous, and composable without (many) parens but that's only because it has automatic currying, and that takes a bit of practice to wrap one's head around.
My one counter argument for 1 and 2 is that with infix, I'm forever trying to remember precedence rules and in my own code, just end up wrapping everything in parentheses anyway, to be sure. In lisp, the ordering is always explicit.
For 3, that's one reason why I like Clojure's syntax: it has just enough extra syntax to break up the code and provide visual cues, at least for me.
Re 4, sure, you can even enable macros without homoiconicity, but with s-expressions, I find it to be mentally much simpler because I can just write a template and fill in the gaps and its natural since my code is in that form already. Overall, though, in all but a few cases, I think macros should be avoided in favour of pure data structures and functions, when possible.
You're right. Lisp syntax makes the totally wrong tradeoff of being slightly easier to parse for the machine, and much harder for the human. An eloquent name for it is that Lisp fails the squint test https://www.teamten.com/lawrence/writings/the_language_squin...
I love s expressions, i can now manipulate my code semantically thanks to paredit & co. Learning vim is the first step to being able to properly manipulate code. Paredit is the next and last step ;)
[+] [-] cracauer|6 years ago|reply
http://blog.quicklisp.org/
[+] [-] kryptiskt|6 years ago|reply
It's also an actively developed modern language not stuck in the 80s.
[+] [-] iLemming|6 years ago|reply
[+] [-] c3534l|6 years ago|reply
I'm not even criticizing, most of these are hobby projects and you can code how you like. I just think it's funny how hard Lisp clings onto the parenthesis thing while claiming the parenthesis thing doesn't matter.
[+] [-] lispm|6 years ago|reply
This enables a bunch of stuff: code can be relatively easily treated as data. It allows easy code generation, transformations (-> macros), traversal (-> interpreters/compilers) or editing.
The parentheses are just a part of the s-expression textual syntax. The s-expressions then are used by basic operations like READ, MACROEXPAND, PRINT and EVAL. Additionally many of the primitive data functions can be used to manipulate code: first/rest, list, append, reverse, map, ...
[+] [-] kazinator|6 years ago|reply
Of course it matters; it just doesn't matter in the sense of not being a problem.
Your argumentation is rooted in drifting across different semantics of the phrase "doesn't matter".
[+] [-] nextos|6 years ago|reply
And it's very different from other Lisps in the sense it's trying hard to be an ecosystem for language-oriented programming, which is probably taking the idea of macros to a new level.
I've used Common Lisp and Clojure for many years, but Racket looks more and more appealing to me.
[+] [-] fungiblecog|6 years ago|reply
The lack of syntax matters in the sense that once you don't have any you realise that it just gets in the way. Having lots of parentheses is a small price to pay for powerful tools so that's why "it doesn't matter". Non-lispers generally don't understand how lisp is different from their language of choice and therefore don't understand why the lack of syntax is an advantage.
[+] [-] mindslight|6 years ago|reply
I think an interesting synthesis is Haskell, where function calls are simply juxtaposition. Parenthesis are just grouping like most languages, but it ends up feeling quite Lispy.
[+] [-] pera|6 years ago|reply
[1] - https://srfi.schemers.org/srfi-110/srfi-110.html
[2] - https://srfi.schemers.org/srfi-119/srfi-119.html
[+] [-] manifestsilence|6 years ago|reply
The advantage of the regularity isn't its human readability, but its ability to macro, no?
What I'd like to see is better tools for reading and editing such a regular syntax. Probably I should just learn emacs, but I'm thinking someone could make a more intuitive structured editor for LISP syntax. No need to mush around blobs of text when everything is nested lists.
[+] [-] iLemming|6 years ago|reply
> Syntax, interestingly, complects meaning and order often in a very unidirectional way. Professor Sussman made the great point about data versus syntax, and it's super true. I don't care how many you really love the syntax of your favorite language. It's inferior to data in every way.
Rich Hickey
[+] [-] manifestsilence|6 years ago|reply
Pixie uses the RPython toolchain and is totally its own language, with its own VM and JIT.
Hy appears to be python with lisp syntax.
Both sound fascinating.
[+] [-] Naac|6 years ago|reply
Pixie does look very cool, but the project on github seems dead?
[+] [-] fernly|6 years ago|reply
Took a look at the github of Pixie: "pre-alpha" and no docs whatever. Not for the student.
Hy is cleanly packaged, installed with pip3, has complete(ish) docs[1], great. So I installed it and started it, it puts up a REPL prompt, and I paste in one of the functions I've worked out:
Error message: "empty expressions are not allowed at top level"Sorry? Exactly that usage, an empty expression when a function takes no argument, is used on (I just checked) page 20 of Graham. But ok, I try it without, "(defun hello" etc.
Error message: "NameError: name 'defun' is not defined"
You what? defun is introduced on page 14, and defined in the "Language Reference" Appendix of Graham. OK, wait, what does Hy use, if not defun? Search their tutorial chapter: "Define named functions with defn".
OK, this is a deal-breaker for somebody trying to learn (ahem) COMMON Lisp. Why would you do that, just arbitrarily change the probably third or fourth name a student learns after car, cdr and setv? And more importantly, if you have taken it on yourself to dick around with (ahem) Common Lisp at this basic point, what else have you changed that will break the examples in my textbook or online tutorial?
[1] https://docs.hylang.org/en/master/index.html[+] [-] pjmlp|6 years ago|reply
[+] [-] rusini|6 years ago|reply
My arguments are not on the familiarity side (with the infix notation), but on the psychological one:
1. S-expressions are not the most simple, natural, or uniform surface form (as they claim); they do have syntactic sugar (quote, even lists themselves!, etc.), so why not to add some more sugar (but sufficiently abstract of course)?
2. Humans' brain has limited "stack" space (especially when closing parentheses); infix forms may "cascade" and do not consume the stack (equally machine on human, due to possibility of "tail recursion")
3. Lack of diverse "visual clues" for humans (note how most natural languages have 40-60 phonemes, and none less than 15)
4. S-expressions and homoiconicity are related but orthogonal features (so the homoiconicity argument is often not valid)
Having that said, when I finally managed to write a working 50+-lines program in Scheme, with "proper" indentation, I was just proud of it, and I said, "Wow, it looks cool!". But I am still on the side of the above rational arguments! My point is that as my experiment demonstrates, it is probably too easy to get on an emotional side of computer-human interaction once you accomplished something a bit challenging (like speaking in classic S-expressions)?
[+] [-] dreamcompiler|6 years ago|reply
That said, I would hate to write Lisp code with Notepad. Fortunately nobody does this. In conjunction with a paren-matching, auto-indenting programmer's editor (which is roughly all of them these days), S-expressions are easy. A good editor is vital not just for writing Lisp programs but also for reading them.
I will not claim parentheses are mandatory. I find Haskell just as simple, unambiguous, and composable without (many) parens but that's only because it has automatic currying, and that takes a bit of practice to wrap one's head around.
[+] [-] dkersten|6 years ago|reply
For 3, that's one reason why I like Clojure's syntax: it has just enough extra syntax to break up the code and provide visual cues, at least for me.
Re 4, sure, you can even enable macros without homoiconicity, but with s-expressions, I find it to be mentally much simpler because I can just write a template and fill in the gaps and its natural since my code is in that form already. Overall, though, in all but a few cases, I think macros should be avoided in favour of pure data structures and functions, when possible.
[+] [-] LessDmesg|6 years ago|reply
[+] [-] globuous|6 years ago|reply
[+] [-] swlkr|6 years ago|reply
[+] [-] aidenn0|6 years ago|reply
[+] [-] haileris|6 years ago|reply
[+] [-] zabzonk|6 years ago|reply
[+] [-] threatofrain|6 years ago|reply
[+] [-] rwmurrayVT|6 years ago|reply
[+] [-] zitterbewegung|6 years ago|reply
[+] [-] byron_fast|6 years ago|reply