Hacker News Reader

Comment by gnulinux | Hacker News Reader

Why not use lisp syntax, at all? Why do we have to reinvent syntax every single generation? I'm not an old school engineer (I'm in my early 20s and in my first job, freshly outta college) but I can't see why we don't use lisp, prolog or ML syntax for everything. Seems vastly better than C-like synaxes in all ways I can think of, easier to implement, easier to extend, easier to read (imho) etc... When I program even in a low caliber lisp like elisp (which I do routinely since I use emacs) it feels like syntax gets in my way less frequently compared to python, C, Javascript etc... I just wanna think about my program, and not the syntax. If lisp is not expressive enough, why not just ML? Why do we have to reinvent it so many times when syntax is not an interesting or relevant problem (e.g. Rust syntax)?

View on HN

I tinkered a bit (as many others have too!) with a lisp syntax for C, just to see what it'd feel like. That is, exact C semantics (so not inventing anything) but sexpressions.

What I remember struggling with is that it was surprisingly kind of hard to remember when parens are necessary where. For example you might define an if statement:

(if (> x 3) (printf ...))

Looks nice, but what about if you want multiple things in the body? Your options are

(if (> x 2) (progn (printf a) (return b)))

Where "progn" means "curly braces" effectively, or instead always requiring a list-shaped argument

(if (> x 2) ((printf a) (return b)))

which means in even the single-expression case you have to remember to always double-wrap

(if (> x 2) ((printf a)))

And now throw in handling of 'else' into the above. It gets surprisingly hard to use surprisingly fast. This problem repeats everywhere (function definitions, type declarations, for loops, and so on).

What all the above really clarified for me is that sexps work great in languages like lisp/scheme that are designed around them, but they don't solve syntax for free.

Or "if" could be a special form so that you can just write (if (> x 3) (printf a) (printf b))

WHEN takes an implicit PROGN like that (so does UNLESS). IF can't because it needs to delimit the then-form from the else-form somehow.

http://clhs.lisp.se/Body/m_when_.htm

See the Common Lisp IF* macro:

  (if* (> 3 2) then (foo) (bar) else (baz))

https://franz.com/~jkf/ifstar.txt

  (when (> x )
    (printf a)
    (return b))

  (cond
    ((> x 3) (printf a)
             (return b))
    ((< x 2) (printf b)
             (return a))
    (t (return c)))

Nobody who works with Lisps thinks in terms of "do I need double parentheses". You just know that if takes two or three expressions, when takes an expression followed by zero or more forms, cond takes a sequence of zero or more clauses which consist of a test followed by a body of zero or more forms.

If you're designing an S-exp syntax for something else, it's probably best to keep the familiar things the same; don't make some different if and such.

The Lisp if maps naturally to the ?: ternary operator; cond, when and unless can compile to cascaded if/else if/else.

Yes, but you are describing how a lisp programmer would expect things to work. As my comment was saying, I was exploring whether a verbatim translation of C syntax works as sexeps, and where it fails.

Because not everyone agrees (thankfully!) that syntax is uninteresting or irrelevant, or that Lisp is some amazing global aesthetic or ergonomic maximum.

Why thankfully?

Because syntax actually does matter, and Lisp is only a local maximum. Thinking otherwise causes pain, as people try to use Lisp in situations where it is not the best answer, and is therefore harder to use than other languages.

So, "thankfully", because acknowledging reality here means not having to live with the pain of using a language that is sub-optimal for the problem you're working on.

This is overstating the case for syntax. Without any empirical evidence that syntax is important to anyone other than folks that draft up syntax rules, this is just an assertion.

Put another way, do you have evidence that it is important? Has it let people write better programs? How would you prove that?

This is akin to saying grammar is important. It is, to an extent; but over adherence to grammar is usually not an effective way to communicate.

Well, empirically, syntax is important to a large number of programmers who complain about Lisp's (lack of) syntax. That's not a rigorous empirical study, but it's the best I can do at the moment...

I assert most programmers have not been exposed to lisp. I further assert most that complain of it's lack of syntax have not used it in any capacity.

I would be interested in studies on this. Most I ever see is posturing and assertions with little to no evidence. Frustrating, because I think both sides have valid points. And I fully believe there is a learning curve both ways. I suspect they both converge on total ability. I am genuinely interested in ideas on how that could be explored.

I think it's going to be really hard to do the study in a rigorous way. Solid data would be nice, though. Then we could stop guessing.

My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s. Now it's on the fringe. I assert that people had been exposed to Lisp, it was widely used. It became less and less popular. It's not that industry didn't know Lisp; they knew it and turned away from it.

Of course, the big flaw in my argument is the growth of the industry. A huge number of new people came in. Did they know Lisp, even at a college level? Maybe, maybe not.

My counter-argument to that is that industry knew Lisp, even if the new programmers didn't. If industry wanted them to learn Lisp, it could have made knowing it a job requirement, or trained people.

> My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s.

Unlikely, given that TIOBE the company wasn't founded until 2000, and the TIOBE index is based on web search engine results, and there weren't any web search engines, or a web for them to search, in the 1980s.

https://www.tiobe.com/tiobe-index/ has historical data going back to 1988. (Presumably they used a different methodology for the older data.)

