Why did Lisp fail?

ITT: Discuss one or more reasons why Lisp failed to stay mainstream.

Attached: images.jpg (256x197, 11K)

Other urls found in this thread:

wilfred.me.uk/blog/2014/09/15/comparative-macrology/
web.archive.org/web/20070720142546/http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003789.html
xahlee.info/UnixResource_dir/writ/analogy_vs_reasoning.html
exploit-db.com/papers/37606/
neurovenge.antonomase.fr/
winestockwebdesign.com/Essays/Lisp_Curse.html
github.com/carp-lang/Carp
twitter.com/NSFWRedditGif

(L)otsa (I)n-(S)ignificant (P)arantheses

Hm, for a moment I thought it was people failing to come up with good language standards, but your answer sounds more reasonable.

You like huge and pointless flame wars, huh?
All right, I start:
LISP failed because it didn't encourage collaboration at the psycological level. It also is extremely resistant to the standardization, as it doesn't itself have any syntax, which means that everyone just ended up having their own personal namespace with a bunch of """cool""" macros which made their code basically unreadable for the rest of the world. Its flexibility, which is its biggest strength ended up being the greatest obstacle in the PL popularity context.

Also, the AI winter did its part.

and then there's always that one brainlet in every single LISP thread who comes to talk about parentheses.

>You like huge and pointless flame wars, huh?
yes
>LISP failed because it didn't encourage collaboration at the psycological level. It also is extremely resistant to the standardization, as it doesn't itself have any syntax, which means that everyone just ended up having their own personal namespace with a bunch of """cool""" macros which made their code basically unreadable for the rest of the world. Its flexibility, which is its biggest strength ended up being the greatest obstacle in the PL popularity context.
But apparently even macros itself aren't compatible from one lisp to another? wilfred.me.uk/blog/2014/09/15/comparative-macrology/

>even macros themselves aren't compatible from one lisp to another
they are obviously not. Search for "hygienic macros" on your engine of choice

sounds more like a standards thing to me, then.
Also, care to explain
>because it didn't encourage collaboration at the psycological level

Because people with a lisp can't pronounce "lisp", and I can't decide if that's funny or sad.

I'm saying that because since every LISP is so flexible every programmer can customize it to fit their own style. And while it might be good for their own text editor - it does not have the same effect on their code, as it's meant to be read and written by other people.

So, I basically mean that LISP encourages the my-own-very-personal-namespace-with-1000LOC-worth-of-hacks-I-like behaviour, which is detrimental for large codebases.

I feared as much, thanks.

the mainstream is most people.
most people are retarded.
this explains why lisp isn't popular while python is.

it also has a lot to do with the mindset most people approach programming. Years of C and C-like stuff educated an average wannabe programmer to think in a turing machine-like engineering way about programming, while lisp, being mainly based on the lambda calculus, is not even build on the same principle.

> free actors in a capitalistic system won't use a supposedly more advanced tool which would supposedly give them a huge advantage over the competitors because, well, they're retarded I guess and don't care about profits

>network effects don't exist
>market participants are perfectly rational with an infinite time horizon

>uses parens which is not like most C-like language syntaxes
>not really taught in university
>macros scare people because of their experiences with c "macros"
>it's too easy to program with, so people are generally more adverse to collaboration
>generally large binaries, slow execution (although about average for gc languages)
I think the biggest one is that people just don't bother teaching/learning lisp

Technological problems: overuse of macros, object system was tacked on rather than integrated.
Social problems: it's too old, which means it was too slow for almost anything real on normal pcs in its heyday, as a result young coders in the 90s didn't bother to write anything serious in it. As a result lisp died with its original boomer userbase.

The fuck you babbling on about standardization troubles? Ever heard of Common Lisp ANSI standard?

No, macros are not necessarily compatible from one Lisp to another. Did you know functions aren't compatible across all Algols? If you take a Pascal function verbatim to a C program it doesn't work.

Yet the "tacked on" CLOS makes pretty much all other object systems look garbage. Also, Lisps got very performant in the 80s.

>Ever heard of Common Lisp ANSI standard?
According to many but vendors it's garbage, though. Similar thing with Scheme, I remember some other user bitching about how it was fucked due not having standardized modules early enough.

>Yet the "tacked on" CLOS makes pretty much all other object systems look garbage.
You can't even make your objects mappable because every map* is a function, not a multimethod. What this means in practice is that it's impossible to write algorithms that works for general 'sequences', everything expects a standard list.
It gets pretty absurd when you try to do things like add matrices: in c++ you can overload the + operator and all operation looks nice, in cl you are forced to make something like matrix-add like it doesn't have polymorphism at all.
This is the biggest problem with CLOS, which also makes libraries much worse.
Even C++98 has these two issues solved much, much better, not to mention C++17 that made iterator definitions a breeze.

These are the main reasons I stopped writing anything in CL. Sure in principle I could personally invent my own extensible methods, but that wouldn't be compatible with anyone else's code.

they won't because finding a java drone is way easier than a LISP programmer. And when your company is over 30 employees you gotta start caring about the bigger numbers.

>overuse of macros
because even among the LISP programmers there are nigger monkeys who don't understand where it's better to use a macro, and where - a higher order function.
>object system was tacked on
alan kay himself admitted that CLOS is a way better implementation of OOP as he himself intended than, for instance, Java. Not that it's that hard.
> social problems
Lisp users are weenies, totally agree. It shouldn't stop anyone from learning it, though.

>Ever heard of Common Lisp ANSI standard
Too broad and badly specified

>I think the biggest one is that people just don't bother teaching/learning lisp
At one point it was pretty heavily taught in schools, especially scheme. There is still some schools that teach it, sometimes in graduate courses as well.

