A brief interview with Common Lisp co-creator Dr. Scott Fahlman
pldb.com
pldb.com
INTERLISP and Symbolics were even worse - you were always in the development environment and couldn't get anything out except a saved state dump.
Eventually the LISP crowd got it and started generating executables, but it was too late by then.
Perhaps you are asking for that to be available as a library? The size isn't very large so it's not big a deal.
A Lisp executable then can be one file which includes a runtime and the (compiled) Lisp code. One could also have these as two separate files.
The there are two basic ways to provide the Lisp code: it's either just compiled code or a memory image of containing the code. SBCL uses the memory image approach. ECL (Embeddable Common Lisp) uses the 'compiled code' approach. ECL compiles to C and then adds the compiled C code to its runtime.
Symbolics had a delivery Lisp on DOS/Windows called CLOE.
On a Lisp Machine one also was not always in the full development environment. But Lisp was the operating system and thus Lisp plus some dev tools was always there. But when one wanted to use the development environment to its full capability one would need to load more stuff and create worlds with more debug information.
The delivery of Lisp applications wasn't a thing until after the mid 80s. Before that there were not that many Lisp applications and not too much machines to install it on. This changed with UNIX workstations, 386/486 PCs, Macs with 68030/40. Even in the early 90s there were questions how to deliver Lisp software in static form to end users. The question was often answered with "rewrite it in C++". Sometimes: prototype it in Lisp and then rewrite it in C++. Sometimes: migrate to C++. Sometimes: use a Lisp compiler generating C code.
For some discussion of delivery problems in Lisp see the German Apply project from 1992:
https://www.researchgate.net/publication/229022605_APPLY_A_m...
Then there were also delivery systems on the Ivory. There was even a stripped down Lisp operating system called Minima for those, IIRC.
Minima was also used for some debug tooling for building the machines themselves, iirc.
Having Genera/Ivory boards in a Mac was also seen as a delivery vehicle. For example:
http://www.bitsavers.org/pdf/symbolics/software/genera_8/Mac...
"MacIvory Delivery is not suitable for application development or debugging.... MacIvory Delivery is tailored for delivery environments"
That sounds the same as Python and Java work now. For python, you have .py source code files or .pyc or .pyo compiled files, but you still have to load them into the Python interpreter.
I asked the Franz LISP devs why they didn't provide a runtime you could just link in, yielding a releaseable executable program without all the baggage for breaking and debugging.
Even now, you typically need to have Python or Java installed on your computer to run Python or Java programs. There are ways to generate standalone Python executables but it's not the usual way of working.
Not really, the .o files were fully compiled, they just needed to call C functions in the Franz Lisp runtime.
Meanwhile C/C++, Pascal and Java were all accessible and cheap if not free...
Still memory and early PCs were expensive. Like a good Compaq system or an Apple Mac IIfx / Quadra. A dev seat could easily cost $10k or much more with RAM, Disk, large screen.
I wonder if anyone else feels this way. The programming world would be a different place.
I can’t help but fantasize about how incredible eMacs would be by now if that had been the case. (Not that it isn’t already incredible.)
If Dylan had been completed in time for the NewtonOS...
If the Newton had taken off...
I mused on some some alternate histories for Common Lisp in a blog posting:
https://medium.com/@kaveh808/41-world-building-and-alternate...
I had later the wonderful Newton MessagePad 2100 with 8 MB RAM and a much improved ARM processor - I used Common Lisp on a Mac with that amount of RAM.. The 2000/2100 series would have been a perfect platform for Dylan, it even would be good enough to run a nice garbage collector.
When they discontinued the platform, we knew that it would take a lot of time, years!, for Apple to come up with a new similar mobile platform, but it eventually happened with the iPod touch and the iPhone. But those were then programmed in an object-oriented C dialect and the operating system wasn't as cool as the Newton OS.
I ended up just tossing my Newton in the trash. Sad.
I think Python, JavaScript, and Go have caught on for somewhat similar reasons, compared to Java and C#: they are easier to get started with, and you can still scale them up to fairly large applications.
On the other hand, I think S-expressions are a sadly underexplored format for data serialization and storage.
Beginner lispy languages come with a suitable beginner IDE, e.g. Racket or Logo.
A typical lisp statement has a leading '(' and a trailing ')', which replaces the ';' in Algol-like languages. So, one additional character, which brings a lot of benefit when writing DSLs and macros.
(Python doesn't have the ';', but its whitespace is ambiguous, so that's not a fair comparison.)
Sane people don't write lisp using Notepad.
My autocorrect has been doing that for some reason and I assumed there was logic to it. Your comment sent me on a dive that proved my intuition woefully incorrect.
Just another barrier and C-style languages seem much easier to write in comparison.
I guess my point is that syntax that works very well with a correctly configured editor used by someone who knows what they’re doing is going to have a higher barrier to entry than a language that can be easily edited in Notepad.
It’s a lot easier when the editor highlights matching pairs.
Not even English.
I only found out after going through SICP using chez scheme’s repl (which I had to compile myself).
And for most people, the mild convenience of readability is preferable to the consistent semantics.
Yes it does; doing it any other way is strictly worse regardless of where you stand on parentheses as such.
Because the human brain is a pattern-matching organ and sometimes redundancy in a signal is useful. I've never understood the lispers' insistence that saving "screen real estate" is a primary concern. Source code is meant to be read, and the more easily code is read, the more utility is has.
You can think of Lisp's paren syntax as the syntactic analogue of Lisp's very simple static type system. To get macros to work with a conventional grammar's complexity is much more annoyingly complex.
A common refrain from Lisp family language enthusiasts. (Personally I prefer Smalltalk-style "conversational" syntax to Lisp-style or C-style syntax, yet it's similarly unpopular.)
For better or for worse, the vast majority of programmers seem to have voted with their feet for C-style syntax (C/C++/Java/JavaScript/etc.) and its variants (Python). In a C/C++/Java/JavaScript world, C syntax has a fair amount of leverage.
It's a shame that Dylan didn't continue, as it seems to have taken a decent crack at adding algebraic syntax to Common Lisp - arguably realizing McCarthy's original vision of infix M-expressions as a more programmer-friendly syntax. I wonder how hard it would be to add a Dylan-style syntax layer to modern CL?
Be that as it may, one can readily write Lisp/Scheme-style programs in JavaScript. See Crockford's "The Little JavaScripter."[1] The major omission/deficiency being macros for JavaScript syntax.
I, for one, welcome my whitespace-surrounded operator overlords, but if you really don't want that you're welcome to use function-call syntax for them.
I've checked it a few minutes ago and Open Dylan's ./configure says to download a bootstrap compiler from https://opendylan.org/download/index.html first -- but there's no such bootstrap compiler there.
Do you have some hints on how to package it?
I wouldn't call Dylan thriving, unless you're a Windows user that really doesn't care about bootstrapping your language.
It's alive though, in the same sense that Miles, the dog that Segall froze and then brought back to life in 1987, was alive. Brain damaged, but alive.
I know what I was doing, and if you look elsewhere in the thread, I was right about what the GUIX maintainer wanted. Not to get egg on your face.
So for Dylan, we'd like to have a compiler for Open Dylan, not written in Dylan. (it can also require multiple steps to get up to Open Dylan--that would be fine)
It's not in the interest of our users to use binary blob compilers for bootstrapping.
We would also unbundle LLVM, clang and the bdw gc and use the ones from Guix.
I actually learned about Lisp/Scheme after I had learned about several other languages.
What do people not like about parentheses? It’s normally along the lines of “well, I just don’t like them”, which can be read as “it’s not what I’m used to”. Yet, these same programmers will freely throw parentheses around expressions in an ad-how manner to communicate with the compiler in their given language. In some ways, one can back Lisp/Scheme out of popular languages by stating that instead of letting parentheses be used to frequently but not always clarify precedence and grouping and function application, they are going to be required to enforce these. Such a thing is not such a radical or unreasonable stance.
McCarthy’s original M-expressions are somewhat irrelevant. He wasn’t trying to make a programming language for software development. He was investigating it as a tool for his research.
My primary complaint about popular languages like Python, C++, C#, etc. are their irregularities. There a lot of syntax, semantics, and little quirks in the languages that make it very hard to just know the language and move on solving problems. My favorite thing about Schemes are their regularity. The social popularity of languages can’t be explained by their technical merits. It’s more due to social and historical phenomena than a technical reason.
For what it’s worth, I also like Smalltalks.
There is power and elegance in syntactic uniformity, but Lisp in particular is hard to read until you train your eye to see through the nest of parentheses, and it's hard to write without something like Paredit assisting you.
Meanwhile I don't think anyone finds Haskell/ML syntax hard to read. The problem is more that, with idiomatic Haskell in particular, too much abstraction, currying, and un-descriptive variable names can obfuscate what a piece of code actually does.
Lisp doesn't have programmer-unfriendly syntax. It's just tailored to a different use case: built-in ever-present meta-programming. The language was designed to compute with symbolic expressions as data and it was early discovered that Lisp programs itself could be treated as symbolic expressions. Code as Lisp data. People found it easier to do it all in s-expressions, compared to the mixed syntax of the early design: m-expressions for programs and s-expressions for data. This was shown over and over.
In that space it has some local optimum of programmer friendliness. It's just that most programmers don't have that use case. Some get the ideas of list processing as a practical programming interface.
Alternatives were spawned, though: LOGO as a beginner's Lisp, ML as a functional programming language, Dylan as an Scheme+CLOS targeting the same audience as Swift nowadays, ...
I do agree with the sentiment to some degree though that it all looks the same. In an aesthetic sense, there is something I do like about it though.
Being a fan of both ML and Scheme, I have actually been experimenting with a syntax that is a hybrid of the two. I’m still in the experimentation phase, but it’s an interesting exercise.
Yes, but those are effectively library conventions, not fixed properties of the language. Maybe more importantly, names aren’t a structural construct, like a for loop or a class definition. And, arguably, you can have similar syntax in other languages, like e.g. `!` in Rust or the type sigils ($, @) in Perl, except that here you can be sure of their semantics.
On the one hand it is important to have discussions on the benefits and drawbacks of different approaches in language design, and some people will change their minds based on that, but it's also an illusion that one single approach will ever suit everyone.
(if (condition) ;; <- must be when, not if!
(do-this)
(do-that))
There are similar problems in other languages; no notation is perfect, and attempted cures for some of these problems can be worse than the diseases.
GCC's relatively recent "misleading indentation" warning is a good example of a cure that has no downside (that I can quickly think of). It can catch code like:
if (condition)
do_this();
do_that(); // not part of the if statement, but indented deceptively
(if (condition) ;; <- must be when, not if!
(do-this)
(do-that))
(if (condition)
(do-this)
(do-that))> The truth is that the stampede began while R was still in a rough state, people were so eager to get away from Lisp.
That's not a big surprise.
The syntax is/was an important reason. Most users of statistics / maths software prefer a more math-like notation. Even the bigger Lisp applications in the maths area provide that always: Macsyma/Maxima, Reduce, Axiom, Derive, ..
One could have written that on top of Lisp, but it was much more convenient to develop a specialized language/runtime using C. C + Lisp + R would have been more complex than C + R.
1. https://www.stat.auckland.ac.nz/~ihaka/downloads/Compstat-20...
That's a good point. How many statisticians were familiar with S but were using Lisp-Stat just because it was free? I don't seem to have traveled in those circles. I wasn't paying a lot of attention, but I don't remember encountering that on campus.
Another slick Lisp package that got too little attention was Yann LeCun's Lush.
I'd say Lisp syntax is clear as day when compared to your average Helm template.
An example is here:
https://github.com/kubernetes/ingress-nginx/blob/main/charts...
https://github.com/kubernetes/ingress-nginx/blob/main/charts...
And yet, all of this somehow doesn't prevent Helm from being popular...
I didn't see any difference between that and C editing support.
This massively accelerated it's adoption curve and built a valuable trademark which would be part of the reason Oracle paid $7 billion to buy it.
Let's also note that to this day I (or any Java professional) can go and earn a living writing Java and not feel like I'm writing COBOL for a mainframe modulo the Spring framework (which I have avoided, to date.)
SMI did not merely pour money in marketing Java. A lot of loving care by very competent software engineers, some of the best, went into creating Java and its virtual machine. The sweet spot of this language is phenomenally large, imo as an s/e, and accessible to an equally large subset of the programming community (even if they hate it, they can do it), from IT low end to investment banks and up to academic people doing super cool stuff like adding fibers to Java (Kilim). Same story holds for performance. Only on the GUI front did Java drop the ball.
Java is, entirely on its technical merits and utility record to date, one of the most practically effective languages created. Thank you Sun Microsystems.
Ultimately what happened to Java was the same thing that would have happened to any other dominant language that the industry uses to build heavy duty enterprise software: stuff like ORM frameworks, data transfer objects, servlet containers, some kind of web integration like JSP, RPC frameworks, SOAP, REST, etc.
Would it be easier or better to do that stuff in Lisp? Maybe. But not by a huge amount. The beauty of the language would certainly end up being obscured by the boring, complex, practical work that we would all be doing with it. And most programmers would not be better than they are now -- instead they would force an imperative model on top of whatever substrate they are given, just like they do today.
It's not a functional programming language. It's an object-oriented imperative language.
Imperative relates to coding style - I can equally write imperative or recursive code in Java.
add functional, add meta-programming.
The Common Lisp object-system does not use the more imperative message-sending / virtual method calling. It favors "generic functions of related methods" instead - thus this is kind of an integration of function-centric programming into the traditional view of OOP where methods belong to classes.
"Since then, my focus has been on AI research, and part of that involves the design of planning systems that (maybe) can eliminate the need for most programming. You tell them what you want, as you might describe it to a smart grad student, they maybe ask some clarification questions, and then they go do it. That only works if they know enough about the world and have enough "common sense" to avoid blunders."
I wonder what he's working on to enable that kind of environment. Thinking about how most of the programming I do (in high level languages) comes down to starting with a pretty rough idea and iterating on the idea while learning more about what's feasible / effective, typically refining what it is I'm building rather fluidly. I rarely know exactly what to build upfront, nor do the CEOs, product managers, designers or sales people I've worked with so far. I think this feed back loop goes far beyond "asking a few clarifying questions".
Maybe the kind of task a professor would give to a grad student is entirely different from that kind of typical industry work?
EDIT: I was thinking of his QuickProp https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas...
:-(
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.
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).
edit: screen shot to support the argument https://en.wikipedia.org/wiki/Steel_Bank_Common_Lisp#/media/...
Symbolics was special. Oberon is similar, and comes close.
So you want two graphical IDEs before you are happy?
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.
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, ...
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.
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.
0. https://gbracha.blogspot.com/2020/05/bits-of-history-words-o...
But IMHO the "your whole dev environment is your shipped application" is too unappealing to catch on.
Until the day Java came, and they pivoted everything into Java.
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.
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).
You could somewhat freely get some compilers. Sun paid a ton to get Java to people.
It was GCC being free, and on DOS thanks to djgpp, that made it successful; and it didn't need corporate megabucks to do it.
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.
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.
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.
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.
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.
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.
Thus the race to improve GCC started.
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.
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.
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.
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.
That combination was killer for a broke teenager in the 90s.
Even today, a large company like google would rather spend time with an inferior language like Go than work with SML.
That was my introduction to ML universe.
It wasn't SML, but close enough.
cc myprog.c
and get stuff done (fast but unsafely)
The Scheme we had at college (which ran on some Sun machines IIRC) just wasn't available in the wild once I left school.
Unexpected advice coming from one of Common Lisp's creators. He goes on to talk about how languages usually become popular because they have the backing of some large company. Things haven't really changed. Rust and Golang both at least had some sort of backing company to get them started.
Microsoft and Borland both were companies that made money on selling developer tools (it's been overshadowed by OS and office software for MS, but Microsoft had a lot of business selling compilers etc.) so of course they sold compilers for languages that got popular (and in case of MS, later used the compilers to prop the environment for developers building software for their OSes)
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
C was the implementation language of AT&T Unix. The operating system spread across universities in the 1970s due to AT&T’s inexpensive licensing to them, including source code. Unix, though its variants and clones, became the dominant operating system with most competitors either dying out or adopting Unix.
Both C and C++ also had the benefits of being the “blessed” languages of Windows (for example, Win32 is a C API, and MFC is a C++ API). Even in the days of the classic Mac, while Pascal was originally the language of choice, eventually in the 1990s C would be “blessed” by Apple.