I agree though that for practical purposes, practical solutions are just going to be more successful.
Then a righthanded person picks up the lefthanded scissors and deems them weird and uncomfortable. Which they are .. for the right hand of a right-handed person.
Other popular examples of such taste controversy are Python's semantic whitespace, the idioyncracies of Perl, the very unusual shape of J/APL, and anyone using FORTH for non-trivial purposes.
edit: https://news.ycombinator.com/item?id=41766753 comment about "other people's Lisp" reminds me, that working as a solo genius dev on your own from-scratch code and working in a team inside a large organization on legacy code are very different experiences, and the "inflexibility" of some languages can be a benefit to the latter.
Most people definitely seem to have specific preferences built into their talents. I don't see why programming or programming languages would be any different from any other medium or art form.
A commonly made up deficiency attributed to Lisp is that it's particularly bad at large scale, either in teams or program size. That would surely be surprising news to the teams doing stuff today or in the past, some responsible for multi-million lines of code systems (some still in operation). Or to use an old example, the documentation for Symbolics Computers, pictured here in book form: https://www.thejach.com/public/symbolics-books-EugyAAEXUAUG_... Such a set of books doesn't come from a "lone wolves only" ecosystem and heritage. Not to mention doc and so on not shown for applications they made for 3D graphics or document editing (https://youtube.com/watch?v=ud0HhzAK30w)
Edit: I should also mention that once I worked out how reader macros worked I went on to enthusiastically (ab)use them for my own ends...
Those reader macros have morphed the language into a new bespoke language. So it is then natural for a new developer to face a steep learning curve to learn that new bespoke language before they can make sense of the code.
I'm not condoning overuse of macros. I'd hate to be working with such code too. I'm only stating that Common Lisp is that language that can be programmed to become a different language. They call it a "programmable programming language" for a reason.
It is definitely not true. The existence of neurodivergence is proof enough.
I can visualize an entire application in my head like it is a forest. I can fly around and see various parts and how they fit together. I am unable to juggle the tokens necessary to do logic and basic math in my head but I have no trouble reading a graph in understanding the relationships between numbers.
No matter how many times I try to read it, Lisp is completely inscrutable to me. It requires the same token juggling math does.
So it's not about taste or preference, left handed people learn how to use right-handed scissors, but they can also use left handed scissors in a way that a right-handed person would struggle to.
All that said, the analogy still works because most people don't understand why it doesn't work.
It's very much about what is comfortable for people.
> a righthanded person picks up the lefthanded scissors and deems them weird and uncomfortable. Which they are .. for the right hand of a right-handed person.
What I disagree with is the idea that you can know, just by picking up a pair of scissors if they are left or right-handed. Except for ergonomically shaped ones!, you can't immediately tell. It's only obvious that something is wrong when you try to use them, and even then, I don't think many people would know why.
Remember that this has to be read in historical context. At the time C was invented, things like garbage collection, message-passing object-orientation, generics, rich sets of conditionals, first-class functions, etc. were brand spanking new. They were The Right Thing to do (even judged in the harsh light of hindsight), but also quite complicated to implement – so much so that the New Jersey people skipped right past most of it.
Today these things are par for the course. At the time, they were the The Right Thing that made the system correct but complex, and had adoption penalties. As time passes, the bar for The Right Thing shifts, and today, it would probably not be embodied by Lisp, but maybe by something like Haskell or Rust?
Some of these things were brand spanking new in 01973, but none were in 01991.
There were Lisp systems for minicomputers like the PDP-11; BSD included one (which I think was ancestral to Franz Lisp) and XLISP ran on CP/M. And of course Smalltalk was developed almost entirely on PDP-11-sized minicomputers. But to my recollection virtually all "serious" software for microcomputers and minicomputers was written in low-level languages like assembly or C into the late 80s, not even PL/M—though Pascal did start to win in the late 80s, in significant part by adopting C's low-level features. Nowadays, microcomputers are big enough and fast enough that Lisp, Haskell, or even Rust is viable.
I don't think "the right thing" is mostly about what features your system has. I think it has more to do with designing those features to work predictably and compose effectively.
> C is from 01973.
> Some of these things were brand spanking new in 01973
...right. The Rise of Worse is Better is a memoir, it's set in the past.
I quite like this view, because these things have clearly been copied everywhere such as my language of choice C#, but the one thing that nobody copied is the one that Lisp programmers rave about most: homoiconicity (brackets everywhere).
Are all homoiconic without being full of parenthesis all over the place, the actual meaning is code and data being interchangeable.
There indeed was a language named LISP 2: https://dl.acm.org/doi/pdf/10.1145/1464291.1464362
I posted it on HN two weeks ago but it didn't get much traction: https://news.ycombinator.com/item?id=41640147
How it this different from tree-sitter, except that you can feed the modified code back to the language to evaluate?
I mean, don't get me wrong, Julia metaprogramming seems lovely, but it just seems to me that the word loses meaning if it can applied to all languages with AST macros, no matter how gnarly the AST data structure is (is Rust homoiconic because of proc_macro?).
However, that's not a parsed data structure; it's a Julia expression to construct one. Though I don't have Julia installed, apparently you can just as well write that as :(a + b*c + 1), as explained a few paragraphs further down the page than I guess you read: https://docs.julialang.org/en/v1/manual/metaprogramming/#Quo.... That's also how Julia represents it for output, by default. What you've written there is the equivalent of Lisp (list '+ 'a (list '* 'b 'c) 1), or perhaps (cons '+ (cons 'a (cons (cons '* (cons 'b (cons 'c '()))) (cons 1 '())))). The data structure is as simple as Prolog's, consisting of a .head such as :call and a list of .args. Prolog's, in turn, is only slightly more complex than Lisp's. From a certain point of view, Prolog's structure is actually simpler than Lisp's, but it's arguable.
How this is different from having a tree-sitter parser is that it's trivially easy to construct and analyze such structures, and not just at compile time.
Possibly the source of your confusion is the syntactic sugar which converts x + y + z into what we'd write in Lisp as (+ x y z), and also converts back? I would argue that such syntactic sugar is precisely what you want for constructing and analyzing expressions. That is, it's part of what makes Julia homoiconic in a more useful sense than J. Random Language equipped with a parser for its own syntax.
Had AT&T been allowed to charge real money for UNIX, and the Worse is Better would never happened.
It’s likely that Unix might not had spread if AT&T didn’t give it relatively liberal licensing in the pre-divestiture era. But it’s also likely that something else that was cheap and readily adaptable would’ve taken over instead, even if it wasn’t technically superior to its competitors.
People choose free beer, it always goes even if warm.
I wasn't paying for access to VMS either; it just didn't hold a candle to Unix.
There is always Assembly, compiler extensions, or OS specific APIs, as part of the deliverable.
Funny how UNIX folks always have these two weights approach.
I beg to differ in wax quality for candles, but if we get to do juice with bitter lemons, so be it.
At least is refreshing during Summer.
K&R C has separate compilation, pointer casting, a usable but janky and bug-prone variable-length string type, variadic functions, static variables, literal data of array and record types, bitwise operations, a filesystem access API, and an array iterator type. None of those require "assembly, compiler extensions, or OS specific APIs." (Well, I'm not sure if they specified variadic functions in the book. The first ANSI C did.)
Jensen & Wirth Pascal has none of those, making it completely inadequate for anything beyond classroom use, which was what it was designed for.
Each Pascal implementation that was used for systems programming did of course add all of these features, but many of them added them in incompatible ways, with the result that, for example, TeX had to implement its own string type (in WEB).
Take all the Assembly routines from libc, and K&R C turns into a macro assembler with nicer syntax. And not a good one, given that real macro assemblers actually have better macro capabilities, alongside their high level constructs.
Quite visible in the C dialects that were actually available outside UNIX, on computers people could afford, like the RatC (Made availalbe via A book on C) and Small-C (DDJ article series).
Well even dumbest standard pascal compilers like GPC do allow calling into Assembly. So it should count for Pascal as well, if that is the measure.
Then we have this thing sticking with ISO Pascal from and its dialects, always ignoring that this was seen as an issue, that that is why Modula-2 exists since 1978, and Extended Pascal since 1991, one year later after ANSI C (C89 got a short C90 revision fix).
Also following the K&R C alongside Assembly line, several companies were quite successful with Pascal dialect alongside Assembly, including a famous fruit company.
Back in 2024, C extensions keep being celebrated to the point the most famous UNIX clone can only be compiled with a specific compiler, and the second alternative is only possible after a search company has burned lots of money making it possible.
But hey, lets stick to Pascal and its dialects.
I think "a macro assembler with nicer syntax" is an excellent summary of C. Though it's transitioning to "a retrocomputing programming language we have to support in order to be able to run software that was written long ago".
I agree that many other macro assemblers have more powerful macro capabilities than C. After looking at most of the output of the group that produced Unix, I think that's on purpose: cpp was deliberately less powerful than GPM or m6, but that's not because they weren't familiar with m6 or couldn't figure out how to write it, and ed was deliberately less powerful than QED or TECO, but that wasn't because they weren't familiar with QED. Possibly Plauger's remark about how one of the worst things he'd done in his life was to write a relocating linker in QED provides a clue as to why.
With the benefit of 45–55 years of hindsight, the decision to prioritize clarity over expressiveness in ed and cpp seems to have really paid off. You seem to disagree, but you don't say why; maybe you think it's axiomatic that more expressive languages are better, despite the fact that we're having this discussion in HTML rather than PostScript or TeX, using URLs rather than Smalltalk or Open Firmware bytecode packets, with browsers written mostly in C++ rather than Scheme or Common Lisp, over TCP/IP rather than CHAOSNET. If my suggested axiom were correct, all of those would be the other way around.
I'd like to see RatC, but I haven't been able to find old editions of A Book on C, and the later revisions seem to have removed it.
I don't see how Modula-2 is relevant to a discussion about Pascal. There were lots of Pascal-inspired languages in the 70s and 80s; Modula-2 was neither the most influential one nor Wirth's favorite.
It remains true that you could easily do portable systems programming in C in the late 70s and 80s, and you could do nonportable systems programming in VAX Pascal, but doing portable systems programming in Pascal required major compromises when it was possible at all. (Just to clarify, when I say "systems" I don't mean "kernels"; I mean "not applications", as you clearly also did when you said "VMS also supported Pascal and BASIC dialects for systems programming.")
There were other parts of your comment I wasn't able to make any sense of, but if you feel you said something I haven't responded to, please feel free to clarify.
1. LISP is easy to start with if you're not a programmer. There is very little syntax to get to grips with, and once you understand "everything is a list" it's super easy to expand out from there.
2. LISP really makes it easy to hack your way to a solution. With the REPL and the transparency of "code is data" model you can just start writing code and eventually get to a solution. You don't need to plan, or think about types, or deal with syntax errors. You just write your code and see it executed right there in the REPL.
For my part, I love LISP when it's just me doing the coding, but once you start adding other peoples custom DSL macros or whatever the heck it becomes unwieldy. Basically, I love my LISP and hate other peoples LISP.
Scheme is not Common Lisp, it's kinda the opposite. It comes with batteries included and MCClim is the defacto GUI for it.
>Stuck with Emacs [from the URL]
Well, Lem tries to be Emacs for Common Lisp, but without having to think on two Lisp languages (albeit closely related) at once.
Once you have a REPL, autocomplete and some docstring looking up tool, you are god.
Scheme is the minimal one. Almost like comparing sh with zsh.
In Lisp, almost all of the language’s power is in “user space.”
The ramifications for that are deep and your beliefs as to whether that is good are largely shaped by whether you believe computation is better handled by large groups of people (thus, languages should restrict users) or smaller groups of people (thus, languages should empower users).
See this for more discussion: https://softwareengineering.stackexchange.com/a/237523
They change because they are used.
What this often meant was that getting a feature into your LISP program was something you could do without having to hack at the compiler.
Used to, people balked at how macros and such would break people's ability to step debug code. Which is still largely true, but step debugging is also sadly dead in a lot of other popular languages already.
https://www.youtube.com/watch?v=o4-YnLpLgtk
https://www.youtube.com/watch?v=gV5obrYaogU
It makes working on VSCode today look like banging rocks together, let alone 30 years ago.
Today we benefit from having a variety of languages, each with tradeoffs regarding how their expressiveness matches the problem at hand and also the strength of its ecosystem (e.g., tools, libraries, community resources, etc.). I still think Lisp has advantages, particularly when it comes to its malleability through its syntax, its macro support, and the metaobject protocol.
As a Lisp fan who codes occasionally in Scheme and Common Lisp, I don’t always grab a Lisp when it’s time to code. Sometimes my language choices are predetermined by the ecosystem I’m using or by my team. I also think strongly-typed functional programming languages like Standard ML and Haskell are quite useful in some situations. I think the strength of Lisp is best seen in situations where flexibility and have malleable infrastructure is highly desirable.
"Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." --Kent Pitman
In retrospect, saying I don't understand was hyperbolic. Of course I understand that people have their preferred languages. The handful of languages I've used in my career each have their draw.
My comment was meant more to question the assertion that Lisp is the-right-thing, which sounds like asserting the-right-religion.
Lisp definitely does depend on personality type. Quoting Steve Yegge's "Notes from the Mystery Machine Bus" (https://gist.github.com/cornchz/3313150):
> Software engineering has its own political axis, ranging from conservative to liberal. (...) We regard political conservatism as an ideological belief system that is significantly (but not completely) related to motivational concerns having to do with the psychological management of uncertainty and fear. (...) Liberalism doesn't lend itself quite as conveniently to a primary root motivation. But for our purposes we can think of it as a belief system that is motivated by the desire above all else to effect change. In corporate terms, as we observed, it's about changing the world. In software terms, liberalism aims to maximize the speed of feature development, while simultaneously maximizing the flexibility of the systems being built, so that feature development never needs to slow down or be compromised.
Lisp, like Perl and Forth, is an extremist "liberal" language, or family of languages. Its value system is centered on making it possible to write programs you couldn't write otherwise, rather than reducing the risk you'll screw it up. It aims at expressiveness and malleability, not safety.
The "right thing" design philosophy is somewhat orthogonal to that, but it also does pervade Lisp (especially Scheme) and, for example, Haskell. As you'd expect, the New Jersey philosophy pervades C, Unix shells, and Golang. Those are also fairly liberal languages, Golang less so. But a C compiler had to fit within the confines of the PDP-11 and produce fast enough code that Ken would be willing to use it for the Unix kernel, and it was being funded as part of a word processing project, so things had to work; debuggability and performance were priorities. (And both C and Unix were guided by bad experiences with Multics and, I infer, M6 and QED.) MACLISP and Interlisp were running on much more generous hardware and expected to produce novel research, not reliable production systems. So they had strong incentives to both be "liberal" and to seek after the "right thing" instead of preferring expediency.
I like lisp for the most part, but holy shit is the enduring dialog surrounding it the absolute worst part of the whole family of languages by far. No, it doesn't have or give you superpowers. Please grow up.