4 ms·

> Why is lisp always rejected? My best guess is performance. In the 70s, computers were slow. When the decade started, the competing languages of the time wer

> Why is lisp always rejected? My best guess is performance. In the 70s, computers were slow. When the decade started, the competing languages of the time were Fortran, Algol and Cobol. All were imperative languages with manual memory management that would compile directly to hardware and had semantics very close to that of the hardware. On the other hand, at that time, Lisp was this high level thing, garbage collected, dynamic types, semantics more removed from the hardware, etc. Meaning Lisp was much less performant. Then in 1972, came C. A language inspired by Algol and Fortran, using very similar imperative semantics and constructs, but changing the syntax slightly to what is now the common syntax most programming languages use. The whole point of C was to be crazy fast, and for compilers to be easy to write so it could be portable as well. C's biggest move was that Unix was re-written in it. Before that, operating system kernels were implemented in assembly language! Unix was implemented in assembly language! Think about that, performance was critical in the 70s for a kernel. Once Unix was re-written in C, and C proved to be performant enough to run a Kernel, its momentum started growing. Unix won the OS war, and slowly everyone was using computers running Unix, meaning that it had a C API. What happens when the most popular OS has binding in a specific language, more people choose that language to write programs for that OS. Thus C became ever so popular. Lisp was there, but not leveraging Unix as much, and still much too slow. And this was the beginning of the momentum for C, it only accelerated since then. Linux came around, also in C, Windows, also in C, all major OS were in C. So C like syntax, semantics and programming constructs became the norm, and was what got thought in school and uni, etc. Fast forward to today, and Lisp is finally "fast enough" to be used. We finally reached a point where you can have useful programs in slower languages, like Python, Java, JavaScript, C# all demonstrate. But how can you beat 50 years of momentum in C like languages? That's what most everyone knows. That's why imperative, mutable, procedural statement based, with C like semantics and syntax is still the norm, and all other languages that aren't struggle to get a foothold.

maliker 7y ago
Interesting. Choosing languages to get work done in the 2010s has insulated my team from a lot of these historical forces; interpreted and garbage collected has always been more than fast enough. I can see how earlier businesses would choose a different route.
flavio81 7y ago
Already in the early 80s, Lisp was used to program massively parallel supercomputers. Lisp stopped being slow a long, long time ago.
- didibus 7y ago
  > Already in the early 80s The 80s is already 10 years later than my timeline, C had already gained massive momentum by then. > Lisp was used to program massively parallel supercomputers I'm curious to learn more about this, can you be more specific or provide links? But anyhow, a massively parallel computer is a very different beast. Most computers used by people and enterprise were not massively parallel, and Lisps had poor performance on them and their architectures compared to C. > Lisp stopped being slow a long, long time ago. How long ago is that? I'd bet it was too little too late already. In my opinion, it would be somewhere along when Java came around, in the mid 90s. And even then, I'd say it was still too slow for most user application, but started being good enough for server work. At that point though, the momentum of C was already unstoppable, and Java became dominant, not CL.
  - DonaldFisk 7y ago
    > How long ago is that? 1973. From http://www.softwarepreservation.org/projects/LISP/maclisp_family/ http://www.softwarepreservation.org/projects/LISP/maclisp_fa... , "This reports the results of a test in which a compiled MacLisp floating-point program was faster than equivalent Fortran code. The numerical portion of the code was identical and McLisp used a faster subroutine-call protocol." Original article: https://www.deepdyve.com/lp/association-for-computing-machinery/reply-to-an-editorial-2MI7JMQeTd https://www.deepdyve.com/lp/association-for-computing-machin...
    - p_l 7y ago
      > > How long ago is that? > 1973. > From http://www.softwarepreservation.org/projects/LISP/maclisp_fa.. http://www.softwarepreservation.org/projects/LISP/maclisp_fa.... , "This reports the results of a test in which a compiled MacLisp floating-point program was faster than equivalent Fortran code. The numerical portion of the code was identical and McLisp used a faster subroutine-call protocol." > Original article: https://www.deepdyve.com/lp/association-for-computing-machin.. https://www.deepdyve.com/lp/association-for-computing-machin.... To add some more detail, the public description MACLISP floating point code being faster than Fortran, was published about 7 months before public unveiling of UNIX and when C was just taking more solid shape in it.
