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

111–120 of 161 posts

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

#111

Post by Oreb »

krapp wrote: post #109
Oreb wrote: post #99

Earlier quoted context omitted.

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.

Source code is indeed meant to be read, and at least to me, low information density seriously hurts readability. I prefer both Python-style indentation based syntax and multiple parens at the end of the line over C-style syntax with closing braces alone on a line. If I write code in a language with curly brace syntax and I don’t have to share the code with others, I prefer to use multiple closing braces on the same line – like Lisp parens – because of improved readability.

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

#112

Post by jb1991 »

nerdponx wrote: post #84
layer8 wrote: post #76

Earlier quoted context omitted.

P.S.: The diversity in programming language design mirrors the diversity in how humans' minds work. Some people work better with dynamic than with static typing. Some people work better with Lisp, some with Haskell or ML, some better with Java and C#, some with APL and friends, etc. There is no one-size-fits-all, and one factor in the adoption of each language is how each programmer's cognition matches the respective…

Human attributes are generally distributed on something like a bell curve. Programming languages with "extreme" characteristics in any direction will almost inevitably be stuck with niche popularity, because they will only be appealing to a small fraction of people. Whereas, even "extreme" people will generally be able to tolerate at least a couple of conventional languages.

At issue in this thread is the very definition of extreme vs conventional. The idea in this thread is that the languages now considered to be conventional could have been the niche syntax.

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

#113

Post by pfdietz »

krapp wrote: post #110
pfdietz wrote: post #94

Earlier quoted context omitted.

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.

It's not meaningless because I disagree with it, it's meaningless because it had nothing to do with why Lisps didn't take over.

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

#114

Post by lispm »

ivan4th wrote: post #92
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 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 (m…

wow, how could that happen?

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

#115

Post by pfdietz »

krapp wrote: post #109
Oreb wrote: post #99

Earlier quoted context omitted.

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.

Parens allow an editor to create the proper indentation.

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.

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

#116

Post by p_l »

jakeinspace wrote: post #64
jes5199 wrote: post #58

Earlier quoted context omitted.

counterexamples: python ruby perl clojure C C++

C++ had a whole host of compilers and tooling/IDEs pushed by large private companies (Microsoft, Borland, Intel). I think that somewhat qualifies as institutional backing of another sort.

The initial push for C was that most Unix systems arrived with a C compiler included (there were exceptions ofc, and once the compilers started going pricy there was a lot of volunteers for GCC).

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)

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

#117

Post by bambataa »

Jtsummers wrote: post #56
bambataa wrote: post #55

Earlier quoted context omitted.

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.

Slime did that? Slime doesn't take over the editor that much (it shouldn't prevent you from typing parentheses, I've used it for 16 years or so and never experienced anything like that). Was it paredit or another editor mode?

Sorry you’re right, it would have been Paredit.

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.

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

#118

Post by p_l »

lispm wrote: post #100
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 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.

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

#119

Post by Jtsummers »

bambataa wrote: post #117
Jtsummers wrote: post #56

Earlier quoted context omitted.

Slime did that? Slime doesn't take over the editor that much (it shouldn't prevent you from typing parentheses, I've used it for 16 years or so and never experienced anything like that). Was it paredit or another editor mode?

Sorry you’re right, it would have been Paredit. 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.

Lisp is no harder to edit in notepad than any other language. It is just a text editor and lisp source is just text. And paredit is a misfeature for most people, turn it off. That should have been the real takeaway. It is not part of a ”correctly configured editor” and it isn’t installed or activated by default anyways so is easy to avoid.

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

#120

Post by rjsw »

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.

Porting CMUCL to x86 required someone having access to a machine that it already ran on as well as a 386 running UNIX, plus knowing that the CMUCL sources were available and having internet access to get hold of them. I think these were the limiting factors rather than lack of demand.
Post reply on HN