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

Alan Kay on Lisp

quora.com

Post reply on HN
Print view View original

121–130 of 207 posts

Re: Alan Kay on Lisp

#121

Post by sparkie »

jcrites wrote: post #76
JepZ wrote: 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…

This is why I love John Shutt's Kernel[0]. All of these "distinct forms" are rolled into one form of "(combiner combiniend)", where combiner is runtime evaluated and can either be a regular applicative (like a lisp procedure call), or an operative (reminiscent of older lisps fexpr). Compound operatives can be created using the primitive operative $vau. Applicatives are created with the primitive wrap. (which $lambda uses in the standard library).

Of the above examples you posted: lambda, let, set!, cond, and, or, when, unless, etc, may all be implemented as a library in the Kernel Report. Some of the others aren't in the report but can be trivially implemented as compound operatives. This simplifies the compiler implementation to requiring only a handful of primitives.

A distinguishing feature of Kernel is the lack of quote in the report. Although it has a trivial implementation ($define! $quote ($vau (x) #ignore x)), quote is considered harmful by Shutt due to the way it interacts with operatives. Also omitted from the language is macros, as their capability can be provided by first class operatives at the library level.

The big downside to Kernel is performance. Compilation is generally not possible because the behavior of operatives can depend on runtime defined environments. This would be one of the reasons macros were chosen over fexprs in the 80s. It means Kernel is not a good language for number crunching, so it'd be nice to have an FFI for the cases where we need to invoke optimised code. (Currently no FFI spec exists).

[0]:http://web.cs.wpi.edu/%7Ejshutt/kernel.html

Re: Alan Kay on Lisp

#123

Post by medfok »

borplk wrote: post #26
jackmott wrote: post #15

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…

Like Steve Jobs he is amongst the group of people who could say anything anyway they like and some people will find a way to glorify it by a factor of a million. If you remove their name from the things they have said or written, at least many of them seem fairly average sensible statements, like something you would read here from a random member. I'd be interested to see a "blind test" for these things. I bet the bi…

You don't get it. You are confusing lack of bias/prejudice with rationality, which is incorrect with regard to any coherent belief system. Your ignorance is harmful and you should try to learn something about the issues that you comment on. I can point you towards resources if you are interested; message me.

Re: Alan Kay on Lisp

#124

Post by medfok »

jackmott wrote: post #15
azag0 wrote: post #14

I'm always blown away by how crisply is Alan Kay able to put complex thoughts into words. I feel that the level of clarity I can achieve on the scale of a sentence or two he can achieve on the scale of several paragraphs.

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…

It's almost like people communicate their experience with words and not benchmarks. The horror!

Re: Alan Kay on Lisp

#125

Post by sparkie »

Silfen wrote: post #89
shalabhc wrote: post #87

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.

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.

The artificial static/runtime boundary is introduced by the way Unix implements files and processes. All statically typed languages are effectively supersets of the language of Unix. In Unix we can treat each executable binary as a library function (except that we have a massive overhead for calling it). The designers of Unix were well aware of this which is why from the POV of bash, there's no distinction between invoking a binary and invoking another script written in bash.

How much of the Unix binary and process bloat is really necessary though to say, concatenate N files? Even someone writing a C program will avoid calling cat and instead implement it themselves, or call a library that does it. Perhaps we need to reconsider where the boundary between type checking and running code should be.

Re: Alan Kay on Lisp

#126

Post by Mikeb85 »

eropple wrote: post #92
Mikeb85 wrote: post #85

Earlier quoted context omitted.

As is LLVM's. I think JVM's might be too, but not 100% sure. Haskell is also pretty much just a lisp with a whole lot of sugar added on.

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?

> How is Haskell a Lisp?

The same way Lisp is a functional language. It has to do with how both languages are built from only a few basic primitives, and how both are based on Lambda calculus.

Re: Alan Kay on Lisp

#127

Post by wruza »

jackmott wrote: post #15
azag0 wrote: post #14

I'm always blown away by how crisply is Alan Kay able to put complex thoughts into words. I feel that the level of clarity I can achieve on the scale of a sentence or two he can achieve on the scale of several paragraphs.

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…

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

It sounds like all the knowledge should be delivered right into someone’s mind in a couple of minutes. It is right there, go and learn it for a week at least.

When I try to directly convince random internet people that e.g. Lua has better async[1] than js due to language primitive that is more abstract and cannot be reimplemented in lower-order primitives, all I hear is usually butwhys and dontneeds, real data on both sides (at best; at worst they claim this code cannot be asynchronous). Instead, folks stick to cumbersome syntactic methods fitting their evolved familiarity. They don’t need anything beyond js, that’s why there is js. And this is one small step torwards less cognitive load and yet we have a friction. Good luck explaining macros, call/cc, evaluation models, etc to them to the point they actually get it en masse.

That said and to be honest, I never mastered lisp skills because it is not actually easy (and I’m not very smart too). You enter the completely new and broad area, where you almost have no clue what you can do. The same would feel a junior entering, say, java after dos basic. But more confusing, because junior has lots of time and is just learning and you’re a professional that “already knows it all” (not really) and has little/no time.

[1] https://news.ycombinator.com/item?id=15472204

Re: Alan Kay on Lisp

#128

Post by wruza »

borplk wrote: post #26
jackmott wrote: post #15

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…

Like Steve Jobs he is amongst the group of people who could say anything anyway they like and some people will find a way to glorify it by a factor of a million. If you remove their name from the things they have said or written, at least many of them seem fairly average sensible statements, like something you would read here from a random member. I'd be interested to see a "blind test" for these things. I bet the bi…

Honestly, I didn’t have any effing clue who Paul Graham is after reading half of his essays and description of Arc. Realized that he wasn’t yet another dev blogger only after someone mentioned on HN that HN is somewhat his. Also, it feels like Joel Spolsky was read in my environment long before stackoverflow.com existed (or became popular). Just one single data point against your hypothesis.

Re: Alan Kay on Lisp

#129

Post by dllthomas »

dllthomas wrote: post #93
eropple wrote: 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?

> How is Haskell a Lisp? ... both communities care a lot about rose trees?

If you squint right, both monads and lisp S-expressions are rose trees.

Re: Alan Kay on Lisp

#130

Post by shiro »

Frondo wrote: post #20
jackmott wrote: post #15

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…

Agreed, and well said. I'm very much a pragmatic kind of person, and my unpopular opinion about code is that Lisp is the greatest single language ever designed, if your goal in designing a language is to produce articles proclaiming it as such. And I am sooo sympathetic to the promises Lispers make. I want to believe. But ultimately, show me the code. Why are the stellar Lisp success stories so few and far between th…

Don't confuse lisp-as-an-executable-device-to-think-meta and lisp-as-one-of-programming-language-choices. Alan is talking the former.

The idea---not just to think about programs per se, but to think about abstract properties and operations of certain category of programs and to be able to actually write it down---gave the exponential power to you. Lisp was the first such tool as a programming language that allowed you to break the ceiling of first-order thinking.

Nowadays there are other languages that provide meta-level tools. And once you get the idea, the language doesn't really matter; you can apply it to any language, albeit you may have to build scaffolds around it to compensate lack of language support (Cf. Greenspun's tenth rule). So, if you already got the idea through other languages, it's good for you. You'll see Lisp as an arcane prototype of modern languages.

But note: since Lisp can write meta-level description in the same language as the base language, you can top up this ladder infinitely, meaning you can think of program-generating-program, then program-generating-program-generating-program, and so on, using a single set of tools. It is indeed powerful but somewhat crude, so modern advanced languages intentionally restrict that aspect and just try to cover the sweet spot. Even if you're familiar with metaprogramming, it may still be worth to play with Lisp to see what (meta)*programming is like, to know its pros and cons, and to get the idea that might come handy someday when single-level metaprogramming isn't enough.

Post reply on HN