Outside of lisp-1 symbol space (lisp-2 is the autism that requires use of #' and funcall in cl) scheme pretty much sucks. It's a language that would be cool in the 80s, python is better in everything. At least CL has areas that are still unbeaten by anything else (CLOS, format syntax).

web.archive.org/web/20070720142546/http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003789.html
Being able to use other people's expertise, code and tools is more important than having a nice language with which to build your own environment from scratch.

Seriously, how often is that even possible? Most code bases are complete mess filled with code that can't be reused.

Lisp-2 is good, of course. Everything forced into a single namespace is just madness and non-scalable (try using a command shell like that).

the only reason it exist is because it was faster on some ancient mainframe programmed by punched cards in the 60s. The idea has literally zero advantages today.
Most languages have a unified symbol space.

Pretty much this. Also don't say it is good to allow you to reuse names for functions and variables, that just makes it more difficult to understand code.

All nonsense, see xahlee.info/UnixResource_dir/writ/analogy_vs_reasoning.html
(about halfway down the page, Erik Naggum on Lisp-1 vs Lisp-2)

>failed to stay mainstream
>It ever was mainstream.
I know of a mid-90s word processor written in it, and a video game. That's it.
I read Paul Graham's book and became competent at LISP, which I encourage everyone to do, but only as a learning exercise.

His explanation is wrong on several levels. There's one symbol space for command line, the first argument just uses $PATH in the absence of an explicit path rather than a local directory.
There's no protection from 'trojan horses', in fact original unix design is vulnerable to local .so injection.
exploit-db.com/papers/37606/
>In particular, in Common Lisp we don't want to change the meaning of a function in some _other_ package just because its symbol is accessible in our package by using it as a variable.
>All of this is very carefully thought out and the practice of Common Lisp is very different from languages where scalability is an after-thought.
that's what namespaces are for. This problem never occurs in C++ or python (implemented much better).

>you would actually design a shell or command processor that made no distinction between files at all and would happily try to execute non-executable files
To see that this is wrong, create a file "a" in /tmp that contains just one line echo "cat". If you enter /tmp/a you will get permission error. If you do chmod +x on it bash will execute it as a script and you will "cat" printed.
Now add /tmp to $PATH as the first directory. "a" will work everywhere. Now do chmod -x /tmp/a. "a" will generate a permission denied error.

>His premature death at the age of 44, On June 17, 2009, was caused by a massive bleeding ulcer, related to ulcerative colitis
lmao he literally died of butthurt

"Most" is not "all". Game studios, for instance, heavily reuse code because they can't really afford not to, and have developed systems both technological and cultural to support this.

The real question is, what did you learn from it?

Heh, that was twenty years ago.
I think it really improved my script-fu, whether interpreter or command line based. But when I messed with genetic programming it was much easier to implement a toy LISP in Perl than try to translate my concept into LISP directly.
Your impression?

It's good that it isn't mainstream. The only drawback is lack of libraries.

>Also, the AI winter did its part.
Why is it called like this, because AI did not took off?

they do care about profits, but dumb people are not good at figuring out what makes money
how fucking retarded are you that you would jump to the defense of other retards

>"fail"
>still remains the pinnacle achievement of humanity that all the vultures keep picking apart and shoving into their shitlangs and passing off as innovation

neurovenge.antonomase.fr/
Neurolet cant compete

Attached: lispBTFO.png (1379x823, 218K)

As soon as an AI problem is solved it stops being an AI problem.
Therefore, it's impossible to make progress into the field. It seemed meaningless at the time.

Scheme wasn't taught in those schools because it was a useful language. It was taught because during those times it was entirely possible to understand the whole process of running scheme programs down to your logic gates on the CPU.
Nowadays those schools have switched to Python because it's the ultimate glue language that can be used everywhere, and because understanding the whole process of running a python program is just impossible. Even your CPU is now implemented in software, running on an operating system running on the actual processor that optimizes your binary however it wants without asking you.

If lisp is plagued by historical issues and rarely used, what is a good modern language with homoiconicity and lisp-style macros? Julia? Also, does any object system in common use today come close to CLOS?

"The LISP Curse"
winestockwebdesign.com/Essays/Lisp_Curse.html
However, I'm professionally writing Clojure. I can look around and count the number of people directly working on code. In a different language, the same development effort would easily be 10x or 20x the headcount. I'm ludicrous-speed productive compared to other languages.
LISP is everything I wish other languages had. Honestly you can build the REPL experience in MOST languages; the E in REPL is for Eval, and that might as well be Compile. C could do this. Haskell could do this. could do this. They just don't; mostly from inertia back when mainframes would batch compile your programs overnight.
At the same time, the supreme comfy (think 'ara~ara' waifu levels) of REPL-based development that is central to lisps is IMPOSSIBLE to convey over text. It's like having a conversation with your program as it's running and in development. That sentence doesn't even make sense unless you've experienced it.
Even the (Parens) become a feature because you learn about block editing. Imagine your braces and parens let you navigate and edit code based on the language's scope rules. It lets you send entire snippets to your REPL for evaluation/compilation. Again, none of this makes sense unless you've experienced it.
None of this means that LISPs are perfect. Each has quirks and warts. One beef I have with the Clojure community is the bifurcation of the library ecosystem into Java and Javascript camps, which makes it harder to write good universal tutorials and makes searching needlessly complex.

Attached: lisp-curse.png (697x901, 181K)

Poor Carp
github.com/carp-lang/Carp

AI Winter because so many sub-problems of AI are 'AI Complete', per Marvin Minsky - they require AI to solve, themselves. And there wasn't much progress for a couple / few decades.