Hacker News Reader

Comment by Joel_Mckay | Hacker News Reader

Lisp has a readability issue, where the syntax makes the authors intent not immediately clear with all the brackets. I think it shared too many of the issues RPL and Forth had to be sustainable outside academia.

When it comes to implicit parallel code, Julia hid a lot of the gruesome details in a friendly interface similar to Octave, Matlab, and Python. However, what surprised me most of all was its math ops are often still faster on a CPU than Numpy and many native C libs.

Julia still has a long way to go with its package version compatibility, but it is slowly improving as the core implementation stabilizes.

View on HN

> Lisp has a readability issue, where the syntax makes the authors intent not immediately clear with all the brackets.

No it doesn’t, that’s like saying that any non-English language has readability issue.

Its ok to disagree friend, but when 95% percent of your bugs are syntax related rather than algorithmic design... it fails the sanity check.

Have a gloriously wonderful day =)

> but when 95% percent of your bugs are syntax related rather than algorithmic design... it fails the sanity check.

And you, of course, have study that proves it, right?

Anecdotes are funny this way, as the data is 100% accurate or 100% arbitrary.

Enhance your calm. =)

QED

Just google "lisp syntax error" for the hit count if you are feeling petulant. =)

"About 1,810,000 results (0.48 seconds)"

Googling "python syntax error"

"About 172,000,000 results (0.46 seconds)"

???

Don't get him started on python readability issues!!

Python is well organized, but has a fundamentally broken threading model.

Again, depends on the intended use-case. =)

You need to correct for the popular share of the languages.

Python is 48.07%

Lisp doesn't even show up in lists ;)

If the 172,000,000 figure from Google were not a brazen lie, it would indicate that for every developer on the planet using any stack, there exist several web pages mentioning Python syntax errors.

After a few years of seeing code build abominations, I am biased to believe that number may be plausible. Especially with automated testing frameworks dumping logs onto public areas of the web for the spiders to crawl.

I like data, but the hate in this place is unbelievable.

Have a great day, and happy computing my friend. =)

Lispers have been using structural editing since at least the 80s. Structural editing essentially allows modification to Lisp programs to be made as edits to a data structure with tokens. It sounds radical but it's really quite simple, at least in a language like Lisp, where

    (setf x 5)

is a piece of code that is truly and immediately represented by a data structure (a list containing the symbol SETF, the symbol X, and the number 5).

Let's do a routine example. In your editor, how would you get from

    (f x (y|)) z

    (f x y| z)

if the '|' was your cursor? Maybe you think you should click around and delete the right parentheses, and carefully balance them. With structural editing, a Lisp programmer might first do a "splice":

    (f x (y|)) z

    ;; splice: press Alt+s

    (f x y|) z

and then they will do a "slurp" (slang for moving the next thing after the cursor into the current enclosing parentheses):

    (f x y|) z

    ;; slurp: press Control-<right>

    (f x y| z)

We've managed to get to our destination by using only two structural commands that makes a parenthesis-mismatch error fundamentally impossible.

These are examples written with a package called "Paredit" in mind, and it actually makes editing Lisp a distinct joy compared to character-based editing of other languages. Some Lisp programmers prefer slightly different styles of structural editing, but they all reduce to the same motivations: Edit a Lisp program's structure, not its characters.

So, contrary to popular belief, Lisp programmers do not count parentheses. Lisp programmers' eyes do not glaze over at the sight of Lisp. Syntax errors are probably a <1% occurrence out of all of the errors one encounters. Though purely informally empirical, I'd be willing to get that syntax errors are far less common in Lisp compared to syntax-rich languages like C++, Haskell, etc.

People who dabble with Lisp for 15 minutes in notepad.exe invariably run into syntax errors, but that is not a reflection of what serious hobbyists and professional Lisp programmers do.

While I appreciate a parenthesis laden straw man argument, this just reinforces the assertion about poor readability.

Have a great day =)

Sorry, I made a mistake. You said

    Lisp has a readability issue

