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

201–207 of 207 posts

Re: Alan Kay on Lisp

#201

Post by gnulinux »

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

Earlier quoted context omitted.

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…

Where did I claim "you cannot prove anything without solving the halting problem" or "static typing means non Turing complete" exactly? I said nothing of this sort... IN TC languages you can prove some properties, but in general you cannot prove your program is correct. When I say in general, I mean exactly that. You keep bringing some specific cases where you can prove correctness, but that's beyond my point.

I sometimes workaround this by proving for "outputs the correct result, or loops forever". Here, you don't have to prove for halting, since your program is not expected to halt in some cases anyway. But then in some particular cases, you can prove that your algorithm is correct. You do not have to lose Turing-completeness to do this. But it gets trickier when you want to built a type system that can give all the bugs in your program, in general. You can definitely build something that finds all the bugs "for all intents and purposes" but not something that can be mathematically proven that will give you all of them. To be concrete, you can build a program, given arbitrary Python code, gives most of/all the bugs in this program. But you cannot build a program, given arbitrary Python code, that is proven that it will correctly know whether this program will output correct result for all possible inputs. You can do this for some restricted Python programs (as you've been arguing for last two comments) but in general you cannot do this, which brings us to this fundamental division.

Re: Alan Kay on Lisp

#202

Post by wahern »

alankay wrote: post #185
wahern wrote: post #103

Earlier quoted context omitted.

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

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/ ("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.

Re: Alan Kay on Lisp

#203

Post by shalabhc »

xfer wrote: post #193
shalabhc wrote: post #189

Earlier quoted context omitted.

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

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

Is it statically typed for cross process messages though?

Re: Alan Kay on Lisp

#204

Post by davexunit »

muxator wrote: post #54
davexunit wrote: post #38

Earlier quoted context omitted.

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.

what are you using? I want to try it.

I use GuixSD https://gnu.org/s/guix

Re: Alan Kay on Lisp

#205

Post by blihp »

kazinator wrote: post #55
blihp wrote: post #51

Earlier quoted context omitted.

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.

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.

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)

Re: Alan Kay on Lisp

#206

Post by scroot »

blihp wrote: post #205
kazinator wrote: post #55

Earlier quoted context omitted.

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.

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)

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.

Re: Alan Kay on Lisp

#207

Post by blihp »

scroot wrote: post #206
blihp wrote: post #205

Earlier quoted context omitted.

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)

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.

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.

Post reply on HN