The main reason why you won’t see a Lisp ‘killer app’ as part of the user’s OS is that Lisp’s world view of the world is incompatible with Unix. Unix accommodates to different languages by providing a ‘common interface’ in processes. To some degree, one can draw the analogy with processes being function calls , the standard input being the parameters of the function and the standard output its return value. By contrast, in Lisp (and Smalltalk) you start with a base world (your image) and you add your program into the world little by little, by incremental compilation. Your compiler, debugger, and the rest of the environment is part of your image. To accommodate to the Unix world view would mean to recompile the whole program each time, which destroys the advantages of incremental development offered by Lisp.
Or does it’s flexibility make it difficult to use in large organizations (with varying levels of experience)? Or something else?
We know its been used in large organization (e.j. ITA now Google Flights) so its not a question of capability.
It’s a big language (though not C++ big, I think). CLtL2 is one book, but it’s a thousand-page book.
A lot of things are structured and/or named oddly for historical reasons. You need to unlearn and relearn a bunch of stuff, and just have to memorize other things.
There’s more high and low-level power than you might be used to in a single language. If you really want to learn CL you’ll want to eventually get comfortable writing super high-level metaprogramming macros and also reading x86 assembly spit out by DISASSEMBLE.
CL tends to err on the side of giving the programmer freedom instead of saying “there is exactly one way to do it” (e.g. the package system’s orthogonality with files).
In short: the barrier to entry is so high for the same reasons it took me ten thousand words to describe how to learn it :)
Agreed. The large majority of volunteering work is thankless work. Sadly, a lot of people are more likely to thank you when they are paying for your work. Yet, throwing a tantrum is counterproductive indeed.
Why is the barrier to entry for Common Lisp so high? Is it just the absurdly high number of things that can be done in it? It kinda sounds like the C++ of parenthesis-languages, if the learning curve is that long.
It would be great to have more repo statuses on GitHub / GitLab. Are the moment there is either active or archived. Some projects are prototypes, some of them are write-only, some of them are actually maintained, community-maintained, …
The best thing to do as a FOSS publisher is to clearly delineate how to interact with the project in my experience. This helps to set the expectations. Having issue templates, contributor guide, … But that takes a long time to put in place unfortunately. That’s why I think we’ll see some repo status archetypes emerging in the future.
As a maintainer you can choose how you want to spend your time. By making it clear what you are willing to spend it it reduces uncertainty on the other end, which is the cause of a lot of bad attitude. Some people get anxious and don’t know how to communicate clearly.
Having learned Go (and written the majority of a decent sized system in production), a solid programmer can be productive in 1 month. I taught it to myself (mostly) with a greenfield project and if you were working in an environment with knowledgable co-workers or some code to reference/build on, that shouldn’t be too much of a stretch.
Ive been reading Grammar Of Graphics, a fantastic book about graphing. Working with d3 on a big data visualization project at work. I’m moving this week… and after reading a few articles about worker burnout I am seriously considering applying for tech lead jobs. People need some good leadership.
Writing Lisp well takes, in my experience, an above average programmer, and in a group, a programmer sensitive to varying capabilities.
I disagree with this assessment. The main attraction of CL to me is that it gets out of my way when I want to do something. I don’t have to jump through hoops of the arbitrary restrictions of a particular programming language. All programers may benefit from this quality. I would concede that it may take an above average programmer to exploit said freedom.
First, there are at least some popular non-trivial projects that use Common Lisp – pgloader is an example. But you’re right that it’s certainly rare.
The glib answer to “why aren’t there a lot of Common Lisp projects” is”because there aren’t a lot of Common Lisp programmers”. I think there are a couple of reasons for that.
One reason is that the barrier to entry for Common Lisp is really high. I’ve had people tell me I could learn Go in a month. I don’t know if that’s true (though I’ll be finding out when I start a new job in Go in October) but I can tell you that you definitely cannot really learn Common Lisp in a month. I think even six months of hard work would be pushing it. It’s been three years for me, with two of them being working in CL almost full time (thanks, grad school), and I’m comfortable now but still feel like I have a lot to learn. Most people aren’t lucky enough to have a few years of their life to dedicate to learning a language, so the pool of Common Lisp programmers is always going to be smaller than languages with less of a barrier to entry.
Another reason is that there are some really common misconceptions about Common Lisp, the primary one being “it’s a functional programming language”. It’s not. It’s a language you can do functional programming in if you want, but is really a procedural language at heart. The misconception is bad for two reasons: people who start learning it because they want a functional language get disillusioned and quit, and people who would otherwise want a procedural Lisp never consider it because of the reputation.
Your example of Python is a good one because it illustrates another aspect of the chicken/egg problem: Common Lisp isn’t installed by default anywhere. If I write a small script in Python I can be pretty sure I can just run it on a server somewhere. If a newbie wants to get started writing some Python on MacOS or Linux they can just dive in and worry about all the virtualenv shit later. But CL isn’t included by default on any distro that I know of, so that’s another barrier to entry to overcome.
Those are just a few reasons off the top of my head. To sum it up: I think there’s a bunch of reasons that all feed back on each other and result in a high barrier to entry for Common Lisp. This means there are fewer Common Lisp programmers overall, and that results in fewer Common Lisp projects overall.
I agree, I was really disappointed in the company when it became apparent that a helpful feature (notifying when cartridge was empty) was really DRM. Otherwise its a pretty cool device.
Exactly. I appreciate that the author is trying to bring attention to the problem. Best route is to present it in a mature, respectable way that average consumer and business person will share with their friends. Most won’t share this. A number will even have filters blocking them from seeing it at work.
An alternative style that did get a lot of traction was Nadia Eghbal’s article. I suggest chaica do one more like that if aiming to maximize sharing and contributions.
Thanks @sjl! I keep thinking I should try again at Lisp and this post will make a handy roadmap to refer to.
But my number 1 question, why aren’t there more significant projects written in lisp?
I would think that it would become a dependency for some important piece of software but it never is (aside from Emacs).
Git is so important that it will require perl and bash on my local machine (even on windows!), mercurial will include python, firefox is starting to sneak Rust in piece by piece, but is lisp just so happy being on its own island that it never gets used by any other project? Clojure flipped this by buildling the lisp on top of the other language, which I think contributes to its success.
Or does it’s flexibility make it difficult to use in large organizations (with varying levels of experience)? Or tsomething else?
Recently, I’ve been playing Octopath Traveler, and I’m very disappointed with the poor texture filtering seen in this game. It is PS1-level, with severe shimmering artifacts, which ruins the nice pixel art. Tastefully merging retro pixel art with 3D environment is a very cool aesthetic to me, so I want it to look right. Taking
The whole point that some pixelart is aliased (including the rotated ones, or 2D-3D mixed) is because it’s a style choice. A lot of people like it that way, me included.
The main reason why you won’t see a Lisp ‘killer app’ as part of the user’s OS is that Lisp’s world view of the world is incompatible with Unix. Unix accommodates to different languages by providing a ‘common interface’ in processes. To some degree, one can draw the analogy with processes being function calls , the standard input being the parameters of the function and the standard output its return value. By contrast, in Lisp (and Smalltalk) you start with a base world (your image) and you add your program into the world little by little, by incremental compilation. Your compiler, debugger, and the rest of the environment is part of your image. To accommodate to the Unix world view would mean to recompile the whole program each time, which destroys the advantages of incremental development offered by Lisp.
We know its been used in large organization (e.j. ITA now Google Flights) so its not a question of capability.
It looks like CL standard is quite close in size to C++.
A couple of reasons:
In short: the barrier to entry is so high for the same reasons it took me ten thousand words to describe how to learn it :)
Awesome. I’ve updated my blog post. Glad I could help contribute. :)
Agreed. The large majority of volunteering work is thankless work. Sadly, a lot of people are more likely to thank you when they are paying for your work. Yet, throwing a tantrum is counterproductive indeed.
Why is the barrier to entry for Common Lisp so high? Is it just the absurdly high number of things that can be done in it? It kinda sounds like the C++ of parenthesis-languages, if the learning curve is that long.
That’s awesome. I’ve tried experimenting with ptrace/strace to ensure correct dependency declaration and it’s a real pain to get right.
It would be great to have more repo statuses on GitHub / GitLab. Are the moment there is either active or archived. Some projects are prototypes, some of them are write-only, some of them are actually maintained, community-maintained, …
The best thing to do as a FOSS publisher is to clearly delineate how to interact with the project in my experience. This helps to set the expectations. Having issue templates, contributor guide, … But that takes a long time to put in place unfortunately. That’s why I think we’ll see some repo status archetypes emerging in the future.
As a maintainer you can choose how you want to spend your time. By making it clear what you are willing to spend it it reduces uncertainty on the other end, which is the cause of a lot of bad attitude. Some people get anxious and don’t know how to communicate clearly.
Having learned Go (and written the majority of a decent sized system in production), a solid programmer can be productive in 1 month. I taught it to myself (mostly) with a greenfield project and if you were working in an environment with knowledgable co-workers or some code to reference/build on, that shouldn’t be too much of a stretch.
Ive been reading Grammar Of Graphics, a fantastic book about graphing. Working with d3 on a big data visualization project at work. I’m moving this week… and after reading a few articles about worker burnout I am seriously considering applying for tech lead jobs. People need some good leadership.
I disagree with this assessment. The main attraction of CL to me is that it gets out of my way when I want to do something. I don’t have to jump through hoops of the arbitrary restrictions of a particular programming language. All programers may benefit from this quality. I would concede that it may take an above average programmer to exploit said freedom.
First, there are at least some popular non-trivial projects that use Common Lisp – pgloader is an example. But you’re right that it’s certainly rare.
The glib answer to “why aren’t there a lot of Common Lisp projects” is”because there aren’t a lot of Common Lisp programmers”. I think there are a couple of reasons for that.
One reason is that the barrier to entry for Common Lisp is really high. I’ve had people tell me I could learn Go in a month. I don’t know if that’s true (though I’ll be finding out when I start a new job in Go in October) but I can tell you that you definitely cannot really learn Common Lisp in a month. I think even six months of hard work would be pushing it. It’s been three years for me, with two of them being working in CL almost full time (thanks, grad school), and I’m comfortable now but still feel like I have a lot to learn. Most people aren’t lucky enough to have a few years of their life to dedicate to learning a language, so the pool of Common Lisp programmers is always going to be smaller than languages with less of a barrier to entry.
Another reason is that there are some really common misconceptions about Common Lisp, the primary one being “it’s a functional programming language”. It’s not. It’s a language you can do functional programming in if you want, but is really a procedural language at heart. The misconception is bad for two reasons: people who start learning it because they want a functional language get disillusioned and quit, and people who would otherwise want a procedural Lisp never consider it because of the reputation.
Your example of Python is a good one because it illustrates another aspect of the chicken/egg problem: Common Lisp isn’t installed by default anywhere. If I write a small script in Python I can be pretty sure I can just run it on a server somewhere. If a newbie wants to get started writing some Python on MacOS or Linux they can just dive in and worry about all the virtualenv shit later. But CL isn’t included by default on any distro that I know of, so that’s another barrier to entry to overcome.
Those are just a few reasons off the top of my head. To sum it up: I think there’s a bunch of reasons that all feed back on each other and result in a high barrier to entry for Common Lisp. This means there are fewer Common Lisp programmers overall, and that results in fewer Common Lisp projects overall.
I agree, I was really disappointed in the company when it became apparent that a helpful feature (notifying when cartridge was empty) was really DRM. Otherwise its a pretty cool device.
Lisp provokes an instinctive hostility from others, much like Haskell.
The Common Lisp community is a crew of mostly loners.
Writing Lisp well takes, in my experience, an above average programmer, and in a group, a programmer sensitive to varying capabilities.
Many groups reject tools that demand anything above average.
GUI integration is, as usual for most open source, terrible.
Web service software tends to be messy.
No company or Glamorous Person really is championing Common Lisp. Unlike Haskell, the academy has rejected Common Lisp (but tolerates Scheme).
Companies absolutely loathe risk and extra investment, so the above keeps Lisp out of the corporate environment.
All of the above keep Common Lisp roughly around OCaml in capability and mindshare. It’s a shame.
I am reasonably certain my first (and only) Win95 machine was a Pentium 100 MHz with 8 MB of RAM.
Exactly. I appreciate that the author is trying to bring attention to the problem. Best route is to present it in a mature, respectable way that average consumer and business person will share with their friends. Most won’t share this. A number will even have filters blocking them from seeing it at work.
An alternative style that did get a lot of traction was Nadia Eghbal’s article. I suggest chaica do one more like that if aiming to maximize sharing and contributions.
“[MD5 is] cryptographically broken and unsuitable for further use”.
I’d hope a “Guru” level Sysadmin would know this.
Could you elaborate on this one?
Thanks @sjl! I keep thinking I should try again at Lisp and this post will make a handy roadmap to refer to.
But my number 1 question, why aren’t there more significant projects written in lisp?
I would think that it would become a dependency for some important piece of software but it never is (aside from Emacs).
Git is so important that it will require perl and bash on my local machine (even on windows!), mercurial will include python, firefox is starting to sneak Rust in piece by piece, but is lisp just so happy being on its own island that it never gets used by any other project? Clojure flipped this by buildling the lisp on top of the other language, which I think contributes to its success.
Or does it’s flexibility make it difficult to use in large organizations (with varying levels of experience)? Or tsomething else?
Thanks
The whole point that some pixelart is aliased (including the rotated ones, or 2D-3D mixed) is because it’s a style choice. A lot of people like it that way, me included.
That aside, it’s a good tutorial.