dreamcompiler 7y ago
How then to explain Python's popularity? Modern Common Lisp is dramatically faster than pure Python. CL is compiled down to the metal; Python is usually interpreted. C functions called from Python (like Numpy) are faster than Common Lisp but pure Python is much slower.
- didibus 7y ago
  I'm not too sure, but Python has always had great integration with C. It also follows the familiar statement based, imperative procedural model pretty closely. And it has been bundled on unix-like systems for the last 25 years. In that sense, its tottally riding the same wave, leveraging the momentum behind those languages. That's the crux of my argument. Not that Lisp is too slow today, it's quite fast considering today's programming language landscape. But that it was when it mattered, in the 70s and 80s. Had Lisp been able to overcome that, we might be in a world where the most popular OS is implemented in Lisp with a Lisp API. Where the commonly thought paradigms in school would be expression based lambda calculus, functional programming, dynamic runtime object systems, meta-programming and the all mighty parenthesis syntax ;)
DonaldFisk 7y ago
C succeeded because of Unix, not the other way around. Unix was given away and ran on small, inexpensive minicomputers (originally the PDP-11). Lisp typically ran on more expensive equipment. High level programming languages have been used to write operating systems, including the kernel: Lisp (on Lisp machines), Algol 60 (MCP on Burroughs mainframes) and PL/1 (MULTICS on General Electric and Honeywell machines). MCP and MULTICS (from which Unix gets its name) preceded Unix. One difference between C and Lisp is that C was designed to run on the PDP-11, and is a close match for its instruction set. Lisp didn't have a native hardware architecture (the closest it had was the PDP-10) until Lisp machines were built, and there were economic reasons - largely economies of scale - why they're no longer built.
- skissane 7y ago
  > High level programming languages have been used to write operating systems, including the kernel: Lisp (on Lisp machines), Algol 60 (MCP on Burroughs mainframes) and PL/1 (MULTICS on General Electric and Honeywell machines). MCP and MULTICS (from which Unix gets its name) preceded Unix. IBM also has a long history of using (non-standard and semi-secret) PL/I dialects for operating system development. Much of MVS was written in a PL/I variant optimised for systems programming PL/S (which later evolved into PL/X) – older versions were mostly assembly, with successive versions more and more written in PL/S – and that remains so with contemporary z/OS, although brand new development has largely switched to other languages, especially C. Similarly, most of the software for the AS/400 was originally written in a pair of PL/I dialects, PL/MP (for code beneath the virtual machine layer) and PL/MI (for code above it.) (Starting with the CISC to RISC transition, PL/MP and PL/MI were progressively replaced by C++.) Apparently, AIX 1.x and 2.x were written in a mixture of C and PL/I, but IBM got rid of all the PL/I code in AIX 3.x onwards which are pure C.
- didibus 7y ago
  > C succeeded because of Unix, not the other way around. Unix was given away and ran on small, inexpensive minicomputers (originally the PDP-11). Lisp typically ran on more expensive equipment. Yes I agree with that, I thought I had made that point clear. C won over the other C-like due to Unix. But Lisp-likes lost because they weren't fast enough to run on commodity hardware. That meant that the hardware that became popular did not run Lisp, and didn't have an OS written in Lisp. Instead it did C, this has created a massive momentum that still dictates to this day what language is popular and which one isn't, in my opinion. At least it is a strong contributor I'd say.
