6 ms·

I find it's better to think in terms of "familiar" vs "not familiar" rather than "easy" / "hard". Lisp syntax to me is the easiest -maybe with Forth and Smallta

I find it's better to think in terms of "familiar" vs "not familiar" rather than "easy" / "hard". Lisp syntax to me is the easiest -maybe with Forth and Smalltalk- syntax around, certainly orders of magnitude easier than Python's. And I don't mean just semantics, but also conceptual beauty. There's something about it that feels so elegant that other languages do not possess (again with Forth / Smalltalk exceptions). I can take a young curious kid with no previous exposure to programming, and teach Lisp syntax in under 5 minutes. But a kid with no previous exposure to programming is nothing like your average developer with strong pre-existing conditioning about how programming languages must look like. And this is the issue I feel with a lot of folks complaining about Lisp syntax. It's easy but it's not _familiar_ and some find it harder than others to get used to this discrepancy.

baq 4y ago
as the saying goes, the only intuitive user interface is the nipple.
- dagw 4y ago
  And the only people who say that are people who never have struggled for hours trying to teach a baby to breastfeed
  - baq 4y ago
    Wife managed to breastfeed four. Anegdata but it seemed rather intuitive. I’m aware not everyone is so lucky.
    - kazinator 4y ago
      Even many of the babies who do well have to learn. Anything learned is not intuitive by definition.
  - robertlagrant 4y ago
    It's a union of them and people who know that their personal experience is not always representative of general experience.
  - kazinator 4y ago
    That saying was probably invented by the same dolt who came up with "easy like taking candy from a baby", without having actually tried it.
- deleted 4y ago
  [deleted]
