Hacker News new | past | comments | ask | show | jobs | submit login

I've been doing serious math with common lisp for 30 years. For me, the convenience of having automatic bignums and complex numbers, n-ary functions, and true rationals means I can think about math rather than about the limits of computers. The prefix notation became a non-issue in about a day.



"Prefix notation is a non-issue" is true for a tiny minority of software developers and mathematicians. The world has already spoken: infix is a minimum requirement for the vast majority of people doing math.

Bignums, true rationals, and many other constructs are already available in Python. Numpy is too. Most importantly, infix is available in Python.

The funny thing is that it's already possible to do infix in Common Lisp. My "readable Lisp" approach has been supporting infix in standard Common Lisp: https://readable.sourceforge.io/ It's already available in the QuickLisp libary as "readable". You can then use {1 + 2} with macros, quasiquoting, and so on.


the idea that prefix notation is some kind of serious hold up for anyone thats mastered, or is even semi-competent at the kind of mathematics you would use this for is so strange to me. Programming and math are (almost) nothing if not the ability to learn new rules of syntactical manipulation in all kinds of different domains. I say this as some one who is both a lisper and has severe dyslexia. It just seems like a totally made up hangup for a programmer to have. Its also weird to say "the world has spoken" when 60 years ago there were all of three or four non-assembly programming languages, and only 30 years ago prefix was still highly represented in serious industrial and research computing. Things change. Even five years ago doing "functional" programming in javascript was the fringe of the fringe of front end web development.


Yeah, function notation and much other math notation is already prefix: f(x), etc. the complications arise because for historical reasons we have the notion of infix operators, that complicate everything by forcing people to think about associativity and precedence.


I think the reason infix feels "nice" is that you can sometimes write dataflows from leafs to roots, whereas with prefix you work from the root up. But then you use a lisp threading macro which lets you do that consistently, with any set of functions/operators.


I find I can still go leaf-to root, at least eith my editor (vim with the slimv plugin)- You can press ,W to 'wrap' a lisp expression in another set of parentheses, which means for something like (a + b) * (c + d) You can write the '(+ a b)' first, then wrap it in a (* [...])


Thanks for bringing up another benefit of s-expressions - paredit and friends!


Let me tell you my perspective as a Lisp enthusiast and ex-software engineer who now works in academia. I think the problem is that most people who write software in the world (even many professional software engineers) just want to solve their problem and will resist if at all possible having to learn anything difficult (such as S-expression syntax), even if it is promised that their hard work will pay off.

The academics I work with, for instance, prefer Python, tolerate Java, do OK with JavaScript, but run for the hills when they see Lisp. When I tell them that ClojureScript not only has semantics with consistency that will elicit sobs of joy, but is also historically the most stable and concise way of targeting JS in the browser, maybe a few of them will be interested, but as soon as I show them a code snippet it's all over. They turn their heads sideways, they frown so that their lips are like the parentheses that splay before them, they mutter something about parentheses, and they go back to tripping over themselves in JavaScript trying to remember which Array functions are mutating or pure.

Learning a new syntax makes you feel dumb, even if you know how to program. And if you're feeling dumb while you're working on something that isn't even strictly related to the problem you're supposed to be solving before your deadline, it starts to get really hard to justify it. Most people only know something with a Python-like syntax, so most people will only ever work with languages which look like Python or Java since it's what they learned in their programming curriculum. It's ALGOL's world, and Lisp's just living in it.

Who does learn Lisp, then? I'd say, from what I've learned about the people in the Lisp world: mathematicians and computer scientists with intrinsic interest in PL's or the mathematical underpinnings of Lisp, old school symbolic AI researchers, and grizzled software engineering veterans who believe Lisp-family languages are engineering weapons of choice. All of these people have motivations (interest in mathematics and PL's per se, an academic interest with an historical connection to Lisp, and an insatiable itch for an ever more comfortable hammock even if it means getting out of the one you're in right now) that do not apply to the larger class of programmers that I just described.

I wish it weren't so. I wish more people would take the time to learn Lisp or an editor like Vim or EMACS: we, ahem, enlightened ones, know what a pittance the upfront investment will come to seem when the benefits of a superior tool are reaped over a lifetime, but people do not listen or do not believe when we tell them so. (Maybe they're right.) Perhaps we should ask ourselves what could make the promise of our salvation more credible.


I ..just... learning s-expressions isn't hard. At all. Its a made up thing and I think people cling to it because it gives them an out, they don't want to feel dumb or uninteresting in their work (understandable). As far as who learns lisp these days, while Clojure may not be doing Python numbers in terms of adherents, it is absolutely used in increasing numbers in business software, has multiple decent sized conferences and forms the back bone for a number of large open source projects. Its also used as a foundation for a lot of devops and build-tools type work. Racket scheme is used by at least a dozen universities for everything from intro to programming classes, to advanced semantics and compilers classes. On top of that there are a suite of new tools written recently (last few years) in Guile which are slowly gaining ground (Guix being the main one), Chez was recently opensourced (and is being integrated into Racket), Common lisp is still used all over and, wait for it, emacs isn't going anywhere. Lisp isn't the specialist tool or old ("grizzled") standby its purported to be. I think this is some message board logic, honestly. Not trying to be overly hostile or antagonistic, I just don't see the scene/market/environment in those terms. For example, I just discovered an extremely interesting but kind of weird embedded lisp in the wild several months ago! Its a scripting extension to a binary analysis framework that doesn't have first class functions, but does utilize meta-programming to drive a term-rewriting engine that executes single instructions on an emulator. Awesome, and strange, and, as far as I've been able to tell, not noted anywhere people draw up lists of lisp implementations (its been out, open sourced for almost 7 years that I know of). Lisp is kind of everywhere, it just doesn't have an organized messaging clique pushing awareness constantly everywhere (thankfully).


