Live data from Hacker News

Alan Kay on Lisp

quora.com

131–140 of 207 posts

Re: Alan Kay on Lisp

#131
post #89

Earlier quoted context omitted.

"Compile time" is artificial, but the difference between static and dynamic is natural (in some sense, I realize these words are quite slippery). It emerges from the underlying mathematics. There's a real difference between correctness properties that I can prove without running my program and correctness properties that will introduce failures at runtime.

You're using a dynamic language (bash) to invoke your statically-typed-language-compiler and then to also invoke the binary it produces. But what's the difference to say, having just a single dynamically typed language with library functions "type-check-my-code", which returns an encapsulated value, and "run-my-typechecked-code" which takes the encapsulated value as input? The whole process happens at "runtime" here.…

runtime here means the runtime of target program, it has nothing to do with unix. If your program fails while executing due to a type error, it's not static type-checking.

Re: Alan Kay on Lisp

#132
post #76
post #53

Actually, I am missing the simplicity of Lisp and Smalltalk in todays languages. From what I remember, they both have a fairly simple but universal syntax, which can be written for Lisp as ([operator] [argument1] [argument2] [argumentN]) and for Smalltalk as [object] [message] So far I haven't seen anything like that for languages with the C-like syntax. Don't get me wrong. For example I love Go, but sometimes I miss…

Lisp, Scheme, and Racket and related languages have many distinct syntax forms, just like other languages. The syntax forms appear visually similar due to the use of parentheses, but the forms themselves are distinct. For example, here are some of the distinct syntax forms in Racket (Scheme): (+ 3 4) # Procedure call (lambda (x) (+ x x)) # Lambda expression # See also case-lambda (let ((x 23) (y 42)) # Variable bindi…

Good explanation. Many people get that wrong and think the syntax for s-expressions is the syntax for Lisp.

Re: Alan Kay on Lisp

#133
post #57

Earlier quoted context omitted.

Well, there are surprisingly few CS graduates who actually understand Object Oriented Programming as Alan Kay designed it for Smalltalk, which in turn lowers the probabilty that any of them will build a qualitatively better language. I mean there are a lot of other skills a programmer needs to have than to understand what OOP is, but sometimes I think it would be better if more young students would learn Smalltalk to…

OOP was taught to me using Smalltalk (VisualWorks actually). It was a PL class, so it didn’t go deep, including also Lisp, Prolog, and SML. I wonder, though, how my OOP thinking would differ if my first exposure was through BETA or Eiffel.

It could be different, but might not be. Exposure to different languages can later broaden your horizon. I started with programming with a programmable calculator, then BASIC, Assembler, Pascal, Modula 2, ... which then typically leads with Wirth moving into OO with Clascal, Oberon, Object Pascal, ...

Re: Alan Kay on Lisp

#134
post #92

Earlier quoted context omitted.

How is Haskell a Lisp? To me, a Lisp pretty necessarily needs to treat the structure of its code as mutable data, which seems kind of incompatible?

The evaluation model of both is quite similar though (reduction), and you can see it in the similarities between Core Haskell and Core Scheme. AFAIK, there are very few truly built in types in Haskell. Most everything can be built out of data constructors and functions. That idea of many things being in language user space is pretty Lisp-y IMO.

The evaluation model is different. Lisp is using strict evaluation and Haskell is using lazy evaluation.

Haskell is statically typed, Lisp is not.

Lisp uses s-expressions for writing programs, Haskell does not.

Generally Haskell and Lisp are very different languages: in syntax, semantics and pragmatics (how the language is used).

Re: Alan Kay on Lisp

#135
post #57
post #10

A similar recent answer on Smalltalk: https://news.ycombinator.com/item?id=15518746 .

Well, there are surprisingly few CS graduates who actually understand Object Oriented Programming as Alan Kay designed it for Smalltalk, which in turn lowers the probabilty that any of them will build a qualitatively better language. I mean there are a lot of other skills a programmer needs to have than to understand what OOP is, but sometimes I think it would be better if more young students would learn Smalltalk to…

[deleted]

Re: Alan Kay on Lisp

#136
post #89

Earlier quoted context omitted.

> more rigorously enforced at compile time 'Compile time', like everything in the artificial science of computing, is a made up thing. We might reconsider if it's a useful idea to keep. Why must there be a specific point in time, when we verify interconnections within a little bundle of code, but later when the bundle of code integrates with a larger system we are completely fine with very different, loosely coupled…

"Compile time" is artificial, but the difference between static and dynamic is natural (in some sense, I realize these words are quite slippery). It emerges from the underlying mathematics. There's a real difference between correctness properties that I can prove without running my program and correctness properties that will introduce failures at runtime.

There certainly is a fundamental difference between what programmers refer to as compile-time and runtime. Naming is probably problematic; but mathematically you cannot prove all the properties of a program just by looking at its syntax, in general. Because this implies a solution to the halting problem. In other words, there is no program, given your program, that can verify it; whereas, there exists a program, given an input and your program, that can verify that your program outputs the correct thing (as long as the language can be emulated by a Turing machine). When it comes to programming languages, the distinction can be trickier, since you can technically get a python program and statically analyze it. So, "compile" time and "run"time are not necessarily perfect words but they belong to the programming terminology. The more crucial thing is, there is a mathematical difference between those two.

Re: Alan Kay on Lisp

#137
post #54

Earlier quoted context omitted.

There are also plenty of Lisp programmers that think that it's a real tool to solve real problems, not just an educational oddity. There are a bunch of Lisps out there, and plenty of them are by no means toys. My laptop's initial RAM disk and init system are Scheme programs.

what are you using? I want to try it.

Not GP but could be Guile https://www.gnu.org/software/guile/

Re: Alan Kay on Lisp

#138

This is really well written and seems to agree with the traditional FP lore. I'm curious what led Alan Kay then to OOP in Smalltalk.

"… the insight that everything we can describe can be represented by the recursive composition of a single kind of behavioral building block that hides its combination of state and process inside itself and can be dealt with only through the exchange of messages." - Alan Kay, The Early History of Smalltalk

Re: Alan Kay on Lisp

#139

Earlier quoted context omitted.

Whatever Alan Kay thinks OOP is, it isn't what we think it is.

just fyi, Alan Kay coined the phrase Object Oriented Programming. So your statement, while true, should probably say what we call object oreinted programming should have a different name.

He did popularly name what others (Nygaard and Dahl) invented, and for which they won ACM Turing Awards.

To quote Alan Kay:- "I don't think I invented 'Object-oriented' but more or less 'noticed' what was really powerful about just making everything from complete computers communicating with non-command messages. This was all chronicled in the HOPL II chapter I wrote 'The Early History of Smalltalk'."

Re: Alan Kay on Lisp

#140
post #32

Earlier quoted context omitted.

Counterpoint: The words he says are nice, and his depth of knowledge is profound, but he hasn't actually provided any evidence making the case that lisp is better and/or in what scenarios it is better. That this sort of rhetoric is the way almost all programmers and language designers try to find truth and communicate ideas is probably why we ended up all programming in javascript. We have no rigor, we are like Freud…

I disagree. I found his meaning clear. The core of the essay is that thinking with the right abstractions provides greater boons to reasoning capacity than comparatively trivial differences in human IQ. To make things a bit more concrete, take any game; Go, Poker, Chess. If these were truly (approached as) combinatorial problems then humans could not stand a chance at them. But over time, people have learned patterns…

"A complaint might be he left out what aspects of Lisp provided that combinatorial boost".

He said it right there: “unlimited programming in an eyeful” (the bottom half of page 13 in the Lisp 1.5 manual)

Post reply on HN