Live data from Hacker News

Alan Kay on Lisp

quora.com

141–150 of 207 posts

Re: Alan Kay on Lisp

#141

Earlier quoted context omitted.

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

> Whatever Alan Kay thinks OOP is, it isn't what we think it is I suspect that there are a lot of people still around who encountered other OOP models before C++ and it's derivatives became dominant for whom that's not really true.

Ralph Johnson (one of the GOF) stated there are three views of OOP: the Scandinavian view; the Mystical view; and the Software Engineering view.

> "The Scandinavian view is that an OO system is one whose creators realize that programming is modeling. The mystical view is that an OO system is one that is built out of objects that communicate by sending messages to each other, and computation is the messages flying from object to object. The software engineering view is that an OO system is one that supports data abstraction, polymorphism by late-binding of function calls, and inheritance."

Most today (sadly) know only variations of the Software Engineering viewpoint.

Re: Alan Kay on Lisp

#143
post #113

Earlier quoted context omitted.

> smalltalk cutest feature is the named parameter syntax trick (I don't like tricks but let's make an exception). And yet, Smalltalk got it wrong by making all the parameter names mandatory, which leads to sources that are much more verbose than they need to be. The correct approach to this is to make parameter names optional, so they're only used when disambiguation is necessary to clarify the intent of the code.

> by making all the parameter names mandatory For example?

In smalltalk the parameter names aren't mandatory in the sense of many other languages.

They are actually part of the method name.

So

robot put: thing in: container.

And

robot put: thing on: shelf.

Are two separate messages that are both understood by the robot instance - "put: in:" vs "put: on:"

Re: Alan Kay on Lisp

#144

Earlier quoted context omitted.

You can put the parameter names in method calls, which makes for much more readable code. Like a makeRange method may take parameters `from` and `to`, when calling this method you could do `makeRange(from: 0, to:10)`. That’s a fairly trivial example but it demonstrates how readability is improved. You can imagine how this becomes even more useful with methods that take many parameters. An interesting document to look…

"You can put the parameter names in method calls, which makes for much more readable code. Like a makeRange method may take parameters `from` and `to` ... That’s a fairly trivial example but it demonstrates how readability is improved." Is that something like keyword arguments in Lisp?

Except Smalltalk keywords can't be reordered or omitted. It's more like you put the arguments in the middle of the method name, like a kind of mixfix notation.

The method name would be "rangeFrom:to:withStep:" and that means you call it exactly like that, with arguments after the colon.

Objective C is the same.

Re: Alan Kay on Lisp

#145
post #66
post #60

Earlier quoted context omitted.

For example, https://github.com/tonyg/pi-nothing/blob/master/kernel.nothi... does something similar to that blinker. It might not be quite what you're after, because it's only superficially a lisp; more an S-expression veneer over something C-like. Toolchain is the rest of the repo. Currently written in Racket. (BTW this is feasibility-study-level stuff, not production stuff. It's messy as hell because I haven't done…

The way things stand now, the only required piece of application software that a new personal computer needs in order to be viable is a web browser. But once you have that, and the system of your machine is sufficiently compelling, it would work for a great many people. This is why I think someone is going to build something like an actual top to bottom Lisp/Smalltalk/Whatever machine sooner than we think. If Smallta…

Well, wouldn't that just be a JavaScript machine implemented in Smalltalk?

Re: Alan Kay on Lisp

#146
post #66
post #60

Earlier quoted context omitted.

For example, https://github.com/tonyg/pi-nothing/blob/master/kernel.nothi... does something similar to that blinker. It might not be quite what you're after, because it's only superficially a lisp; more an S-expression veneer over something C-like. Toolchain is the rest of the repo. Currently written in Racket. (BTW this is feasibility-study-level stuff, not production stuff. It's messy as hell because I haven't done…

The way things stand now, the only required piece of application software that a new personal computer needs in order to be viable is a web browser. But once you have that, and the system of your machine is sufficiently compelling, it would work for a great many people. This is why I think someone is going to build something like an actual top to bottom Lisp/Smalltalk/Whatever machine sooner than we think. If Smallta…

Could you elaborate? It's a bit cryptic to me, but it sounds exciting!

