Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A brief interview with Common Lisp co-creator Dr. Scott Fahlman

pldb.com

Post reply on HN
Print view View original

141–150 of 161 posts

Re: A brief interview with Common Lisp co-creator Dr. Scott Fahlman

#141

Post by TeMPOraL »

nerdponx wrote: post #83
Animats wrote: post #63

The early LISP crowd just didn't get the concept of making a product. The idea that eventually you generate an executable and leave the development environment behind was totally alien. I used Berkeley's Franz LISP in my years at the aerospace company. That was a compiler which generated .o files. So they were close to being able to do this. But you didn't link the .o files; you had to load them into the development…

Aren't SBCL and Chez executables basically just dumps of an environment?

The concept of (development) environment as separate from the program is alien to Lisp.

Re: A brief interview with Common Lisp co-creator Dr. Scott Fahlman

#142

Post by dleslie »

tmtvl wrote: post #138
dleslie wrote: post #53

Earlier quoted context omitted.

No, there is not. There's no desktop environment for Linux that supports the runtime extensibility and inspection abilities of a symbolics lisp machine.

Not even StumpWM running Nyxt?

Not really, no; they aren't integrated and it's not a single lisp environment from kernel to surface and all the way in between.

Symbolics was special. Oberon is similar, and comes close.

Re: A brief interview with Common Lisp co-creator Dr. Scott Fahlman

#143

Post by dleslie »

lispm wrote: post #105
skissane wrote: post #43

Earlier quoted context omitted.

> Not sure how this is a counter point? 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…

> 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 system…

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.

Re: A brief interview with Common Lisp co-creator Dr. Scott Fahlman

#144

Post by nerdponx »

pfdietz wrote: post #93
nerdponx wrote: post #83

Earlier quoted context omitted.

Aren't SBCL and Chez executables basically just dumps of an environment?

You need all that with SBCL, because you can call all that from a running Lisp program. 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.

I'm not asking for it as such, but the claim that Lisps now produce "executables" is sometimes still not quite what people have in mind. It's still a whole bundled Lisp runtime, not unlike using PyInstaller to bundle an entire Python runtime in an executable.

Re: A brief interview with Common Lisp co-creator Dr. Scott Fahlman

#145

Post by eternalban »

pjmlp wrote: post #126
eternalban wrote: post #66

Earlier quoted context omitted.

This is all true, and it should be noted that at the time of its release in mid 90s, Java was an incredibly fun toy to play with and adoption was enthusiastic, and at least in my case, it was an immediate decision to say goodbye to C++ ("forever" /g) and adopt Java, which also turned out to be a good bet in terms of jobs. Let's also note that to this day I (or any Java professional) can go and earn a living writing J…

Also thank you Oracle for buying Sun, when no one else cared about it, for improving Java beyond version 6, bringing MaximeVM out of Sun Labs research into GraalVM research labs, integrating JRockit JIT caching and VM monitoring into OpenJDK, and caring about AOT compilation when Sun left it for commercial 3rd party vendors.

This is true. What a surprise that has turned out. A lot of us were boohooing Oracle buying Sun. I ate my hat on that one.

Re: A brief interview with Common Lisp co-creator Dr. Scott Fahlman

#146

Post by dleslie »

lispm wrote: post #107
rjsw wrote: post #17

Earlier quoted context omitted.

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.

SBCL is still broken on Windows.

Re: A brief interview with Common Lisp co-creator Dr. Scott Fahlman

#147

Post by rjsw »

jonjacky wrote: post #139
Animats wrote: post #63

The early LISP crowd just didn't get the concept of making a product. The idea that eventually you generate an executable and leave the development environment behind was totally alien. I used Berkeley's Franz LISP in my years at the aerospace company. That was a compiler which generated .o files. So they were close to being able to do this. But you didn't link the .o files; you had to load them into the development…

I used Berkeley's Franz LISP ...That was a compiler which generated .o files. ... But you didn't link the .o files; you had to load them into the development environment to run them. Compiling was just an optimization. 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 Fra…

> That sounds the same as Python and Java work now.

Not really, the .o files were fully compiled, they just needed to call C functions in the Franz Lisp runtime.

Re: A brief interview with Common Lisp co-creator Dr. Scott Fahlman

#148

Post by dleslie »

pjmlp wrote: post #128
taeric wrote: post #45

Earlier quoted context omitted.

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.

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. Thus the race to improve GCC started.

gcc was relevant on DOS and Windows thanks to djgpp; it was basically the only free option for a time.

Re: A brief interview with Common Lisp co-creator Dr. Scott Fahlman

#149

Post by wrp »

gnufx wrote: post #121
wrp wrote: post #87

Earlier quoted context omitted.

Lisp syntax is an extreme impediment to uptake. Consider what happened to Lisp-Stat. It was a really slick package, but people immediately dropped it when R became available. Lisp defenders like to think that R won out because of better libraries, performance, or some such. The truth is that the stampede began while R was still in a rough state, people were so eager to get away from Lisp.

Is it clear people wanted to get away from Lisp rather than use a more-or-less clone of S? (One of R's originators did propose moving back to a Lisp base [1], though part of the justification was HPC, which is now at least partially covered [2].) However, much as I like Lisp, I do want a mixfix syntax for interactive use like R, but something CGOL-ish is easy enough; I don't remember xlisp-stat having something like…

> Is it clear people wanted to get away from Lisp rather than use a more-or-less clone of S?

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.

Re: A brief interview with Common Lisp co-creator Dr. Scott Fahlman

#150

Post by skissane »

dleslie wrote: post #143
lispm wrote: post #105

Earlier quoted context omitted.

> 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 system…

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 l…

> 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.

Post reply on HN