which I interpreted a statement of generality, but I think you meant

    Lisp is difficult for me to read

which I have no business arguing against, except to offer you guidance on what I believe are best practices for reading and writing Lisp. (In short, it's to use an editor specifically equipped to write Lisp. It gives you canonical indentation and structural editing. Emacs is the most popular choice, but there are extensions to Vim and VSCode; as well as full-blown commercial IDEs (plural!) by LispWorks and Franz Inc.)

again, getting sidetracked by making things personal.

You would not be upset, unless deep down you also agree this was true.

https://www.youtube.com/watch?v=q225u-qGpas

When you are reduced to arguing that your opponent's passion proves your point, you know you have lost.

I would be interested in hearing how degenerative prefix notation affecting visual acuity relates to a cults indignation.

Having someones opinions disrespected under the guise of a off-topic counter-argument, doesn't sound much like a prize.

Here is an up-vote, and have a wonderful day. =)

Toxic kindness and skill issues right here.

You do realize that Julia code parsing and code-lowering were implemented in FemtoLisp a.k.a. a Scheme/Lisp dialect

And I genuinely still like you, even if you think the world is a terrible place. =)

Of course. I love both Julia and lisps. How does your comment contradict anything I’ve said?

Hard to say really, as I do not like to encourage off topic personal nonsense.

Have a wonderful day =)

Are you saying that Lisp has a readability issue just because you have trouble reading it?

1. I spend more time programming C than Lisp, but am more prone to syntax errors in C than lisp, so my experience is quite different than yours

2. Syntax bugs have little to do with readability; that has more to do with writeability.

3. Most languages make it possible to write code that is inscrutable, but that is not necessarily an indictment of their readability.

1. How quickly can you understand what others have written in a large lisp project. I found I was spending a lot of time interpreting what was going on rather than the design implementation process itself.

2. unless some clown thought conditional tail recursion was super awesome for the next guy.

3. All code is terrible, but some of it is useful... and if it is only useful to a few than it fails as a language.

Keep in mind I learned on an RPN machine, so understand the sirens song lisp sings. ;)

RE: 2

Tail recursion is non-idiomatic in Common Lisp; both because the standard does not guarantee tail-call elimination (as opposed to, say, Scheme) and because dynamic-binding, which is idiomatic in Common Lisp reduces the number of calls that are in a tail position.

Also, tail-recursion is entirely divorced from syntax; perhaps you meant semantics? For example GCC will optimize tail calls in a rather broad number of contexts.

If I recall correctly, some Lisp dialects had a super character that world close n open parentheses left open.

You may have confused interesting with useful...

Have a nice say ;)

1. In an average project Lisp would rank fairly high for me. In fact for making meaningful changes in an average quality large code base I'd rank it at the top, my order being (best first):

  Lisp, C, Java, C++, Python

It all depends, e.g., C++ would rank higher in a very high quality code base.

Do you find you yourself more productive from a time use perspective in lisp?

Or do you just prefer reading the structure in prefix notation.

Like any language, Lisp has readability issues when you’re not familiar with it. You find it hard to read because it’s alien to you. To my eyes – because Lisp is what I’m used to – every non-Lisp language has readability issues. These days I do a significant amount of work in Python, Rust and Julia, and although there are things I love in all of these languages, I always miss s-expression syntax when using them.

Infix notation can be useful for arithmetic; as a "Lisp person" I acknowledge that.

S-exps can be good for arithmetic too though.

S-expressions allow n-ary operators:

  (+ (* 3 x y) (* a b z w) (* r s t u v))

There is a systematic way to break up large expressions across multiple lines, which helps readability. Infix doesn't have a satisfactory way to do this:

  (+ (* 3 x y)
     (* a b z w)
     (* r s t  
        u v))

We see just from from the

   +  *
      *
      *

pattern that we have a sum of three products.

S-exps are unambiguous. You never misread an arithmetic (or any other) S-exp due to precedence, unless it's a macro that has created precedence rules among its arguments (vanishingly rare).

