▲ 147 points
back
110 comments
There's a Star Trek TOS episode "Errand of Mercy" where the simple primitive inhabitants of Organia are caught in the middle of a war between the Federation and the Klingons. Kirk is baffled because the Organians refuse his help to defend them against the Klingons. Finally when the Organians have had enough they simply make all the guns disappear, revealing themselves to be a much more advanced species than either of the fighting races.
Lisp reminds me of the Organians. It seems simple and kind of boring until you try something you know is impossible and it just works. It spoils you for other languages.
Impossible might not be the right word. When I was much younger, I would describe it as seeing things done easily in Lisp that I had no idea how to do at all.
Lisp could easily express ideas that I didn't know how to express in other languages. Just as Pascal had made it possible for me to express ideas that I had no idea how to express in BASIC.
Lisp gave me new tools. Just as earlier Pascal had given me new tools.
The Organians told Kirk and the Klingons that they would one day be friends. And rise to their level. Ironically, languages in the 90's and 2000's borrowed more and more from Lisp. Starting with most languages of the last quarter century having Garbage Collection.
Something they don't tell you when you start learning lisp is the sense of calm it brings
It's such a elegant thing, it ruins me for doing "professional" programming
This effect is real for some people, despite a lot of people don't like it.
It's like some post-war syndromes where people feel the hollowness and pointlessness when seeing other people living a normal, meaningful life, or have to go back to the village from large cities.
It's like a red pill, it always bugs me like "I wish I have macros here", or "type classes here", "Erlang process here", "Hindley-Millner or structural typing here"... Actually those languages are not that outstanding, however, it defeats the motivations to make small in-box-improvements like "I'm going to use some OO pattern to make this more SOLID".
You can also try hard to slowly push the industry forward but it's still tens of years to be "professional" based on the history you have read, which sound very defeating for mortals, too.
Imagine yourself has been throwback to an early 90s project where the mantra is still "if it ain't broke, don't fix it", and everyone endlessly patches everything while rejects new technologies because no one else is using them.
Some people have a psychological or emotional reaction to code, similar to the way others do to poetry or prose, and sometimes the shape and structure of code gives people a sense of order and centeredness, in a similar way to OCD. The relative simplicity of Lisp compared to other languages probably makes these effects more acute.
I don't know if that's necessarily a trait of the paradigm or of some of its adherents. I've felt that same calming effect but with other languages - and honestly I've found lisp code to be masochistically terse and opaque a lot of the time, although I've only messed with Arc and dabbled with Clojure and Racket. I guess that just means I haven't found enlightenment yet.
> Some people have a psychological or emotional reaction to code, similar to the way others do to poetry or prose, and sometimes the shape and structure of code gives people a sense of order and centeredness, in a similar way to OCD. The relative simplicity of Lisp compared to other languages probably makes these effects more acute.
I would really dislike to work with such people in a professional setting. Can you imagine having PR with someone who thinks code should inspire an emotional response?
You know what’s beautiful? Simple and effective things, even if you can’t fall in love with the way they look.
Exposure to Go and Clojure brings the opposite effect:
"I don't really want this glitzy thing. Functions, plain data and a bit of polymorphism is all it takes to solve the problem"
uh... clojure is a lisp and supports full blown macros. Surem 95% of the time, Functions, plain data and a bit of polymorphism is all you need. those higher abstractions are for flattening the curve on making easy to use libraries. They are sharp tools. Go decides to hand you safety scissors, clojure gives you a high end razor sharp knife and expects you to be educated on its proper usage.
“And solving the problem in the simplest way possible is what I’m paid to do.”
So I would be doing Clipper 5.x, Turbo Pascal 7, modular development, AOT compiled to native code in a type safe manner?
While reading about Common Lisp and Smalltalk/V releases on Computer Shopper?
Sounds an interesting time travel proposal.
I fear this good feeling may be misleading Lisp fans into liking the language more than it deserves.
Personally, I find that the more feverish I am, the more attractive I find Lisp. It’s one of the first signs that I am coming down with a cold.
This happened to me too. The more I learn about alternative programming methods, the more my brain constructs elegant solutions that completely go around the problem at hand, or even the conditions which led to the context of the problem. I've reached the point where I mainly do data-driven and declarative programming with low-code or no-code in spreadsheets or GUIs. I feel almost physical pain now when I have to write traditional imperative or object-oriented code, because 95% of it feels like a waste of time to me. As in, most of the effort expended by a programmer is in initial setup, remembering mutable state, poorly-architected class hierarchies/interfaces, and rapidly breaking dependencies that only last a few months at most now. Less than 5% of what I do is the "real work" of solving the actual problem.
Not really sure where to go with this, but I found that getting away from programming for 6 months or so this last year has really helped my psyche.
few other good languages have had that said about them:
ml
prolog
apl
forth
they all 'ruin' your life by showing you everything's wrong about daily realities.
oh, and smalltalk
PS: if I missed some, tell me
If you want to see your life ruined, watch this deep dive into Mesa/Cedar environment. :)
https://www.youtube.com/watch?v=z_dt7NG38V4
One of the first workstation OSes written in a memory safe systems programming languages, early 80's at Xerox PARC.
Can we go back in time and kill UNIX?
I have seen this said about almost any non-mainstream language from Haskell to Perl.
I think it comes down to these languages are mostly used by enthusiasts on their own projects, without the daily realities of evolving business requirements and a legacy code base built by mediocre developers.
I would add Rebol & Erlang.
c
I remember in college, there was a point while learning scheme where I felt like a cracked through to another reality. I went from feeling like "eh I can finish this assignment" to "holy shit, I can build _anything_".
I've never written lisp professionally, but every few years I try to get back to it to see if the feeling is still there -- only to get pulled away from the endeavor by life stuff before I can dig the same depth.
"APL has been compared to a diamond, which cannot be made into a larger diamond by the addition of a second one. LISP, in this context, is a ball of clay."
I couldn't have said it better myself. I've come to think that APL and Lisp represents two diametrically opposing philosophies about structuring programs. Right now I'm leaning toward the opinion that the ball of clay approach has run its course and is no longer (or maybe never way) viable. The thousands of layers of abstraction is no longer viable, for both performance and productivity reasons.
Your conclusion may well be correct but I must reject your reasons : 1) we have more (cheap!) hardware capacity than we can shake a stick at so sub-optimal performance is very tolerable and 2) depending on how you measure productivity, i'd argue high level/many layers of indirection languages let you deliver features and value faster than non ball-of-clay languages at the cost of weaker confidence in the code. Which can be mitigated to some extent by more clay :)
Personnaly, give me mud over diamonds any day.
Lisp-programmer does not count brackets, but visualizes the linked list world in some other way. My world consists of brown and red LEGO-bricks. They are clued together in pairs and brown bricks are things and red bricks abstract links. These greasy fake bricks were only playthings we had in the cheap-ass post-war daycare center 1957.
Anyways it would interesting to see 3D-environment where this Lego-paradigm is implemented. I sometimes think about it, but do not find really beautiful way to name things, except tags with letters on them.
Throughout the years, it has always been an inspiration to read up on Stephen K Roberts adventures! If you haven't yet, I strongly recommend exploring the rest of his website: https://microship.com/
I've only written a little bit of it, but it brings me anxiety.
Any language without static types brings me a certain degree of anxiety, thinking at all times about all the ways a given piece of code might be misused and go terribly wrong.
But in Lisp you add another layer: that anything looking like a function call could actually be a macro, further blowing open the door of possibilities for what an unfamiliar piece of code might do.
Of course, parsing Lisp is an exercise in tranquility ;)
It's all about the programmer's personality, I think. Graydon Hoare expressed my feelings: "Basically I've an anxious, pessimist personality; most systems I try to build are a reflection of how terrifying software-as-it-is-made feels to me. I'm seeking peace and security amid a nightmare of chaos."
I’ve never written in lisp, and my lack of knowledge of it always makes me feel a bit of respect towards people who do. Like maybe it’s this amazing thing that if I was smart enough to understand, I would achieve transcendence, or something.
But the biggest thing I look for in a programming language, is “how many bugs can it stop me from writing”, and a lack of any compile time checking is what keeps me from even bothering to look at it.
I’ve spent many years programming in perl, then ruby, before finally using Go and then Java and then Typescript and now Swift, and I feel like the period of time where I would tolerate a lack compile-time type checks is gone. It’s just table stakes at this point.
Maybe lisp is the end game for non-type-checked languages and it’s the best a dynamic language can hope to be. But I just don’t care at this point, because that whole category of languages seems to be a broken idea to me at this point.
>and a lack of any compile time checking is what keeps me from even bothering to look at it.
Common Lisp more than compensates due to some key features:
1. any bug can be corrected at runtime without having to stop the program
2. the type system is completely strong, not weak
3. it actually has a pretty nice type system.
4. the conditions-restart exception handling system is world-class
> it actually has a pretty nice type system
Not by default. And herein lies the core social problem with Lisp:
[new/non-lisp programmers]: Lisp doesn't have X!
[lisp programmers]: Just make your own X! Lisp is extensible! Or pick from the twelve implementations already out there!
Here's the thing: probably all of those implementations are going to be half-baked. And good luck finding editor support for the one you end up going with when there's no standard to rally around. And have fun re-learning the nuances of basic language features every time you join a new team.
A simple core language does not mean simple code:
> 1. any bug can be corrected at runtime without having to stop the program
Can you do this in an automatable and testable way? I.e. can you provide a migration script as part of an automated deployment to an Ops team?
I wouldn't say it's a broken idea. It's just an idea that doesn't scale. Working in a dynamic codebase - especially a Lisp one - basically means you have to be familiar with how everything you're using works. You can't rely on interfaces; you have to fully hold everything in your mental model. When this is feasible - usually meaning that you or a small cohesive team wrote all of it yourselves - the tradeoff is a huge amount of expressiveness. The barriers between the program in your mind and the program in the code get very small, and you can just make things, concisely, unhindered. This is all well and good, but expressiveness tends to be at odds with constraints, safety, and team communication. Lisp is just one extreme of that spectrum.
Personally I feel better having some of those constraints even on throwaway solo projects, though that might not be perfectly rational.
I will also say that Clojure's heavy focus on immutable data helps somewhat with this problem. You can at least count on functions not having side-effects. Usually. Hopefully.
>I wouldn't say it's a broken idea. It's just an idea that doesn't scale. Working in a dynamic codebase - especially a Lisp one - basically means you have to be familiar with how everything you're using works.
That's FUD. Just make your code modular. Lisp gives you tools: namespaces, and systems.
>You can at least count on functions not having side-effects.
The great majority of functions in Lisp don't mutate data.
Hello late: Common Lisp does quite a lot of compile-time type checks though: https://lispcookbook.github.io/cl-cookbook/type.html it's not as extensive as type-safe languages, but clearly far better than any interpreted one. Add the interactivity where you compile a function (yes, just a function) with a keystroke and thus get the errors or warnings instantly, that makes a pleasant experience. We're also waiting for the Coalton library to mature, it brings Hindley-Milner type inference on top of CL…
It's weird to frame lispers as optimistic, possibly a bit insulting since the typical lisper is far from new to programming
Lispers also have features and methods that mean they sleep peacefully at night too
In a modern lisp like Clojure a type checking tooling is a helpful but small aspect of that
Why would it be misused? I could just as easily misuse a function written with static types.
Think about all the ambiguities in the English language. Imagine if you just couldn't get your point across to someone because the words you chose together bring up a different image than the one you intended. And if you really want to have nightmares think about all the ways using the public highway might go wrong.
At some point you have to stop worrying about things that aren't a problem in practice. Type errors represent a tiny proportion of the bugs in dynamically typed programs. It just isn't a problem. Emacs doesn't even have namespaces or anything, yet it still works.
Lisp is very good at teaching you that you're not as good a programmer as you think you are, and that you don't understand the domain as well as you think you do.
These sound like negatives, but it's better to learn these things up front.
Most instructive would be to identify how reality turned out to be so different from the breathless ideal presented, and how to recognize when the next breathless ideal turns out to be similarly unable to be realized.
When reading these old computer-related articles, it's like reading about a parallel universe, slightly different, but very recognizable.
What app someone should build in 2020 to find and show it's true prowess?
I'd say any app that will do any kind of (more than simple) data manipulation. If you plan to support more and more data formats, things will get exponentially worse.
One domain where I'd go with Lisp/Clojure/Scheme any day are banking/financial switches - software used to communicate between banks, card providers, POS devices, even ATMs. These programs usually has to support tons of weird binary protocols (among other things), designed in 70-ties and 80-ties. To make matter worse, bigger banks adds own "juice" to those protocols, making hybrid monstrosities. And usually, you can't find documentation about those protocols, unless you are deeply in banking business.
i would think elixir and erlang suit that better. they both have beautiful binary pattern matching built in, and are perfect to wrap up disparate pieces that talk to each other. they also share some commonality with common lisp that a lisper should like.
Why not use a language which supports Session Types instead?
I'd probably recommend a full-stack SPA, use Clojure's Fulcro with Datomic to get a peek into what's coming next in other ecosystems
Something which uses a DSL to describe the business domain, like Viaweb by PG in the late 90s
Erm.. I think it's a bit overrated TBH. Don't get me wrong - lisp is quite simply magical (and very ahead of the curve). However, when you look back at code, those written in Python just seem much nicer. The AIMA/PAIP code in Common Lisp, for instance, are ugly as hell, while that in Python (for AIMA) is far far elegant. No doubt this stems, in part, from CL's legacy, but I haven't found things to be much better in Scheme land either.
>those written in Python just seem much nicer
>The AIMA/PAIP code in Common Lisp, for instance, are ugly as hell
perhaps it just means you are familiar with python, not lisp.
I have 3 years of experience with both and let me tell you, there is nothing elegant in Python: there's nothing elegant in having to deal with one-line lambdas, global interpreter lock, 30x-50x longer execution times than Lisp, distinction between statements vs expressions, mutability everywhere, a flaccid OOP system, no interactive development features, and horribly written libraries.
Python isn't elegant. It's just more pragmatic and to the point with little waste. Lisp is definitely more elegant, but no one knew (and still don't know) how to tame the beast. We know it's a powerful language, but don't know what school of thought can utilize it safely. That's why Lisp has many horrible messes.
With the small difference that the code written in CL runs blazing fast versus pure Python.
This is a matter of subjective opinion. I see Python code and I think "ew.. this has got 10-20 bugs or mis-handled edge cases I just haven't found yet."
Lisp isn't my favorite syntax, but a piece of Lisp code is much less likely to have hidden gotchas.
Personally I think the PAIP code is very well written. The AIMA code probably slightly less. These are pedagogical programs.
Actual production code may look different, sometimes very different.