Hacker News Reader

Comment by nerdponx | Hacker News Reader

I think S-expressions are fundamentally too difficult to work with, without good editor support, to make Lisp anything other than a niche power tool for the highly motivated. I love CL, Scheme, Clojure, Janet, Fennel, etc. but I don't blame anyone for finding them inaccessible.

I think Python, JavaScript, and Go have caught on for somewhat similar reasons, compared to Java and C#: they are easier to get started with, and you can still scale them up to fairly large applications.

On the other hand, I think S-expressions are a sadly underexplored format for data serialization and storage.

View on HN

I have never really understood people‘s aversion to parentheses. Many languages require them in ad-hoc ways to groups expressions. For S-expressions, you give up some mild convenience and looks for extremely consistent semantics.

It's not so much an aversion to parentheses as an aversion to nothing but parentheses. Other languages use other brackets to indicate different contexts, but s-expressions can more difficult to read. The idiom of putting all of your end parens on a single line doesn't help.

And for most people, the mild convenience of readability is preferable to the consistent semantics.

> The idiom of putting all of your end parens on a single line doesn't help.

Yes it does; doing it any other way is strictly worse regardless of where you stand on parentheses as such.

I don't think the syntax has anything to do with the outcome. Some people like to complain about it, but it's just meaningless noise.

No, disagreements with your opinions are not just meaningless noise.

It's not meaningless because I disagree with it, it's meaningless because it had nothing to do with why Lisps didn't take over.

What’s the problem with having the end parens on a single line? I never understood why languages with curly brace syntax don’t do the same. A line of code containing nothing but a curly brace seems like a waste of screen real estate to me. It contains absolutely no information (the end of the block can be seen by indentation anyway).

One could just as easily write s-expressions using whitespace, so why bother with parens at all?

Because the human brain is a pattern-matching organ and sometimes redundancy in a signal is useful. I've never understood the lispers' insistence that saving "screen real estate" is a primary concern. Source code is meant to be read, and the more easily code is read, the more utility is has.

Source code is indeed meant to be read, and at least to me, low information density seriously hurts readability. I prefer both Python-style indentation based syntax and multiple parens at the end of the line over C-style syntax with closing braces alone on a line. If I write code in a language with curly brace syntax and I don’t have to share the code with others, I prefer to use multiple closing braces on the same line – like Lisp parens – because of improved readability.

Parens allow an editor to create the proper indentation.

You can think of Lisp's paren syntax as the syntactic analogue of Lisp's very simple static type system. To get macros to work with a conventional grammar's complexity is much more annoyingly complex.

> I have never really understood people‘s aversion to parentheses