But I remembered wrong. They list Lisp as #2 in 1988.

In the realm of personal computing, Lisp was nothing in 1988. "Nobody" was doing any Lisp programming for affordable consumer hardware. Lisp had almost no mindshare among people who got started in computing with 8 bit microcomputers in the late 1970's and 80's and who moved on to PC's and Macs. (Speaking of Macs, there was maybe the OpenMCL exception there.) Lisp was something that you heard about that ran on "big iron" owned by exclusive institutions. Lisp machines count as that, basically.

Macintosh Common Lisp was mildly popular on Macs. Apple used it themselves in several projects and eventually bought it, hired the team and sold it into their developer channel.

Another interesting offer was MacScheme.

LeLisp had a Mac version and it was used to implement an interface builder, which was demoed to Steve Jobs, who then hired the developer to create a version for NeXT.

Both Symbolics and TI delivered Lisp Machine boards for the Mac II.

Procyon developed a Common Lisp with UI for both Macs and PCs.

ExperCommon Lisp was another Lisp for Macs.

XLisp had Mac version.

On the PC there were numerous Lisp implementations.

Agreed it would be really hard. I do want to underscore I'm interested in the question. And I don't know which way I expect it to go.

My personal hunch is that lisp was just too expensive when most industry took off. In near every way. C compilers being basically free is a ridiculous advantage. Yes, there are free lisp implementations today. However, early mover advantage is working against them, now.

I'd agree that Lisp was too expensive when things took off. Not just in terms of compilers, but also in terms of hardware requirements. C was a better match for the tight memory of the day.

My personal hunch about the experiment (based on nothing more than my intuition) is that people think differently, and that Lisp's syntax is a good match for how some people think, but not for how the majority of programmers think. But as I said, that's just my current intuition. My intuition a year ago, for example, was different...

Sure, but what's not known is whether that's primarily because the majority of programmers learn to program on languages inspired by C syntax.

Maybe because they don't understand it.

Lisp has syntax. More than any other programming language.

What you think Lisp syntax is, are really simple function calls like

    (+ 1 2)

which are based on the function + various args pattern.

But something like Common Lisp has a few dozen syntactic built-in forms. For example the syntax for LET is in an EBNF (extended backus naur form) form:

     let ({var | (var [init-form])}*) declaration* form*

Then Lisp has macros. Zillions. Each of them implements syntax.

Lisp has a two-stage syntax:

1. stage are s-expressions, a data format: symbols, numbers, lists, strings, ...

2. stage are Lisp forms. They are written as s-expressions. But they have to follow a defined syntax. not every s-expression is a valid Lisp form.

  (let ((a 1) (b 2))
    (declare (integer a b))
    (+ a b))

Above is a valid LET form.

  (let ((a 1) (b 2))
    (+ a b)
    (declare (integer a b)))

Above is not a valid LET form, because the syntax requires that the optional declaration is directly after the binding form.

Without parentheses it might look like:

  let (a 1) (b 2)
    declare integer a b
    a + b

You would think that it has a syntactic structure. Just because Lisp uses s-expressions as a base mechanism, does not mean Lisp has no syntactic structure - but it is on top of s-expressions.

Since Lisp has user-programmable syntax, there is basically an unlimited amount of all kinds of syntactical constructs.

I really should adopt this view in my future posts.

I think the difference is most people, myself included, are looking at basically the syntax as where the capital letter and the sentence ending punctuation go. Which is really the only mostly constant thing in most sentences. You raise a vital point that that is a small part of the syntactic makeup of a sentence.

Which is funny, because so many people are convinced you get no static help in lisp. Which is demonstrably wrong.

Another helpful comparison is Lisp syntax versus Forth syntax. If you actually want a simple, terse, unstructured language, Forth is the way to do it: Words will consume and return any number of inputs or outputs to the stack, and you get entire classes of error when it's unbalanced that would surface as syntax errors anywhere else.

Just adding s-expressions is actually a huge jump up in syntactic complexity and structure, since now you can define a whole hierarchy statically, "on the page", instead of having to use a series of stack operations to manipulate memory from afar. And then as you lucidly put it, going from s-expressions to a practical Lisp dialect adds another level of context on top of that.

(And yeah, it's possible to bolt structure onto a Forth dialect, too, but the "Chuck Moore way" is that you do that custom every time you need it, instead of trying to generalize. Generalizing a concatenative structure leads to something like Factor.)

The ""market"" (including me) overwhelmingly prefers Algol-derived languages. The different types of bracket used in different ways seem to be a benefit. Very few empirical studies of this have been done, and there's also the problem that "easy to read (for newbies)" and "easiest to read (for experienced people familiar with C syntax)" can be completely different.

The average programmers seem to like different symbols for what they consider different things. I don't know if it is better or not, but it seems to be the status quo...

But if that's really the case, then why hasn't Perl way of denoting the basic kind of variable with a starting symbol been copied in other languages?

My guess is because most languages don't do that, so people are used to variables not having a symbol denoting their basic type. It largely comes down to what sort of syntax people are accustomed to.

It was copied. Php, Ruby, Powershell...

Reply on news.ycombinator.com