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

181–190 of 207 posts

Re: Alan Kay on Lisp

#181

Post by [deleted] »

nerdponx wrote: post #102
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…

Ruby is nice for this. It has message-passing OO and clean, minimal syntax.

[deleted]

Re: Alan Kay on Lisp

#182

Post by hota_mazi »

igouy wrote: post #113
hota_mazi wrote: post #81

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 languages where parameter names are optional, you can say

    foo(1, 1, create = true)
This is the best of both worlds, allowing you to only name parameters when there can be ambiguity (for example when the function takes two int parameters and both mean very different things).

Smalltalk forces you to always name your parameters, which leads to overly verbose source files.

Re: Alan Kay on Lisp

#183

Post by igouy »

hota_mazi wrote: post #182
igouy wrote: post #113

Earlier quoted context omitted.

> by making all the parameter names mandatory For example?

In languages where parameter names are optional, you can say foo(1, 1, create = true) This is the best of both worlds, allowing you to only name parameters when there can be ambiguity (for example when the function takes two int parameters and both mean very different things). Smalltalk forces you to always name your parameters, which leads to overly verbose source files.

I don't think any of us know what:

    foo(1, 1, create = true)
:is supposed to do.

Please show a meaningful example so we can see whether the Smalltalk is overly verbose or your alternative is overly ambiguous.

Re: Alan Kay on Lisp

#184

Post by hota_mazi »

igouy wrote: post #183
hota_mazi wrote: post #182

Earlier quoted context omitted.

In languages where parameter names are optional, you can say foo(1, 1, create = true) This is the best of both worlds, allowing you to only name parameters when there can be ambiguity (for example when the function takes two int parameters and both mean very different things). Smalltalk forces you to always name your parameters, which leads to overly verbose source files.

I don't think any of us know what: foo(1, 1, create = true) :is supposed to do. Please show a meaningful example so we can see whether the Smalltalk is overly verbose or your alternative is overly ambiguous.

I tried to pick up an example as generic as possible so you could understand my general point instead of focusing on this specific example, and you choose to focus on this specific example. .

How about this:

     createWindowAtCoordinates(10, 10, redraw = true)
vs

     createWindowAtCoordinates(x = 10, y = 10, redraw = true)
Regardless of how you feel about this specific example, surely you can agree that it's not always necessary to specify all the parameter by names?

Re: Alan Kay on Lisp

#185

Post by alankay »

wahern wrote: post #103
signa11 wrote: post #5

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

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

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.

Re: Alan Kay on Lisp

#186

Post by alankay1 »

aryehof wrote: post #139
DigitalJack wrote: post #50

Earlier quoted context omitted.

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

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)

Re: Alan Kay on Lisp

#187

Post by shalabhc »

loup-vaillant wrote: post #148
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…

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

> As for why we switch to dynamic typing as we scale up, some of it probably has to do with trust.

I'll note that we switch to 'dynamic' much before the question of trust arises. Whenever you do IPC between two OS processes you fully trust, communicate through a database or file, wire up a multi-process system with config files, etc. Most internal code at an organization is trusted, yet the communication between OS processes within an company uses dynamic messaging semantics.

I'll also point out that if you use a compiled shared library, or any system call you are forced to use the type system of C, which isn't particularly advanced.

It could be that we haven't developed dynamic messaging protocols that can bind safely and correctly. I'm arguing that if we have these, they might apply on a smaller scale too (objects within a 'process' or connections between shared libraries, etc.)

> Static typing enables faster feedback loops.

All of that only works on the small scale - where the type knowledge has to be fully shared within the entire program. As soon as you're writing code to call a service, static typing benefits are moot. The current solution is to create 'stubs', which doesn't scale well either. I am not arguing for 'dynamic typing everywhere', but rather about a different POV where we start looking at 'interconnections' at all levels the same way, and think about making the introspection and safe late binding in a standard, scalable way. Minimizing pre-shared knowledge would be one way to improve how this scales, for instance.

Re: Alan Kay on Lisp

#188

Post by shalabhc »

Silfen wrote: post #104
shalabhc wrote: post #91

Earlier quoted context omitted.

> It emerges from the underlying mathematics. Which mathematics? (Lisp has its own math, for instance.)

Very fundamental ideas around computability, or total vs partial functions. There are some correctness properties that we can prove without running the underlying program, such that we can always accept or reject a given program. None of this is particular to lisp.

Fundamental ideas about computability include the model of the Turing machine, which has no notion of types, verification, or even functions whatsoever - there are just too many degrees of freedom.

I agree there are correctness properties we can prove without running a 'program', but how do we map the notion of a 'program' into the real world. Is a single function a program? A single module which includes multiple functions? A single executable? A single system that includes multiple processes communicating over a network? I'm arguing each of these is a 'program' and a Turing machine in the theoretical sense. Each of these programs is hooked up to other 'programs' outside of it. 'Compilation' requires the input to be static, but if we think about how things are in flux (you can change a function, switch out a shared library or upgrade and restart a running process, etc.) when do you verify that a 'program' is 'correct'?

This is what I mean by 'compile time is made-up' - it falls out of the current frame of thinking of one OS process = one program = static set of source files. It is possible to design systems that have no notion of 'compile time'. You could still have verification, but it could be incremental and spread out all through the lifetime of the running system. So the system would have no 'compile phase' - it would be running live and as you update parts of it, the updated parts would integrate with the rest of the system and do verification like things.

Re: Alan Kay on Lisp

#189

Post by shalabhc »

xfer wrote: post #131
sparkie wrote: post #125

Earlier quoted context omitted.

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.

I think sparkie has a very valid point. It has to do with Unix because a 'program' in Unix has specific meaning (and Windows is no different in this regard, btw). A Unix program doesn't map exactly to what a program means in the theoretical sense. E.g. two Unix processes talking over a socket are not thought of as single Unix program, even though they can be considered a single theoretical program. So there is a tendency to think in 'processes' not 'systems'. I elaborated a little more about this elsewhere in this thread (https://news.ycombinator.com/item?id=15581591).

Re: Alan Kay on Lisp

#190

Post by erikpukinskis »

coldtea wrote: post #179
erikpukinskis wrote: post #90

Earlier quoted context omitted.

I think lack of understanding the data/code parity is a huge part of why so many development ecosystems are broken right now. The lack of metaprogramming in other languages has spawned this proliferation of declarative programming that results from the use of build systems (config files are declarative) and filesystem tools (git, ember-cli) and psuedolanguages (SQL, jquery selectors). Because we’re not writing these…

That's an interesting take on the matter -- and I also agree that while this is a real problem, Lisp-everywhere or X-everywhere is also not necessarily the solution. The problem with the "best tool for the job" is that it leaves us with 2000 tools we need to integrate -- which is an even bigger problem often than what the tools collectively help us solve.

Yes, that’s the Hegelian antithesis to the “Language Wars” of the previous decade.

The synthesis will be “it’s OK to use the right tool, but only if your specific needs will play out in a meaningfully better way than the native solution, and keep in mind the cost cliff at each new language or psuedolanguage”.

Post reply on HN