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

191–200 of 207 posts

Re: Alan Kay on Lisp

#191

Post by igouy »

hota_mazi wrote: post #184
igouy wrote: post #183

Earlier quoted context omitted.

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

So you mean that in this case we might assume the conventional order x coordinate first and y coordinate second would be understood.

However (the specifics always matter) if we're assuming that, and we're bothered about verbosity then why say:

    createWindowAtCoordinates(10, 10, redraw = true)
:instead of assuming that it will be understand that the window will be created at a point:

    createWindowAt(10, 10, redraw = true)
:and something more like a Smalltalk method send:

    Window new openAt: 10@10 redraw: true
:where we've used the x then y convention, and a binary message @, to create a point (without mandatory parameter names).

Re: Alan Kay on Lisp

#192

Post by hota_mazi »

igouy wrote: post #191
hota_mazi wrote: post #184

Earlier quoted context omitted.

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

So you mean that in this case we might assume the conventional order x coordinate first and y coordinate second would be understood. However (the specifics always matter) if we're assuming that, and we're bothered about verbosity then why say: createWindowAtCoordinates(10, 10, redraw = true) :instead of assuming that it will be understand that the window will be created at a point: createWindowAt(10, 10, redraw = tru…

> So you mean that in this case we might assume the conventional order x coordinate first and y coordinate second would be understood

... and again, you focus on the specific example and completely miss my more general point.

I'll give this one more try: I prefer a language that gives me the option of specifying the parameters names over one that forces me to always specify them.

Re: Alan Kay on Lisp

#193

Post by xfer »

shalabhc wrote: post #189
xfer wrote: post #131

Earlier quoted context omitted.

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

But it has nothing to with typing, as typing means tying to a location in program, you can have processes communicating part of the same program, but the type-error will refer to a part of program and when the type-error is detected i.e. during execution of that part of program or some external part of program is what we are concerned here.

Example: You could think of an interpreter for a statically-typed language running various processes as the same program, but we still say the language is statically typed.

Re: Alan Kay on Lisp

#194

Post by loup-vaillant »

shalabhc wrote: post #187
loup-vaillant wrote: post #148

Earlier quoted context omitted.

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

> Most internal code at an organization is trusted,

It is not.

We trust our colleagues not to be malicious, but we generally don't trust them not to make mistakes. Hence defensive programming.

Re: Alan Kay on Lisp

#195

Post by aryehof »

alankay1 wrote: post #186
aryehof wrote: post #139

Earlier quoted context omitted.

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)

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.

Re: Alan Kay on Lisp

#196

Post by gnulinux »

loup-vaillant wrote: post #178
gnulinux wrote: post #136

Earlier quoted context omitted.

There certainly is a fundamental difference between what programmers refer to as compile-time and runtime. Naming is probably problematic; but mathematically you cannot prove all the properties of a program just by looking at its syntax, in general. Because this implies a solution to the halting problem. In other words, there is no program, given your program, that can verify it; whereas, there exists a program, give…

> mathematically you cannot prove all the properties of a program just by looking at its syntax, in general. A solution that is often overlooked is to simply shrink the set of legal programs. Simply typed lambda calculus for instance has a perfectly decidable halting problem (which is, programs written in it always halt). There are 2 ways to handle undecidable properties with static analysis: either reject programs f…

Yeah, but now you're arguing something else. Simply typed lambda calculus is not Turing-complete. With a Turing-complete language, you cannot decide the halting problem of an arbitrary sentence of that language. With a non-Turing-complete one, you potentially can. For example, Charity is one such non-Turing-complete language, for which, hypothetically, one can find an algorithm to decide halting of an arbitrary program. But most languages today are Turing-complete, because TC is a very easy property not to have, and it is very hard to construct non-TC but useful languages (eg, C++ metaprogramming is accidentally Turing complete, so is HTML+CSS). So, while what you explained is correct, it does not have direct implications on languages like Python, C++ etc. We still have different sort of properties while we're statically analyzing a TC language, and executing it with an input. This was what I was trying to explain.

Re: Alan Kay on Lisp

#197

Post by 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.)

Re: Alan Kay on Lisp

#198

Post by loup-vaillant »

gnulinux wrote: post #196
loup-vaillant wrote: post #178

Earlier quoted context omitted.

> mathematically you cannot prove all the properties of a program just by looking at its syntax, in general. A solution that is often overlooked is to simply shrink the set of legal programs. Simply typed lambda calculus for instance has a perfectly decidable halting problem (which is, programs written in it always halt). There are 2 ways to handle undecidable properties with static analysis: either reject programs f…

Yeah, but now you're arguing something else. Simply typed lambda calculus is not Turing-complete. With a Turing-complete language, you cannot decide the halting problem of an arbitrary sentence of that language. With a non-Turing-complete one, you potentially can. For example, Charity is one such non-Turing-complete language, for which, hypothetically, one can find an algorithm to decide halting of an arbitrary progr…

Being Turing complete doesn't mean you cannot prove anything without solving the halting problem. Programs have many potentially undecidable properties, and halting is only one of them. It's also one of the strongest.

It doesn't matter which property you are looking at. If it's undecideable, you can sidestep the issue by forbidding programs for which the checker is not sure.

That doesn't mean you have to lose Turing Completeness. You just have to chose properties that don't imply that the program halts. Static typing for instance doesn't mean the language isn't Turing Complete. Simply typed lambda calculus is the exception here.

Re: Alan Kay on Lisp

#199

Post by igouy »

hota_mazi wrote: post #192
igouy wrote: post #191

Earlier quoted context omitted.

So you mean that in this case we might assume the conventional order x coordinate first and y coordinate second would be understood. However (the specifics always matter) if we're assuming that, and we're bothered about verbosity then why say: createWindowAtCoordinates(10, 10, redraw = true) :instead of assuming that it will be understand that the window will be created at a point: createWindowAt(10, 10, redraw = tru…

> So you mean that in this case we might assume the conventional order x coordinate first and y coordinate second would be understood ... and again, you focus on the specific example and completely miss my more general point. I'll give this one more try: I prefer a language that gives me the option of specifying the parameters names over one that forces me to always specify them.

> … you focus on the specific example…

That's the only way we can see whether what you claim makes sense.

> … which leads to sources that are much more verbose than they need to be.

We can see that for the example you provided, the Smalltalk style need not be "much more verbose" than the alternative you provided.

Using positional arguments will be a little more concise than using keyword arguments, but only a little.

Re: Alan Kay on Lisp

#200

Post by shalabhc »

loup-vaillant wrote: post #194
shalabhc wrote: post #187

Earlier quoted context omitted.

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

> Most internal code at an organization is trusted, It is not. We trust our colleagues not to be malicious, but we generally don't trust them not to make mistakes. Hence defensive programming.

The point is trust and typing seem orthogonal. E.g. I use static typing within one 'program' but 'dynamic' as soon as I split my program into two, even when the level of trust didn't change. Same thing when including my colleagues' code within my 'program' vs. calling it across program boundaries.

The point I'm trying to make is that 'static-typing style verification' which happens across different parts of a 'single program' doesn't extend to multiple programs or real systems. Maybe we should look at some kind of late bound dynamically bound verification - i.e. a protocol that is executed whenever one 'program' reaches out and connects to another, to determine if the connection is safe and correct. Do you think this has value?

Post reply on HN