Hacker News Reader

Comment by zestyping | Hacker News Reader

This part was counterintuitive for me:

> We found the age-old belief that "lisp syntax is just too hard" is simply false; the main thing that most people lack is decent lisp-friendly tooling with a low barrier to entry, and DrRacket provides that.

If the syntax requires special tooling to make it usable, isn't that a sign that the syntax is hard?

Are there many people who believe Lisp syntax is as easy as Python or other non-Lisp languages? If that's true for you, I'd be interested in hearing more about your experience.

View on HN

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.

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

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.

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

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.

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.

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

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.

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.

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.

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

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

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

I had little experience with Lisp until recently when I converted a few hundred lines of Lua to Fennel. I have a lot of experience with Python.

I've always been scared of Lisp syntax, but after just a little experience with it it all kind of fades away and it feels like an indentation-based language, while remaining very compact. Now I'm like "why aren't all higher-level languages lisps"?

Editor tooling definitely helps, but it's one of those "skill floor skill ceiling" ideas. Parenthesis-based syntax has a slightly higher "skill floor" (takes more effort to edit), but with editor tooling has a much higher "skill ceiling", where experts can move blocks at the level of syntax rather than characters. Even just vscode's new bracket highlighting and guides are a small feature but a big help to see structure.

No one can convince me that Python is an easy or simple language.

For parentheses, I find Racket and in particular Scheme to be enjoyable. My primary reasons are that it creates a massive amount of regularity and consistency in the language, of which there is none in Python. I had my girlfriend at the time take the How to Code: Simple Data course on edX, which uses the Racket learning languages. Not once did I need to answer a syntax question. Not one complaint about parentheses. She had no prior experience programming.

I find the people who whine and moan about parentheses are usually ones who have massive preconceived notions of what programming should look like or are so deep in some other language they are resistant to change.

I honestly feel like the best textual syntax is something like ML (as found in F#) or Scheme. Anything else is basically just random tweaks and way too much time has been wasted on textual syntax, which is conceptually bounded in terms of its expressiveness. But programmers and computer scientists are extremely myopic. Somehow we graduated from punch cards to text files and have plateaued ever since.

> decent lisp-friendly tooling with a low barrier to entry, and DrRacket provides that

I'm not really sure what the commenter meant by that, but in my experience, all I ever needed was the auto-formatter and parentheses matching DrRacket provides. Matching delimiters occurs in any language, it's just that you have more of them.

> If the syntax requires special tooling to make it usable, isn't that a sign that the syntax is hard?

So, do you write your code on Notepad?

It's interesting that every time Lisp syntax comes up there's a comment like this. But when someone adds "refactoring" and "intellisense" to other languages it gets applauded. Why?

You dont need special tools. But being able to manipulate the sexpressions directly gives you more power.

If we were discussing teaching apprentice roof installers, you wouldn't argue that collated nails (the kind that feed into a nail gun) are worse for teaching because they are harder to use without additional tooling (a nail gun). The 'additional tooling' is in fact industry standard tooling that the apprentice will be using from the very start anyways, and that they need to be comfortable with as well.

Having seen >1mil EUR of machinery stop because of a quick fix to python code done without special editor and thus resulting in having one #\Space less in one line, I would say Python is the language that requires special tools - not Lisp.

Worst case, you can align your parens vertically, like many AutoLISP programmers did when their only tool was Notepad or EDIT.COM. And usually incorrect parens result in code blowing up at build time, not runtime. Counting parentheses is definitely easier than counting whitespace.

If anything, Lisp just happens to be language with community that embraced quite advanced editor enhancements before many other languages got invented, and thus lisper's baseline expectations might be bigger than other developers'

You can reduce this, in a manner of thinking, to structure control being produced by: A) Visible characters B) invisible characters

Yes.

I'll just claim probably forever that when semantics depend on you counting invisible characters, you really need specialized tools

I’ve been persuaded by HTDP that lisp, or at least “beginning student language” (BSL) is probably better than python for non programmers - if the goal is to understand programming.

I still like “think python” as an introductory text to programming https://greenteapress.com/thinkpython/html/index.html - and I’d still go python if the goal was a specific one-off outcome.

But now that I’ve gone through HTDP, that’ll be my textbook for beginners http://htdp.org/2022-2-9/Book/part_preface.html

Heavy book to drag to community evening classes though…

I believe lisp is easier than python in usage, but ONLY after you learned it. That might sound a bit strange but it's a classic issue most people ignore: ecosystem.

Python is "battery included" in the sense that with the language it's users can access a rich set of ready-usable code pip-able in a venv without any special gimmick and python itself is probably preinstalled in most desktops people who ever write a line of code use, that means python is not a stranger, it's a citizen of a familiar and ready made ecosystem for most users.