A common refrain from Lisp family language enthusiasts. (Personally I prefer Smalltalk-style "conversational" syntax to Lisp-style or C-style syntax, yet it's similarly unpopular.)

For better or for worse, the vast majority of programmers seem to have voted with their feet for C-style syntax (C/C++/Java/JavaScript/etc.) and its variants (Python). In a C/C++/Java/JavaScript world, C syntax has a fair amount of leverage.

It's a shame that Dylan didn't continue, as it seems to have taken a decent crack at adding algebraic syntax to Common Lisp - arguably realizing McCarthy's original vision of infix M-expressions as a more programmer-friendly syntax. I wonder how hard it would be to add a Dylan-style syntax layer to modern CL?

Be that as it may, one can readily write Lisp/Scheme-style programs in JavaScript. See Crockford's "The Little JavaScripter."[1] The major omission/deficiency being macros for JavaScript syntax.

[1] https://www.crockford.com/little.html

(Open) Dylan is surviving just fine, and we expect to do a new release later this month.

I haven't given a look at this language in a few years; is it still so that there are no enums, and that operators must be surrounded by spaces?

Yes. Making a macro for defining enums isn't that hard (there's one here: https://github.com/cgay/uncommon-dylan/blob/master/enum.dyla...).

I, for one, welcome my whitespace-surrounded operator overlords, but if you really don't want that you're welcome to use function-call syntax for them.

As a Guix developer (there's a lot of Scheme and Common Lisp in Guix :) ), every few years I check on Open Dylan but so far each time there was something missing that made me unable to package it for Guix (building it entirely from source).

I've checked it a few minutes ago and Open Dylan's ./configure says to download a bootstrap compiler from https://opendylan.org/download/index.html first -- but there's no such bootstrap compiler there.

Do you have some hints on how to package it?

The way you actually have to do it is trawling through git repos to find an old version of Gwydion, bashing at it for a while, and maybe getting it to compile on modern platforms. Look for 2.4, then rewind, then pass a config flag, and a few more steps.

I wouldn't call Dylan thriving, unless you're a Windows user that really doesn't care about bootstrapping your language.

It's alive though, in the same sense that Miles, the dog that Segall froze and then brought back to life in 1987, was alive. Brain damaged, but alive.

Gwydion Dylan has been out of the picture for years. Open Dylan is the only maintained implementation. Perhaps you went down a wrong path....

You can't bootstrap OpenDylan from source without a Dylan compiler. You can bootstrap Gwydion without one with substantial elbow work, which you can then pivot into bootstrapping OpenDylan.

I know what I was doing, and if you look elsewhere in the thread, I was right about what the GUIX maintainer wanted. Not to get egg on your face.

There's no special "bootstrap compiler"; you can download a binary release for your platform from the page you linked, and then use that to bootstrap a newer version from a source checkout. If it would help, we could provide a minimalistic build that was only useful for bootstrapping, but at present our builds are "batteries included" (with LLVM/Clang and the BDW garbage collector already provided in the tarball).

Ideally, what Guix would want is similar to what https://github.com/thepowersgang/mrustc/ does for Rust (a compiler, not written in Rust, for Rust).

So for Dylan, we'd like to have a compiler for Open Dylan, not written in Dylan. (it can also require multiple steps to get up to Open Dylan--that would be fine)

It's not in the interest of our users to use binary blob compilers for bootstrapping.

We would also unbundle LLVM, clang and the bdw gc and use the ones from Guix.

My favorite languages are MLs, particularly F#, which usually have some of the cleanest syntaxes available. It’s not just Lisp-family enthusiasts. I think it’s more for anyone that thinks rather that follows or assumes or whatever.

I actually learned about Lisp/Scheme after I had learned about several other languages.

What do people not like about parentheses? It’s normally along the lines of “well, I just don’t like them”, which can be read as “it’s not what I’m used to”. Yet, these same programmers will freely throw parentheses around expressions in an ad-how manner to communicate with the compiler in their given language. In some ways, one can back Lisp/Scheme out of popular languages by stating that instead of letting parentheses be used to frequently but not always clarify precedence and grouping and function application, they are going to be required to enforce these. Such a thing is not such a radical or unreasonable stance.

McCarthy’s original M-expressions are somewhat irrelevant. He wasn’t trying to make a programming language for software development. He was investigating it as a tool for his research.

My primary complaint about popular languages like Python, C++, C#, etc. are their irregularities. There a lot of syntax, semantics, and little quirks in the languages that make it very hard to just know the language and move on solving problems. My favorite thing about Schemes are their regularity. The social popularity of languages can’t be explained by their technical merits. It’s more due to social and historical phenomena than a technical reason.

For what it’s worth, I also like Smalltalks.

The problem is precisely that too much regularity makes the code harder to scan visually. The irregularity of various delimiters and separators helps to distinguish certain language elements from others.

There is power and elegance in syntactic uniformity, but Lisp in particular is hard to read until you train your eye to see through the nest of parentheses, and it's hard to write without something like Paredit assisting you.

Meanwhile I don't think anyone finds Haskell/ML syntax hard to read. The problem is more that, with idiomatic Haskell in particular, too much abstraction, currying, and un-descriptive variable names can obfuscate what a piece of code actually does.

I never used Dylan, but isn’t Julia kind of similar, as a Lisp with multiple dispatch and a main-stream syntax?

In high level yes, however Dylan was designed as systems programming language, so it also enjoys AOT compilation and low level stuff that Julia currently isn't able to.

> more programmer-friendly syntax

Lisp doesn't have programmer-unfriendly syntax. It's just tailored to a different use case: built-in ever-present meta-programming. The language was designed to compute with symbolic expressions as data and it was early discovered that Lisp programs itself could be treated as symbolic expressions. Code as Lisp data. People found it easier to do it all in s-expressions, compared to the mixed syntax of the early design: m-expressions for programs and s-expressions for data. This was shown over and over.

In that space it has some local optimum of programmer friendliness. It's just that most programmers don't have that use case. Some get the ideas of list processing as a practical programming interface.

Alternatives were spawned, though: LOGO as a beginner's Lisp, ML as a functional programming language, Dylan as an Scheme+CLOS targeting the same audience as Swift nowadays, ...

The syntax is consistent, I don't know about the semantics. The trade-off is that it becomes more difficult to glance at a piece of code and visually distinguish what's what.

The syntactic consistency is at the same time its downfall: everything looks the same. (Functional languages like Haskell have a similar problem.) It’s more accommodating to human cognition if at least some part of the complexity and diversity of conceptual constructs in programming is represented in the syntax, meaning a certain range of different syntactic constructs that humans can attach meaning to. There is a sweet spot in syntactic diversity that matches the middle of the bell curve across programmers of how human cognition can absorb code. And that sweet spot isn’t on the more “spartan” side where Lisp resides. A different extreme are the more “cryptic” languages like APL and descendants. In a certain way, everything looks the same in those as well.

I can understand this argument. However, at the same time, S-expressions do allow for rather expressive function names not usually available in other languages. various arrows, question and other punctuation makes, etc. can make for some nice function names.

I do agree with the sentiment to some degree though that it all looks the same. In an aesthetic sense, there is something I do like about it though.

Being a fan of both ML and Scheme, I have actually been experimenting with a syntax that is a hybrid of the two. I’m still in the experimentation phase, but it’s an interesting exercise.

> expressive function names

Yes, but those are effectively library conventions, not fixed properties of the language. Maybe more importantly, names aren’t a structural construct, like a for loop or a class definition. And, arguably, you can have similar syntax in other languages, like e.g. `!` in Rust or the type sigils ($, @) in Perl, except that here you can be sure of their semantics.

The naming is enabled by the way S-expressions work and aren't merely convention. Handling such syntax in non-parenthetic languages is difficult because of the overlap with the other meaning of those infix operators in the language. For example, in F#, if I have a function named `string->number`, then the parser doesn't know if I mean `(string) - (>number)`, `(string-) > (number)`, `(string) -> (number)`, or the function `string->number`.

I totally understand. What I meant was that the meaning of such names, or the names chosen for a given meaning, is a convention of the library (or set of libraries) that defines the names, and not a semantics the language guarantees, like keywords and punctuation do in other languages. (In Lisp I don't know what `string->number` does any more than I know what `stringToNumber` does.) So S-expressions give you more freedom in the syntax of your function names, but they don't provide more kinds of constructs in the language.

P.S.: The diversity in programming language design mirrors the diversity in how humans' minds work. Some people work better with dynamic than with static typing. Some people work better with Lisp, some with Haskell or ML, some better with Java and C#, some with APL and friends, etc. There is no one-size-fits-all, and one factor in the adoption of each language is how each programmer's cognition matches the respective kind of language, and also a little bit what they want to achieve practically with the language.

On the one hand it is important to have discussions on the benefits and drawbacks of different approaches in language design, and some people will change their minds based on that, but it's also an illusion that one single approach will ever suit everyone.

Human attributes are generally distributed on something like a bell curve. Programming languages with "extreme" characteristics in any direction will almost inevitably be stuck with niche popularity, because they will only be appealing to a small fraction of people. Whereas, even "extreme" people will generally be able to tolerate at least a couple of conventional languages.

At issue in this thread is the very definition of extreme vs conventional. The idea in this thread is that the languages now considered to be conventional could have been the niche syntax.

I've ever understood it either. I love s-expressions! But I suppose there must be something to the complaint. If you ask me I'd say Python's space-as-syntax is far more horrible, but doesn't get nearly the same amount of vitriol.

I've been working with Lisp for over twenty-two years and still got tripped up recently by something that was

  (if (condition)  ;; <- must be when, not if!
    (do-this)
    (do-that))

Phony complaints about problems with editing parentheses and getting them to match are just trolling nonsense, but Lispers should acknowledge this kind of problem: when your editor has already helped you ensure that the code has valid syntax, everything is beautifully indented and compiles without diagnostics, but you have a mistake like this: parentheses being closed in the wrong place, not including something, or the wrong operator like the above.

There are similar problems in other languages; no notation is perfect, and attempted cures for some of these problems can be worse than the diseases.

GCC's relatively recent "misleading indentation" warning is a good example of a cure that has no downside (that I can quickly think of). It can catch code like:

  if (condition)
    do_this();
    do_that();  // not part of the if statement, but indented deceptively

No language save you from writing a program similar to the one you should be writing, but which is correct for a different set of requirements relative to what you want. Just verification and testing.

  (if (condition)  ;; <- must be when, not if!
    (do-this)
    (do-that))

I didn't find that to be a common problem when writing Emacs Lisp at least. The "misleading indentation" warning is relevant thre. If you enter the above code into Emacs, auto-indenting as you go, it will indent like this, making it obvious you meant `when`:

  (if (condition)
      (do-this)
    (do-that))

I find this syntax argument a bit strange nowadays. There's this extremely popular Kubernetes tool called Helm, which uses go-templated YAML to generate Kubernetes resources. The template syntax is nothing short of horrible. An endless maze of {{ ... }}s, where it's just too easy to shoot oneself in the foot by using {{- or -}} in wrong place, etc. And on top of that, you literally need to count spaces for nindent (mind you, you don't need to count parentheses while writing Lisp code).

I'd say Lisp syntax is clear as day when compared to your average Helm template.

An example is here:

https://github.com/kubernetes/ingress-nginx/blob/main/charts...

And yet, all of this somehow doesn't prevent Helm from being popular...

wow, how could that happen?

But, you always have good editor support. Lisp/Scheme has traditionally been coded using Emacs or its equivalent. With that support, the parens seem to disappear after you've been writing lisp for awhile.

Beginner lispy languages come with a suitable beginner IDE, e.g. Racket or Logo.

A typical lisp statement has a leading '(' and a trailing ')', which replaces the ';' in Algol-like languages. So, one additional character, which brings a lot of benefit when writing DSLs and macros.

(Python doesn't have the ';', but its whitespace is ambiguous, so that's not a fair comparison.)

Sane people don't write lisp using Notepad.

I think the parent comment is alluding to the notion that the very entry level programmer enjoys being able to use notepad. That is to say the initial barrier of eMacs is just too much. Obviously worth it in the long run though.

“eMacs” is the wrong capitalization. It’s “Emacs”.

M-c would fix that I believe.

My autocorrect has been doing that for some reason and I assumed there was logic to it. Your comment sent me on a dive that proved my intuition woefully incorrect.

I tried using Slime with Scheme when I was doing SICP. I’m sure it’s great when you know it well, but I kept pressing the wrong shortcut and moving things around in ways I didn’t intend and then it wouldn’t let me manually type or delete parentheses to fix things. I found it very frustrating and ended up turning it off.

Just another barrier and C-style languages seem much easier to write in comparison.

Slime did that? Slime doesn't take over the editor that much (it shouldn't prevent you from typing parentheses, I've used it for 16 years or so and never experienced anything like that). Was it paredit or another editor mode?

Sorry you’re right, it would have been Paredit.

I guess my point is that syntax that works very well with a correctly configured editor used by someone who knows what they’re doing is going to have a higher barrier to entry than a language that can be easily edited in Notepad.

Lisp is no harder to edit in notepad than any other language. It is just a text editor and lisp source is just text. And paredit is a misfeature for most people, turn it off. That should have been the real takeaway. It is not part of a ”correctly configured editor” and it isn’t installed or activated by default anyways so is easy to avoid.

Yeah, all you have to do is keep track of the number of closing parens in your head.

It’s a lot easier when the editor highlights matching pairs.

I don't know of any language that can be easily edited in Notepad.

Not even English.

In case you didn’t know — DrRacket (IDE for the how to design programs book) has a language directive you can run that sets up DrRacket as if it were the environment the sicp authors expect the reader to have.

I only found out after going through SICP using chez scheme’s repl (which I had to compile myself).

Lisp syntax is an extreme impediment to uptake. Consider what happened to Lisp-Stat. It was a really slick package, but people immediately dropped it when R became available. Lisp defenders like to think that R won out because of better libraries, performance, or some such. The truth is that the stampede began while R was still in a rough state, people were so eager to get away from Lisp.

Ironically R inside is still much of a Lisp.

> The truth is that the stampede began while R was still in a rough state, people were so eager to get away from Lisp.

That's not a big surprise.

The syntax is/was an important reason. Most users of statistics / maths software prefer a more math-like notation. Even the bigger Lisp applications in the maths area provide that always: Macsyma/Maxima, Reduce, Axiom, Derive, ..

One could have written that on top of Lisp, but it was much more convenient to develop a specialized language/runtime using C. C + Lisp + R would have been more complex than C + R.

Is it clear people wanted to get away from Lisp rather than use a more-or-less clone of S? (One of R's originators did propose moving back to a Lisp base [1], though part of the justification was HPC, which is now at least partially covered [2].) However, much as I like Lisp, I do want a mixfix syntax for interactive use like R, but something CGOL-ish is easy enough; I don't remember xlisp-stat having something like that.

1. https://www.stat.auckland.ac.nz/~ihaka/downloads/Compstat-20...

2. https://pbdr.org

> Is it clear people wanted to get away from Lisp rather than use a more-or-less clone of S?

That's a good point. How many statisticians were familiar with S but were using Lisp-Stat just because it was free? I don't seem to have traveled in those circles. I wasn't paying a lot of attention, but I don't remember encountering that on campus.

Another slick Lisp package that got too little attention was Yann LeCun's Lush.

I've done all my Lisp coding, pretty much ever, in Vim. Just basic :set lisp mode, % key for matching parens, autoindent and off we go.

I didn't see any difference between that and C editing support.

Reply on news.ycombinator.com