Re: Alan Kay on Lisp

#147
post #22

Posting Alan's reply as a comment below for posterity, since Quora appears to forbid archive.org from making a copy. --- First, let me clear up a few misconceptions from the previous answers. One of them said “Try writing an operating system with Lisp”, as though this would be somehow harder. In fact, one of the nicest operating systems ever done was on “The Lisp Machines” (in Zeta-Lisp), the hardware and software fo…

And these operating systems in both Smalltalk and Lisp were both better and easier to write than the standard ones of today. Look, I love Lisp as much as the next hacker, but is Alan Kay for real? Where's the Lisp equivalent to this C code? https://github.com/dwelch67/raspberrypi/tree/master/blinker0... More importantly, where's the accompanying toolchain? Seriously, I really want to know because I'd love, Love, LOVE…

> is Alan Kay for real? Where's the Lisp equivalent to this C code?

Have you ever heard of the STEPS project? It's a complete OS, with applications libraries, and compiler collection, all in 20,000 lines of code. Pretty real if you ask me. Here are the reports (latest first).

http://www.vpri.org/pdf/tr2012001_steps.pdf

http://www.vpri.org/pdf/tr2011004_steps11.pdf

http://www.vpri.org/pdf/tr2010004_steps10.pdf

http://www.vpri.org/pdf/tr2009016_steps09.pdf

http://www.vpri.org/pdf/tr2008004_steps08.pdf

http://www.vpri.org/pdf/tr2007008_steps.pdf

Re: Alan Kay on Lisp

#148
post #29

There seem to be two big camps that preach a "learn this weird new programming paradigm because it'll help you see things from a new perspective and will make you a better engineer" message: the lispy languages, and the ML-like languages. Both of these languages categories give you functional programming as well as metaprogramming, which is great. Having tried both, I've found that the ML-derived languages tend to ha…

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

Static typing enables faster feedback loops. The kind of thing Bret Victor raves about.

In practice, I've been able to accomplish things with static typing that I hadn't the brainpower to do with dynamic typing, because even with a REPL, runtime errors came too late, and didn't meaningfully informed me of my mistakes.

As for why we switch to dynamic typing as we scale up, some of it probably has to do with trust. Computers communicating over the internet cannot trust each other, if they can even trust they are talking to one another to begin with. They have no choice but to perform lots of runtime checks to make sure they don't get pwned by the slightest remote mishap. Once you get to this point, static verifications become much less useful, and can often be skipped altogether.

Re: Alan Kay on Lisp

#149

Earlier quoted context omitted.

"smalltalk cutest feature is the named parameter syntax trick..." make-range from: 10 to: 20 calss (make-range.from:to 10 20) or something similar. Free nanodsls For the uninitiated among us, what does that do and what's so magic about it?

So the example would be: 1 to: 10. Sends the "to:" message to the number 1 with the parameter 10. Returns a range representing the numbers from 1 to 10. You can then iterate that range with by sending it the "do:" message with a block argument. 1 to: 10 do:[ :i | ]. And so on. Looks a lot like syntax for a for-loop, but is just message sends to collections with keyword syntax. Every type of collection implements do:…

Sorry to "well actually" you, but

    1 to: 10 do:[ :i |   ].
would be a single message `to:do:`, not a chain of messages.

Re: Alan Kay on Lisp

#150

Earlier quoted context omitted.

You can put the parameter names in method calls, which makes for much more readable code. Like a makeRange method may take parameters `from` and `to`, when calling this method you could do `makeRange(from: 0, to:10)`. That’s a fairly trivial example but it demonstrates how readability is improved. You can imagine how this becomes even more useful with methods that take many parameters. An interesting document to look…

> makeRange(from: 0, to:10) [..] Swift’s guidelines on naming methods. The syntax you show is Swift, which is a weird mash-up of C/C++ style function call/method call syntax with keywords jammed into them. To me, actual Smalltalk syntax is just so much cleaner: 0 to: 10. It manages the "reads like english" trick without trying to be english-like or natural-language-like. (See Applescript for the disaster that results…

AppleScript may be the only read-only programming language in existence.
Post reply on HN