Lisp on contrary have many flavors, syntax is similar, but here is (defn, here (defun, ... and CL is still complex and not such immediate. QuickLisp is not here by default etc. Lisp is a stranger in most user's familiar ecosystem.

Non only Lisp is from a civilized age where computer were desktops, a unique ecosystem at the users fingertips, centered on users needs and desire. In that sense lisp is an ecosystem, not a part of a larger ecosystem the user already know. Again a stranger.

Once you know a bit let's say SBCL or Emacs it's far easier implementing something that do not demand something ready-made and absent (the aforementioned battery included) BUT if nobody teach them and only very few know them...

I say that fly a small plane is easier than drive a car, but while I do both things most people do not and so for them I say something alien and the subject of the topic is also alien to them. Most think that's easier turning the steering wheel obtaining a definite result instead of gently hit a stick to see loose effects. Of course that's true, if you are bound to a little path named a road, more specifically a small part of it, however it's far easier NOT being bound to such small areas and loosely move in the air, with far less strict limits all around. You have to try to understand though and so someone have to tech you up front... That's the modern Lisp issue...

> Of course that's true, if you are bound to a little path named a road, more specifically a small part of it, however it's far easier NOT being bound to such small areas and loosely move in the air, with far less strict limits all around.

That's a very interesting observation. It's also interesting in that when you get back to "high traffic" areas where you have to interact with others, the limits get stricter again.

I'll probably torture that analogy for a while.

I really like this analogy.

> If the syntax requires special tooling to make it usable, isn't that a sign that the syntax is hard?

I think it is easier to put a nail through a 2x4 than a push-pin, but that presupposes I have a hammer; if I have a nailgun it's going to be easier to put 100 nails in than 100 push-pins. If I have neither, then the push-pin wins. There are always tradeoffs, but it doesn't mean that nails are inherently "hard" and push-pins are inherently "easy"

> Are there many people who believe Lisp syntax is as easy as Python?

Even with python I find myself getting bogged down by missing a parenthesis here and there around function calls, but perhaps that problem is unique to me and my attention and memory issues. Syntax highlighting in editors is great, and certainly it helps me, but I wish for them to be even more interactive and assertive: it should mark fields with obvious errors like unclosed quotes and parentheses, I shouldn't have to wait after compile or run-time to be informed of these errors.

Aid that reduce syntax errors should always be welcome. Moreover, some of us have high working memory and some don't so I welcome opinionated tools like Spyder IDE and Jupyter that are hands-on in the dev stage, and serve to encourage a fun and exploratory dev environment.

> it should mark fields with obvious errors like unclosed quotes and parentheses

PyCharm does that and more.

What editor are you currently using?

It still won't catch if/elif/else mismatches.

Once I got into the habit of typing the corresponding closing entity (quote, paren, backtick, whatever) immediately after typing the opening one, and _then_ coming back to fill in the data in the enclosure, most of my syntax errors disappeared.

It's surprising how many professional devs don't have this habit. I learned it pairing one day.

My text editor automatically adds those in front of the cursor. It’ll also wrap a highlighted selection if you type the opening entity

For me, lisp was pretty intuitive when I first picked it up. It wasn't the first language I learned though.

When I was little my dad had a reverse polish notation calculator he explained and taught me to use. I think it was sort of a novelty for him, but when I encountered lisp in college my first thought was something like "oh this is just like reverse polish calculators".

There was sort of a strange learning curve for me though. The basics were fairly intuitive to me, then things got frustrating, and then easier again.

I really miss lisp though and wish it (or scheme or racket) had more widespread use, especially in numerical computing. I admit, though, that the hardware-lisp gap is bigger in my mind than the hardware-c gap, which extends to more procedural languages.

Syntax can be simple or complex, and - independently - easy or hard.

IMO Lisp's is hard, but simple; Python's is hard and complex.

Tooling can make it easier (keeping track of parentheses and significant whitespace, respectively), but not simpler.

I've done all my Common Lisp programming in Vim.

The TXR language was developed using nothing but Vim, for all the C and Lisp code.

The tooling is the same as for C: indentation, coloring, parenthesis matching, and that's more than you need.

E.g. visually select some code with V and cursor movement, then hit =, and it's nicely reindented.

Vim's Lisp indentation is based on the classic Vi ':set lisp' mode which was in Unix since 1980 something. That is combined with some generic autoindent settings, most of which are pretty much the same as for C.

GNU mkid (from the id-utils project) indexes Lisp like other languages for quickly finding all references to an identifier.

Exuberant Ctags recognizes Lisp files, for jump-to-definition.

People who talk about special tooling for Lisp must be coming from the perspective of Nano or Notepad.

Or else from the perspective of "any programming editor which is not the one I know is 'special tooling', and the one I know doesn't recognize any Lisp file suffixes."

> If the syntax requires special tooling to make it usable

It doesn't. Lisp is perfectly editable in Vim, with basic indentation and syntax highlighting. Lisp's properties make it easy to work with even in that type of basic editor without special Lisp support.

Exuberant ctags indexes Lisp code for jump to definition.

No, the syntax is easy. Aligning the paranthesis is the annoying part where the tooling comes in.

> If the syntax requires special tooling to make it usable, isn't that a sign that the syntax is hard?

Not in this case. Lisp syntax is easy, people lack familiarity.

The only "hard" part is checking that the number of parens are right. But it's not that other programming languages don't have equivalent "hard" problems, like closing the right kind and amount of brackets on C, of whitespace problems in python.

If you make an error in the number of closing parens, and hit return, your cursor will end up in an unexpected place. That's the sign you should take a second look at what you just did.

> If the syntax requires special tooling to make it usable,

In Linux I'm using Geany https://www.geany.org/ with almost the default highlighting. The only change I made was to make the good and bad matches of parenthesis more visible. (In the default, the color of the parenthesis changes from black to blue or red, but it's too difficult to see. I changed it so the color is black but the background is blue or red. It's just a two lines change in the style, not special tool.)

In Windows I'm using WinEdt https://www.winedt.com/ and using again almost the default highlighting.

My recommendation is to mix () with [] and {} as recommended unofficially, instead of using only (). [For my personal code I use a few more [] and {} than the standard. I use [] for long [begin ...] blocks and {} for {define ...}. That helps a lot to find the problems.]

Lisp syntax is simpler than other languages. Unfortunately, simplicity often clashes with conciseness. In Python, you can do neat stuff like `[a[a!=0][:, 8] for a in A]`. It is possible to somewhat replicate the same ease of use using (reader) macros, but Lisps seldom seem to have mature, standard macros for these kinds of stuff.

Racket is up there for something I want to learn so I poke around in it. I don't find the syntax as easy as Python myself.

Reply on news.ycombinator.com