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

131–140 of 161 posts

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

#131

Post by kazinator »

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've done all my Lisp coding, pretty much ever, in Vim. Just basic :set lisp mode, % key for matching parens, autoindent and off we go.

I didn't see any difference between that and C editing support.

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

#132

Post by kazinator »

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 been working with Lisp for over twenty-two years and still got tripped up recently by something that was

  (if (condition)  ;;
Phony complaints about problems with editing parentheses and getting them to match are just trolling nonsense, but Lispers should acknowledge this kind of problem: when your editor has already helped you ensure that the code has valid syntax, everything is beautifully indented and compiles without diagnostics, but you have a mistake like this: parentheses being closed in the wrong place, not including something, or the wrong operator like the above.

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
No language save you from writing a program similar to the one you should be writing, but which is correct for a different set of requirements relative to what you want. Just verification and testing.

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

#133

Post by lispm »

dleslie wrote: post #122
lispm wrote: post #104

Earlier quoted context omitted.

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

Scratch 1.x and 2.x were written in Smalltalk, FWIW. But IMHO the "your whole dev environment is your shipped application" is too unappealing to catch on.

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.

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

#134

Post by lispm »

p_l wrote: post #118
lispm wrote: post #100

Earlier quoted context omitted.

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

Don't forget dedicated "delivery" 36xx series machines from Symbolics, which were lower priced specifically because they weren't supposed to be used with the development environment.

For those there was also a system called "Firewall", which shields the end user from the underlying Lisp in some way.

Then there were also delivery systems on the Ivory. There was even a stripped down Lisp operating system called Minima for those, IIRC.

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

#135

Post by jlokier »

kazinator wrote: post #132
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've been working with Lisp for over twenty-two years and still got tripped up recently by something that was (if (condition) ;; Phony complaints about problems with editing parentheses and getting them to match are just trolling nonsense, but Lispers should acknowledge this kind of problem: when your editor has already helped you ensure that the code has valid syntax, everything is beautifully indented and compiles…

  (if (condition)  ;;
I didn't find that to be a common problem when writing Emacs Lisp at least. The "misleading indentation" warning is relevant thre. If you enter the above code into Emacs, auto-indenting as you go, it will indent like this, making it obvious you meant `when`:

  (if (condition)
      (do-this)
    (do-that))

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

#136

Post by cgay »

wott wrote: post #54
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.

I haven't given a look at this language in a few years; is it still so that there are no enums, and that operators must be surrounded by spaces?

Yes. Making a macro for defining enums isn't that hard (there's one here: https://github.com/cgay/uncommon-dylan/blob/master/enum.dyla...).

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.

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

#137

Post by cgay »

headhasthoughts wrote: post #78
dannymi wrote: post #57

Earlier quoted context omitted.

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…

The way you actually have to do it is trawling through git repos to find an old version of Gwydion, bashing at it for a while, and maybe getting it to compile on modern platforms. Look for 2.4, then rewind, then pass a config flag, and a few more steps. 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 Mil…

Gwydion Dylan has been out of the picture for years. Open Dylan is the only maintained implementation. Perhaps you went down a wrong path....

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

#138

Post by tmtvl »

dleslie wrote: post #53
jll29 wrote: post #47

Earlier quoted context omitted.

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

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?

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

#139

Post by jonjacky »

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

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

#140

Post by dannymi »

housel wrote: post #97
dannymi wrote: post #57

Earlier quoted context omitted.

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

Ideally, what Guix would want is similar to what https://github.com/thepowersgang/mrustc/ does for Rust (a compiler, not written in Rust, for Rust).

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.

Post reply on HN