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

91–100 of 161 posts

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

#91

Post by aidenn0 »

jll29 wrote: post #47
pfdietz wrote: post #9

Earlier quoted context omitted.

Indeed. It took a while for a good free Common Lisp to become available. Arguably this wasn't until SBCL (initial release, December 1999).

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

> and no, I don't mean Emacs

So you want two graphical IDEs before you are happy?

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

#92

Post by ivan4th »

nerdponx wrote: post #20
comfypotato wrote: post #4

He certainly implies that he thinks Common Lisp (and maybe Dylan) would have been as popular as Java is today if the lottery had played out differently. 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.)

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 find this syntax argument a bit strange nowadays. There's this extremely popular Kubernetes tool called Helm, which uses go-templated YAML to generate Kubernetes resources. The template syntax is nothing short of horrible. An endless maze of {{ ... }}s, where it's just too easy to shoot oneself in the foot by using {{- or -}} in wrong place, etc. And on top of that, you literally need to count spaces for nindent (mind you, you don't need to count parentheses while writing Lisp code).

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

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

#93

Post by pfdietz »

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?

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.

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

#94

Post by pfdietz »

krapp wrote: post #31
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.

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.

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

#95

Post by admax88qqq »

Animats wrote: post #74
rjsw wrote: post #68

Earlier quoted context omitted.

Franz Lisp could generate executables from the beginning, the debugging features didn't add much to the size.

You could export something runnable from the dev environment, but it was, I think, a copy of the dev environment.

Was it an executable that you could release to clients or not?

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

#96

Post by msworddebugger »

bambataa wrote: post #55
wrycoder wrote: post #26

Earlier quoted context omitted.

But, you always have good editor support. Lisp/Scheme has traditionally been coded using Emacs or its equivalent. With that support, the parens seem to disappear after you've been writing lisp for awhile. 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 char…

I tried using Slime with Scheme when I was doing SICP. I’m sure it’s great when you know it well, but I kept pressing the wrong shortcut and moving things around in ways I didn’t intend and then it wouldn’t let me manually type or delete parentheses to fix things. I found it very frustrating and ended up turning it off. Just another barrier and C-style languages seem much easier to write in comparison.

In case you didn’t know — DrRacket (IDE for the how to design programs book) has a language directive you can run that sets up DrRacket as if it were the environment the sicp authors expect the reader to have.

I only found out after going through SICP using chez scheme’s repl (which I had to compile myself).

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

#97

Post by housel »

dannymi wrote: post #57
housel wrote: post #46

Earlier quoted context omitted.

(Open) Dylan is surviving just fine, and we expect to do a new release later this month.

As a Guix developer (there's a lot of Scheme and Common Lisp in Guix :) ), every few years I check on Open Dylan but so far each time there was something missing that made me unable to package it for Guix (building it entirely from source). 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 bo…

There's no special "bootstrap compiler"; you can download a binary release for your platform from the page you linked, and then use that to bootstrap a newer version from a source checkout. If it would help, we could provide a minimalistic build that was only useful for bootstrapping, but at present our builds are "batteries included" (with LLVM/Clang and the BDW garbage collector already provided in the tarball).

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

#98

Post by Oreb »

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…

I never used Dylan, but isn’t Julia kind of similar, as a Lisp with multiple dispatch and a main-stream syntax?

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

#99

Post by Oreb »

krapp wrote: post #31
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.

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

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

#100

Post by lispm »

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…

> ... Symbolics were even worse - you were always in the development environment and couldn't get anything out except a saved state dump

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

Post reply on HN