lispm 7y ago
I agree with lot what you say. In the 70s speed wasn't really the big problem, but performance. Sounds similar, but it wasn't. The performance of Lisp on a mini computer seriously degraded with the number of users on the machine and the lack of available RAM (one megabyte?). A single Lisp on the machine could be relatively fast, but Lisp had high memory demands and a simple GC could walk through all allocated (virtual) memory of a Lisp process. Thus the machine got slow when 50 users suddenly worked next to one or two Lisp users. For Lisp users this was especially a problem, since they were often meaning to use interactive Lisp systems, not batch computation. The idea of Lisp computers was not so much about faster CPUs, but a performant machine for a single user with high memory demands. 90s memory sizes started to get bigger, but Lisp was then hit by the AI winter. Many projects at that time were either moving to C++ for applications (because that was the new efficient industrial language) or tried to develop new languages, which are simpler, cheaper and more deployment friendly (Dylan, Java, C#, Scripting languages in a C runtime, reimplementations of special languages in C/C++, ...). Cost of development systems and the cost of deployment - we are talking about cost of both software and hardware here - was a problem for a long time. There were always also people who tried to provide solutions, Scott Fahlman for example directed the CMUCL project and his goal was to have an optimizing CL system for free - providing CMUCL as no-cost public domain software was a major goal for him.

maliker 7y ago

Interesting. Choosing languages to get work done in the 2010s has insulated my team from a lot of these historical forces; interpreted and garbage collected has always been more than fast enough. I can see how earlier businesses would choose a different route.

flavio81 7y ago

Already in the early 80s, Lisp was used to program massively parallel supercomputers. Lisp stopped being slow a long, long time ago.

didibus 7y ago
> Already in the early 80s The 80s is already 10 years later than my timeline, C had already gained massive momentum by then. > Lisp was used to program massively parallel supercomputers I'm curious to learn more about this, can you be more specific or provide links? But anyhow, a massively parallel computer is a very different beast. Most computers used by people and enterprise were not massively parallel, and Lisps had poor performance on them and their architectures compared to C. > Lisp stopped being slow a long, long time ago. How long ago is that? I'd bet it was too little too late already. In my opinion, it would be somewhere along when Java came around, in the mid 90s. And even then, I'd say it was still too slow for most user application, but started being good enough for server work. At that point though, the momentum of C was already unstoppable, and Java became dominant, not CL.
- DonaldFisk 7y ago
  > How long ago is that? 1973. From http://www.softwarepreservation.org/projects/LISP/maclisp_family/ http://www.softwarepreservation.org/projects/LISP/maclisp_fa... , "This reports the results of a test in which a compiled MacLisp floating-point program was faster than equivalent Fortran code. The numerical portion of the code was identical and McLisp used a faster subroutine-call protocol." Original article: https://www.deepdyve.com/lp/association-for-computing-machinery/reply-to-an-editorial-2MI7JMQeTd https://www.deepdyve.com/lp/association-for-computing-machin...
  - p_l 7y ago
    > > How long ago is that? > 1973. > From http://www.softwarepreservation.org/projects/LISP/maclisp_fa.. http://www.softwarepreservation.org/projects/LISP/maclisp_fa.... , "This reports the results of a test in which a compiled MacLisp floating-point program was faster than equivalent Fortran code. The numerical portion of the code was identical and McLisp used a faster subroutine-call protocol." > Original article: https://www.deepdyve.com/lp/association-for-computing-machin.. https://www.deepdyve.com/lp/association-for-computing-machin.... To add some more detail, the public description MACLISP floating point code being faster than Fortran, was published about 7 months before public unveiling of UNIX and when C was just taking more solid shape in it.

dreamcompiler 7y ago

How then to explain Python's popularity? Modern Common Lisp is dramatically faster than pure Python. CL is compiled down to the metal; Python is usually interpreted. C functions called from Python (like Numpy) are faster than Common Lisp but pure Python is much slower.

didibus 7y ago
I'm not too sure, but Python has always had great integration with C. It also follows the familiar statement based, imperative procedural model pretty closely. And it has been bundled on unix-like systems for the last 25 years. In that sense, its tottally riding the same wave, leveraging the momentum behind those languages. That's the crux of my argument. Not that Lisp is too slow today, it's quite fast considering today's programming language landscape. But that it was when it mattered, in the 70s and 80s. Had Lisp been able to overcome that, we might be in a world where the most popular OS is implemented in Lisp with a Lisp API. Where the commonly thought paradigms in school would be expression based lambda calculus, functional programming, dynamic runtime object systems, meta-programming and the all mighty parenthesis syntax ;)

