Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Idea of Lisp

dev.to

Post reply on HN
Print view View original

291–300 of 348 posts

Re: The Idea of Lisp

#291

Post by lispm »

pjlegato wrote: post #238
mbrock wrote: post #128

Earlier quoted context omitted.

I don't think actual Lisp programmers share this obsession with purity and ideal forms. It's more something that shows up in blog posts about Lisp by people who probably don't actually use it. The title of this one is telling: it's about "the idea of Lisp." On the other hand, if you look at, say, ANSI Common Lisp, it's not at all some kind of perfectionistic attempt at divine elegance. It's a pragmatic compromise res…

ANSI Common Lisp is rather a design-by-committee monstrosity which was forced on the unwilling Lisp vendors by the Defense Department. Most of the feature set was designed via backroom political horse trading ("We'll let you include pet feature X if you support us for our pet feature Y".) There is no coherent overall plan or design to it at all. (Source: personal communication from a member of the committee that desi…

Given that most of the hundreds of Lisp implementations each have their own way to open a TCP connection, Clojure just added another incompatible one. To claim that it is a standard one, is a bit funny. Each of the hundreds other implementations could claim that, too.

Clojure generally added incompatibilities, since it is fully incompatible to any other Lisp before in fundamental ways. Clojure was designed with zero backwards compatibility. Lisp concepts were removed, renamed, redesigned. Even identifiers with the same name are doing completely different things. If it did something similar to what Lisp did, Clojure sure has it renamed and redesigned.

I doubt that you ever had talked to anyone from the ANSI CL committee. It would also have been easy to find out that Common Lisp was designed by a few core people (the gang of five) with lots of community input from 1980 to 1984. This part is well documented. 1984 the first version of Steele's book Common Lisp the Language was published. The ANSI Common Lisp standardization was started later in 1986, when the core of Common Lisp was already defined. Even there the major extensions were designed by small groups with community input. See for example how CLOS was designed by a few people (Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon.) and by providing a complete reference implementation (PCL).

Re: The Idea of Lisp

#292

Post by eschaton »

kazinator wrote: post #275
bsder wrote: post #232

Earlier quoted context omitted.

> John McCarthy didn't implement Lisp in machine code. McCarthy also didn't expect S-expressions to be a concrete form. He expected everybody would write in M-expressions. The fact that S-expressions worked as the language itself is again due to Steve Russell's insight.

The problem was that M-expressions are just really silly way of spelling S-expressions, almost node for node, atom for atom. Whatever disadvantages we agree S-expressions have, M-expressions have all of them, and then some: like extra noise due to punctuation. What are M-expressions? Basically this: (a b c) (quote (a b c)) car[x] (car x) car[append[(a b c); (d e f)]] (car (append (quote (a b c)) (quote (d e f)))) Par…

Another interesting aspect of M-expressions is how much like Mathematica/Wolfram they look.

Re: The Idea of Lisp

#293

Post by bogomipz »

hindenburg wrote: post #67
clarkd99 wrote: post #55

This great idea of Lisp (the simple syntax of function calls in round brackets) isn't much different than a good macro assembler even back in the 1960's. The only major difference was that more than 1 function could be defined in 1 source code line. (I think that machine code is nothing but a sequence of function calls where the function is the logic encoded in the CPU itself for each opcode.) Is it fair to compare t…

You make some specific claims here that sound a little odd to this LISP and assembly language hacker. Assembly language doesn't provide any datatypes. LISP does. Assembly language doesn't provide any type checking. LISP does. Assembly language doesn't provide automatic storage reclamation. LISP does. Assembly language doesn't provide naming. LISP does. You also make a claim about L1 caches and locality of reference.…

>"every LISP garbage collector writer, knows about CDR-coding."

I thought CDR needed hardware support as opposed it being a general programming technique, is that not correct?

I've only ever read about it on FAQs like in the following:

http://www.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part2/fa...

Re: The Idea of Lisp

#294

Post by anoctopus »

qwertyuiop924 wrote: post #258
pjlegato wrote: post #238

Earlier quoted context omitted.

ANSI Common Lisp is rather a design-by-committee monstrosity which was forced on the unwilling Lisp vendors by the Defense Department. Most of the feature set was designed via backroom political horse trading ("We'll let you include pet feature X if you support us for our pet feature Y".) There is no coherent overall plan or design to it at all. (Source: personal communication from a member of the committee that desi…

Clojure's an odd, unlispish language, at least for us Lispers and Schemers. CL is still very good at what it does: all current implementations have solved many of the problems you mentioned, and there are a lot of libraries that will run across implementations. CL is a beast, but clojure is a mess. Scheme is elegant, but has a radically different, more ALGOL mentality than CL, at least in some respects. Some of it is…

Could you explain what you think is wrong with Clojure? Maybe it's because I've spent far more time using it than CL, but I see Clojure as having a very consistent, well designed core. It's very opinionated in it's design, but it's a practical and pragmatic one. I don't see what's unlispish about it.

Re: The Idea of Lisp

#295

Post by Retra »

kazinator wrote: post #279
zeveb wrote: post #184

Earlier quoted context omitted.

> Implementing Lisp properly in machine code is not easy; you have to write a garbage collector. That's not actually true: you could, instead, just fill up memory and crash when you're out. It's not ideal, but it does work.

That might not meet some expectations behind the word "properly".

Such expectations would have little to do with Lisp. Even one with a garbage collector can run out of memory. How quickly that happens and how it handles it is just a matter of how good of a garbage collector you have.

Re: The Idea of Lisp

#296

Post by lispm »

btilly wrote: post #277
rntz wrote: post #241

Earlier quoted context omitted.

I have no reason to believe that Russell wrote a garbage collector for the first Lisp implementations. I used the adverb "properly" specifically because it's possible to implement Lisp without GC, but this isn't really a viable approach long-term. So to make Lisp practical, significant work on GC had to be (and was) done.

My understanding is that the first version of Lisp with true GC was Scheme. Which was, not coincidentally, the first version of Lisp with lexical scope and closures. The first implementation of Lisp used reference counting.

That's strange.

McCarthy describes a mark&sweep GC.

http://www-formal.stanford.edu/jmc/recursive/node4.html

Re: The Idea of Lisp

#297

Post by eschaton »

traviscj wrote: post #23
erik14th wrote: post #18

I wonder why lisp isn't as popular as say python for AI, ML, and stuff. I see these fields as having a strong academic tone, and it feels like racket or clojure could be bigger when it comes to that.

Lisp was way more popular for classic AI for many many years, and possibly still is. For machine learning, you want very fast matrix operations for the actual training/evaluation parts and very good data munging for the "get the data from this file/API/database to your ML library". The Python ecosystem is strong at both, which sets up a good feedback loop for even better libraries to be built on top. That's my take,…

Back then there weren't really ML libraries to speak of, you had to write your own. Though Symbolics did have a neural network tool and framework they sold.

And you could certainly do things like shuffle lots of data easily for more hardcore processing. For example, Symbolics didn't just have a Weitek floating point accelerator option for their systems, they had vector processing boards for them too that you could use from Lisp. (And even a GPU, the Framethrower, that did full-frame HD with 2D and 3D acceleration! S-Graphics is amazing for the time.)

Also, a lot of AI work back then was focused on symbolic processing. That's largely been eclipsed by the more math-heavy approaches these days but symbolic processing is still around, for example in tools like Cyc.

Re: The Idea of Lisp

#298

Post by [deleted] »

WorldMaker wrote: post #108
rntz wrote: post #70

This article has many misstatements in its first half. > John McCarthy wrote 6 easy things in machine code, then combined them to make a programming language. John McCarthy didn't implement Lisp in machine code. Steve Russell did. Implementing Lisp properly in machine code is not easy; you have to write a garbage collector. To do that in the early 60s, you had to first invent garbage collection . Lisp was and is bril…

«`lambda` and function application alone are Turing-complete, as McCarthy would have known. The credit here belongs with Turing and Church, not McCarthy» I have sometimes pedantically quibbled with people that it is properly named the Church-Turing Theorem (of Computation) and that that distinction of including both esteemed mathematicians helps to push people towards the realization of how groundbreaking that effort…

[deleted]

Re: The Idea of Lisp

#299

Post by Retra »

agentgt wrote: post #2

The conditional expression or more specifically everything being an expression is my favorite thing about Lisp. I did not know that McCarthy pushed to add it to Algol which apparently today is the ternary operator for most languages. It is annoying that so many languages (C, Java, C#, etc) have both a conditional statement (if-else) and conditional expression (ternary ?:). Really the if-else should be an expression (…

Probably a bit off-topic: I always get frustrated with C++ because `if` is not an expression, you can't do conditional initialization under RAII easily.

Re: The Idea of Lisp

#300

Post by ericbb »

kazinator wrote: post #275
bsder wrote: post #232

Earlier quoted context omitted.

> John McCarthy didn't implement Lisp in machine code. McCarthy also didn't expect S-expressions to be a concrete form. He expected everybody would write in M-expressions. The fact that S-expressions worked as the language itself is again due to Steve Russell's insight.

The problem was that M-expressions are just really silly way of spelling S-expressions, almost node for node, atom for atom. Whatever disadvantages we agree S-expressions have, M-expressions have all of them, and then some: like extra noise due to punctuation. What are M-expressions? Basically this: (a b c) (quote (a b c)) car[x] (car x) car[append[(a b c); (d e f)]] (car (append (quote (a b c)) (quote (d e f)))) Par…

I think that M-expressions are quite interesting but I'll just make a few concrete points here.

> if we want (quote x) it looks as if we have to write: ... quote[x]

I think that you could just write X in that case. Uppercase text was for symbolic atoms.

Also, you didn't mention conditionals:

M-expressions:

    ff[x] = [atom[x] → x; T → ff[car[x]]]
S-expressions:

    (defun ff (x) (cond ((atom x) x) (T (ff (car x)))))
The semicolon and the infix arrow have the benefit of reducing the need for parentheses in that case. And you can avoid writing "defun" and "cond".
Post reply on HN