Right. Who are these people who do (numpy stuff) linear algebra, svd decomposition, pseudoinverses, linear regression, machine learning, but see a S-expression and immediately give up?


Mathematicians aren't averse to learning syntax, but they're lazy.

They learned that stuff because they are either basic methods in the field that have demonstrated value, or what they're actually doing research on.

The syntax buys them power that they wouldn't otherwise have, and they can smell it.

S-expressions? Not so much - the notation is more or less and arbitrary choice unless you're going to leverage the metalanguage capabilities to the hilt, and there are many other programming approaches available.

A mathematician who really wanted to jump into the deep end with programming syntax/structure would much more likely pick up Haskell (categories, yay!) or AVL rather than Lisp.


Understanding s-expressions isn't hard, but reading s-expression code quickly when you're not used to it is very slow and frustrating. Fluency is essential for efficient use of a language, and breaking people's already-existing infix fluency is quite a hurdle (or certainly appears to be from the outside).


The claim that learning how to read and write s-expressions is hard might well be a "made up thing". (I agree with you, I think anyone, if they sat down for a day and really applied themselves to it, would get it.) On the other hand, I think you'd agree, the fact that people have strong, negative, emotional reactions to s-expressions when they first encounter them is absolutely not made up.

We could sit here and grumble about how silly it is that people cannot overcome such an irrational response (indeed I often do), but that won't change the fact that people have these responses. If we did that, we'd be doing the same thing that GUI designers did in the 90's. "Why, the widget for $x is right here. Any reasonable user will RTFM, know that $x can be checked there, and behave perfectly rationally." (And it happened just so, as decreed from developer's rolling chair, right?) Of course, we know now how misguided this is as a method for UX design: all users are in a sense irrational, and systems need redundant strategies for saving the user from themselves.

The similarity here is that we cannot will away intellectual blemishes in users, we can only accommodate them. That is Lisp's challenge if it is ever to get big. For GUI's, the solution was to take seriously users' need for visually attractive interfaces, redundant display of information, and guardrails/handholding for actions commensurate with their risk, to name a few strategies. For Lisp, it's hard to know what might be the right approach. As klibertp writes in a sibling comment, maybe the solution needs to come from outside the language itself.


> Perhaps we should ask ourselves what could make the promise of our salvation more credible.

Consistent, long-term, highly visible propaganda put everywhere. Paid ads, people proselytizing in the streets, billboards with posters repeating the same message over and over.

In general, to get popular, you either need to luck out and be at the right place at the right time, or you can force it with propaganda. I don't see any other way. Rational arguments are useless if no one is aware they exist. Plus, rational arguments tend to require thinking on the receiving end, which is hard for people who just glance at something in passing. Simple message hammered into people's heads over and over is the only thing that seems to work.

If I ever become a billionaire, I will fund such a campaign. It's so disheartening to see a great technology being left in the dust due to historical accidents and resistance to any change that's intrinsic in most people. We can't do anything about the AI Winter or Lisp-machines demise, but - as many successful ad campaigns show - we can convince people to change their ways. It's just incredibly expensive, time-consuming, and hard to do right - as many failed ad campaigns show.


The flip side is: network effects. What is popular may not be perfect, but for any project that requires more than 1 coder, you can often get a lot more done in a popular language because you can find other coders to work with.

And even for solo programmers, it's easier to find an answer on stackoverflow for a popular language than an unpopular one.


You're actually getting at something deeper which I've been noticing more and more lately. Many people seem really reluctant to learn how to use things. It only seems to happen with software. They see a program or a new language and seem to think "well, I'm already a coder, I should be able to use this". When it's even slightly different to what they expect they complain that it's "hard".

It's really strange to me. Imagine if people did that outside of software. I can already walk so I must be able to ride a bike. I can speak English, so I must be able to speak French. The same goes for software. I spent years trying to understand infix notation and learning the precedence rules. Why would it not take time and effort to learn prefix notation?


> It only seems to happen with software.

Nope, it happens with EVERYTHING. If it doesn't work like something they've used before, they have to really, really need it to use (as in, be forced to use it), otherwise, into the trash it goes.


You may well be right. I probably only notice it with software because that's what I do every day.


> Bignums, true rationals, and many other constructs are already available in Python. Numpy is too.

The difference is that these things all run dramatically faster in CL than in plain Python, because CL is compiled AOT. In CL, a C library for math is optional. In Python, Numpy is mandatory.

> Most importantly, infix is available in Python.

Infix is certainly available in CL too, as other posters in this thread attest. I just don't feel any need for it.


I'm an art student. Prefix notation is a non-issue. If people want an infix Lisp, Dylan is awesome and doesn't add yet another flow-breaking set of different parantheses to the syntax.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: