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

81–90 of 161 posts

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

#81

Post by linguae »

jes5199 wrote: post #58
djha-skin wrote: post #50

> programming languages don't become mainstream based on their elegance or their deep utility. For any given project, the best programming language to use is the one everyone else is using for that kind of programming at that time. It doesn't have to be the language that is best or most beautiful, and it hardly ever is. As long as the currently-dominant language is adequate to the task without TOO many infuriating sh…

counterexamples: python ruby perl clojure C C++

Counterpoint regarding C and C++ is the famous “Worse is Better” essay by famed Lisp hacker Richard Gabriel:

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

C was the implementation language of AT&T Unix. The operating system spread across universities in the 1970s due to AT&T’s inexpensive licensing to them, including source code. Unix, though its variants and clones, became the dominant operating system with most competitors either dying out or adopting Unix.

Both C and C++ also had the benefits of being the “blessed” languages of Windows (for example, Win32 is a C API, and MFC is a C++ API). Even in the days of the classic Mac, while Pascal was originally the language of choice, eventually in the 1990s C would be “blessed” by Apple.

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

#82

Post by nerdponx »

bmitc wrote: post #60
musicale wrote: post #37

Earlier quoted context omitted.

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

My favorite languages are MLs, particularly F#, which usually have some of the cleanest syntaxes available. It’s not just Lisp-family enthusiasts. I think it’s more for anyone that thinks rather that follows or assumes or whatever. I actually learned about Lisp/Scheme after I had learned about several other languages. What do people not like about parentheses? It’s normally along the lines of “well, I just don’t like…

The problem is precisely that too much regularity makes the code harder to scan visually. The irregularity of various delimiters and separators helps to distinguish certain language elements from others.

There is power and elegance in syntactic uniformity, but Lisp in particular is hard to read until you train your eye to see through the nest of parentheses, and it's hard to write without something like Paredit assisting you.

Meanwhile I don't think anyone finds Haskell/ML syntax hard to read. The problem is more that, with idiomatic Haskell in particular, too much abstraction, currying, and un-descriptive variable names can obfuscate what a piece of code actually does.

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

#83

Post by nerdponx »

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?

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

#84

Post by nerdponx »

layer8 wrote: post #76
layer8 wrote: post #65

Earlier quoted context omitted.

The syntactic consistency is at the same time its downfall: everything looks the same. (Functional languages like Haskell have a similar problem.) It’s more accommodating to human cognition if at least some part of the complexity and diversity of conceptual constructs in programming is represented in the syntax, meaning a certain range of different syntactic constructs that humans can attach meaning to. There is a sw…

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.

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

#85

Post by nerdponx »

jes5199 wrote: post #58
djha-skin wrote: post #50

> programming languages don't become mainstream based on their elegance or their deep utility. For any given project, the best programming language to use is the one everyone else is using for that kind of programming at that time. It doesn't have to be the language that is best or most beautiful, and it hardly ever is. As long as the currently-dominant language is adequate to the task without TOO many infuriating sh…

counterexamples: python ruby perl clojure C C++

Python I think got a major popularity boost by becoming the de-facto standard language of the natural sciences, machine learning, AI, and data science. That, and being a substantially more accessible alternative to Java, and arguably to Ruby as well.

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

#86

Post by layer8 »

bmitc wrote: post #80
layer8 wrote: post #73

Earlier quoted context omitted.

> expressive function names Yes, but those are effectively library conventions, not fixed properties of the language. Maybe more importantly, names aren’t a structural construct, like a for loop or a class definition. And, arguably, you can have similar syntax in other languages, like e.g. `!` in Rust or the type sigils ($, @) in Perl, except that here you can be sure of their semantics.

The naming is enabled by the way S-expressions work and aren't merely convention. Handling such syntax in non-parenthetic languages is difficult because of the overlap with the other meaning of those infix operators in the language. For example, in F#, if I have a function named `string->number`, then the parser doesn't know if I mean `(string) - (>number)`, `(string-) > (number)`, `(string) -> (number)`, or the func…

I totally understand. What I meant was that the meaning of such names, or the names chosen for a given meaning, is a convention of the library (or set of libraries) that defines the names, and not a semantics the language guarantees, like keywords and punctuation do in other languages. (In Lisp I don't know what `string->number` does any more than I know what `stringToNumber` does.) So S-expressions give you more freedom in the syntax of your function names, but they don't provide more kinds of constructs in the language.

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

#87

Post by wrp »

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

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.

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

#88

Post by [deleted] »

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.

[deleted]

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

#89

Post by kazinator »

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.

> The idiom of putting all of your end parens on a single line doesn't help.

Yes it does; doing it any other way is strictly worse regardless of where you stand on parentheses as such.

Post reply on HN