Java and C++ had capable, even enterprise quality free compilers at a time when Common Lisp environments were typically either hideously expensive or poorly supported or both.
You could grab Sun's JDK for free, or GCC, or (later) Visual Studio Express at a time when the best options for Common Lisp were thousands of dollars per seat, or barely working on x86 (CMUCL didn't have x86 support in any capacity until after 96, and by then Java was out).
Personally, I loved lisp in the 90s, but it was just so much easier to get my hands on C and Java, and libraries to go with them. Java, C and C++ were actually available on DOS and Windows. Even today, Windows support among lisps is terrible!
Edit: I miss Turbo C, but had there been a Turbo Lisp, priced affordably and on the shelf at radio shack? We'd all be programming in lisp.
Similar forces hampered the adoption of Smalltalk in the 90s as well [0]. Charging per-seat licenses to use programming languages almost never works, introducing friction that counters needed network effects, especially when prospective users can download a perfectly viable (if not much worse) alternative for free. Sure, there are a few systems bitterly hanging on to this business model - Lispworks, Cincom, Mathematica - but it's clear they are surviving in spite of it.
As I wrote in another thread, IBM abandoning Smalltalk for Java was the biggest blow, in a way Smalltalk was IBM's .NET to put in more modern terms, used for their IDEs (Visual Age), OS/2 RAD development and 4GL like language across all their enterprise offerings.
Until the day Java came, and they pivoted everything into Java.
On the Lisp side this is an extra step and a source of problems. Traditionally the commercial Lisps REQUIRE one to ship an application without the full dev environment. So there is always a delivery step which generates an application or a shared library. Some other Lisp applications require a delivery Lisp compiler, usually to C because of some other limitations: space, memory management or the platform does not allow a full dev Lisp. Example: there is a process control engine written in Lisp, which is used in industrial control applications. This Lisp application is largish and gets compiled to C and runs without garbage collection.
I think that is just a facet of his point. It was Sun's corporate backing and muscle that enabled you to get their SDK for free. And this is ignoring the reach out into education markets to get Java as the 101 level course for an absurd number of students.
> It was Sun's corporate backing and muscle that enabled you to get their SDK for free.
You could get GCC for free before Java 1.0 was released. My personal introduction to GCC was Walnut Creek's Hobbes OS/2 CD-ROM from 1994, the EMX port. Paid for the CD-ROM, but we could have downloaded it for free if we had Internet access. EMX did DOS too, and DJGPP was also available at the same time (and ended up overtaking EMX under DOS).
That was indeed where many of my teenage hours went - hacking out game experiments in DJGPP and Allegro on our family’s 486. It was also my intro to Emacs which stayed with me for decades afterwards.
GCC being freely available didn't require massive corporate backing.
So lack of massive corporate backing is insufficient as an explanation of Common Lisp's lack of free availability (on then-mainstream platforms) circa 1995.
I think the real explanation is, at that point, the Common Lisp community mostly didn't get why it was important. And by the time they got it, it was too late.
> GCC being freely available didn't require massive corporate backing.
But it had. Most operating systems were written in C. Lot's of supporting libraries were written in C. Stallman chose to implement a C compiler because of that. There is and was a huge eco-system around C just because it is a low-level language used to implement the basics of many systems.
Lisp was only accidentally used for a few operating systems - the AI programmers needed capable workstations, there were none and thus they developed their own and wrote their OS in a language they knew best. Outside of that community C was (or became) the standard for implementing the low-level and application environments on top. Most Lisp implementations contain a runtime written in C (and assembler). Apple tried to write early OS stuff and applications in PASCAL. C and then Objective-C replaced that.
Stallman also chose to build Emacs and Emacs Lisp. He could have made an editor extendable in c only, but did not. Emacs' problem, then and now, was non-existent, then terrible DOS and Windows support.
Really, the problem was that there was no DOS or Windows lisp available for cheap, or free. Even GCC was only available thanks to a small company, Delorie, who made djgpp.
I would have greatly preferred to program in lisp; but on DOS and Windows all I had was C, Pascal, and Basic; thanks to Borland, Delorie and Microsoft. Later I had Java, Python and Perl; again thanks to companies like ActiveState.
The focus on UNIX-only kept these other languages, free or not, from being useful to the broader public.
> Emacs' problem, then and now, was non-existent, then terrible DOS and Windows support.
I don't know when GNU Emacs first became available under DOS. If you look at the GNU Emacs 18.59 source distribution (October 1992), while it doesn't support DOS/Windows, its FAQ mentions a DJGPP-based port to 32-bit machines called Demacs (which wasn't pure GNU Emacs, it was actually based on the Nemacs fork which added improved Japanese language support).
The many limitations of MS-DOS (8.3 file names, no multitasking) meant that it was essentially impossible for GNU Emacs under MS-DOS to work as well as it did on more capable platforms. Windows 3.x/9x/Me laboured under many of the same limitations – 9x/Me didn't have a 32-bit command line environment, all it had was DOS boxes and COMMAND.COM, plus some horrible kludge by which 32-bit console applications would have their I/O routed through a DOS process (CONAGENT.EXE) via a VxD.
While NT-based Windows fixes many of those problems, it doesn't fix all of them – for example, until relatively recently (some Windows 10 build), Windows had no pseudoterminals (except for various flaky unofficial workarounds), which put big limitations on Emacs support for subprocesses compared to other platforms. Now at last it does, but I'm not sure if GNU Emacs has been updated to support them.
IIRC, Stallman's original mission was to write a 'free' operating system (-> GNU Hurd). For that he needed a C compiler, an editor, a Lisp, etc.
Integrating GNU Emacs into proprietary operating systems like Microsoft DOS / Windows or Apple's MacOS wasn't his priority.
There were a bunch of other Lisps on DOS/Windows: Xlisp, MuLisp, CLISP, EcoLisp, RefLisp, LinkLisp, Corman Lisp, Golden Common Lisp, Procyon Common Lisp, Allegro CL, Medley, LispWorks (later), NanoLisp, Software Engineer, Star Sapphire Common Lisp, ...
Maybe they were too late, didn't fit your requirements, etc. But it was not that there was none.
GCC being freely available is by far the exception, historically. Such that I don't really get your point. Do we know why/how GCC was able to pull off being free?
And, as I said in a sibling thread, my assertion is that it took massive corporate spending for Sun to get inroads with Java. In large because they were competing with GCC.
> Do we know why/how GCC was able to pull off being free?
Because RMS is an ideological obsessive for whom software being free was more important than making money. Although he wrote a major Lisp implementation himself (Emacs Lisp), he saw C as the more pragmatic path to making free software widely available than Lisp. Also, as a former employee, MIT gave him a lot of (in-kind) support.
(Actually GCC was not the first free compiler. RMS started out planning to turn LLNL's free compiler for a Pascal derivative, Pastel, into a C compiler. But he abandoned that approach, because the Pastel compiler was a big resource hog by the standards of the time – it was initially developed to run on a supercomputer, it wouldn't work on the Unix workstation RMS was using.)
CMU Common Lisp was free, and CMU's research funding paid for it. But their focus was on Unix workstations, they never saw the value in porting it to x86 (let alone DOS/Windows). By the time the x86 port happened (done by volunteers, not paid for by CMU), Java had already taken off.
Hardly anyone cared about GCC in those days, most compilers were still commercial.
In fact, GCC only started to matter to UNIX folks, because Sun introduced the concept of user and developer UNIX workloads, and all UNIX vendors followed along, making the UNIX development tools into an additional package one had to buy.
It was popular with people who came from a Unix background and wanted to port Unix software to DOS/Windows (or even OS/2). While the API differences were still a challenge, GCC did better at code ported from Unix than Borland/Microsoft/etc did - especially since a lot of that software was already being compiled under GCC on Unix anyway
True that Borland/Microsoft was more popular among professional DOS/Windows developers, especially those for whom that was their native platform
> those that could not buy them, would get copies from a street bazar
Teenage me didn’t know of any “street bazaars” selling Microsoft/Borland developer tool warez. But I walked into the local computer shop and saw some modestly priced CD-ROMs, with GCC (among other things), and convinced my Dad to buy them for me.
I think you are talking past me, though. My claim is that it took massive corporate bucks for Java to get inroads. Specifically because it was competing with some free options.
Common lisp had nothing like that. Nor did Ada. Or... really, any other language? Microsoft did a pretty heavy push with C# and the general .NET ecosystem. Though, even they had to resort to destroying a lot if the VBScript world that had proliferated quite heavily by just being available on tools that folks otherwise had.
Java was free, too; and at the time, djgpp was effectively the only free c++ toolchain on DOS and Windows.
Common Lisp wasn't even available to DOS and Windows users, let alone free or corporately backed. Even now every single free common lisp has substandard or outright broken Windows support.
Common Lisp didn't bother to show up to the party. That's the first problem; it was priced terribly, when it did become usefully available.
(Free) LISPs on Linux today look a bit rough, is there any implementation that turns Linux into something that has the look and feel of a LISP machine?
Parentheses aside, don't expect people to pick up a language if all they can see is a REPL where the only edit operation that works is DEL(ete), at a time when all other languages have graphical IDEs with syntax coloring, context-sensitive help, single-step debugging etc. (and no, I don't mean Emacs).
No, there is not. There's no desktop environment for Linux that supports the runtime extensibility and inspection abilities of a symbolics lisp machine.
Most Lisp systems provide a naked version which runs in the terminal without assuming much. Development environments are loaded on top. Thus one would use SBCL typically either with GNU Emacs and the SLIME environment for it.
Alternatively there is something like: McCLIM and SBCL. McCLIM provides a similar user interface management system to what Symbolics used.
If one uses something like LispWorks or Allegro CL, they have their IDEs integrated and one can typically start them directly into the IDE.
CMUCL was his baby and he was responsible for that. But it addressed UNIX systems. Those usually had not x86 processors at that time and Windows was not very interesting as a platform then.
Windows (and Macs) were never a good place for free Lisps for, since the support of those on proprietary platforms was costly (in terms of knowhow, time and money) and there was no vendor support. Users on those platforms usually expect support for the vendor libraries AND full GUI support. Microsoft and Apple always pushed their own development tools&languages (Visual Basic, C, C++ and Pascal, C/C++, Objective-C, Swift). The Lisp systems used on Windows and Mac were mostly commercial, since they had GUI and platform support. MCL on the Mac and on Windows then Golden Common Lisp, Allegro CL, ...
CMUCL could have been ported to x86 earlier, I was running UNIX on a 386 in 1987 but only had AKCL for it. I was the first beta-tester for CMUCL on FreeBSD in 1996.
ports usually don't happen just so. If there wasn't one, I would interpret it such that there was little demand at that time.
SBCL later was forked from CMUCL to have a simpler implementation and build system. Recently the port to M1 Macs went smooth. The person(s) doing the port did an excellent job.
Porting CMUCL to x86 required someone having access to a machine that it already ran on as well as a 386 running UNIX, plus knowing that the CMUCL sources were available and having internet access to get hold of them. I think these were the limiting factors rather than lack of demand.
I transferred from community college to a CSU in the early '00s. Our high school was using Pascal, the community college I went into was using C++, and the CSU I eventually transferred into recently transitioned to Java, and they were using C++ before then.
When we used C++, the education version of Visual Studio was about the price of a text book - so not very expensive considering you would use it across many classes.
I assume the schools followed industry rather than the other way around. But thinking about it, Java had made its way into at least one CSU, as the primary language, about 3-4 years after its 1.0 release date. That is amazingly fast.
I started college in 1988 and they were offering copies of Turbo C with all the books for $5, but you had to supply the 5 1/4" disks.
I only lasted 1 1/2 years in college (that time around) so I didn't get to experience Unix or lisp or anything like that. Well I did take an IBM 370 assembly language class. Had to do the assignments on dumb terminals in the basement of the dorms and pick up the print outs in the basement of the CS building.
If this were the case, then explain StandardML which is vastly superior to Java and it's relatives in every conceivable way outside of a big corporation to push it.
Even today, a large company like google would rather spend time with an inferior language like Go than work with SML.
Available libraries are another factor. C and C++ can directly call all OS functions. Java very early had an extensive runtime library supporting networking, GUI programming, multithreading, collection classes, localization, date/time, etc.
agree. this has also been the problem fore smalltalk. before things like scratch and pharo came along, commercial smalltalk licences were eye-wateringly expensive.
Java and C++ had capable, even enterprise quality free compilers at a time when Common Lisp environments were typically either hideously expensive or poorly supported or both.
You could grab Sun's JDK for free, or GCC, or (later) Visual Studio Express at a time when the best options for Common Lisp were thousands of dollars per seat, or barely working on x86 (CMUCL didn't have x86 support in any capacity until after 96, and by then Java was out).
Personally, I loved lisp in the 90s, but it was just so much easier to get my hands on C and Java, and libraries to go with them. Java, C and C++ were actually available on DOS and Windows. Even today, Windows support among lisps is terrible!
Edit: I miss Turbo C, but had there been a Turbo Lisp, priced affordably and on the shelf at radio shack? We'd all be programming in lisp.