N-ary math functions associate left to right in Common LIsp: (+ a b c d) means we add (a b) first, then c, and d. This makes a difference when you have mixed types, which have to undergo conversions, and when you have non-associative types like floating-point.

If I'm cribbing some numeric calculation to use in my code (whether that code is Lisp or not), and have examples in half a dozen languages, none of which I use, I will crib it from that one that is a Lisp dialect, just because of the vanishingly small opportunity for getting it wrong due to some ambiguity issue.

This is a comment that I like, acknowledging the obvious unsophisticated but no less reasonable objection from the bystanders, and offering them an alternate viewpoint.

My reservation would be that most applications of arithmetic operators are binary and not ternary. A typical expression in one of my C programs at least has some function call, some subscript, some member access, some addition / subtraction / multiplication / division. But very few have more than one of each. Overall arithmetic is actually quite rare by itself in most code.

My windmill is simply I still can't think in prefix for math.

It's trivial for me to write x = (-b + sqrt(b^2 + 4 * a * c)) / (2 * a).

But writing (setf x (/ (+ (- b) (sqrt (+ (* 4 a c) (* b b)))) (* 2 a))).

That's a mind bender. Were this my source code, I'd probably put the (* 2 a) on the next line (properly indented) so it stood out as the divisor.

All that said, honestly, the physical task of writing Lisp code is just so much better than anything else. There's something satisfying closing up all of the parens. And I just love using-hyphens-for-identifiers vs CamelCase or using_underscores.

Fortunately doing infix math in CL has since the 90s been one small library include away: https://github.com/quil-lang/cmu-infix

That's nice but we can all agree that it's not the same thing as a standard builtin syntax that everyone knows and is forced to use.

I think you're writing it off as not actually being valuable in practice, which I don't think is fair.

Should we consider Python's NumPy as not a feature of Python because it's not a built-in library?

A commenter says they prefer to write infix math. Lisp has a completely ordinary, stable, well-known, 30-year-old library to do it. Thus the commenter's concerns are largely allayed.

Not having it in the standard library means people have a choice to use it or not, and it also means one can't expect all Lisp code which has infix math to use it, but it certainly does not means the commenter will be perpetually hamstrung in reading and writing complicated math formulas.

Macros are a cure that's worse than the disease. Unless everyone agrees on which set of macros you're using, you can't trust any code to mean what it looks like it means. (And if you could agree on which set of macros you were using, or what sanity-preserving restrictions you'd put on your macros, surely you'd just build those into your language).

In my experience, this is hyperbolic and not reflective of actual Lisp code people write or read. A lot of code is pretty straightforward: functions and classes. Some domains (like quantum computing) benefit from macros that introduce syntax that is broadly known to that domain's community, and would otherwise be opaque and inscrutable were it not for macros.

Have people written bad, useless, nearly antagonistic macros? Sure, but that happens with any abstraction in any language, including humble functions.

Sure, because people have an intuition for what a macro should or shouldn't do. In practice you end up with an ad-hoc, informally specified, etc. implementation of half of a domain-appropriate language. Actually even (especially?) the general-purpose parts end up the same.

Functions (at least in languages where they really are functions) are a lot safer; they're inherently compositional, and they follow the rules of the language. Most people have an intuition for what a macro should and shouldn't do, but there are very few guardrails that actually make that concrete, and often different team members will disagree about where the boundary between "sensible syntax sugar" and "inscrutable" lies.

I can agree it's not the same, but what's the point? A more interesting disagreement is that I wouldn't say it's a downside (though yes, there are tradeoffs). Especially in Current Year when open source is fashionable and pretty much every language has a package manager to make pulling in or swapping out dependencies pretty easy, I don't see the issue. It's also interesting to note that of all the things Clojure did to "fix" shortcomings of past languages with a more opinionated (and often more correct I'll admit) design philosophy that users are forced to use (even when it's not more correct), infix-math-out-of-the-box wasn't one of them. I don't think that specifically really hurt Clojure adoption. (But of course Clojure is reasonably extensible too so it also has a library to get the functionality, though it's more fragile especially around needing spaces because it's not done with reader macros.)

