48 ms·

There seems to be plenty of people who think Lisp is awesome. If so, then why hasn't it become "mainstream"?

by hoodoof 9y ago

35bge57dtjku 9y ago
"Don't worry about people stealing an idea. If it's original, you will have to ram it down their throats."
throwaay31283 9y ago
If the fish said that we'd never have mammals.
hcarvalhoalves 9y ago
"Lisp is a minimal fixed point amongst programming languages. It's not an invention, but a discovery. That's why it won't just go away." - Brian Beckman [1] That said, LISP machines are quite interesting on their own, because they follow a different architecture compared to (mainly) register-based x86 and similar. [1] https://twitter.com/lorentzframe/status/821001730938654724 https://twitter.com/lorentzframe/status/821001730938654724
jandrese 9y ago
A big part, especially back in 1984 was that LISP tended to be slow on traditional PC hardware. Also somewhat memory hungry, which was a definite problem back in the 80s when memory was expensive.
- lispm 9y ago
  That's correct. The microprocessor CPUs were not that good at running Lisp. A boost came with the 68020+MMU and the 68030 with integrated MMU. Those had large enough address spaces, were fast enough and had good performing GCs. Memory was very expensive. The 1984 Mac started with 128kb RAM... A 1988 Mac IIx with 8MB was usable.
  - jandrese 9y ago
    My memory is that in 1988 8MB was a luxurious amount of RAM, that machine would cost 2 to 4 thousand dollars. Most people were still using machines with memory measured in kilobytes. Even serious business users were usually limited to 640KB.
    - lispm 9y ago
      It was luxurious, no doubt. The 68030 Mac IIx started slightly below $8000 with 4 MB RAM and no disk. I can't remember the prices, but I would expect that another 4MB would have cost up to $2k.
yung_endian 9y ago
You are commenting on a site run by Lisp
- hoodoof 9y ago
  Are you saying that makes Lisp mainstream?
  - fao_ 9y ago
    It's more mainstream than the $NEW-AWESOME-JAVASCRIPT-FRAMEWORK. Not being mainstream doesn't mean that something isn't awesome. There are lots of awesome discoveries trapped in research/academia because the overton window of the current technology community is shifted too far to "What I am used to", or because nobody cares to look. Eventually some of these ideas will get dislodged and fall down to us, but you can't rely on that. If you read about Lisp's history it's very obvious why it is rejected by people at the moment.
    - hoodoof 9y ago
      >>> It's more mainstream than the $NEW-AWESOME-JAVASCRIPT-FRAMEWORK. This sentence doesn't make any sense. "Mainstream" means used alot - widespread acceptance. Lisp is #33 on Tiobe after Cobol, Foxpro, Fortran and Ada. How you can compare that to the takeup of the latest JS nframeworks I don't really understand. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ 21 SAS 1.372% 22 Dart 1.306% 23 D 1.103% 24 Transact-SQL 1.075% 25 ABAP 1.065% 26 COBOL 1.055% 27 (Visual) FoxPro 0.932% 28 Scala 0.923% 29 Fortran 0.879% 30 Ada 0.787% 31 Crystal 0.756% 32 Erlang 0.733% 33 Lisp 0.690% 34 Awk 0.662% 35 Lua 0.648%
      - criddell 9y ago
        I was just looking at that same list. I'm surprised Lua is that low considering how many applications embed it.
        deleted 9y ago
setzer22 9y ago
I don't see why language quality should have anything to do at all with mainstream usage. PHP can be considered a mainstream language today. Even COBOL in some parts of the industry. Are they any better because of that?
- AnimalMuppet 9y ago
  Well... for a language to succeed long-term, it needs to be either significantly better than the alternatives (at some particular kind of use), or else it needs to be entrenched in existing code. When C began to spread, it was significantly better than alternatives for writing operating systems and associated tools on commodity hardware. Part of that "better" was cost - cost of the machines it ran on, cost of buying a compiler, and cost of implementing a compiler. (The mistake the anti-C people make in saying "but other languages were so much better!" is that they forget that cost was part of "better".) C became entrenched in Unix and, later, Windows. But it didn't start entrenched. It started by being better. If Lisp were significantly better, with everything considered, it should have won by now. I mean, yes, there are a lot of people chasing the current hotness. But the programming profession is not made up entirely of fools and sheep. Better languages get noticed, get used, acquire momentum. (Note well, however, that "better" again is "better with all things considered" - it doesn't equate to "better" as defined by theorists who about how much better their language is, even though it's a little-used language.)
  - deleted 9y ago
    [deleted]
- criddell 9y ago
  According to TIOBE, in 1987 only C was more popular than Lisp. Thirty years later, C is #2 and Lisp is #31. Lisp was mainstream and for some reason other languages overtook it. I think it's a good question.
  - deleted 9y ago
    [deleted]
