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

111–120 of 207 posts

Re: Alan Kay on Lisp

#111

Post by julian_1 »

pmoriarty wrote: post #70
ohazi wrote: post #29

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

"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." You probably meant to contrast ML's static typing (not strong typing) with Lisps's dynamic typing. See "What To Know Before Debating Type Systems" : https://cdsm…

For another (type-theory) perspective - a 'dynamic language' can be automatically considered weakly typed if it can return an runtime exception due a failure to perform a runtime type coercion, or because the typesystem is not expressive enough to include a proof of totality. That makes the whole dynamic/static versus strong/weak distinction kind of meaningless.

> The functional and imperative languages are weakly typed, i.e. the result of computing the value of an expression e of type T is one of the following: [...]

http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceMa...

As a matter ordinary meaning, I also feel it makes sense to talk about more strongly typed languages, because they can express 'stronger' guarantees about behavior. Eg. a proof that the code cannot deadlock.

Re: Alan Kay on Lisp

#112

Post by mquander »

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…

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.

Re: Alan Kay on Lisp

#113

Post by igouy »

hota_mazi wrote: post #81
agumonkey wrote: post #56

Earlier quoted context omitted.

smalltalk cutest feature is the named parameter syntax trick (I don't like tricks but let's make an exception). make-range from: 10 to: 20 calss (make-range.from:to 10 20) or something similar. Free nanodsls smalltalk simplicity lies in that the metamodel is actually human reasoning friendly, even while dynamic, you have a clear picture of what's gonna happen in case of errors etc. It didn't please visual age users,…

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

Re: Alan Kay on Lisp

#114

Post by spc476 »

Cybiote wrote: post #32
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…

I disagree. I found his meaning clear. The core of the essay is that thinking with the right abstractions provides greater boons to reasoning capacity than comparatively trivial differences in human IQ. To make things a bit more concrete, take any game; Go, Poker, Chess. If these were truly (approached as) combinatorial problems then humans could not stand a chance at them. But over time, people have learned patterns…

Godel's Incompleteness Theory states that within an axiomatic system, there are statements that are true that you can't prove true. You can only prove them true if you go up a level.

In programming (assuming a "computer language" as an analog to "axiomatic system"), there are abstractions that cannot be implemented. You can only implement them by going up a level.

In LISP, you have this "going up a level" ability with macros. The only reason this works for LISP is that the language is written in terms of data LISP can manipulate, meaning you can manipulate code at compile time. Forth has an ability to "go up a level" as well, with a defined way to extend the compiler.

Re: Alan Kay on Lisp

#115

Post by dang »

mjburgess wrote: post #106
dang wrote: post #100

Earlier quoted context omitted.

This crosses into incivility. That breaks the site guidelines. Please re-read them and don't do that when commenting here. https://news.ycombinator.com/newsguidelines.html

I'm not sure how this is incivil? The claim is logically incoherent: typing cannot be a property of the internet, in the same way tuesday cannot be pink nor can addition sound terrifying. The claim is a category error: the internet cannot posses such a property. In addition, to say, of something, that it is " is a made up thing " is a degree of hubris that is presumably reasonably met by being perplexed at overconfid…

"What on earth are you talking about" is uncivil. Your comment didn't need that.

Actually you broke this guideline as well: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize." It's possible that shalabhc intended to make a mathematical claim, but a stronger plausible interpretation is easy to come up with (e.g. "it's hard to enforce static guarantees across the software that interoperates on the internet").

The reason we ask people to follow this guideline is not so much that it's nicer, but that nitpicking things each other probably didn't say is tedious and detracts from good conversation, which is what we're really hoping for.

Re: Alan Kay on Lisp

#116

Post by hxegon »

spc476 wrote: post #114
Cybiote wrote: post #32

Earlier quoted context omitted.

I disagree. I found his meaning clear. The core of the essay is that thinking with the right abstractions provides greater boons to reasoning capacity than comparatively trivial differences in human IQ. To make things a bit more concrete, take any game; Go, Poker, Chess. If these were truly (approached as) combinatorial problems then humans could not stand a chance at them. But over time, people have learned patterns…

Godel's Incompleteness Theory states that within an axiomatic system, there are statements that are true that you can't prove true. You can only prove them true if you go up a level. In programming (assuming a "computer language" as an analog to "axiomatic system"), there are abstractions that cannot be implemented. You can only implement them by going up a level. In LISP, you have this "going up a level" ability wit…

Wow. That's a really interesting way of explaining macros.

Re: Alan Kay on Lisp

#117

Post by andai »

hxegon wrote: post #116
spc476 wrote: post #114

Earlier quoted context omitted.

Godel's Incompleteness Theory states that within an axiomatic system, there are statements that are true that you can't prove true. You can only prove them true if you go up a level. In programming (assuming a "computer language" as an analog to "axiomatic system"), there are abstractions that cannot be implemented. You can only implement them by going up a level. In LISP, you have this "going up a level" ability wit…

Wow. That's a really interesting way of explaining macros.

I wonder if LISP and LSD encourage similar ways of thinking.

Re: Alan Kay on Lisp

#118

Post by physicsyogi »

spc476 wrote: post #114
Cybiote wrote: post #32

Earlier quoted context omitted.

I disagree. I found his meaning clear. The core of the essay is that thinking with the right abstractions provides greater boons to reasoning capacity than comparatively trivial differences in human IQ. To make things a bit more concrete, take any game; Go, Poker, Chess. If these were truly (approached as) combinatorial problems then humans could not stand a chance at them. But over time, people have learned patterns…

Godel's Incompleteness Theory states that within an axiomatic system, there are statements that are true that you can't prove true. You can only prove them true if you go up a level. In programming (assuming a "computer language" as an analog to "axiomatic system"), there are abstractions that cannot be implemented. You can only implement them by going up a level. In LISP, you have this "going up a level" ability wit…

I’ve been using Clojure off and on for a few years but skipped learning about macros because I haven’t (yet) needed to write my own. Your comment makes me regret that decision.

Re: Alan Kay on Lisp

#119

Post by ScottBurson »

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…

Right. There's still syntax, but instead of that syntax being defined directly in terms of characters and tokens, it's defined in terms of s-expressions. Thus s-expressions serve as an intermediate syntactic level between tokens and forms. (Forms are what other languages call expressions and/or statements.)

Re: Alan Kay on Lisp

#120

Post by Retra »

spc476 wrote: post #114
Cybiote wrote: post #32

Earlier quoted context omitted.

I disagree. I found his meaning clear. The core of the essay is that thinking with the right abstractions provides greater boons to reasoning capacity than comparatively trivial differences in human IQ. To make things a bit more concrete, take any game; Go, Poker, Chess. If these were truly (approached as) combinatorial problems then humans could not stand a chance at them. But over time, people have learned patterns…

Godel's Incompleteness Theory states that within an axiomatic system, there are statements that are true that you can't prove true. You can only prove them true if you go up a level. In programming (assuming a "computer language" as an analog to "axiomatic system"), there are abstractions that cannot be implemented. You can only implement them by going up a level. In LISP, you have this "going up a level" ability wit…

LISP macros are formalized in LISP. You don't "go up a level" by using them. You go up a level by going into the human brain and thinking about your code in a way the computer doesn't.
Post reply on HN