DonaldFisk 7y ago

C succeeded because of Unix, not the other way around. Unix was given away and ran on small, inexpensive minicomputers (originally the PDP-11). Lisp typically ran on more expensive equipment. High level programming languages have been used to write operating systems, including the kernel: Lisp (on Lisp machines), Algol 60 (MCP on Burroughs mainframes) and PL/1 (MULTICS on General Electric and Honeywell machines). MCP and MULTICS (from which Unix gets its name) preceded Unix. One difference between C and Lisp is that C was designed to run on the PDP-11, and is a close match for its instruction set. Lisp didn't have a native hardware architecture (the closest it had was the PDP-10) until Lisp machines were built, and there were economic reasons - largely economies of scale - why they're no longer built.

skissane 7y ago
> High level programming languages have been used to write operating systems, including the kernel: Lisp (on Lisp machines), Algol 60 (MCP on Burroughs mainframes) and PL/1 (MULTICS on General Electric and Honeywell machines). MCP and MULTICS (from which Unix gets its name) preceded Unix. IBM also has a long history of using (non-standard and semi-secret) PL/I dialects for operating system development. Much of MVS was written in a PL/I variant optimised for systems programming PL/S (which later evolved into PL/X) – older versions were mostly assembly, with successive versions more and more written in PL/S – and that remains so with contemporary z/OS, although brand new development has largely switched to other languages, especially C. Similarly, most of the software for the AS/400 was originally written in a pair of PL/I dialects, PL/MP (for code beneath the virtual machine layer) and PL/MI (for code above it.) (Starting with the CISC to RISC transition, PL/MP and PL/MI were progressively replaced by C++.) Apparently, AIX 1.x and 2.x were written in a mixture of C and PL/I, but IBM got rid of all the PL/I code in AIX 3.x onwards which are pure C.
didibus 7y ago
> C succeeded because of Unix, not the other way around. Unix was given away and ran on small, inexpensive minicomputers (originally the PDP-11). Lisp typically ran on more expensive equipment. Yes I agree with that, I thought I had made that point clear. C won over the other C-like due to Unix. But Lisp-likes lost because they weren't fast enough to run on commodity hardware. That meant that the hardware that became popular did not run Lisp, and didn't have an OS written in Lisp. Instead it did C, this has created a massive momentum that still dictates to this day what language is popular and which one isn't, in my opinion. At least it is a strong contributor I'd say.

lispm 7y ago

I agree with lot what you say. In the 70s speed wasn't really the big problem, but performance. Sounds similar, but it wasn't. The performance of Lisp on a mini computer seriously degraded with the number of users on the machine and the lack of available RAM (one megabyte?). A single Lisp on the machine could be relatively fast, but Lisp had high memory demands and a simple GC could walk through all allocated (virtual) memory of a Lisp process. Thus the machine got slow when 50 users suddenly worked next to one or two Lisp users. For Lisp users this was especially a problem, since they were often meaning to use interactive Lisp systems, not batch computation. The idea of Lisp computers was not so much about faster CPUs, but a performant machine for a single user with high memory demands. 90s memory sizes started to get bigger, but Lisp was then hit by the AI winter. Many projects at that time were either moving to C++ for applications (because that was the new efficient industrial language) or tried to develop new languages, which are simpler, cheaper and more deployment friendly (Dylan, Java, C#, Scripting languages in a C runtime, reimplementations of special languages in C/C++, ...). Cost of development systems and the cost of deployment - we are talking about cost of both software and hardware here - was a problem for a long time. There were always also people who tried to provide solutions, Scott Fahlman for example directed the CMUCL project and his goal was to have an optimizing CL system for free - providing CMUCL as no-cost public domain software was a major goal for him.