_sdegutis 9y ago
Most of Lisps novel features have been incorporated into the mainstream high-level languages of today: Python, Ruby, JavaScript, C#, Objective-C. The one that's still relatively unique to lisp is homoiconicity-based macros, but some non-s-expression languages like Nim and Elixir are able to accomplish them. And then there's languages like Clojure and Hy which are gaining mainstream status slowly through over-zealous adoption by disgruntled Rubyists and Pythonistas.
pjmlp 9y ago
Lisp workstations were quite expensive with proprietary source code, while UNIX workstation were built on source code available almost for free (AT&T could not sell it so they licensed it for a symbolic price), which made them cheaper to sell. Also the companies involved in selling Lisp machines did quite a few management errors.
- Animats 9y ago
  Ask anyone who owned a Symbolics 3600, a single-user machine the size of a refrigerator. Overpriced hardware. Poor maintenance service and low hardware reliability. A level of company arrogance seldom seen in a small company. (They thought they were going to rule AI. Didn't happen.) And, originally, 45-minute garbage collections. (Virtual memory plus slow disk plus naive garbage collection.) What really killed them was decent LISP compilers for mainstream CPUs. LISP doesn't really need special hardware with tag bits.
  - taeric 9y ago
    I'm beginning to find that small companies have more arrogance than larger. Just, confirmation bias seems to get people to remember the ones with the skills to back it up. Most companies fail without you ever hearing of them.
  - pjmlp 9y ago
    Yes, that is what I meant with management errors.
  - lispm 9y ago
    When the machine appeared there was nothing like it. Later machines were more robust and also smaller using microprocessors, downto Lisp Machines on Nubus cards for Macs. > a small company At max they had 1000 employees. > And, originally, 45-minute garbage collections Then they invented and commercialized better GCs.
davexunit 9y ago
It all comes back to the "worse is better" thing. Frequently enough the technologies in mainstream usage are not the best, technically speaking. Mainstream programming languages are still playing catch up on the features that the Lisp family of languages has had for decades. UNIX succeeded not because it was the best OS of the time (it wasn't, MIT made much better systems) but it had a killer feature: it ran on commodity hardware, the PDP-11.
- e40 9y ago
  but it had a killer feature: it ran on commodity hardware, the PDP-11 That is not the essence of worse is better. UNIX won over the others because it was simple and regular, and was built from components that could be reassembled into more complex things. Pipes were a big part of that.
  - davexunit 9y ago
    UNIX had a weak design. It won not because it was good, but because it ran on more computers. There are many other OSes of that time period that had superior designs. The Lisp Machine had way better composition primitives than UNIX's pipes passing plain text around.
    - xfer 9y ago
      The part of the problem they were hard to implement efficiently back then.
Jtsummers 9y ago
What does mainstream have to do with quality? There's a lot of crap that's mainstream in most industries. I don't see why ours would be any different (especially as fad-driven as programming tends to be).
agumonkey 9y ago
Lisp genes are all over the place. Wait for 20 years and you'll even more of them.
deleted 9y ago
[deleted]
patrickmay 9y ago
Because Brendan Eich's management lied to him about allowing him to do Scheme in the browser: https://brendaneich.com/2008/04/popularity/ https://brendaneich.com/2008/04/popularity/ When I think of what web programming could have been like, it makes me want to weep.
- willismichael 9y ago
  I also dream of what it would be like if lisp in the browser had become mainstream, but it's possible that if he had implemented it like he wanted to, it wouldn't have received such wide spread adoption like javascript did.
  - patrickmay 9y ago
    True. My optimistic/pessimistic daydream is that, as the only game in town for some period of time, it would have introduced enough developers to the language to really give it traction. We'd now be seeing people asking "Why can't I run the same language on the server as in the browser?" It would be the second renaissance!
    - peatmoss 9y ago
      If I had more free time on my hands, or were king of the world and could make it so, a fun exercise would be to retrofit Firefox / Chromium to support Scheme as replacements for HTML/CSS/Javascript and get a merry band of geeks to build a shadow web.
  - zeveb 9y ago
    > it's possible that if he had implemented it like he wanted to, it wouldn't have received such wide spread adoption like javascript did. I don't care for Scheme, but I'd be very, very surprised if it'd have failed in such a situation. If a terrible train wreck of a language like JavaScript can succeed, pretty much anything better than INTERCAL can. People wanted to extend browsers; had Scheme been the only way to do that, Scheme is what they'd have used.
fusiongyro 9y ago
A more powerful language is not enough of an advantage to defeat entrenched alternatives with strong network effects. There isn't a reason why language X is not entrenched, but there are historical reasons why C, C++ and Java are entrenched. Lisp just isn't enough more powerful than them to beat their home-court advantage. I guess I'd say, Lisp might be 10x better, but the network effects are orders of magnitude more meaningful than that intrinsic benefit. It's not a very meaningful answer to the question, but it's a bit like asking why Todd isn't rich when we all know Todd is a smart guy. It's because getting rich takes more than raw intelligence. Suppose you have a wildly evolving field where nobody can really predict what technologies are going to be successful in the market beyond the next five years or so. Suppose you have no internet. Suppose there are thousands of programmers with the ability to invent a language. Wouldn't you expect that some of them will, by happenstance, wind up on successful products and become successful while others stay relatively unknown? That's the birth of the mainstream programming languages and their antecedents in the 70s and early 80s.
- deleted 9y ago
  [deleted]
- AnimalMuppet 9y ago
  > Lisp just isn't enough more powerful than them to beat their home-court advantage. Note, however, that Lisp had a 10 year head start on C. Lisp had the home-court advantage, and C ate its lunch anyway.
  - lispm 9y ago
    Lisp had a different purpose. It wasn't developed as a systems programming language and wasn't used much as such. Though it had been used for some very specialized machines from the mid 70s to early 90s, see the Lisp Machine Manual. But if you read the manual. you'll see that it was initially developed for a very narrow group of people: high-end personal workstation users in research&development. This required very deep pockets. When this manual was published (1984) the cost was in the range from $70k upwards. Most of the machines at that time were bought with government money (aka DARPA). C spread, because it was a low-level systems programming language and various operating systems were written in C. The Lisp Machine softwre OTOH was written in a high-level language with special requirements for the hardware: tagged memory, stack-based instruction set CPU, large memory space, garbage collection support in hardware, ... Thus the software was not stripped down to a minimum and not very portable - which Unix and C was.
dleslie 9y ago
Clojure isn't mainstream?
dwheeler 9y ago
Asbestos suit on. There are many positive things you can say about Lisp. However, many day-to-day developers, and their managers, believe that Lisp's syntax creates nigh-unreadable programs. For example, there's no built-in infix syntax, as opposed to practically all other programming languages, and many modern programmers today expect infix as minimum table stakes for a language. Lisp syntax is extremely simple, but that doesn't mean the resulting code is easily read. Very smart people will disagree with that opinion - especially a number of people on Hacker News!! However, just look up phrases like "lots of irritating silly parentheses" and you'll see that this opinion is extremely widespread. Many people here will disagree with the sentiment, and that's fine, but it's a fact many people believe programs in Lisp syntax are hard to read. A lot of people will reply that Lisp's syntax is simple, that real programs have been written in Lisp, that it has a kind of simplicity/elegance, and that Lisp syntax enables powerful facilities like Lisp macro processing. All of that is absolutely true. Lisp is quite powerful. But trying to convince people that Lisp is "advanced", even though it doesn't support basic capabilities like infix out of the box, is a losing battle. Forth is one of the few other languages that has an odd syntax and lacks support for infix, and it is also rarely used today. Feel free to reply, but thoughtful responses preferred :-).
- howlgram 9y ago
  I will agree that lisp syntax is hard to read and write, not because it's hard to come up and figure out in what order the parenthesis should be set (or because it uses prefix notation, that's the easiest to get used to), but because it's nigh imposssible to keep track of the parenthesis mentally and visually. Writing lisp involves too much parenthesis-checking to be anywhere near fun. It's not hard to understand, but when it comes to writing complex functions it just spills out of proportion, or maybe I'm just bad at diluting functions into small enough parts. Either way, some large function in C is much simpler to get a grasp of the general control flow. Love the idea, hate actually using it.
  - throwanem 9y ago
    If you have to cope with parens and indentation by hand, then sure. A proper editor deals with those for you, and provides facilities for semantic traversal and editing besides.
