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.…
Alan Kay on Lisp
131–140 of 207 posts
Re: Alan Kay on Lisp
#132Actually, 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…
Re: Alan Kay on Lisp
#133Earlier 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.
Re: Alan Kay on Lisp
#134Earlier 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.
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
#135A 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…
Re: Alan Kay on Lisp
#136Earlier 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.
Re: Alan Kay on Lisp
#137Earlier 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.
Re: Alan Kay on Lisp
#138This 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.
Re: Alan Kay on Lisp
#139Earlier 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.
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
#140Earlier 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…
He said it right there: “unlimited programming in an eyeful” (the bottom half of page 13 in the Lisp 1.5 manual)