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

101–110 of 161 posts

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

#101

Post by lispm »

Mikeb85 wrote: post #24

In the 80's and 90's Common Lisp compilers and editors were insanely expensive. The hardware was too, not even sure if those early implementations ran on x86... That's why they didn't take off. Easy to look back with rose coloured lenses now that we've had free implementations for awhile... Meanwhile C/C++, Pascal and Java were all accessible and cheap if not free...

The commercial versions for Windows and Mac were not all "insanely expensive". Apple's MCL was sold for under $1000. Later the price was reduced even further. That's expensive, but far from a commercial UNIX workstation Lisp, which would be $4000 or more. On the PC there were also mid-priced offerings like Allegro CL, Golden Common Lisp, ...

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.

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

#102

Post by lispm »

musicale wrote: post #37
bmitc wrote: post #29

Earlier quoted context omitted.

I have never really understood people‘s aversion to parentheses. Many languages require them in ad-hoc ways to groups expressions. For S-expressions, you give up some mild convenience and looks for extremely consistent semantics.

> I have never really understood people‘s aversion to parentheses 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…

> more programmer-friendly syntax

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

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

#103

Post by lispm »

headhasthoughts wrote: post #69
twblalock wrote: post #34

Earlier quoted context omitted.

Honestly it would have turned into something like Java if it had become popular in the industry. OOP and functional programming are really just different ways to encapsulate data and control dispatch. They don't change the fundamental nature of the work. 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 sof…

Reading this, it feels like you have never touched Common Lisp. It's not a functional programming language. It's an object-oriented imperative language.

> It's an object-oriented imperative language.

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.

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

#104

Post by lispm »

rileyphone wrote: post #18
dleslie wrote: post #5

Earlier quoted context omitted.

He's overlooking an incredibly important factor: 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 did…

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, Mathemati…

Again the same: now there are good free Smalltalk implementations, and their adoption is not great. There are also other factors than price.

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

#105

Post by lispm »

skissane wrote: post #43
taeric wrote: post #38

Earlier quoted context omitted.

Right. Gcc was free. And had wider reach than lisp. Not sure how this is a counter point? You could somewhat freely get some compilers. Sun paid a ton to get Java to people.

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

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

#106

Post by lispm »

wrp wrote: post #87
nerdponx wrote: post #20

Earlier quoted context omitted.

I think S-expressions are fundamentally too difficult to work with, without good editor support, to make Lisp anything other than a niche power tool for the highly motivated. I love CL, Scheme, Clojure, Janet, Fennel, etc. but I don't blame anyone for finding them inaccessible. 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,…

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.

Ironically R inside is still much of a Lisp.

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

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

#107

Post by lispm »

rjsw wrote: post #17
lispm wrote: post #11

Earlier quoted context omitted.

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…

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.

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

#108

Post by zshrdlu »

bmitc wrote: post #29
nerdponx wrote: post #20

Earlier quoted context omitted.

I think S-expressions are fundamentally too difficult to work with, without good editor support, to make Lisp anything other than a niche power tool for the highly motivated. I love CL, Scheme, Clojure, Janet, Fennel, etc. but I don't blame anyone for finding them inaccessible. 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,…

I have never really understood people‘s aversion to parentheses. Many languages require them in ad-hoc ways to groups expressions. For S-expressions, you give up some mild convenience and looks for extremely consistent semantics.

I've ever understood it either. I love s-expressions! But I suppose there must be something to the complaint. If you ask me I'd say Python's space-as-syntax is far more horrible, but doesn't get nearly the same amount of vitriol.

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

#109

Post by krapp »

Oreb wrote: post #99
krapp wrote: post #31

Earlier quoted context omitted.

It's not so much an aversion to parentheses as an aversion to nothing but parentheses. Other languages use other brackets to indicate different contexts, but s-expressions can more difficult to read. The idiom of putting all of your end parens on a single line doesn't help. And for most people, the mild convenience of readability is preferable to the consistent semantics.

What’s the problem with having the end parens on a single line? I never understood why languages with curly brace syntax don’t do the same. A line of code containing nothing but a curly brace seems like a waste of screen real estate to me. It contains absolutely no information (the end of the block can be seen by indentation anyway).

One could just as easily write s-expressions using whitespace, so why bother with parens at all?

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.

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

#110

Post by krapp »

pfdietz wrote: post #94
krapp wrote: post #31

Earlier quoted context omitted.

It's not so much an aversion to parentheses as an aversion to nothing but parentheses. Other languages use other brackets to indicate different contexts, but s-expressions can more difficult to read. The idiom of putting all of your end parens on a single line doesn't help. And for most people, the mild convenience of readability is preferable to the consistent semantics.

I don't think the syntax has anything to do with the outcome. Some people like to complain about it, but it's just meaningless noise.

No, disagreements with your opinions are not just meaningless noise.
Post reply on HN