I've brought the library up many times because CL, unlike so many other languages, really lets you extend it. Want a static type system? https://github.com/coalton-lang/coalton/ Want pattern matching? No need to wait for PEP 636, https://github.com/guicho271828/trivia/ If all that keeps someone from trying CL, or from enjoying it as much as they could because of some frustration or another, due to lacking <insert feature here> out of the box, chances are it is available through a library. (Or heck, even just tooling setup. Tab completion for symbols and jumping to function definitions are just two great things modern programmers enjoy in all sorts of languages, CL too, if someone doesn't have that setup I wonder if they must enjoy pain.)

And if you're really desperate to write infix notation in Lisp, you can use CMU-INFIX [1]:

    #I( (-b + sqrt(b^^2 - 4*a*c))/(2*a) )

That is completely valid Lisp if you need it. In fact, you can change your editor to highlight #I(...) if you want it to stick out a little more since it's "different" than usual prefix notation.

Suffice it to say, a binary expression like

    (+ b (* m x))

probably doesn't warrant bringing in a library, but if you're calculating orbital dynamics of the solar system, then perhaps having the above library would be useful.

[1] https://github.com/quil-lang/cmu-infix

> Were this my source code, I'd probably put the (* 2 a) on the next line (properly indented) so it stood out as the divisor.

And that's exactly how written math does it (big bar for division of complex terms). Infix code notation has an extra set of '() around the numerator and denominator which helps in this specific case.

This is a really interesting point. What I'm seeing is that infix lends itself to chunking subterm "nouns" of the whole expression, where prefix/function is "verb oriented" and feels more like trying to remembering a series of dance steps rattled off by an instructor who knows them and can't remember what it's like to be a newbie.

I don't know how much of this is not being used to "dancing" but being entirely used to dealing trees of infix terms.

starting from infix equation a*x^2 + b*x + c = 0

  x = (-b + sqrt(b^2 + 4*a*c)) / (2*a)

is obviously conceptually clearer than

  (setf x (/ (+ (- b) 
                (sqrt (+ (* 4 a c) 
                         (* b b)))) 
             (* 2 a)))

i however think the latter is computationally clearer. also i think the difference is most striking when we use well known infix formulas such as the quadratic formula. you would not have this effect with the cubic equation for example - https://en.wikipedia.org/wiki/Cubic_equation#Cardano.27s_met...

"alien to you" Nope, but I do classify lisp/scheme next to Haskell, Icon/Unicon, and snowball... as ivory-tower languages. However, you wouldn't be the first person to spend 3 years of their lives failing to prove the assertion false.

Is there utility assuming everyone who doesn't share your opinion is an Alien? I find it just causes the 103rd purple proboscis to itch. ;)

It is mostly switching from print(something) to (print something).

And focusing on (), instead of ()[]{}:;.

Or from

  foo.x

  (foo-x foo)

  print(a, b, c, d)

  (print (a) (b) (c) (d))

I don't think it's the end of the world, but I'm pretty sure one can make solid physiological arguments why the first is a little easier to read.

If it wasn't, how come math notation relies heavily on infix operators and even subscripts, superscripts and more? It's because you want to optimize notation for the frequently used stuff.

Really instead it's

  (accessor object)

and

  (print arg-1 arg-2 ... arg-n)

No idea why you suddenly converted the values a, b, c, d to full-blown forms. But of course, baby duck syndrome will prevail and Minsky's comments are painfully true to this day: "Anyone can learn it [Lisp syntax] in a day, unless they know Fortran, in which case it's three days."

P.S. Making general comments about "math notation" is pretty dishonest argument. The math I studied was all commutative diagrams and blobs to represent manifolds; very little "infix operators" as far as I could tell. Mathematicians in general are flexible with notation (and definitions!) and will normally default to whatever is the loose consensus in their field :)