shawn 9y ago
The future is long. Computers will be around for thousands of years. They've only been useful for the last ~60 years. A programming language needs at least two things to succeed: a niche, and corporate backing. Almost every successful language has had both. Lisp's benefit is that it is discoverable. Programmers hundreds of years from now will continue to stumble across the roots of lisp: http://www.paulgraham.com/rootsoflisp.html http://www.paulgraham.com/rootsoflisp.html http://ep.yimg.com/ty/cdn/paulgraham/jmc.lisp http://ep.yimg.com/ty/cdn/paulgraham/jmc.lisp The axioms are too simple not to discover by accident. What are some promising niches for Lisp? I think gamedev is a likely candidate. The whole gamedev industry still uses C++ / C#. But Lisp can be just as fast -- you can even make a statically-typed Lisp, which avoids any possibility that Lisp's performance will bite you. The benefits for gamedev in particular are immense: http://all-things-andy-gavin.com/2011/03/12/making-crash-bandicoot-gool-part-9/ http://all-things-andy-gavin.com/2011/03/12/making-crash-ban... The reason this hasn't happened is because it takes a certain personality type to write languages. In 99% of cases, your language will fail. Meaning, if you spend 3 years on it, that's 3 years you didn't spend learning React or Vue or %salary-du-jour. You have to love it. That love is quite the feeling. When you design your own language from the ground up, and break down all barriers of complexity, it stops mattering whether anyone else ever uses your language. Making it was reward enough. In concrete terms, I think self-hosted Lisps are a promising way forward. It's simple to bootstrap a Lisp in almost any language: JS, Lua, Python, Ruby. Write a reader (you can use JSON to start), then write a compiler that steps through the tree of expressions and spits out the native language constructs. E.g. (%while true (print "she sells C shells by the C store")) becomes C#: while (true) { Console.WriteLine("she sells C shells by the C store"); } or Python: while True: print("she sells C shells by the C store") etc. Then you can save the output code to disk and run it. At this point you've written your compiler in Python, Ruby, or whatever. Now the trick: Create a file "compiler.l" that sits alongside your "compiler.py" file. For each function in compiler.py, translate it into your Lisp language and save it into compiler.l. E.g. if your compiler.py file has: def compile(x): if atom(x): return compile_atom(x) if special(x): return compile_special(x) return compile_call(x) then in your compiler.l file, you should write: (define compile (x) (if (atom x) (return (compile_atom x))) (if (special x) (return (compile_special x))) (return (compile_call x))) And hey presto -- your compiler.py file is now capable of reading in compiler.l and generating the exact same code. Meaning you no longer have to program in Python! (Or whatever language you're targeting.) At that point your language is fully self-hosted, and you can extend it however you like. It's so incredibly easy to set up a self-hosted Lisp that it almost seems like a toy. But it's incredibly powerful. E.g. I'm currently building one on top of Racket so that I can write traditional unhygenic macros, completely sidestepping Racket's syntax transformer system. You could imagine doing something similar for React, letting you write programs to generate React components -- a step toward the ultimate templating system. Once you've done this, you'll notice that the entire language is extremely small. It's a thin wrapper around the host language. But that's the value -- that's why it's useful. E.g. in many Lisps, it's common to use the symbol 't for True and an empty list for False. In those systems, there is no such thing as a "boolean" type. Everything is either an empty list or not-an-empty-list. You could do that, which demonstrates just how powerful this technique is. Just modify the way you compile IF statements: (define compile_if (cond a b) (+ "if (" (compile cond) ") { " (compile a) " } else { " (compile b) " }\n")) to (define compile_if (cond a b) (+ "if (yes(" (compile cond) ")) { " (compile a) " } else { " (compile b) " }\n")) (i.e. wrap COND in a call to a YES function.) Then you can define YES as: (define yes (x) (return (not (or (== x false) (empty_list x))))) Now your compiler spits out "if (yes(x)) { a } else { b }" everywhere, and your YES function is your definition of truthiness. So, you can do that, and it works, but at that point you'll discover that you start wrestling with the underlying language. If you change how IF behaves, then you'll need to change how AND and OR behave, too. Stuff like that. I've found the best strategy is to make your Lisp as close to the target language's semantics as possible. When you do that, you end up with a tiny runtime. Clojure's runtime is gargantuan because it has to define in Java all of Clojure's semantics. But here, you're using the host language's semantics directly. Now it might seem that this "isn't really a Lisp". But it turns out that it's just as powerful as any other Lisp. All you have to do is change your compiler from: (define compile-file (src) (compile (read-file src))) to (define compile-file (src) (compile (expand (read-file src)))) Then define an EXPAND function that performs macroexpansion on the expressions you got from the reader. At that point it's straightforward to introduce: (define-macro when (cond . body) (return `(if ,cond (do ,@body)))) which compiles to: def when_macro (cond, *body): return ["if", cond, ["do"] + body] environment["when"]["macro"] = when_macro Your EXPAND function becomes dead simple: def expand(form): if atom(form): return form mac = environment[form[0]]["macro"] if mac: return apply(mac, form) return map(expand, form) Finish it off by defining DEFINE-MACRO: def define_macro_macro(name, args, *body): f = eval(compile(["fn", args] + body)) environment[name]["macro"] = f environment["define-macro"]["macro"] = define_macro_macro Presto, now you can write (define-macro add1 (x) (return (list "+" x 1))) (print (add1 41)) and it compiles to print(41+1). Scott Bell and Daniel Gackle pioneered the above technique, and I've spent the last couple of years implementing it across different languages, including Python, elisp, ruby, and racket. You can try it out here: https://github.com/sctb/lumen https://github.com/sctb/lumen That's Lumen, a Lisp for JS and Lua. One of the coolest aspects is that it compiles to both JS and Lua simultaneously, and runs in both. If you want one for Python, you can try out my branch: https://github.com/shawwn/lumen/tree/features/python https://github.com/shawwn/lumen/tree/features/python It compiles to JS, Lua, and Python simultaneously. So the same codebase runs on node, lua, luajit, torch, python2.7, python3, and pypy. LuaJIT has a fantastic FFI library -- and since our lisp runs in Lua, that means we automatically get a fantastic FFI: https://github.com/sctb/motor/blob/master/pq.l https://github.com/sctb/motor/blob/master/pq.l Imagine how much work it would be to write your own FFI! I think it's one of the best FFI's of any Lisp implementation. So that's a rough outline of Lisp's unique power. It's so versatile that it feels like just a matter of time until someone decides to embed it in some popular system, like a game engine or an online store builder. Clojure might get some serious competition within the next decade.
progman 9y ago
Excellent languages like Lisp, Haskell, Ada, etc., maybe also Rust and Nim, will likely never be mainstream since they offer a lot of features which require a lot of discipline by the programmer. Companies want mediocre developers for mediocre languages (Java, C++, C#, etc.) because mediocre developers can be replaced easily, and because they get lower salary due to great competition. Mediocre languages are just good enough to implement the things which need to be done. All their features are comprehensible by mediocre developers. That's another reason why only mediocre languages become mainstream.
- kbp 9y ago
  If an excellent language doomed to obscurity is one that offers "a lot of features which require a lot of discipline by the programmer," and for the mediocre-only mainstream languages "all their features are comprehensible by mediocre developers," then I think C++ is pretty clearly a counter-example to that, not a supporting example.
middleorigin 9y ago
There's not much money in getting people to use it—it's rarely required and can be expensive to train for (as opposed to java, say).

There seems to be plenty of people who think Lisp is awesome. If so, then why hasn't it become "mainstream"?

35bge57dtjku 9y ago

"Don't worry about people stealing an idea. If it's original, you will have to ram it down their throats."

throwaay31283 9y ago

If the fish said that we'd never have mammals.

hcarvalhoalves 9y ago

"Lisp is a minimal fixed point amongst programming languages. It's not an invention, but a discovery. That's why it won't just go away." - Brian Beckman [1] That said, LISP machines are quite interesting on their own, because they follow a different architecture compared to (mainly) register-based x86 and similar. [1] https://twitter.com/lorentzframe/status/821001730938654724 https://twitter.com/lorentzframe/status/821001730938654724

jandrese 9y ago

A big part, especially back in 1984 was that LISP tended to be slow on traditional PC hardware. Also somewhat memory hungry, which was a definite problem back in the 80s when memory was expensive.

lispm 9y ago
That's correct. The microprocessor CPUs were not that good at running Lisp. A boost came with the 68020+MMU and the 68030 with integrated MMU. Those had large enough address spaces, were fast enough and had good performing GCs. Memory was very expensive. The 1984 Mac started with 128kb RAM... A 1988 Mac IIx with 8MB was usable.
- jandrese 9y ago
  My memory is that in 1988 8MB was a luxurious amount of RAM, that machine would cost 2 to 4 thousand dollars. Most people were still using machines with memory measured in kilobytes. Even serious business users were usually limited to 640KB.
  - lispm 9y ago
    It was luxurious, no doubt. The 68030 Mac IIx started slightly below $8000 with 4 MB RAM and no disk. I can't remember the prices, but I would expect that another 4MB would have cost up to $2k.

yung_endian 9y ago

You are commenting on a site run by Lisp

hoodoof 9y ago
Are you saying that makes Lisp mainstream?
- fao_ 9y ago
  It's more mainstream than the $NEW-AWESOME-JAVASCRIPT-FRAMEWORK. Not being mainstream doesn't mean that something isn't awesome. There are lots of awesome discoveries trapped in research/academia because the overton window of the current technology community is shifted too far to "What I am used to", or because nobody cares to look. Eventually some of these ideas will get dislodged and fall down to us, but you can't rely on that. If you read about Lisp's history it's very obvious why it is rejected by people at the moment.
  - hoodoof 9y ago
    >>> It's more mainstream than the $NEW-AWESOME-JAVASCRIPT-FRAMEWORK. This sentence doesn't make any sense. "Mainstream" means used alot - widespread acceptance. Lisp is #33 on Tiobe after Cobol, Foxpro, Fortran and Ada. How you can compare that to the takeup of the latest JS nframeworks I don't really understand. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ 21 SAS 1.372% 22 Dart 1.306% 23 D 1.103% 24 Transact-SQL 1.075% 25 ABAP 1.065% 26 COBOL 1.055% 27 (Visual) FoxPro 0.932% 28 Scala 0.923% 29 Fortran 0.879% 30 Ada 0.787% 31 Crystal 0.756% 32 Erlang 0.733% 33 Lisp 0.690% 34 Awk 0.662% 35 Lua 0.648%
    - criddell 9y ago
      I was just looking at that same list. I'm surprised Lua is that low considering how many applications embed it.
      - deleted 9y ago

setzer22 9y ago

I don't see why language quality should have anything to do at all with mainstream usage. PHP can be considered a mainstream language today. Even COBOL in some parts of the industry. Are they any better because of that?

AnimalMuppet 9y ago
Well... for a language to succeed long-term, it needs to be either significantly better than the alternatives (at some particular kind of use), or else it needs to be entrenched in existing code. When C began to spread, it was significantly better than alternatives for writing operating systems and associated tools on commodity hardware. Part of that "better" was cost - cost of the machines it ran on, cost of buying a compiler, and cost of implementing a compiler. (The mistake the anti-C people make in saying "but other languages were so much better!" is that they forget that cost was part of "better".) C became entrenched in Unix and, later, Windows. But it didn't start entrenched. It started by being better. If Lisp were significantly better, with everything considered, it should have won by now. I mean, yes, there are a lot of people chasing the current hotness. But the programming profession is not made up entirely of fools and sheep. Better languages get noticed, get used, acquire momentum. (Note well, however, that "better" again is "better with all things considered" - it doesn't equate to "better" as defined by theorists who about how much better their language is, even though it's a little-used language.)
- deleted 9y ago
  [deleted]
criddell 9y ago
According to TIOBE, in 1987 only C was more popular than Lisp. Thirty years later, C is #2 and Lisp is #31. Lisp was mainstream and for some reason other languages overtook it. I think it's a good question.
- deleted 9y ago
  [deleted]

_sdegutis 9y ago

Most of Lisps novel features have been incorporated into the mainstream high-level languages of today: Python, Ruby, JavaScript, C#, Objective-C. The one that's still relatively unique to lisp is homoiconicity-based macros, but some non-s-expression languages like Nim and Elixir are able to accomplish them. And then there's languages like Clojure and Hy which are gaining mainstream status slowly through over-zealous adoption by disgruntled Rubyists and Pythonistas.

pjmlp 9y ago

Lisp workstations were quite expensive with proprietary source code, while UNIX workstation were built on source code available almost for free (AT&T could not sell it so they licensed it for a symbolic price), which made them cheaper to sell. Also the companies involved in selling Lisp machines did quite a few management errors.

Animats 9y ago
Ask anyone who owned a Symbolics 3600, a single-user machine the size of a refrigerator. Overpriced hardware. Poor maintenance service and low hardware reliability. A level of company arrogance seldom seen in a small company. (They thought they were going to rule AI. Didn't happen.) And, originally, 45-minute garbage collections. (Virtual memory plus slow disk plus naive garbage collection.) What really killed them was decent LISP compilers for mainstream CPUs. LISP doesn't really need special hardware with tag bits.
- taeric 9y ago
  I'm beginning to find that small companies have more arrogance than larger. Just, confirmation bias seems to get people to remember the ones with the skills to back it up. Most companies fail without you ever hearing of them.
- pjmlp 9y ago
  Yes, that is what I meant with management errors.
- lispm 9y ago
  When the machine appeared there was nothing like it. Later machines were more robust and also smaller using microprocessors, downto Lisp Machines on Nubus cards for Macs. > a small company At max they had 1000 employees. > And, originally, 45-minute garbage collections Then they invented and commercialized better GCs.

davexunit 9y ago

It all comes back to the "worse is better" thing. Frequently enough the technologies in mainstream usage are not the best, technically speaking. Mainstream programming languages are still playing catch up on the features that the Lisp family of languages has had for decades. UNIX succeeded not because it was the best OS of the time (it wasn't, MIT made much better systems) but it had a killer feature: it ran on commodity hardware, the PDP-11.

e40 9y ago
but it had a killer feature: it ran on commodity hardware, the PDP-11 That is not the essence of worse is better. UNIX won over the others because it was simple and regular, and was built from components that could be reassembled into more complex things. Pipes were a big part of that.
- davexunit 9y ago
  UNIX had a weak design. It won not because it was good, but because it ran on more computers. There are many other OSes of that time period that had superior designs. The Lisp Machine had way better composition primitives than UNIX's pipes passing plain text around.
  - xfer 9y ago
    The part of the problem they were hard to implement efficiently back then.

Jtsummers 9y ago

What does mainstream have to do with quality? There's a lot of crap that's mainstream in most industries. I don't see why ours would be any different (especially as fad-driven as programming tends to be).

agumonkey 9y ago

Lisp genes are all over the place. Wait for 20 years and you'll even more of them.

deleted 9y ago

[deleted]

patrickmay 9y ago

Because Brendan Eich's management lied to him about allowing him to do Scheme in the browser: https://brendaneich.com/2008/04/popularity/ https://brendaneich.com/2008/04/popularity/ When I think of what web programming could have been like, it makes me want to weep.

willismichael 9y ago
I also dream of what it would be like if lisp in the browser had become mainstream, but it's possible that if he had implemented it like he wanted to, it wouldn't have received such wide spread adoption like javascript did.
- patrickmay 9y ago
  True. My optimistic/pessimistic daydream is that, as the only game in town for some period of time, it would have introduced enough developers to the language to really give it traction. We'd now be seeing people asking "Why can't I run the same language on the server as in the browser?" It would be the second renaissance!
  - peatmoss 9y ago
    If I had more free time on my hands, or were king of the world and could make it so, a fun exercise would be to retrofit Firefox / Chromium to support Scheme as replacements for HTML/CSS/Javascript and get a merry band of geeks to build a shadow web.
- zeveb 9y ago
  > it's possible that if he had implemented it like he wanted to, it wouldn't have received such wide spread adoption like javascript did. I don't care for Scheme, but I'd be very, very surprised if it'd have failed in such a situation. If a terrible train wreck of a language like JavaScript can succeed, pretty much anything better than INTERCAL can. People wanted to extend browsers; had Scheme been the only way to do that, Scheme is what they'd have used.

fusiongyro 9y ago

A more powerful language is not enough of an advantage to defeat entrenched alternatives with strong network effects. There isn't a reason why language X is not entrenched, but there are historical reasons why C, C++ and Java are entrenched. Lisp just isn't enough more powerful than them to beat their home-court advantage. I guess I'd say, Lisp might be 10x better, but the network effects are orders of magnitude more meaningful than that intrinsic benefit. It's not a very meaningful answer to the question, but it's a bit like asking why Todd isn't rich when we all know Todd is a smart guy. It's because getting rich takes more than raw intelligence. Suppose you have a wildly evolving field where nobody can really predict what technologies are going to be successful in the market beyond the next five years or so. Suppose you have no internet. Suppose there are thousands of programmers with the ability to invent a language. Wouldn't you expect that some of them will, by happenstance, wind up on successful products and become successful while others stay relatively unknown? That's the birth of the mainstream programming languages and their antecedents in the 70s and early 80s.

deleted 9y ago
[deleted]
AnimalMuppet 9y ago
> Lisp just isn't enough more powerful than them to beat their home-court advantage. Note, however, that Lisp had a 10 year head start on C. Lisp had the home-court advantage, and C ate its lunch anyway.
- lispm 9y ago
  Lisp had a different purpose. It wasn't developed as a systems programming language and wasn't used much as such. Though it had been used for some very specialized machines from the mid 70s to early 90s, see the Lisp Machine Manual. But if you read the manual. you'll see that it was initially developed for a very narrow group of people: high-end personal workstation users in research&development. This required very deep pockets. When this manual was published (1984) the cost was in the range from $70k upwards. Most of the machines at that time were bought with government money (aka DARPA). C spread, because it was a low-level systems programming language and various operating systems were written in C. The Lisp Machine softwre OTOH was written in a high-level language with special requirements for the hardware: tagged memory, stack-based instruction set CPU, large memory space, garbage collection support in hardware, ... Thus the software was not stripped down to a minimum and not very portable - which Unix and C was.

dleslie 9y ago

Clojure isn't mainstream?

dwheeler 9y ago

Asbestos suit on. There are many positive things you can say about Lisp. However, many day-to-day developers, and their managers, believe that Lisp's syntax creates nigh-unreadable programs. For example, there's no built-in infix syntax, as opposed to practically all other programming languages, and many modern programmers today expect infix as minimum table stakes for a language. Lisp syntax is extremely simple, but that doesn't mean the resulting code is easily read. Very smart people will disagree with that opinion - especially a number of people on Hacker News!! However, just look up phrases like "lots of irritating silly parentheses" and you'll see that this opinion is extremely widespread. Many people here will disagree with the sentiment, and that's fine, but it's a fact many people believe programs in Lisp syntax are hard to read. A lot of people will reply that Lisp's syntax is simple, that real programs have been written in Lisp, that it has a kind of simplicity/elegance, and that Lisp syntax enables powerful facilities like Lisp macro processing. All of that is absolutely true. Lisp is quite powerful. But trying to convince people that Lisp is "advanced", even though it doesn't support basic capabilities like infix out of the box, is a losing battle. Forth is one of the few other languages that has an odd syntax and lacks support for infix, and it is also rarely used today. Feel free to reply, but thoughtful responses preferred :-).

howlgram 9y ago
I will agree that lisp syntax is hard to read and write, not because it's hard to come up and figure out in what order the parenthesis should be set (or because it uses prefix notation, that's the easiest to get used to), but because it's nigh imposssible to keep track of the parenthesis mentally and visually. Writing lisp involves too much parenthesis-checking to be anywhere near fun. It's not hard to understand, but when it comes to writing complex functions it just spills out of proportion, or maybe I'm just bad at diluting functions into small enough parts. Either way, some large function in C is much simpler to get a grasp of the general control flow. Love the idea, hate actually using it.
- throwanem 9y ago
  If you have to cope with parens and indentation by hand, then sure. A proper editor deals with those for you, and provides facilities for semantic traversal and editing besides.

shawn 9y ago

The future is long. Computers will be around for thousands of years. They've only been useful for the last ~60 years. A programming language needs at least two things to succeed: a niche, and corporate backing. Almost every successful language has had both. Lisp's benefit is that it is discoverable. Programmers hundreds of years from now will continue to stumble across the roots of lisp: http://www.paulgraham.com/rootsoflisp.html http://www.paulgraham.com/rootsoflisp.html http://ep.yimg.com/ty/cdn/paulgraham/jmc.lisp http://ep.yimg.com/ty/cdn/paulgraham/jmc.lisp The axioms are too simple not to discover by accident. What are some promising niches for Lisp? I think gamedev is a likely candidate. The whole gamedev industry still uses C++ / C#. But Lisp can be just as fast -- you can even make a statically-typed Lisp, which avoids any possibility that Lisp's performance will bite you. The benefits for gamedev in particular are immense: http://all-things-andy-gavin.com/2011/03/12/making-crash-bandicoot-gool-part-9/ http://all-things-andy-gavin.com/2011/03/12/making-crash-ban... The reason this hasn't happened is because it takes a certain personality type to write languages. In 99% of cases, your language will fail. Meaning, if you spend 3 years on it, that's 3 years you didn't spend learning React or Vue or %salary-du-jour. You have to love it. That love is quite the feeling. When you design your own language from the ground up, and break down all barriers of complexity, it stops mattering whether anyone else ever uses your language. Making it was reward enough. In concrete terms, I think self-hosted Lisps are a promising way forward. It's simple to bootstrap a Lisp in almost any language: JS, Lua, Python, Ruby. Write a reader (you can use JSON to start), then write a compiler that steps through the tree of expressions and spits out the native language constructs. E.g. (%while true (print "she sells C shells by the C store")) becomes C#: while (true) { Console.WriteLine("she sells C shells by the C store"); } or Python: while True: print("she sells C shells by the C store") etc. Then you can save the output code to disk and run it. At this point you've written your compiler in Python, Ruby, or whatever. Now the trick: Create a file "compiler.l" that sits alongside your "compiler.py" file. For each function in compiler.py, translate it into your Lisp language and save it into compiler.l. E.g. if your compiler.py file has: def compile(x): if atom(x): return compile_atom(x) if special(x): return compile_special(x) return compile_call(x) then in your compiler.l file, you should write: (define compile (x) (if (atom x) (return (compile_atom x))) (if (special x) (return (compile_special x))) (return (compile_call x))) And hey presto -- your compiler.py file is now capable of reading in compiler.l and generating the exact same code. Meaning you no longer have to program in Python! (Or whatever language you're targeting.) At that point your language is fully self-hosted, and you can extend it however you like. It's so incredibly easy to set up a self-hosted Lisp that it almost seems like a toy. But it's incredibly powerful. E.g. I'm currently building one on top of Racket so that I can write traditional unhygenic macros, completely sidestepping Racket's syntax transformer system. You could imagine doing something similar for React, letting you write programs to generate React components -- a step toward the ultimate templating system. Once you've done this, you'll notice that the entire language is extremely small. It's a thin wrapper around the host language. But that's the value -- that's why it's useful. E.g. in many Lisps, it's common to use the symbol 't for True and an empty list for False. In those systems, there is no such thing as a "boolean" type. Everything is either an empty list or not-an-empty-list. You could do that, which demonstrates just how powerful this technique is. Just modify the way you compile IF statements: (define compile_if (cond a b) (+ "if (" (compile cond) ") { " (compile a) " } else { " (compile b) " }\n")) to (define compile_if (cond a b) (+ "if (yes(" (compile cond) ")) { " (compile a) " } else { " (compile b) " }\n")) (i.e. wrap COND in a call to a YES function.) Then you can define YES as: (define yes (x) (return (not (or (== x false) (empty_list x))))) Now your compiler spits out "if (yes(x)) { a } else { b }" everywhere, and your YES function is your definition of truthiness. So, you can do that, and it works, but at that point you'll discover that you start wrestling with the underlying language. If you change how IF behaves, then you'll need to change how AND and OR behave, too. Stuff like that. I've found the best strategy is to make your Lisp as close to the target language's semantics as possible. When you do that, you end up with a tiny runtime. Clojure's runtime is gargantuan because it has to define in Java all of Clojure's semantics. But here, you're using the host language's semantics directly. Now it might seem that this "isn't really a Lisp". But it turns out that it's just as powerful as any other Lisp. All you have to do is change your compiler from: (define compile-file (src) (compile (read-file src))) to (define compile-file (src) (compile (expand (read-file src)))) Then define an EXPAND function that performs macroexpansion on the expressions you got from the reader. At that point it's straightforward to introduce: (define-macro when (cond . body) (return `(if ,cond (do ,@body)))) which compiles to: def when_macro (cond, *body): return ["if", cond, ["do"] + body] environment["when"]["macro"] = when_macro Your EXPAND function becomes dead simple: def expand(form): if atom(form): return form mac = environment[form[0]]["macro"] if mac: return apply(mac, form) return map(expand, form) Finish it off by defining DEFINE-MACRO: def define_macro_macro(name, args, *body): f = eval(compile(["fn", args] + body)) environment[name]["macro"] = f environment["define-macro"]["macro"] = define_macro_macro Presto, now you can write (define-macro add1 (x) (return (list "+" x 1))) (print (add1 41)) and it compiles to print(41+1). Scott Bell and Daniel Gackle pioneered the above technique, and I've spent the last couple of years implementing it across different languages, including Python, elisp, ruby, and racket. You can try it out here: https://github.com/sctb/lumen https://github.com/sctb/lumen That's Lumen, a Lisp for JS and Lua. One of the coolest aspects is that it compiles to both JS and Lua simultaneously, and runs in both. If you want one for Python, you can try out my branch: https://github.com/shawwn/lumen/tree/features/python https://github.com/shawwn/lumen/tree/features/python It compiles to JS, Lua, and Python simultaneously. So the same codebase runs on node, lua, luajit, torch, python2.7, python3, and pypy. LuaJIT has a fantastic FFI library -- and since our lisp runs in Lua, that means we automatically get a fantastic FFI: https://github.com/sctb/motor/blob/master/pq.l https://github.com/sctb/motor/blob/master/pq.l Imagine how much work it would be to write your own FFI! I think it's one of the best FFI's of any Lisp implementation. So that's a rough outline of Lisp's unique power. It's so versatile that it feels like just a matter of time until someone decides to embed it in some popular system, like a game engine or an online store builder. Clojure might get some serious competition within the next decade.

progman 9y ago

Excellent languages like Lisp, Haskell, Ada, etc., maybe also Rust and Nim, will likely never be mainstream since they offer a lot of features which require a lot of discipline by the programmer. Companies want mediocre developers for mediocre languages (Java, C++, C#, etc.) because mediocre developers can be replaced easily, and because they get lower salary due to great competition. Mediocre languages are just good enough to implement the things which need to be done. All their features are comprehensible by mediocre developers. That's another reason why only mediocre languages become mainstream.

kbp 9y ago
If an excellent language doomed to obscurity is one that offers "a lot of features which require a lot of discipline by the programmer," and for the mediocre-only mainstream languages "all their features are comprehensible by mediocre developers," then I think C++ is pretty clearly a counter-example to that, not a supporting example.

middleorigin 9y ago

There's not much money in getting people to use it—it's rarely required and can be expensive to train for (as opposed to java, say).