giraffe_lady 4y ago
I love lisp but there is the practical problem of paren juggling. You either need to come up with and execute by hand a line-break-and-indent system on the spot, or use tooling to manage them. It's not a huge hurdle and other languages have equivalent problems. But the lisp one is particularly ill-suited to other tools, even visual techniques like manually aligning indents. I've taught programming to beginners, including lisps, and it's definitely one of the early disorientations even without prior expectations about code. You don't need much: I eventually settled on just giving them sublime with rainbow parens and telling them to hit enter a lot. But you need something and it's not obvious what's missing unless someone points you in the right direction.
- metroholografix 4y ago
  If Hal Abelson and Jerry Sussman can use Lisp syntax to teach an iconoclastic, supremely philosophical class about programming that must rank amongst the best ever conceived and taught, 40 years ago, with blackboards and pieces of chalk, your average newcomer to Lisp should breeze through the process today. I've met a lot of folks that seem to possess mental models that are fundamentally mismatched with what Lisp expects: It's not just the syntax but a lot of the base models of the language that demand an open mind and time involvement before they get imprinted. And at least in some cases, blaming the parens becomes the easy way out of why one doesn't get it.
  - jepler 4y ago
    On a blackboard it didn't matter whether all the parentheses matched all the time
    - metroholografix 4y ago
      What matters on the blackboard (or a book) is "understanding" and that is not affected by a missing paren or two (which is a testament to Lisp's regularity of syntax). When they wanted their programs executed by a computer, their editor -Edwin- matched parens, exactly like how one would do it today, or even easier with things like Paredit.
lastofus 4y ago
After writing Clojure for a few years, there were several times where I ended up with a complex function with unbalanced parens, and the only way I could fix it was to basically re-write the function piece by piece. This is something I've never had to do in any other language. I'd also end up in not great places when utilizing parinfer while editing code written using different formatting than what parinfer expected. I'd have to fall back to paredit and hope for the best. This is all to say that yes, sometimes editing lisp syntax is "hard", at least for me. Turns out some humans make so-so AST parsers. That said, structural editing is great once you get good at it, and something I miss back in other languages.
- soegaard 4y ago
  > After writing Clojure for a few years, there were several times where I ended up with a complex function with unbalanced parens, and the only way I could fix it was to basically re-write the function piece by piece. That's the punishment for removing some of the "reduntant" parentheses from Scheme. Compare Clojure: (let [a 1 b 2] (+ a b)) Scheme: (let ([a 1] [b 2]) (+ 1 2)) If for some reason, say, `b` get deleted a Scheme compiler can tell you which binding pair has a problem. In more complicated setups, in Scheme/Racket I indent the piece of code, and from the indentation I can see, where end parenthesis is missing.
- kazinator 4y ago
  What editor were you using? Maybe it had broken indentation? You should be able to indent the code automatically and then the wrong subordination of the pieces shows up as wrong indentation. Like, e.g. what you think should be inside some conditional statement isn't intended at the expected level for that role.
- outworlder 4y ago
  > After writing Clojure for a few years, there were several times where I ended up with a complex function with unbalanced parens, and the only way I could fix it was to basically re-write the function piece by piece. Mess up Python indentation and you get something like that, but worse.
capn_duck 4y ago
I strongly disagree that Lisp syntax is straightforward. Racket/Scheme is decent, but Common Lisp and other Lisp-2's can be incredibly confusing. Having different value and function namespaces for symbols is complicated enough, but the worse problem is that the simple evaluation rules don't always apply. The base case is simple enough, the symbol-function value of the first symbol in a list is looked up, the rest of the arguments are evaluated or self-evaluated, then passed in to the function. The problem is that when the first symbol is a macro, you need to remember which of the following arguments are evaluated, or taken as unevaluated forms. Anyone who thinks this is easier to parse because there's less syntax either has too little experience with Common Lisp, or is kidding themselves.
- User23 4y ago
  The syntax is straightforward. You're referring to semantics. And in that respect, yes, Common Lisp is a very complicated language. The specification is about a thousand pages after all. I wouldn't say it's more complicated than C++ though, and personally I like simple syntax plus complicated semantics considerably more than complicated syntax and semantics. Personally I don't find separate function and value namespaces particularly confusing, but I do agree that it introduces some inelegance. Then again I'm demented enough that I think Perl is beautiful so YMMV. Even so there are some syntactic hints in terms of symbol naming, like how you can be pretty confident that a form that starts with WITH- is probably some kind of UNWIND-PROTECT macro that grabs a resource and cleans up after itself. Another example is that a symbol with asterisks for the first and last characters names a special variable.
- kazinator 4y ago
  The syntax is easy in Lisp, but you don't know what it means without having the vocabulary of operators. The vocabulary is fluid and varies from dialect to dialect. However, the vocabulary part of a Lisp dialect consists of things which are named. Names can easily be looked up in documentation. Furthermore, you know what is and is not part of the form even if you don't recognize the operator: you know that (fnoozle blub (grogg)) q42 is invoking fnoozle with two argument expressions, and q42 has no part of it. You don't know how/if those two arguments are evaluated but if you look up fnoozle in the manual, it should be clear. The manual will talk about the arguments, and you can identify which of those is blub and which is (grogg).

baq 4y ago

as the saying goes, the only intuitive user interface is the nipple.

dagw 4y ago
And the only people who say that are people who never have struggled for hours trying to teach a baby to breastfeed
- baq 4y ago
  Wife managed to breastfeed four. Anegdata but it seemed rather intuitive. I’m aware not everyone is so lucky.
  - kazinator 4y ago
    Even many of the babies who do well have to learn. Anything learned is not intuitive by definition.
- robertlagrant 4y ago
  It's a union of them and people who know that their personal experience is not always representative of general experience.
- kazinator 4y ago
  That saying was probably invented by the same dolt who came up with "easy like taking candy from a baby", without having actually tried it.
deleted 4y ago
[deleted]

giraffe_lady 4y ago

I love lisp but there is the practical problem of paren juggling. You either need to come up with and execute by hand a line-break-and-indent system on the spot, or use tooling to manage them. It's not a huge hurdle and other languages have equivalent problems. But the lisp one is particularly ill-suited to other tools, even visual techniques like manually aligning indents. I've taught programming to beginners, including lisps, and it's definitely one of the early disorientations even without prior expectations about code. You don't need much: I eventually settled on just giving them sublime with rainbow parens and telling them to hit enter a lot. But you need something and it's not obvious what's missing unless someone points you in the right direction.

metroholografix 4y ago
If Hal Abelson and Jerry Sussman can use Lisp syntax to teach an iconoclastic, supremely philosophical class about programming that must rank amongst the best ever conceived and taught, 40 years ago, with blackboards and pieces of chalk, your average newcomer to Lisp should breeze through the process today. I've met a lot of folks that seem to possess mental models that are fundamentally mismatched with what Lisp expects: It's not just the syntax but a lot of the base models of the language that demand an open mind and time involvement before they get imprinted. And at least in some cases, blaming the parens becomes the easy way out of why one doesn't get it.
- jepler 4y ago
  On a blackboard it didn't matter whether all the parentheses matched all the time
  - metroholografix 4y ago
    What matters on the blackboard (or a book) is "understanding" and that is not affected by a missing paren or two (which is a testament to Lisp's regularity of syntax). When they wanted their programs executed by a computer, their editor -Edwin- matched parens, exactly like how one would do it today, or even easier with things like Paredit.

lastofus 4y ago

After writing Clojure for a few years, there were several times where I ended up with a complex function with unbalanced parens, and the only way I could fix it was to basically re-write the function piece by piece. This is something I've never had to do in any other language. I'd also end up in not great places when utilizing parinfer while editing code written using different formatting than what parinfer expected. I'd have to fall back to paredit and hope for the best. This is all to say that yes, sometimes editing lisp syntax is "hard", at least for me. Turns out some humans make so-so AST parsers. That said, structural editing is great once you get good at it, and something I miss back in other languages.

soegaard 4y ago
> After writing Clojure for a few years, there were several times where I ended up with a complex function with unbalanced parens, and the only way I could fix it was to basically re-write the function piece by piece. That's the punishment for removing some of the "reduntant" parentheses from Scheme. Compare Clojure: (let [a 1 b 2] (+ a b)) Scheme: (let ([a 1] [b 2]) (+ 1 2)) If for some reason, say, `b` get deleted a Scheme compiler can tell you which binding pair has a problem. In more complicated setups, in Scheme/Racket I indent the piece of code, and from the indentation I can see, where end parenthesis is missing.
kazinator 4y ago
What editor were you using? Maybe it had broken indentation? You should be able to indent the code automatically and then the wrong subordination of the pieces shows up as wrong indentation. Like, e.g. what you think should be inside some conditional statement isn't intended at the expected level for that role.
outworlder 4y ago
> After writing Clojure for a few years, there were several times where I ended up with a complex function with unbalanced parens, and the only way I could fix it was to basically re-write the function piece by piece. Mess up Python indentation and you get something like that, but worse.

capn_duck 4y ago

I strongly disagree that Lisp syntax is straightforward. Racket/Scheme is decent, but Common Lisp and other Lisp-2's can be incredibly confusing. Having different value and function namespaces for symbols is complicated enough, but the worse problem is that the simple evaluation rules don't always apply. The base case is simple enough, the symbol-function value of the first symbol in a list is looked up, the rest of the arguments are evaluated or self-evaluated, then passed in to the function. The problem is that when the first symbol is a macro, you need to remember which of the following arguments are evaluated, or taken as unevaluated forms. Anyone who thinks this is easier to parse because there's less syntax either has too little experience with Common Lisp, or is kidding themselves.

User23 4y ago
The syntax is straightforward. You're referring to semantics. And in that respect, yes, Common Lisp is a very complicated language. The specification is about a thousand pages after all. I wouldn't say it's more complicated than C++ though, and personally I like simple syntax plus complicated semantics considerably more than complicated syntax and semantics. Personally I don't find separate function and value namespaces particularly confusing, but I do agree that it introduces some inelegance. Then again I'm demented enough that I think Perl is beautiful so YMMV. Even so there are some syntactic hints in terms of symbol naming, like how you can be pretty confident that a form that starts with WITH- is probably some kind of UNWIND-PROTECT macro that grabs a resource and cleans up after itself. Another example is that a symbol with asterisks for the first and last characters names a special variable.
kazinator 4y ago
The syntax is easy in Lisp, but you don't know what it means without having the vocabulary of operators. The vocabulary is fluid and varies from dialect to dialect. However, the vocabulary part of a Lisp dialect consists of things which are named. Names can easily be looked up in documentation. Furthermore, you know what is and is not part of the form even if you don't recognize the operator: you know that (fnoozle blub (grogg)) q42 is invoking fnoozle with two argument expressions, and q42 has no part of it. You don't know how/if those two arguments are evaluated but if you look up fnoozle in the manual, it should be clear. The manual will talk about the arguments, and you can identify which of those is blub and which is (grogg).