> you can work on your problem, or you can customize the language to fit your problem better
There’s a thing I’m whispering to myself constantly as I work on software: “if I had something that would make this easy, what would it look like?”
I do this continuously, whether I’m working in C++ or Python. Although the author was talking about Lisp here, the approach should be applied to any language. Split the problem up into an abstraction that makes it look easy. Then dive in and make that abstraction, and ask yourself again what you’d need to make this level easy, and repeat.
Sometimes it takes a lot of work to make some of those parts look and be easy.
In the end, the whole thing looks easy, and your reward is someone auditing the code and saying that you work on a code base of moderate complexity and they’re not sure if you’re capable enough to do anything that isn’t simple. But that’s the way it is sometimes.
Yes! I call this sort of top-down programming "wishful thinking." It is these days much easier to explain to people, because machine learning tools.
“if you can just trust that chat GPT will later fill in whatever stub functions you write, how would you write this program?” — and you can quickly get going, “well, I guess I would have a queue, while the queue is not empty I pull an item from there, look up its responsible party in LDAP, I guess I need to memoize my LDAP queries so let's @cache that LDAP stub, if that party is authorized we just log the access to our S3-document, oh yeah I need an S3-document I am building up... otherwise we log AND we add the following new events to the queue...”
It is not the technique that has most enhanced what I write, which is probably a variant on functional core imperative shell. But it's pretty solid as a way to break that writers block that you face in any new app.
"Wishful thinking" is exactly what it's called in SICP. You write the code to solve your problem using the abstraction you want, then you implement the abstraction.
“The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”
> C++ is for when complexity cost is worth trading for performance gain. What type of person successfully finds simplicity working in C++?
> What type of person successfully finds simplicity working in C++?
Be the change you want to see!
Every language has the raw materials available to turn the codebase into an inscrutable complex mess, C++ more than others. But it’s still possible to make it make sense with a principled approach.
Those of us that grew up with the language, always used it instead of C when given the option, thus even if no one can claim expertise, we know it well enough to find it relatively simple to work with.
In the some vein that Python looks simple on the surface, but in reality it is a quite deep language, when people move beyond using it as DSL for C/Fortran libraries, or introduction to programming scenarios.
The classic issue of who made the first tongs could be inserted here, with some hammering.
(It's a classic legend. There is an Islamic legend that Allah gave the first pair of tongs to the first blacksmith because you need a pair of tongs to make a pair of tongs. There's a Nordic legend that Thor made the first tongs. In reality, somebody probably used a bent piece of green wood, which didn't last long, but could be easily replaced.)
His piece "Vibe Coding, Final Word"[1] is relevant right now.
Whitworth [0] showed that you can make a more precise tool than the one you use to make it. This means you "evolve" towards tongs, or screws, or high-precision calipers, or anything else you want to make, if you use the right process.
It doesn’t make any sense that you’d need tongs to make tongs; just hold the workpiece. Maybe you cant draw out the reins quite so much on your first one. (Ok im a modern blacksmith that assumes the existence of rolled bar as a source material)
But a hammer! How do you make a hammer without a hammer?
That's not remotely "vibe coding" though. Vibe coding would be like using Claude Code or Codeium Windsurf with a recent model. Something that does the code edits for you and optionally lets you code-review them first to approve/deny. Not copy-pasting GPT4o-produced bupkis.
The truth is that when you tap softened tongs around a workpiece into shape, they turn into parentheses. That's what reminds you of Lisp, not the malleability explanation that you invented afterward.
The distinction between Lisp and the programming languages widely adopted in the industry is a bit like the distinction between artist blacksmiths and fabricators. If blacksmiths have the skills and technique to transform the form of the metal materials they work with. While fabricators essentially rely upon the two operations of cutting and welding. Blacksmiths will use those two operations in their work, but also have the more plastic techniques of splitting, drifting, upsetting, fullering, etc.
This is a great analogy, particularly with one addition. That the two operations vary between fabricators so that, ideally, you have the two operations that work the best for your industry. That is the same difference between Lisp like languages and industrial languages, that the former allows you to build any domain language while the latter are already built domain languages. That is that when using Lisp you work like a sculptor, you build your language by removing expressiveness until you can only express your domain. Industrial languages have already removed the expressiveness and are adopted by people who find it useful for their working domain. The main difference is that the latter are more generalized to a category of domains vs. one particular domain. I think this is one of the key reasons they 'won' over more expressive languages like Lisp. They created a better common ground for related projects to collaborate on and collaboration is more important than domain expressiveness.
From this comment it follows that for “industrial” software, having less power actually allows for a greater degree of composition at a higher level. Whether “more power” is advantageous is contextually dependent. Having only cutting and welding at your disposal is, as a designer, somewhat freeing.
This comment reminded me of a Youtube channel I watch. The episode I was just watching had Kurtis making flogging spanners (wrenches intended to be used with a hammer) out of steel plate. Draw the outline, cut with a torch, smooth the edges with a grinder, done.
It'd be interesting if we could draw up a family tree of tool fabrication for any object.
The root object would be two rocks brought together in a bang heard 'round the world, then perhaps some sharpened sticks, all the way up to a Colchester lathe somewhere in Victorian England and the machinery that made whatever object we're looking at.
which is a multi-volume series based on the fact that a lathe is the only tool in a machine shop which can replicate itself, so the first volume has one make an aluminum casting foundry in one's backyard, the second how to use it to make a lathe, then one can use the rough-cast lathe to improve itself (or make a better lathe), and from there make the entirety of a machine shop.
Blacksmithing as noted in the original article is unique in that it is self-sufficient in a way that few other processes are, and downright elemental in what one needs.
Another book which touches on this sort of things is Verne's _The Mysterious Island_ which has a couple of escaped Civil War prisoners making things from essentially first principles:
Less on the nose are _Robinson Crusoe_ and _The Swiss Family Robinson_, though those have starter kits in the form of flotsam and jetsam (rather more than that for the latter).
Lisp is a tool meant to be molded to the work, not to have the work forced into a broader, less expressive Lisp mold. Tongs are tools that can be molded to fit the work, rather than forcing the work to fit the tongs (or awkwardly, and perhaps disastrously, not fitting the tongs).
There's one thing I've never understood. Lisp is 65 years old. It's older than any mainstream programming language apart from FORTRAN. It has a bevy of vocal fans in every generation. So...why hasn't it gone mainstream? Or at least, why has it failed to remain there?
Lisp became incredibly popular at one point. It spawned so much productivity that it created huge programs that used lots of memory and demanded expensive hardware.
This peaked at a time when microcomputers had not reached the right affordability and power parameters.
People who were developing in Lisp turned their eyes to the microcomputer market and the business to be had there, if the stuff would only run. So there was some activity of rewriting Lisp stuff in languages like Bliss and C.
The transition from powerful workstations (where we can count Lisp machines) to microcomputers basically destroyed everything which couldn't make the jump nimbly.
The new crop of programmers who cut their teeth on micros simply had no knowledge or experience with anything that didn't run on micros.
Poof, just like that, a chunk of the computing sphere consisting of new people suddenly had amnesia about Cobol, Fortran, Snobol, PL/I, operating systems like TOPS/20 and VMS and whatnot.
Only Unix pulled through, pretty much --- and that's because Unix started on relatively weak hardware, and was kept small. Unix started getting complicated approximately in step with micro hardware getting more complicated and powerful. E.g. a Unix kernel was around 50 kilobytes in 1980. not a good fit for some Apple II or Commodore Pet, but not far off from the resources the IBM PC would have.
By the time micros were powerful enough to the huge Lisp stuff with 20 megabyte images, we were into the 90s, and starting to be overrun with crap dynamic languages.
Now Lisp people could have buckled down and worked on promoting excellent Lisps for microcomputers. There were a few fledgling efforts like that that were not promoted well.
It seems that what Lisp programmers there were, they were mostly wrapped up working on bigger problems on larger hardware, and ignored microcomputers.
It's very hard to promote anything today that most of your Generation X (now management class) didn't get to play with in the 80s and 90s.
Because Lispers sneered at the microprocessors of the time while everybody else piggybacked on them. And, by the time that attitude changed in the early 90s, there were already socially entrenched languages that had the "superpower" of garbage collection (Tcl for ECAD, Perl for sysadmin).
Nobody in the Lisp world ever took the time to implement stuff that people wanted on those tiny machines. Or to demonstrate to people the cool stuff it could do.
You can see this in Dr. Dobbs Journal. People are doing things like drawing graphics, writing spell checkers and controlling modems. Assembly and BASIC are normal but C and Forth are mentioned regularly. Turbo Pascal pops up in 1984. Some of the names are famous enough that you recognize them even now, decades later.
Lisp just ... gets barely mentioned in passing sometimes. And nobody of note writes anything about it. Somebody could have built a word processor, a spell checker, a chess game, a reversi game, ANYTHING ... but nobody did.
Related question: Why is welding pretty mainstream while blacksmithing is a much more niche craft? Blacksmithing is a more overarching skill: After all every blacksmith knows how to weld but relatively few welders can forge effectively.
Possible answers:
1. Blacksmiths enjoy making custom tools for each domain while welders just want to get on with solving their domain problem.
2. Blacksmithing is harder to learn. Welding using modern techniques is easy to learn. (Caveat: Welding well is quite difficult. But learning to weld good enough to repair a broken hitch on your tractor is easy.)
3. Welding can solve a very large chunk of metalwork problems. Not all of them--and not always with elegance--but it gets the job done quickly. Blacksmithing can solve a larger set of metalwork problems with more elegance but it also takes more time and skill.
Disclaimer: this mostly happened before, or at best shortly after, I was born, so this isn't drawn from personal recollection but rather attempting to synthesize from others' recollections, often from people who have some bias.
One of the major trends in computing in the 80's and 90's is that high-end systems lost out to the growth in capabilities of low-end systems, and this happens in pretty much every level in the computing stack. Several people responded to this trend by writing articles sniffling that their high-end systems lost to mass market garbage, often by focusing on the garbage of the mass market garbage and conveniently avoiding analysis as to why the high-end systems failed to be competitive in the mass market. The wonders of Lisp is one of the major topics of this genre.
Most famously, Lisp was tarred by its association with AI during the concomitant collapse of AI that led to the AI Winter, though it's less often explored why AI failed. In short, it didn't work. But more than just AI at the time, people also felt that the future of programming in general was based around the concept of something like rules-based systems: you have a set of rules that correspond to all of the necessary business logic, and a framework of program logic that's making those rules actually take effect--you can see how a language like Lisp works very well in such a world. But programming doesn't have a clean separation between business logic and program logic in practice, and attempts to make that separation cleaner have largely failed.
So Lisp has a strong competitive advantage in a feature that hasn't proven to actually be compelling (separating business from program logic). Outside of that feature, most of its other features are rather less unique and have seeped into most mainstream programming languages. Functional paradigms, REPLs, smart debuggers, garbage collection--these are all pretty widespread nowadays. Where Lisp had good ideas, they've been extensively borrowed. Where those ideas haven't pulled their weight... they've languished, and most of the people wistfully wishing for a return to Lisp haven't acknowledged that the limitations of these features.
The language was married to and sold with a hardware architecture that didn’t achieve massive commercial success compared to the other workstations at the time and later microcomputers.
But where is it now? If not mainstream, where? Is it not used at all, or only by hobbyists, or also by successful companies, today? If it isn't mainstream, is it important, if not, what's the cursor?
Programming language adoption is more than just about syntax and semantics; there are other factors. For example, JavaScript is often criticized for its design, yet this hasn’t stopped tens of millions of developers from learning the language, since if you want to do client-side Web programming (the most widely deployed platform in the world), you need to use JavaScript, period. It also helps if a language has/had a major corporate backer at a crucial time in its life. Java has Sun/Oracle, C# has Microsoft, Go has Google, and C and C++ had AT&T (Bell Labs).
Lisp’s most successful commercial period was during the 1980s during an AI boom. Companies such as Symbolics, Texas Instruments, and Xerox sold workstations known as Lisp machines that were architecturally designed for running Lisp programs. They had corporate and institutional customers who were interested in AI applications developed under Lisp, including the United States government. Lisp was also standardized during this time period (Common Lisp). Lisp even caught the attention of Apple; Apple had some interesting Lisp and Lisp-related projects during its “interregnum” period when Steve Jobs was absent, most notably Macintosh Common Lisp, the original Newton OS (before C++ advocates won approval from CEO John Sculley), Dylan, and SK8.
However, the AI Winter of the late 1980s and early 1990s, combined with advances in the Unix workstation market where cheaper Sun and DEC machines were outperforming expensive Lisp machines at Lisp programs, severely hurt Lisp in the marketplace. AI would boom again in the 2010s, but this current AI boom is based not on the symbolic AI that Lisp excelled at, but on machine learning, which relies on numerical computing libraries that have C, C++, and even Fortran implementations and Python wrappers. Apple in the 1990s could have been a leading advocate of Lisp for desktop computing, but Apple was an unfocused beacon of creativity; many interesting projects, but no solid execution for replacing the classic Mac OS with an OS that could fully meet the demands for 1990s and 2000s computing. It took Apple to purchase NeXT to make this happen, and under Steve Jobs’ leadership Apple was a focused beacon of creativity with sharp execution. Of course, we ended up with Smalltalk-inspired Objective-C, not Common Lisp or Dylan, as Apple’s official language before Swift was released after the end of Jobs’ second reign.
Some other factors:
1. Lisp was truly unique in the 60s, 70s, and 80s, but it required expensive hardware to run. It would be hard to conceive of a Lisp running well on a 6502 or an 8086. Something like my NeXT Cube with a 68040 would do a much better job, but those machines cost roughly $6500 in 1989 dollars, out of reach for many developers.
2. By the time hardware capable of running Lisp acceptably became affordable, other languages started offering certain features that used to be unique to Lisp. Wanted garbage collection? In 1995 Java became available. Want object-oriented programming? You didn’t even have to wait until 1995 for that due to C++. Want anonymous functions and map()? Python’s popularity took off in the 2000s. Yes, Lisp still offers features that are not easily found in other languages (such as extensive metaprogramming), but the gap between Lisp and competing popular languages has been narrowing with each successive decade.
Heavyweight support for corporate usecases is exactly what Lisp is missing right now. I would love for MS to pump out a Visual Scheme or TypeLisp. It’s the perfect scripting language for embedding in CLR Managed Code. Rather than bringing in something massive like C#.
Alas, I think MS saw the failure of Clojure within the Java ecosystem and foresaw the same if they made a similar effort.
> you can work on your problem, or you can customize the language to fit your problem better
There’s a thing I’m whispering to myself constantly as I work on software: “if I had something that would make this easy, what would it look like?”
I do this continuously, whether I’m working in C++ or Python. Although the author was talking about Lisp here, the approach should be applied to any language. Split the problem up into an abstraction that makes it look easy. Then dive in and make that abstraction, and ask yourself again what you’d need to make this level easy, and repeat.
Sometimes it takes a lot of work to make some of those parts look and be easy.
In the end, the whole thing looks easy, and your reward is someone auditing the code and saying that you work on a code base of moderate complexity and they’re not sure if you’re capable enough to do anything that isn’t simple. But that’s the way it is sometimes.
Yes! I call this sort of top-down programming "wishful thinking." It is these days much easier to explain to people, because machine learning tools.
“if you can just trust that chat GPT will later fill in whatever stub functions you write, how would you write this program?” — and you can quickly get going, “well, I guess I would have a queue, while the queue is not empty I pull an item from there, look up its responsible party in LDAP, I guess I need to memoize my LDAP queries so let's @cache that LDAP stub, if that party is authorized we just log the access to our S3-document, oh yeah I need an S3-document I am building up... otherwise we log AND we add the following new events to the queue...”
It is not the technique that has most enhanced what I write, which is probably a variant on functional core imperative shell. But it's pretty solid as a way to break that writers block that you face in any new app.
"Wishful thinking" is exactly what it's called in SICP. You write the code to solve your problem using the abstraction you want, then you implement the abstraction.
I want to hear more about this functional core/imperative shell....
2 replies →
“The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”
George Bernard Shaw, Man and Superman
C++ is for when complexity cost is worth trading for performance gain. What type of person successfully finds simplicity working in C++?
> C++ is for when complexity cost is worth trading for performance gain. What type of person successfully finds simplicity working in C++?
> What type of person successfully finds simplicity working in C++?
Be the change you want to see!
Every language has the raw materials available to turn the codebase into an inscrutable complex mess, C++ more than others. But it’s still possible to make it make sense with a principled approach.
Those of us that grew up with the language, always used it instead of C when given the option, thus even if no one can claim expertise, we know it well enough to find it relatively simple to work with.
In the some vein that Python looks simple on the surface, but in reality it is a quite deep language, when people move beyond using it as DSL for C/Fortran libraries, or introduction to programming scenarios.
I think Casey Muratori calls this "compression". And yeah (see other child comment), he does it in C++ :-)
Creating a Domain Specific Language (DSL) for a given task is a classic approach to solving problems.
The classic issue of who made the first tongs could be inserted here, with some hammering.
(It's a classic legend. There is an Islamic legend that Allah gave the first pair of tongs to the first blacksmith because you need a pair of tongs to make a pair of tongs. There's a Nordic legend that Thor made the first tongs. In reality, somebody probably used a bent piece of green wood, which didn't last long, but could be easily replaced.)
His piece "Vibe Coding, Final Word"[1] is relevant right now.
[1] https://funcall.blogspot.com/2025/04/vibe-coding-final-word....
Whitworth [0] showed that you can make a more precise tool than the one you use to make it. This means you "evolve" towards tongs, or screws, or high-precision calipers, or anything else you want to make, if you use the right process.
[0] https://en.wikipedia.org/wiki/Joseph_Whitworth
Simon Winchester did a book on this:
_The Perfectionists: How Precision Engineers Created the Modern World_
(alternately title _Exactly_)
https://www.goodreads.com/work/editions/56364115-the-perfect...
and for further technical details see:
_Foundations of Mechanical Accuracy_ by Wayne R. Moore
https://mitpress.mit.edu/9780262130806/foundations-of-mechan...
3 replies →
According to "official" legend it was the brothers Brokkr & Eitri who made Mjolnir, though I couldn't find anything about the tongs.
https://en.wikipedia.org/wiki/Brokkr
Re: "funcall's vibe coding findings", it makes sense that human-style lisp (/tongs) would be too nonlinear for LLMs (or gods like Thor) to generate?
Edit: but in line with latter-day retcons it also makes sense that Thor would get credit for something good that Loki did
It doesn’t make any sense that you’d need tongs to make tongs; just hold the workpiece. Maybe you cant draw out the reins quite so much on your first one. (Ok im a modern blacksmith that assumes the existence of rolled bar as a source material)
But a hammer! How do you make a hammer without a hammer?
1 reply →
That's not remotely "vibe coding" though. Vibe coding would be like using Claude Code or Codeium Windsurf with a recent model. Something that does the code edits for you and optionally lets you code-review them first to approve/deny. Not copy-pasting GPT4o-produced bupkis.
Have you considered the possibility that this would have made things worse?
1 reply →
The truth is that when you tap softened tongs around a workpiece into shape, they turn into parentheses. That's what reminds you of Lisp, not the malleability explanation that you invented afterward.
Lisp, Jazz, Aikido and (now) Blacksmithing.
More generous & valuable comment from reddit
The distinction between Lisp and the programming languages widely adopted in the industry is a bit like the distinction between artist blacksmiths and fabricators. If blacksmiths have the skills and technique to transform the form of the metal materials they work with. While fabricators essentially rely upon the two operations of cutting and welding. Blacksmiths will use those two operations in their work, but also have the more plastic techniques of splitting, drifting, upsetting, fullering, etc.
https://old.reddit.com/r/lisp/comments/1eu9gd9/comment/likzw...
These additional basic tools are created from essentially the same working material, on the fly, just like the tongs in TFA
This is a great analogy, particularly with one addition. That the two operations vary between fabricators so that, ideally, you have the two operations that work the best for your industry. That is the same difference between Lisp like languages and industrial languages, that the former allows you to build any domain language while the latter are already built domain languages. That is that when using Lisp you work like a sculptor, you build your language by removing expressiveness until you can only express your domain. Industrial languages have already removed the expressiveness and are adopted by people who find it useful for their working domain. The main difference is that the latter are more generalized to a category of domains vs. one particular domain. I think this is one of the key reasons they 'won' over more expressive languages like Lisp. They created a better common ground for related projects to collaborate on and collaboration is more important than domain expressiveness.
From this comment it follows that for “industrial” software, having less power actually allows for a greater degree of composition at a higher level. Whether “more power” is advantageous is contextually dependent. Having only cutting and welding at your disposal is, as a designer, somewhat freeing.
6 replies →
This comment reminded me of a Youtube channel I watch. The episode I was just watching had Kurtis making flogging spanners (wrenches intended to be used with a hammer) out of steel plate. Draw the outline, cut with a torch, smooth the edges with a grinder, done.
I love this analogy!
For the academic take on this see:
https://ocw.mit.edu/courses/6-001-structure-and-interpretati...
It'd be interesting if we could draw up a family tree of tool fabrication for any object.
The root object would be two rocks brought together in a bang heard 'round the world, then perhaps some sharpened sticks, all the way up to a Colchester lathe somewhere in Victorian England and the machinery that made whatever object we're looking at.
For the machine shop there are the "Gingery" books:
https://gingerybookstore.com/
which is a multi-volume series based on the fact that a lathe is the only tool in a machine shop which can replicate itself, so the first volume has one make an aluminum casting foundry in one's backyard, the second how to use it to make a lathe, then one can use the rough-cast lathe to improve itself (or make a better lathe), and from there make the entirety of a machine shop.
Blacksmithing as noted in the original article is unique in that it is self-sufficient in a way that few other processes are, and downright elemental in what one needs.
Another book which touches on this sort of things is Verne's _The Mysterious Island_ which has a couple of escaped Civil War prisoners making things from essentially first principles:
https://www.gutenberg.org/ebooks/1268
Less on the nose are _Robinson Crusoe_ and _The Swiss Family Robinson_, though those have starter kits in the form of flotsam and jetsam (rather more than that for the latter).
appropedia.org has a lot of instructions on how to build things, I don't thing a "progression tree" exists, but it is a place to start!
Any sufficiently complicated piece of code contains an ad-hoc implementation of Lisp.
I just don’t get the analogy he’s trying to draw here
Lisp is a tool meant to be molded to the work, not to have the work forced into a broader, less expressive Lisp mold. Tongs are tools that can be molded to fit the work, rather than forcing the work to fit the tongs (or awkwardly, and perhaps disastrously, not fitting the tongs).
That's it, not too complex.
Imagine the software industry if lisp was mainstream.
There's one thing I've never understood. Lisp is 65 years old. It's older than any mainstream programming language apart from FORTRAN. It has a bevy of vocal fans in every generation. So...why hasn't it gone mainstream? Or at least, why has it failed to remain there?
Lisp became incredibly popular at one point. It spawned so much productivity that it created huge programs that used lots of memory and demanded expensive hardware.
This peaked at a time when microcomputers had not reached the right affordability and power parameters.
People who were developing in Lisp turned their eyes to the microcomputer market and the business to be had there, if the stuff would only run. So there was some activity of rewriting Lisp stuff in languages like Bliss and C.
The transition from powerful workstations (where we can count Lisp machines) to microcomputers basically destroyed everything which couldn't make the jump nimbly.
The new crop of programmers who cut their teeth on micros simply had no knowledge or experience with anything that didn't run on micros.
Poof, just like that, a chunk of the computing sphere consisting of new people suddenly had amnesia about Cobol, Fortran, Snobol, PL/I, operating systems like TOPS/20 and VMS and whatnot.
Only Unix pulled through, pretty much --- and that's because Unix started on relatively weak hardware, and was kept small. Unix started getting complicated approximately in step with micro hardware getting more complicated and powerful. E.g. a Unix kernel was around 50 kilobytes in 1980. not a good fit for some Apple II or Commodore Pet, but not far off from the resources the IBM PC would have.
By the time micros were powerful enough to the huge Lisp stuff with 20 megabyte images, we were into the 90s, and starting to be overrun with crap dynamic languages.
Now Lisp people could have buckled down and worked on promoting excellent Lisps for microcomputers. There were a few fledgling efforts like that that were not promoted well.
It seems that what Lisp programmers there were, they were mostly wrapped up working on bigger problems on larger hardware, and ignored microcomputers.
It's very hard to promote anything today that most of your Generation X (now management class) didn't get to play with in the 80s and 90s.
Because Lispers sneered at the microprocessors of the time while everybody else piggybacked on them. And, by the time that attitude changed in the early 90s, there were already socially entrenched languages that had the "superpower" of garbage collection (Tcl for ECAD, Perl for sysadmin).
Nobody in the Lisp world ever took the time to implement stuff that people wanted on those tiny machines. Or to demonstrate to people the cool stuff it could do.
You can see this in Dr. Dobbs Journal. People are doing things like drawing graphics, writing spell checkers and controlling modems. Assembly and BASIC are normal but C and Forth are mentioned regularly. Turbo Pascal pops up in 1984. Some of the names are famous enough that you recognize them even now, decades later.
Lisp just ... gets barely mentioned in passing sometimes. And nobody of note writes anything about it. Somebody could have built a word processor, a spell checker, a chess game, a reversi game, ANYTHING ... but nobody did.
4 replies →
Related question: Why is welding pretty mainstream while blacksmithing is a much more niche craft? Blacksmithing is a more overarching skill: After all every blacksmith knows how to weld but relatively few welders can forge effectively.
Possible answers:
1. Blacksmiths enjoy making custom tools for each domain while welders just want to get on with solving their domain problem.
2. Blacksmithing is harder to learn. Welding using modern techniques is easy to learn. (Caveat: Welding well is quite difficult. But learning to weld good enough to repair a broken hitch on your tractor is easy.)
3. Welding can solve a very large chunk of metalwork problems. Not all of them--and not always with elegance--but it gets the job done quickly. Blacksmithing can solve a larger set of metalwork problems with more elegance but it also takes more time and skill.
6 replies →
Disclaimer: this mostly happened before, or at best shortly after, I was born, so this isn't drawn from personal recollection but rather attempting to synthesize from others' recollections, often from people who have some bias.
One of the major trends in computing in the 80's and 90's is that high-end systems lost out to the growth in capabilities of low-end systems, and this happens in pretty much every level in the computing stack. Several people responded to this trend by writing articles sniffling that their high-end systems lost to mass market garbage, often by focusing on the garbage of the mass market garbage and conveniently avoiding analysis as to why the high-end systems failed to be competitive in the mass market. The wonders of Lisp is one of the major topics of this genre.
Most famously, Lisp was tarred by its association with AI during the concomitant collapse of AI that led to the AI Winter, though it's less often explored why AI failed. In short, it didn't work. But more than just AI at the time, people also felt that the future of programming in general was based around the concept of something like rules-based systems: you have a set of rules that correspond to all of the necessary business logic, and a framework of program logic that's making those rules actually take effect--you can see how a language like Lisp works very well in such a world. But programming doesn't have a clean separation between business logic and program logic in practice, and attempts to make that separation cleaner have largely failed.
So Lisp has a strong competitive advantage in a feature that hasn't proven to actually be compelling (separating business from program logic). Outside of that feature, most of its other features are rather less unique and have seeped into most mainstream programming languages. Functional paradigms, REPLs, smart debuggers, garbage collection--these are all pretty widespread nowadays. Where Lisp had good ideas, they've been extensively borrowed. Where those ideas haven't pulled their weight... they've languished, and most of the people wistfully wishing for a return to Lisp haven't acknowledged that the limitations of these features.
It very nearly did. Then the AI Winter happened.
https://en.wikipedia.org/wiki/AI_winter
The language was married to and sold with a hardware architecture that didn’t achieve massive commercial success compared to the other workstations at the time and later microcomputers.
1 reply →
The Lisp Curse: http://winestockwebdesign.com/Essays/Lisp_Curse.html
5 replies →
But where is it now? If not mainstream, where? Is it not used at all, or only by hobbyists, or also by successful companies, today? If it isn't mainstream, is it important, if not, what's the cursor?
elements to not judge in the void https://github.com/azzamsa/awesome-lisp-companies/ (some are hiring) (that's just the companies we know, nothing official)
https://github.com/CodyReichert/awesome-cl/
Programming language adoption is more than just about syntax and semantics; there are other factors. For example, JavaScript is often criticized for its design, yet this hasn’t stopped tens of millions of developers from learning the language, since if you want to do client-side Web programming (the most widely deployed platform in the world), you need to use JavaScript, period. It also helps if a language has/had a major corporate backer at a crucial time in its life. Java has Sun/Oracle, C# has Microsoft, Go has Google, and C and C++ had AT&T (Bell Labs).
Lisp’s most successful commercial period was during the 1980s during an AI boom. Companies such as Symbolics, Texas Instruments, and Xerox sold workstations known as Lisp machines that were architecturally designed for running Lisp programs. They had corporate and institutional customers who were interested in AI applications developed under Lisp, including the United States government. Lisp was also standardized during this time period (Common Lisp). Lisp even caught the attention of Apple; Apple had some interesting Lisp and Lisp-related projects during its “interregnum” period when Steve Jobs was absent, most notably Macintosh Common Lisp, the original Newton OS (before C++ advocates won approval from CEO John Sculley), Dylan, and SK8.
However, the AI Winter of the late 1980s and early 1990s, combined with advances in the Unix workstation market where cheaper Sun and DEC machines were outperforming expensive Lisp machines at Lisp programs, severely hurt Lisp in the marketplace. AI would boom again in the 2010s, but this current AI boom is based not on the symbolic AI that Lisp excelled at, but on machine learning, which relies on numerical computing libraries that have C, C++, and even Fortran implementations and Python wrappers. Apple in the 1990s could have been a leading advocate of Lisp for desktop computing, but Apple was an unfocused beacon of creativity; many interesting projects, but no solid execution for replacing the classic Mac OS with an OS that could fully meet the demands for 1990s and 2000s computing. It took Apple to purchase NeXT to make this happen, and under Steve Jobs’ leadership Apple was a focused beacon of creativity with sharp execution. Of course, we ended up with Smalltalk-inspired Objective-C, not Common Lisp or Dylan, as Apple’s official language before Swift was released after the end of Jobs’ second reign.
Some other factors: 1. Lisp was truly unique in the 60s, 70s, and 80s, but it required expensive hardware to run. It would be hard to conceive of a Lisp running well on a 6502 or an 8086. Something like my NeXT Cube with a 68040 would do a much better job, but those machines cost roughly $6500 in 1989 dollars, out of reach for many developers.
2. By the time hardware capable of running Lisp acceptably became affordable, other languages started offering certain features that used to be unique to Lisp. Wanted garbage collection? In 1995 Java became available. Want object-oriented programming? You didn’t even have to wait until 1995 for that due to C++. Want anonymous functions and map()? Python’s popularity took off in the 2000s. Yes, Lisp still offers features that are not easily found in other languages (such as extensive metaprogramming), but the gap between Lisp and competing popular languages has been narrowing with each successive decade.
2 replies →
Microsoft/Google would push a TypeLisp with Java DX
Heavyweight support for corporate usecases is exactly what Lisp is missing right now. I would love for MS to pump out a Visual Scheme or TypeLisp. It’s the perfect scripting language for embedding in CLR Managed Code. Rather than bringing in something massive like C#.
Alas, I think MS saw the failure of Clojure within the Java ecosystem and foresaw the same if they made a similar effort.
5 replies →
Ah shit, right, it’s probably for the best lisp isn’t mainstream.
Parentheses wouldn't be shift-9 and -0.
"If C was mainstream braces wouldn't be shift-[ and shift-], clearly LOGO must be the dominant language"
1 reply →
i very rarely type parens while coding in lisp.
it's a tree. it's just a few operations to transform it as a structure.
[flagged]