
Alan Kay on Lisp - shakes
https://www.quora.com/What-did-Alan-Kay-mean-by-Lisp-is-the-greatest-single-programming-language-ever-designed/answer/Alan-Kay-11?share=1
======
JepZ
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 the beauty of
Lisp and Smalltalk.

~~~
jcrites
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 binding
             (+ x y))            # And also:
                                 # let*, letrec, letrec*, let-values,
                                 # let*-values, let-syntax, letrec-syntax, local
        (set! x 4)               # Assignment (mutating)
        (define x 23)            # Defined value
        (define (f x)            # Defined procedure
                (+ x 42))
        (quote a)                # Quotation
        (#%datum . 10)           # Quotation (keywords prohibited)
    
        # Conditionals
        (if (> 2 3) 'yes 'no)
        (cond ((> 3 2) 'greater)
              ((< 3 2) 'less))               
        (and a b)
        (or a b)
        (cond ('(1 2 3) => cadr) # Test clause
              (else #f))         # Else clause
    
        # Guarded evaluation
        (when (positive? -5)
          (display "hi"))
        (unless (positive? 5)
          (display "hi"))
    
        # Dispatch      
        (case (+ 7 5)
          [(1 2 3) 'small]
          [(10 11 12) 'big])
    
        # Sequencing
        (define x 0)             
        (begin (set! x 5)
               (+ x 1))
        # See also: begin0, begin-for-syntax
    
        # Iterations and Comprehensions
        # for, for/and, for/or, for/vector, for/hash, for/hasheq ...
    
        # Modules and imports
        (module id module-path form ...)
        (require ...)
        (provide ...)
    

As you can see, although the language consistently uses parentheses, it has
similar syntax structure to other languages: assignments, definitions,
functions, switch/case, etc. Some of the syntax forms above have multiple
variations, as well.

See: [https://docs.racket-lang.org/reference/syntax.html](https://docs.racket-
lang.org/reference/syntax.html)

~~~
merlincorey
I think your examples underscore the GP's point.

Every single one of your examples is an S-Expression where the first element
of the list is an operator/function followed by N arguments, from an abstract
context-less view, anyway.

In lisp there are atoms, lists, and expressions. They have uniform expression
but not uniform meaning.

~~~
jcrites
The notation uses S-expressions, that’s true, but the point that I was trying
to make is that you can’t understand anything about the meaning of those
S-expressions without parsing them in a context-aware way.

It’s not as if there is just one form `(<op> <arg1> ... <argN>)` where the
expression means invoking `op` with some arguments.

A human or machine interpreting the code needs to be aware of these forms and
the meaning/semantics of each one. Consider the following S-exps:

    
    
        (if a b)
        (set! a b)
        (define a b)
    

They’re all three-term S-expressions, but you can’t understand their meaning
without contextually interpreting the first term. There is a second layer of
contextual syntax. Similarly:

    
    
        ((lambda (x y) (list y x)) 1 2)
    

Consider the term `(x y)` in that expression. Without context, it looks like a
call to the procedure `x` with `y` as input. With context, it’s a list of
argument names for the lambda function.

In languages like C# and Java there is just one meaning of:

    
    
        f(a, b);
    

You know this is actually a procedure invocation with some arguments.

There are trade offs to each approach. I’m not saying that one is better, just
that there’s more to Scheme syntax than S-exps. Concatenative languages like
Forth and Factor have even less syntax than Scheme.

~~~
taeric
Strictly, this isn't true. In f(a, b), if f is while, it is not a procedure
call. Or if it is a declaration.

Then, of course, there is the specifics of the call. Is it single dispatch?
Where is it dispatched? Etc.

Which isn't really to argue against the point. Yes, you need context. Pretty
much always. Having gotten used to lisp, I find it much easier to understand.
I realize familiarity helps, though.

------
dpeck
that this has an unbalanced paren has me laughing a lot more than it probably
should

------
jf
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 following the
lead of “The Parc Machines” and Smalltalk (and we in turn had been very
influenced by the Lisp model of programming and implementation. (And these
operating systems in both Smalltalk and Lisp were both better and easier to
write than the standard ones of today.)

Another interesting answer assumed that “the test of time” is somehow a cosmic
optimization. But as every biologist knows, Darwinian processes “find fits” to
an environment, and if the environment is lacking, then the fits will be
lacking. Similarly, if most computer people lack understanding and knowledge,
then what they will select will also be lacking. There is abundant evidence
today that this is just what has happened.

But neither of these has anything to do with my praise of Lisp (and I did
explain what I meant in more detail in “[The Early History of
Smalltalk]([http://worrydream.com/EarlyHistoryOfSmalltalk/)”](http://worrydream.com/EarlyHistoryOfSmalltalk/\)”)).

To start with an analogy, let’s notice that a person who has learned calculus
fluently can in many areas out-think the greatest geniuses in history.
Scientists after Newton were _qualitatively_ more able than before, etc. My
slogan for this is “Point of view is worth 80 IQ points” (you can use
“context” or “perspective” etc.). A poor one might subtract 80 IQ points! (See
above). A new more powerful one makes some thinking possible that was too
difficult before.

One of our many problems with thinking is “cognitive load”: the number of
things we can pay attention to at once. The cliche is 7±2, but for many things
it is even less. We make progress by making those few things be more powerful.

This is one of the reasons mathematicians like compact notation. The downside
is the extra layers of abstraction and new cryptic things to learn — this is
the practice part of violin playing — but once you can do this, what you can
think about at once has been vastly magnified. There were 20 Maxwell’s
Equations in their original form (in terms of partial differentials and
cartesian coordinates). Today the four equations we can think about all at
once are primarily due to their reformulation by Heaviside to emphasize what
is really important about them (and what is likely to be problematic — e.g.
the electric and magnetic fields should probably be symmetric with respect to
movement, etc).

Modern science is about experiencing phenomena and devising models whose
relationships with the phenomena can be “negotiated”. The “negotiation” is
necessary because what’s inside our heads, and our representations systems etc
have no necessary connection to “[what’s out
there?]([http://www.vpri.org/pdf/m2003001_human_cond.pdf)”](http://www.vpri.org/pdf/m2003001_human_cond.pdf\)”).

Taking this point of view, we can see there can be a “bridge science” and
“bridge scientists” because engineers build bridges and these furnish
phenomena for scientists to make models of.

Similarly, there can be a “computer science” and “computer scientists” because
engineers build hardware and software and these furnish phenomena for
scientists to make models of. (In fact, this was a large part of what was
meant by “computer science” in the early 60s — and it was an aspiration —
still is — not an accomplished fact).

The story behind Lisp is fun (you can read John McCarthy’s account in the
first History of Programming Languages). One of the motivations was that he
wanted something like “Mathematical Physics” — he called it a “Mathematical
Theory of Computation”. Another was that he needed a very general kind of
language to make a user interface AI — called “The Advice Taker” — that he had
thought up in the late 50s.

He could program — most programs were then in machine code, Fortran existed,
and there was a language that had linked lists.

John made something that could do what any programming language could do
(relatively easy), but did it in such a way so that it could express the
_essence_ of what it was about (this was the math part or the meta part or the
modern Maxwell’s Equations part, however you might like to think of it). He
partly did this — he says — to show that this way to do things was “neater
than a Turing Machine”.

Another observation about this is that the “slope” from the simplest machine
structures to the highest level language was the steepest ever — meaning that
the journey from recognizable hardware to cosmic expression is a rocket jump!

As is often the case — especially in engineering — a great scientific model is
often superior to what exists, and can lead to much better artifacts. This was
certainly true here. Steve Russell (later famous for being the main inventor
and programmer of “SpaceWar”) looked at what John had done, and said: “That’s
a program. If I coded it up we’d have a running version”. As John remarked:
“He did, and we did”!

The result was “unlimited programming in an eyeful” (the bottom half of page
13 in the Lisp 1.5 manual). The key was not so much “Lisp” but the kinds of
thinking that this kind of representational approach allowed and opened up
regarding all kinds of programming language schemes.

A fun thing about it this is that once you’ve grokked it, you can think right
away of better programming languages than Lisp, and you can think right away
of better ways to write the meta descriptions than John did. This is the “POV
= 80 IQ points” part.

But this is like saying that once you’ve seen Newton, it becomes possible to
do electrodynamics and relativity. The biggest feat in science was Newton’s!

This is why “Lisp is the greatest!”

~~~
xenophonf
_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...](https://github.com/dwelch67/raspberrypi/tree/master/blinker01)

More importantly, where's the accompanying toolchain? Seriously, I really want
to know because I'd love, Love, LOVE to play around with it.

~~~
tonyg
For example, [https://github.com/tonyg/pi-
nothing/blob/master/kernel.nothi...](https://github.com/tonyg/pi-
nothing/blob/master/kernel.nothing#L203-L221) 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 even the most rudimentary tidying-up of it for public
view. Caveat lector.)

But hardware access - replacing C - is the really easy part. The real power of
a lisp/Smalltalk OS is getting away from the hardware in one "rocket jump", as
Alan put it. Once you can start using integrated high-level language
constructs spanning the whole of the abstraction tower from hardware through
user interface, that's when it starts to get fun. The really good stuff is the
new abstractions you can unlock. Smalltalk is a far better Unix than Unix,
from that point of view.

~~~
scroot
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 Smalltalk machines existed, I would buy one today.

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

~~~
scroot
All I meant by bringing up the web browser is that for a personal computer to
be usable in reality by a lot of people they'll need a web browser. But just
that user application alone gets them really far: email, office productivity,
etc. It's a good first application to have in any system.

Therefore we could have all kinds of exotic, bespoke personal computers again,
except that unlike the 80s and 90s we now have fairly standardized formats
across systems. This gives us the freedom to make whatever kinds of
architectures and OSes we want. In this case, that could even include a
machine whose board is designed from the ground up to run Lisp or Smalltalk or
something we evolve out of those as its operating system.

The web browser that would come with such a default system would be written in
one of those languages. Yes, I know making a web browser is an enormous
undertaking, but at least some totally new personal computing system wouldn't
have to then also implement office productivity etc.

~~~
mbrock
Agreed. I think the best way would be to use Linux as the kernel, maybe with
Wayland for display, and Chromium/Firefox in a sandbox, and then the custom OS
system running alongside this. Emacs with the Elisp window manager is an
example.

~~~
scroot
I don't think we're on the same page here. You don't need Linux for the
kernel. Insofar as there's a kernel, it's the programming environment itself
(like Smalltalk) or a set of primitive programs written in that environment
(like Lisp).

For graphics you don't need X or Wayland or any of that stuff. BitBlt was able
to handle graphics in Smalltalk, because the hardware of the Alto (via
microcode) was setup to allow Smalltalk to handle all graphics. If you truly
wanted something optimized, something like Nile/Gezira and DSLs written in the
environment could work too.

The whole point is that such a system would need to be redesigned and rebuilt
from the hardware level on up. A difficult task, to be sure, but the reward is
invaluable: the ability to reason about the entire system through the system
itself.

~~~
mbrock
Oh. For me it's just pointless drudgery to remake everything like that. I want
a new fully coherent and portable system using an existing kernel and graphics
layer for bootstrapping. I mean, Emacs or Squeak are already almost there as
far as I'm concerned.

------
signa11
it is the man himself :), and ofcourse, this p.o.v is worth 80 IQ points. this
insight is

'One of our many problems with thinking is “cognitive load”: the number of
things we can pay attention to at once. The cliche is 7±2, but for many things
it is even less. We make progress by making those few things be more
powerful.'

just beautiful

~~~
wahern
It's probably more literally true than he intended. And 7 isn't really a
cliche; it's not an opinion but a thoroughly proven, universal limitation of
human working memory.

Before the advent of cheap writing instruments, and especially cheap printing,
we used poetry to almost effortlessly recall and communicate large working
sets of data, privately or in discourse. With poetry and similar mnemonic
devices people memorized volumes of information. A student or scholar in
ancient Greece would have literally memorized all the classics. Someone like
Cicero would write a speech of 5,000 to 10,000 words and then, a few days
later, deliver it nearly verbatim from memory. The dominate form of mass
communication was through open speeches, and this is why most of the great
speeches came from the ancient world. But it was limited; recalling and
sharing was easy, but memorizing was still laborious, notwithstanding the fact
that ancient scholars' memorization faculties seem like super powers to modern
humans.

With the advent of cheap writing and printing, we were able to archive,
recall, and disseminate magnitudes more information at a more rapid pace. And
while slower to recall, speed of creation and dissemination, and sheer volume
more than made up for that limitation. Moreover, mass communication proved far
more efficient in written form.

Today computers are killing writing just as writing killed poetry. But it's
not really computers, per se. With writing it was the system of creating and
using written works (alphabets, printing presses, libraries) that actually
realized the efficiency gain. In Alan Kay's view, Lisp is what made the
promise of computers realizable, capable of supplanting the dominant form of
"thinking" and of opening up new frontiers. Computers are like papyrus; it's
learning how to use them that matters, and Lisp was that great leap. It's one
thing to laboriously write a program using machine code; it's something else
entirely to do this using an elegant, higher-order programming language.
Indeed, once you use that higher-order language you can't go back; it changes
how you think about programming, including how you structure programs written
in machine code. Like with poetry and writing the utilitarian leap in
productivity is forgotten because it becomes so effortless and seemingly
obvious; instead all you see are the limitations and faults.

~~~
alankay1
The 7±2 was thoroughly proven for sequences of numbers, letters, words, etc.
by George Miller and followers. Much has been done since, and this shows that
for many things we can handle fewer chunks. That "7±2" is still used for the
larger idea of "cognitive load" makes it a cliche and a metaphor.

So it is just as true as I intended. We live in a world of unsupported
opinion. I'm 77 and from a world in which one was supposed to have
considerable support for an opinion before voicing it. I realize that this is
out of step these days, and especially with web fora.

~~~
wahern
To my mind a cliche refers to an archaic metaphor. Archaic because it out-
lives the discarded conceptual framework it describes, and therefore no longer
communicates anything of substance. Worse, such cliches often perpetuates err
in conceptualizing an issue.

Qualitatively and quantitatively, working memory capacity strongly reflects
limitations of so-called executive attention and, more generally, executive
function. See, e.g.
[https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2852635/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2852635/)
("Based on the finding that WMC and EF tasks shared substantial common
variance, we argue that the current data provide evidence for reciprocal
validity for both of those constructs. Reciprocal validity can be defined as a
particularly strong form of construct validity, such that two constructs that
are strongly empirically related to one another lend support to the
theoretical reality of each other.").

AFAIU, the 7±2 quantity is still both valid in its original context and in
communicating something substantive about more complex phenomena. Of course,
depending on how you "chunk" a "concept" the number quickly becomes
meaningless, but that's a game of semantics. The more sophisticated
definitions of chunking that one would use to invalidate 7±2 necessarily
invoke broader, more speculative models, given that so much about cognition is
still unknown. I can't see how one could fairly use such models to invalidate
the 7±2 rule, which remains literally and meaningfully true for "chunks" as
originally defined. 7±2 communicates something both qualitatively and
quantitatively true about something very specific--words, letters, numbers,
etc--and about larger phenomena in cognition--constraints on higher-order
cognitive processes are reflected by a phenomenon which has a fixed absolute
limit, 7±2, in relation to these easily identifiable and measurable inputs--
words, letter, etc.

In other words, referring to 7±2 is saying something both concrete and
meaningful. Moreover, the conceptual model it invokes is still the dominant
framework, if only because the rule circumscribes what it purports to
describe, even in common usage. Nobody mistakes a heuristic for determining
the length of a phone number (a derivative "rule" which is far more
susceptible to the monicker, cliche) with a limit on our innate capacity for
conceptualizing Relativity. Examples which invalidate the rule actually muddy
the waters by drawing in more incomplete and uncertain premises, exemplifying
what the 7±2 rule gets right about how best to communicate something of
substance about such a complex and incomplete field of study. Of course, there
are limitations to what you can extrapolate from 7±2, but that would be
understood.

That's why I think it unfair to disparage application of the "7±2" phenomenon
as cliche. Whatever one's specific definition of cliche, I think it's fair to
say that labeling such usage "cliche" is to disparage it. I think such
disparagement is unfair. It's rare for a simplified anchor to a complex field
to retain such validity and power. But ultimately I guess my point rests on
what might be an idiosyncratic definition of cliche.

------
dang
A similar recent answer on Smalltalk:
[https://news.ycombinator.com/item?id=15518746](https://news.ycombinator.com/item?id=15518746).

~~~
JepZ
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 understand what OOP is about and why the
simple existence of classes doesn't make a language an OO language...

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

~~~
lispm
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, ...

------
etruong42
I like how Alan Kay still ends up using nested parentheses when discussing
Lisp:

> (These operating systems in both Smalltalk and Lisp were both better (claim)
> and easier to write (simpler to demonstrate) than the standard ones of
> today.)

------
timonoko
Operating system written in lisp:
[https://github.com/timonoko/Nokolisp_On_Nokia_phone](https://github.com/timonoko/Nokolisp_On_Nokia_phone)

------
kazinator
I disagree with the "single ... language" right off the bat before any deeper
considerations.

Lisp is a great collection of design patterns for making languages.

 _> The key was not so much “Lisp” but the kinds of thinking that this kind of
representational approach allowed and opened up regarding all kinds of
programming language schemes.

> A fun thing about it this is that once you’ve grokked it, you can think
> right away of better programming languages than Lisp, and you can think
> right away of better ways to write the meta descriptions than John did._

Once you've grokked it, those programming languages are more advanced dialects
of Lisp.

Or else, you didn't really grok it.

~~~
coldtea
> _Or else, you didn 't really grok it._

Only if you believe that the only good thing one should grok is the data/code
parity part.

For me Smalltalk is even better and more concise than Lisp is.

~~~
kazinator
It seems like it wouldn't be hard to make a Smalltalk-like sub-language inside
a Lisp dialect like Common Lisp or Racket. It could be programmed using
S-exps, or custom read syntax to make it look like actual Smalltalk.

~~~
blihp
Might be interesting as an academic exercise but doesn't seem like a terribly
useful thing to actually do. I like both languages but using Smalltalk syntax
in Lisp isn't something I'd want. Besides, Lisp has (IMO) nice optional
keyword parameter syntax which fits better in the Lisp world than the
Smalltalk message/block syntax ever would.

~~~
kazinator
You and I might not want a Smalltalk syntax in Lisp, but someone who favors
Smalltalk (like user coldtea to whom I was responding, who finds that
Smalltalk is "better and more concise") might want that.

~~~
blihp
Fair enough. I was reacting more to what I interpreted as you advocating the
approach as opposed to just trying to offer a solution based on coldtea's
comment. (I likely had a visceral reaction because I've actually implemented a
toy Lisp in Smalltalk and it wasn't something I'd want to do much more than
play with)

~~~
scroot
Have you looked at Ian Piumarta's work with COLAs? Curiously it's a mix of a
Smalltalkish higher level object language with a lower-level lisp like
language. I never quite understood how they worked together, but maybe you can
understand the papers over at vpri.org better than I.

~~~
blihp
I'm somewhat familiar with Ian's COLA work but am much more familiar with the
Smalltalk related portions of the project since I'm currently working with
some of those pieces of it. As I understand it, the original intention was to
prototype the system in a Smalltalk image and eventually re-target the work to
his COLA architecture via OMeta (which the higher-level stuff was written in
so retargeting would be done via OMeta parsers and not require many (any?)
higher level changes) I _think_ they got some of the lower level things
running that way (i.e. I think I recall seeing a demo of at least part of the
Nile/Gezira work running as 'native' code but could be remembering it wrong)
but due to time/money constraints I don't think they ever got completely there
with it as their final demonstration artifact (FRANK) was Smalltalk image-
based (plus a couple of plugins for performance). Take this explanation with a
grain of salt as I admit to being a bit fuzzy as to how far they got with
Ian's lower-level work...

What they were trying to do was demonstrate that they could build the entire
system from highest level languages (i.e. the OMeta-based languages they wrote
the system in) down to machine code (i.e. what the COLA stuff generated and
runtime it provided which would replace the Smalltalk environment) in 20kloc
_and_ preserve linkages (i.e. chain-of-meaning) from the top to the bottom.
While they may not have technically achieved everything they set out to, I'm
sold that they were successful in proving the concept and that they could have
gotten there (i.e. the parts they did deliver were impressive) at that order
of magnitude in terms of lines of code.

------
ohazi
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 have a stronger type system that's more
rigorously enforced at compile time. I personally find this much more valuable
in practice than some of the dynamic magic that you can do with lisp.

There are some notable exceptions, of course, but part of this is just
inherent to the design of lisp, and I think it's easy to end up with a type
safety system that feels more like it's bolted on than part of the language.

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

~~~
krapp
And it's not a Lisp per se, but WebAssembly's text format uses
s-expressions[0]. It's likely that the "oddity" of Lisps will seem less odd as
adoption increases if they stick with that.

[0][https://developer.mozilla.org/en-
US/docs/WebAssembly/Underst...](https://developer.mozilla.org/en-
US/docs/WebAssembly/Understanding_the_text_format)

~~~
tomjakubowski
gcc’s IR, “GIMPLE”, is also commonly printed in s-expression form.

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

~~~
eropple
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?

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

~~~
lispm
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).

------
ahmedalsudani
“I am the Alan Kay in question”

Hah. Not everyone can be that cool.

------
eternalban
It's funny, he can't even balance his parens in the first para.

------
CyberDildonics
Citizen Kaine is often called 'the best movie ever made'. If you watch it, it
is arguable whether it is even minimally entertaining. I would say it is one
of the most influential movies created along with Kurosawa movies. If I'm
stuck on a plane I would rather watch the latest Transformers or sit in
silence (given only those three options).

Lisp is arguably the most influential programming language, that doesn't mean
it is objectively 'the best'.

~~~
nickik
You would rather watch Transformers then Citizen Kaine? Wat?

~~~
thedaemon
Attention spans are different now.

~~~
vixen99
Whose and where?

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

~~~
jackmott
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 era
psychology with flowering and impressive sounding prose but no real data. And
while psychology still has a long way to go, we have even further.

~~~
borplk
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 bias would
show.

As in, display something from Alan Kay but post it on a random internet forum
as JoeSchmo11, and you will have lots of people disagreeing with it and
tearing it apart without hesitation.

But oh look if Steve Jobs or Alan Kay or Elon Musk's name is attached to it
suddenly becomes a unique gem of knowledge to be cherished by the humanity for
the rest of time and surely the fault lies with anyone not agreeing with it
right? Because after all they could not possibly be more right than those
authority figures?

I'm not making a judgement about this, neither am I surprised by it. Just
saying that you should ask yourself exactly how much of your own brain power
and judgement do you use to judge the quality of an idea and how much of your
conclusion is conveniently borrowed from your image of the author?

It reminds me of when Elon Musk talked about the probability of our universe
being a simulation.

I'm not saying he is right or wrong, just using that as an example. But if
JoeSchmo11 said exactly the same thing people would just dismiss it.

But when Elon Musk says it all the newspapers go mad and write stories about
it.

Again I'm not saying it shouldn't be like this, reputation matters, I get it.

But my point is that the fact that this happens to the degree that it does is
in some ways a sad admission that we are incapable of evaluating thoughts and
ideas independently of their originators and on their own merits. Instead we
borrow from the past credibility and the authority of the people they are
attached to.

~~~
mquander
What is the sad admission here? That not everyone establishes 100% of their
belief system from first principles, and instead adopts some of it empirically
based on other reasoners' beliefs? I don't consider that a bug.

If I don't know anything about X, and the Alan Kay of X comes and tells me
something about X, it's pretty likely to be true. If equally-ignorant-as-me-
person tells me something about X, it's not as likely to be true. That's the
meaning of knowledge and ignorance.

None of this precludes thinking for yourself about anything. It's just the
thing you do in addition to thinking for yourself about it, if you want to
have true beliefs.

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

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

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

~~~
aryehof
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'."

~~~
alankay1
Simula can't be praised too highly, and it was a huge influence. But if you
take the care to check, you will find out that what I termed "Object Oriented"
was quite different from Simula in (what I thought were) important ways. And
if you are looking for the earliest inventions of ideas like these, there are
several that predate Simula (take a look at that HOPL II chapter mentioned
above)

~~~
aryehof
I certainly don't want to underemphasise the huge contribution of Smalltalk.

Nevertheless, consider a couple of modern widely-used languages. C++ in terms
of object-orientation, is based on Simula, and Java's object model is entirely
based on Simula.

I argue that it was Nygaard and Dahl who first introduced those language's key
concepts (objects, classes, sub-classing and virtual functions) in a coherent
and programmable form. This is why Nygaard's Turing Award page states "Kristen
Nygaard is internationally acknowledged as the co-inventor with Ole-Johan Dahl
of object-oriented programming and the programming language SIMULA", and why I
stated in my parent response that you named the term others invented,
notwithstanding that today's common use isn't necessarily consistent with your
coining of the term.

