Live data from Hacker News

The Idea of Lisp

dev.to

131–140 of 348 posts

Re: The Idea of Lisp

#131

Earlier quoted context omitted.

Agreed about linked lists; that virtually all functional languages make them the default/literal data structure is IMO a poor practical design choice (no matter how theoretically elegant) and is the primary culprit for their reputation for slowness. And the tendency for functional compile-to-JS langs to emulate linked lists in Javascript and keep them the default data structure is downright laughable.

(Singly linked) lists are a functional data structure. You can manipulate them efficiently without modifying the lists you started with. You can't do that easily with arrays. So if you base your language around arrays, you're better off making it imperative. Lisp predated level 1 caches. I think it's better to design hardware around the software that runs on it (the Burroughs mainframe/Lisp machine approach), than de…

I would argue that there's no such thing as a "functional data structure." If a data structure maps poorly to existing functional languages, that's a symptom of an insufficiently powerful and generic type system.

Say you have (pseudocode)

  Array(4 16 5 20)
What's its type?

  Array
  Array
  Array
  Array
  Array(Int Int Int Int)
None of these lend themselves easily to paradigms other than imperative, true. But this is because they unnecessarily discard known information. The type of an array ought to be itself:

  assert Array(4 16 5 20) hasType Array(4 16 5 20)
    => Ok
  
  assert Array(4 16 5 20) hasType Array
    => Error("Expected Array but got Array(4 16 5 20). Hint: Typeclass Array cannot be directly instantiated")
  
  assert Array(4 16 5 20) hasTypeclass Array
    => Ok
Fully functional and referentially transparent.

Re: The Idea of Lisp

#133

Earlier quoted context omitted.

> Things which don't have a logical value evaluate to `()` (the empty tuple), I believe. If Rust follows Scala then `()` is not the empty tuple, but rather Unit (void in C*).

void in C can't be created, used, or passed around - () can.

But void pointers can, and are often used.

Re: The Idea of Lisp

#134

Earlier quoted context omitted.

I see two issues with the ternary operator. One, the syntax is much less readable, and two, the consequent and alternate are both single expressions, so you can't do something like: x = if(something) { a = foo(); baz(a); } else { b = bar(); baz(b); }

If you insist on the assignments: x = something ? ((a=foo()), baz(a)) : ((b = bar()), baz(b)); Otherwise: x = something ? baz(foo()) : baz(bar());

a and b have to be defined before the statement containing the terniary expression here. And the point is that you can embed arbitrary multi-statement logic in your if expressions in Rust in the same way you'd do it anywhere else.

Re: The Idea of Lisp

#135

Earlier quoted context omitted.

> Things which don't have a logical value evaluate to `()` (the empty tuple), I believe. If Rust follows Scala then `()` is not the empty tuple, but rather Unit (void in C*).

It's the same thing. It's a type with only a single value.

It's not the same thing, a value of type Unit can only produce a side effect (or do nothing at all).

Re: The Idea of Lisp

#136
The thing about the way ideas about programming are "sold" to other programmers, is that it has as much to do with the actual profession of programming as a typical tween's conception of being a "rockstar" has to do with the actual profession of being a touring musician. A lot of the really vital hard work is glossed over, and huge amounts of attention are paid to certain abstracted "sexy" ideas.

When people watch someone soldering, their attention is drawn to the iron, and to the shiny melted flowing metal. However, it's really cleaning the tip of the iron and having an iron that can provide enough power at the right temperature that matters.

Re: The Idea of Lisp

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

The article is called "the idea of Lisp" conveying the broad concepts. It's mean as something that can be digested as a newsletter or an email. He even mentions his email list in the article. I don't think it was meant to be an encyclopedic reference on the language. I think its odd that you spent that much effort tearing it apart. I for one enjoyed reading it while I was waiting for a coffee. Who actually wrote the…

I don't like that you're being downvoted. You're making a fair point. I do like the second half of the article, for the record.

I think that attribution matters; albeit probably more the attribution to Church and Turing than to Steve Russell over McCarthy. It matters because if someone finds the ideas the article brings up interesting and wants to dig into them, they should know where to turn. The history of ideas informs future ideas to come.

I also think understanding the details of high-level ideas matters. The misconceptions about self-interpretation, for example, are quite deep: no language can ultimately be defined in terms of itself, but always in terms of something lower-level. Chase this thread far enough and you start studying transistors; or, in another direction, Goedel's incompleteness theorems.

Re: The Idea of Lisp

#138

Earlier quoted context omitted.

> Things which don't have a logical value evaluate to `()` (the empty tuple), I believe. If Rust follows Scala then `()` is not the empty tuple, but rather Unit (void in C*).

The empty tuple/unit is not the same as void. It has exactly one possible value, void has zero possible values. A way to write it in Rust is `enum Void {}` (an enumeration with no options).

The point is that both void and Unit can only produce a side effect. In everything-is-an-expression based languages Unit is exactly equivalent to void in C*.

Re: The Idea of Lisp

#139

It's interesting, I'm reading Black Swan at the moment by Nassim Taleb, and one of his big rants is about how we get blinded by idealized, platonic forms and ideas when the real world is messy and inherently unpredictable. E.g. trying to explain the forms of nature with platonic archetypal shapes like circles, rectangles and triangles. Lisp and the community around it kinda has that flavor - getting lost in a world o…

Yes, I really like Taleb's books because they are about the gap between theory and practice -- and in particular, how to make bets and take action to discover that gap.

His later books go into this too: how academics rewrite history in favor of the ideas they created, but "tinkerers" create history.

I believe he uses the example of the Wright brothers. Were they physicists? No, they were engineers and tinkerers. And what is amazing is that people still argue about the physics of how planes fly!!! Practice often precedes theory.

Whether there's a similar phenomenon in computing is an interesting question. Computing is sort of special because the finished product, a program, is probably the closest thing to a pure idea that you will find in engineering (as opposed to a plane or a telescope). It is created almost entirely in the human mind.

On the one hand, you could say that what you learn in school is idealized and gives academics too much credit. To use a recent example, what was the contribution of Phil Katz vs. academic research in compression? That would make for an interesting essay I would love to read.

What about BitTorrent, or BitCoin? I believe plenty of academics were trying to create systems like BitTorrent, and publishing papers about them, but Bram Cohen said he pulled a bunch of magic numbers out of his butt and dealt with router quirks, and made it work. But certainly he also used computer science.

I like this essay, "Notes on postmodern programming": https://scholar.google.com/scholar?cluster=16064138633971247...

Some excerpts:

The word “algorithm” is often claimed as the central concept of computer science [35] “Algorithm”, however, leaves out large amounts of the discipline of programming: components, patterns, protocols, languages, data structures [76].

There is equal acceptance of high and low culture: Visual Basic and Haskell are equally of interest, as there is no reason to applaud the one and disparage the other

Postmodern programming rejects overarching grand narratives. As a result, it favours descriptive reasoning rather than prescriptive. Rather than working top down from a theory towards practice, postmodern programming theories are built up, following practice.

Re: The Idea of Lisp

#140
post #106
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…

The story as I have heard it before is that John McCarthy wrote a Lisp interpreter in Lisp and Steve Russell translated it directly into machine code to get a working interpreter. Wikipedia indicates that Steve Russell implemented Lisp in machine code twice but gives no details. Do you have a source giving additional details of what happened?

Here's an account by McCarthy of the early history: http://www-formal.stanford.edu/jmc/history/lisp/lisp.html
Post reply on HN