4 ms·
I remember loving these papers back in the day. First, I would be far less skeptical than this author is over the tradeoffs of scripting languages. Given the
by btilly 5y ago
I remember loving these papers back in the day.
First, I would be far less skeptical than this author is over the tradeoffs of scripting languages. Given the tools offered by scripting languages, there is one obvious way to do things. The overhead of building a fancy "just right" data structure almost always makes things perform worse than the straightforward solution using dictionaries, arrays and scalars. Given that, people go directly to that solution, leading to less variation in length of code, time and performance. It is always possible to beat a scripting language's performance, but a surprising number of programmers won't.
This is a lesson that generation after generation of programmers have learned in a variety of scripting languages. With the latest winner being Python. But the differences between popular scripting languages generally matter a lot less than the commonalities. (There are exceptions, specialized languages like Lua, R and Julia have very specific strengths and weaknesses despite being aimed at scripting.)
Second, there are two basic reasons why Lisp loses.
The first is the disadvantage of being an image based system. This has a lot of upsides, but the downside is that people lose access to a long toolchain that they are used to for dealing with files. Tools including editors, source control, and so on. Programming expertise is fragile, and that is a pretty big shock.
The second is that Lisp attracts people who want a perfect language. Unfortunately people's ideas of perfection different. So we get a large number of related dialects of Lisp, which are almost compatible with each other. And fail to get critical mass behind any of them.
That said, how big a deal is achieving critical mass? Well obviously it matters. If you're using a mainstream language you can find packages for things that you need, answers on StackOverflow, and so on. But there are diminishing returns. The size of CPAN didn't keep Ruby from rising, and JavaScript and Python in turn have seen meteoric growth.
But that said, there is a fundamental tradeoff. Working in a popular language matters more if you're planning on leveraging lots of existing work. The more your project is building on what you yourself have built, the less important the easy start of external packages is relative to your own development familiarity. The more specialized the thing that you're building, the more it makes sense to use the perfect language for you/your space, rather than going with what's popular.
- pfdietz 5y agoCommon Lisp implementations typically aren't image based systems, although one can dump images. Code is in files, which are loaded. The typical workflow involves modifying files, compiling/loading the changed files and their dependencies (using asdf), and running tests. Nothing persistent is in the image.
- lisper 5y agoI've heard lots of people give lots of reasons over the years why Lisp loses. Very few of those reasons were ever based in fact. Even today I hear people complain that Lisp is an interpreted language. Back in the day they used to complain that it used too much memory, with a RAM footprint of about 8 megabytes (that was including the application code).
- gumby 5y agoThey also commonly complained that the Common Lisp standard was too large with too many library functions. Nowadays one common criticism is that there aren’t enough libraries.
- e3bc54b2 5y agoI started dabbling in CL last month, and I both of those points are valid, if for different reasons today. Most languages have a single standard way of doing basic things, and provide libraries for advanced operations that are not faced by everyone everyday, but more than once per average person. First criticism of Common Lisp being it has too large standard lib, and it collides with first half of above paragraph, because newcomers like me get confused at 4 different ways to set variable, all named ever so slightly differently. Second criticism being lack of libraries. This comes in effect with second half of first paragraph. For eg. I wanted to build a simple webapp to parse PDF into separate pages and convert them to speech. I could write one in Java in a weekend, but there is nothing comparable in Common Lisp, especially in terms of proper documentation and examples. I couldn't lift off after initial interface. I had to scour through library source to even understand basic usage. It is possible I missed something obvious, but as it is, Common Lisp is not a good language to start greenfield projects.