It is, but there are situations where speed of execution and use of memory are less important criteria for choosing a language. For example, when developing very large and complex programs. Lisp(s) allow encapsulation (hiding) of complexity into small modules, easier than c-family languages. Programs in lisp are faster to write, easier to maintain and reason about. The cost of being a bit slower is getting less important with better hardware.
It was about Clojure vs Haskell and more specifically, dynamic vs static typing. Person was claiming that it was so much easier to change statically typed languages. It get more difficult to maintain large projects that are Lisps.
From what I've learned so far about languages, it makes sense. It looks that Lisps are more suitable for implementing algorithms because of the reductionism, but in more realistic systems world, you build interfaces, add random strings, and so on.
If you are patient and good enough, you can probably build significant part of a system, but not all of it. I do not know any systems built entirely on Lisp, but I might be wrong.
Common Lisp doesn't have full static type checking, and very little polymorphic type checking. Only one Lisp compiler (and its derivative) can even do something that's remotely close to static type checking, and even then it's woefully incomplete.
Yeah, it was wrong to say that Common Lisp has static type checking, as it's not part of the standard, and I'm not familiar with many implementations.
All I really know is that when I've programmed with SBCL, I've gotten useful type checking warnings at compile time.
I agree that static type checking is very useful for less stressful refactoring, and so on, and I'm a huge fan of Haskell. But I think very simple kinds of type checking can often be enough.
The argument was that Lisp lacks types to such an extent that building large Lisp systems becomes very difficult (due to the lack of typing). Well, there are lots of large JavaScript systems these days, and Common Lisp, in my experience with SBCL, provides at least more compile-time type checking than that.
It totally depends on what you're doing with your software; different tasks map better or worse to the respective paradigms, depending on what you're trying to do.
Static typing certainly makes it easier to maintain large systems, but it's certainly not a requirement.
You can certainly write entire systems in Lisp; people have made entire computers in order to run Lisp in hardware; there have been operating systems etc.
Moreover, you don't really need to use it for whole systems; use it where it works. There need not be One True Language.
At the moment, Clojure is used in production at Netflix, Twitter, Amazon, Akamai, etc etc etc.
Many of the benefits of Lisps that you talk about here seem to be refuted by writeups I've read where large groups switched from a Lisp to something else...often because it was hard to work with, slower to write and harder to maintain.
Over at reddit.com, we rewrote the site from Lisp to Python in the past week. It was pretty much done in one weekend. (Disclosure: We used my web.py library.) The others knew Lisp (they wrote their whole site in it) and they knew Python (they rewrote their whole site in it) and yet they decided liked Python better for this project. The Python version had less code that ran faster and was far easier to read and maintain.
If Lisp is so great, why did we stop using it? One of the biggest issues was the lack of widely used and tested libraries. Sure, there is a CL library for basically any task, but there is rarely more than one, and often the libraries are not widely used or well documented. Since we're building a site largely by standing on the shoulders of others, this made things a little tougher. There just aren't as many shoulders on which to stand.
...
We were already familiar with Python. It's fast, development in Python is fast, and the code is clear.
...
The entire task took less than a week, with 80% of the code written in a single weekend.
I know of several other large corporate projects over the years that made similar switches for similar reasons. Perl, Python, Java, etc. were faster to write in, performed better, and had better long-term maintainability (okay, maybe not Perl). Nobody regrets those switches except for a couple Lispers who continue to complain about how none of this is true, even after Lisp didn't provide the results, and something else did.
Continuing to claim that Lisp is better than all the proven better alternatives starts to make it smell like religion. Trying to explain away why a Lisp didn't work for whatever reason, but it's still the best start to taste like religion.
At some point its important to just make a call and realize that Lisps are interesting, you can compute with them, and they've had important influence, but they aren't the best way to do things - for many reasons. There's always another language choice that's faster, or easier, or offers a better ecosystem.
GNU CL has been out for a long while now, and it hasn't taken the world by storm. "Better", while qualitative in many respects, is also obvious, and it's obvious across a sample of millions of software projects that there are simply better holistic software development tools.
edit it makes me really happy when this gets downvoted without comment. Nobody ever downvotes an anti-Lisp rant with a pointer to a large and ongoing Lisp-based project. They just virtually claim I'm wrong without any substantial backup.
At reddit were not really Lisp experts - more like they heard the hype and believed it for a while, without having written anything substantial before. They wrote not more than a sketch of the site in Lisp and at the first sight of problems they switched to a language/implementation they were more familiar with. Neither Lisp in general nor SBCL specifically were/are that much used to form the bases of high profile websites.
> I know of several other large corporate projects over the years that made similar switches for similar reasons.
I've seen lots of large corporations rewriting all kinds of software. For example I've seen a lot C++ software being rewritten in Java.
Large corporations are not interested to use 'powerful' languages like Lisp. They are more interested in cost cutting, outsourcing, offshoring, 'industrialized' software production, cheap supply of labor, ...
> Continuing to claim that Lisp is better than all the proven better alternatives starts to make it smell like religion.
It's religion. Stallman's statement is decades old. Lisp is powerful, flexible, etc. ... but there are a lot of great alternatives. Plus, as I said above, in many companies 'powerful' and 'flexible' is not the most important criteria when selecting languages and tools. Java got successful because of other qualities: being developed by SUN (then Google and IBM) for enterprise software development.
'GNU CL' was never a GNU project as such. GNU CL based on KCL/AKCL and has been used in a few applications. It never has been a focus of the GNU project - it's merely published under their umbrella.
Stallman also never was a fan of Common Lisp - when he developed Emacs Lisp, he developed a very much simpler version, also based on Maclisp - which Common Lisp replaced.
So here's the list you provided, somebody had to rebut me, we may as well enjoy the debate.
- to use a lisp on large-scale production software, the developers need to be experts, while the same isn't true of other languages
- if you just commit long enough, a lisp will come through in the end
- unless it's the wrong lisp (without specifying what is a right lisp)
- large corporations don't want to use languages that are powerful or flexible, they prefer weak and rigid languages
- lisps don't provide cheap, large-scale, easy to synchronize development at an industrial scale
- other languages became successful because they targeted their audience
So let's invert that and derive the ideal audience for a lisp that you just described:
- not on a large scale project or team (something you can write 80% over a weekend in Python is too large)
- already at an expert level
- will commit to a path even when it's not working
I'm not saying this to bash your statement, but I think you've provided a microcosm of why not to use Lisp. From a language selection standpoint, there are pitifully few consequential projects that scope to the ideal for a lisp. There's no obvious as to why its better, and there is to all of the alternatives. Based on this, it's possible to make easy arguments as to why to choose Asm, Perl or 80's Basic over a lisp that make those languages look like great ideas for almost any project where a lisp might be proposed.
And nobody still has backed up a downvote with a pointer to a good lisp project. Not even one. I can probably find a list of ongoing MS-Basic projects without too much fuss, but it's like doing dentistry on an angry tiger to get something similar from the lisp community.
Nope, it's actually what you said, point for point in the same order.
1. "At reddit were not really Lisp experts" - this implies that they would have been successful if they were Lisp experts. Not needing to be an expert in a language to be productive is a powerful reason to use something that's not a Lisp.
2. "They wrote not more than a sketch of the site in Lisp and at the first sight of problems they switched to a language/implementation they were more familiar with" - implies that they didn't commit long enough to the language and that it would have worked out in the end. Reddit says their code wasn't even all that complicated, and they were already hitting huge intractable problems. Problems large enough that moving to an entirely different language was a better solution than continuing to fight with tools that didn't work.
3. "'GNU CL' was never a GNU project as such. GNU CL based on KCL/AKCL and has been used in a few applications. It never has been a focus of the GNU project - it's merely published under their umbrella." - This implies that GNU CL is not a good Lisp. What is a good Lisp? No idea, apparently there isn't one because RMS had to roll his own. Having to write your own dialect of a language to be productive does not sound like a good language.
4. "Large corporations are not interested to use 'powerful' languages like Lisp. They are more interested in cost cutting, outsourcing, offshoring, 'industrialized' software production, cheap supply of labor, ..." - you use a lot of words describing what large corporations want. The implication is that Lisp doesn't offer or support these things or corporations would be using one.
5. "Plus, as I said above, in many companies 'powerful' and 'flexible' is not the most important criteria when selecting languages and tools. Java got successful because of other qualities: being developed by SUN (then Google and IBM) for enterprise software development." See #4 above.
And yes, anybody can go to the "Applications" section for Common Lisp on Wikipedia. What's more interesting is that Lispers, part of the Lisp community, can't just name some interesting projects off the cuff. Most developers can rattle off a list of interesting projects in languages they have only tangential relationship with.
If you look around in the Lisp community, you see lots of "stuck at square one" with hundreds of implementations of some kind of Lisp, or Lisp compilers, or Lisp written in Foo language or Lisp-likes, but not a real big ecosystem beyond that.
Why don't lispers just say "Hunchentoot", "Maxima" or something (Heck HN is written in a Lisp last I checked). These are legitimate, interesting projects!
Lisp is exactly where it has been for decades, despite being taught formerly in major schools, have the same access to the internet and community as elsewhere and having supposed benefits that make it "better". But something like 90% of the time, when developers have to choose a language to work in, they don't choose a Lisp.
It's not powerful if it doesn't solve people's problems.
This bizarre cognitive dissonance among lispers is a real problem for the community and a big part of why the language is stuck in such a quagmire.
You use all kinds of generalizing faulty logic. This won't get you very far.
> Nope, it's actually what you said, point for point in the same order.
I told you what I said.
>1. "At reddit were not really Lisp experts" - this implies that they would have been successful if they were Lisp experts. Not needing to be an expert in a language to be productive is a powerful reason to use something that's not a Lisp.
'this implies' nothing. Speak about yourself. YOU infer something from what I said.
I said 'a'. You infer that this also means 'b' and tell me that I said 'b'. What kind of strange discussion tactics is that?
> this implies that they would have been successful if they were Lisp experts.
That's YOUR opinion, not mine. You are not listening to what I say.
> 2. "They wrote not more than a sketch of the site in Lisp and at the first sight of problems they switched to a language/implementation they were more familiar with" - implies that they didn't commit long enough to the language and that it would have worked out in the end. Reddit says their code wasn't even all that complicated, and they were already hitting huge intractable problems. Problems large enough that moving to an entirely different language was a better solution than continuing to fight with tools that didn't work.
A beginner in a language sees a 'huge intractable' problem. Okay...
> 3. "'GNU CL' was never a GNU project as such. GNU CL based on KCL/AKCL and has been used in a few applications. It never has been a focus of the GNU project - it's merely published under their umbrella." - This implies that GNU CL is not a good Lisp.
Why do you say it is not a good Lisp?
> What is a good Lisp? No idea,
Now you are discussing arguments you made up with yourself. Sorry, you are wasting my time.
> apparently there isn't one because RMS had to roll his own. Having to write your own dialect of a language to be productive does not sound like a good language.
> 4. "Large corporations are not interested to use 'powerful' languages like Lisp. They are more interested in cost cutting, outsourcing, offshoring, 'industrialized' software production, cheap supply of labor, ..." - you use a lot of words describing what large corporations want. The implication is that Lisp doesn't offer or support these things or corporations would be using one.
> 5. "Plus, as I said above, in many companies 'powerful' and 'flexible' is not the most important criteria when selecting languages and tools. Java got successful because of other qualities: being developed by SUN (then Google and IBM) for enterprise software development." See #4 above.
> And yes, anybody can go to the "Applications" section for Common Lisp on Wikipedia. What's more interesting is that Lispers, part of the Lisp community, can't just name some interesting projects off the cuff. Most developers can rattle off a list of interesting projects in languages they have only tangential relationship with.
I've written down these examples without looking at Wikipedia. Maybe you need to do that. Not me.
> If you look around in the Lisp community,
Where? The 'Lisp community' is extremely diverse.
> you see lots of "stuck at square one" with hundreds of implementations of some kind of Lisp, or Lisp compilers, or Lisp written in Foo language or Lisp-likes, but not a real big ecosystem beyond that.
That's why there are languages like Common Lisp, which have mature implementations and allow code sharing between implementations.
> Why don't lispers just say "Hunchentoot", "Maxima" or something (Heck HN is written in a Lisp last I checked).
I gave you other examples. American Express 'Authorizer's Assistant', or PTC's 'CREO are Lisp applications, too. DWAVE's quantum computer also.
Great, if you can name more. We can play this game a long time.
> These are legitimate, interesting projects!
The applications I told you about are legitimate, interesting projects.
> Lisp is exactly where it has been for decades, despite being taught formerly in major schools, have the same access to the internet and community as elsewhere and having supposed benefits that make it "better". But something like 90% of the time, when developers have to choose a language to work in, they don't choose a Lisp. It's not powerful if it doesn't solve people's problems.
You are thinking in some bizarre way that developers need to choose Lisp. There are literally thousands of programming languages out there.
Why are not more people driving a Mercedes S-class or the recent BW beetle. Aren't they supposed to be good cars? 99% of the time drivers are choosing another car. This is all pointless.
> This bizarre cognitive dissonance among lispers is a real problem for the community and a big part of why the language is stuck in such a quagmire.
Maybe the bizarre cognitive dissonance is in YOUR head?
Thank you for continuing to demonstrate the precise issues I'm trying to illustrate. I even quoted you and you refuted your own quotes ... absolutely stunning example.
Until lispers like yourself can get over these mental blocks, Lisp will continue to not be chosen as a computing tool. Right now it's requires too many qualifications, more downsides than up, and the community has deluded itself into being comfortable with those issues, and excusing them, rather than fixing them.
It's a cool language family, but it has lots of problems, and the state of denial the community is in about those problems won't solve them. Unfortunately, it's also a community of ideological purists who can't see the problems with their religion to fix them.
Lispers are right, once you commit to a Lisp, and it 'clicks' something in your thinking process changes, and I'm pretty sure it's not a good change.
edit and goodness, Amex doesn't use the lisp Auth Assistant anymore. What is this? 1991? You can stop bringing it up, they moved away from Lisp just like everybody else. And it never provided more than summarized database information as part of the larger authorization enterprise.
It's far more important for there to be new, or well maintained projects than to continue to rely on old, irrelevant glories that have long been surpassed by something else. Go out and write some and put them up on github! Do something interesting!