> But of course, baby duck syndrome will prevail and Minsky's comments are painfully true to this day: "Anyone can learn it [Lisp syntax] in a day, unless they know Fortran, in which case it's three days."

That’s hilarious, where did he say that?

I'm only finding the quote, no source. But here's something we can be sure he said:

> The complete syntax of LISP can be learned in an hour or so; the interpreter is compact and not exceedingly complicated, and students often can answer questions about the system by reading the interpreter program itself.

https://web.media.mit.edu/~minsky/papers/TuringLecture/Turin...

No need to throw offenses. See my cousin comment for an explanation.

> P.S. Making general comments about "math notation" is pretty dishonest argument. The math I studied was all commutative diagrams and blobs to represent manifolds; very little "infix operators" as far as I could tell. Mathematicians in general are flexible with notation (and definitions!) and will normally default to whatever is the loose consensus in their field :)

It is exactly the point of what you are answering: mathematicians too use a flexible, ad-hoc notation. Presumably it is better for them. I don't see how it is dishonest, I find it quiet on point.

I guess it needs less ink/chalk, and gives more visual clue about the structure and the content of the equation, than a more uniform, lisp like notation would.

Your second example isn't right, you've added an extra layer of parens. It's either (print a b c d) or your pre-translation should be print(a(), b(), c(), d()).

My thought here is that a, b, c, d are expression placeholders (and assuming they don't contain commas in the ALGOL syntax version). It's (print a b c d) if all arguments to the ALGOL version are already terminal symbols. If instead it was print(foo.a, foo.b, foo.c, x + y) it's now (print (get-a foo) (get-b foo) (get-c foo) (+ x y)).

    (print (a) (b) (c) (d))

would be

    print(a(), b(), c(), d())

I agree you can make arguments, I like your explanation for the final form further downthread. For the second form, another choice could be (.x foo) or (. foo x). Or if you're trying to write something like System.out.println("x"), Clojure's .. shows it could be written as (.. System out (println "x")). Or, if you're using CL, you can use the access library (https://github.com/AccelerationNet/access) and write things like #Dfoo.bar.bast or (with-dot () (do-thing whatever.thing another.thing)).

In trying to further steelman a case where random Lisp syntax can be more difficult to read than, say, equivalent Python, two other areas come to mind. First is the inside-outness order of operations thing, it trips people up sometimes. Like the famous "REPL" (with a bad printer) is just (loop (print (eval (read)))), but in English we want to see that as LPER. Solutions include things like the arrow macro (Clojure did good work on showcasing it and other simple macros that can resolve this issue in many places) and if you write/pull one into CL REPL becomes (-> (read) (eval) (print) (loop)), how nice to read. But even the ancient let/let* forms allow you to express a more linear version of something, and you can avoid some instances of the problem with just general programming taste on expression complexity (an issue with all languages -- https://grugbrain.dev/#grug-on-expression-complexity shows one form).

The second area is on functions that have multiple exit points. A lot of Lispers seem to just not like return-from, and will convert things into cond expressions or similar or just say no to early exits and it can make things a bit more awkward. The solution here I think comes from both ends, the first is a broader cultural norm spreading in other languages against functions with multiple return statements and getting used to code written that way, the other is to just not get so upset about return-from and use it when it makes the code nicer to read.

> how come math notation relies heavily on infix operators and even subscripts, superscripts and more?

"Mathematical notation" is an ad-hoc compilation of a huge number of historical accidents, conventions and personal preferences. For each function in math, there's at least 3 different notations for it, and somehow each of your professors ends up using a different one. And to counter your argument, prefix operators appear very frequently in mathematics, including the most common function notation (although of course there's also a postfix and an infix notation), sigma notation, quantificators, roots, and many other common operators.

By the way, your second example should be (print a b c d), I'm not sure why you made a,b,c,d functions there.

Reply on news.ycombinator.com