Hacker News Reader

Comment by metroholografix | Hacker News Reader

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.

View on HN

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.

> 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.

Mess up Python indentation and you get something like that, but worse.

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.

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.

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.

On a blackboard it didn't matter whether all the parentheses matched all the time

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.

And if you leave out a paren, the resulting auto-indented structure will look obviously wrong, signalling that you made an error.

It's not so obvious in Python when you make an indentation error in a complicated if/elif/else structure.

In a language with a sane syntax, we can do this:

   if (A) {                  if (A) {
     B                         B
     C              -->        C
   }                           D
   D                           E
   E                         }

Imagine that is 300 lines long and BCDE contain their own nesting and such.

We can do a "git diff -w" and just see that the closing brace moved and that there are no changes in D and E.

Do the same in Python and "git diff -w" comes up empty.

It's not the parentheses or the Polish notation that matter. Those are covered in the first chapter of any Lisp/Scheme book and they are trivial, especially with a proper editor that understands structure and will indent unambiguously accordingly. Unless you're stuck on simple editors like Notepad or Nano, there's no issue here.

What's more challenging in Scheme, as Abelson and Sussman teach it, is the use of recursion instead of looping and in particular understanding that recursion is only equivalent to looping when the recursion is in "tail position", i.e. when there is nothing left for the calling function to do except return to its own caller.

Common Lisp style tends to use looping, not recursion.

I’ve watched those videos. IIRC, the parentheses always matched.

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.

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).

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.

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

And the only people who say that are people who never have struggled for hours trying to teach a baby to breastfeed

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.

It's a union of them and people who know that their personal experience is not always representative of general experience.

Wife managed to breastfeed four. Anegdata but it seemed rather intuitive.

I’m aware not everyone is so lucky.

Even many of the babies who do well have to learn.

Anything learned is not intuitive by definition.

Reply on news.ycombinator.com