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

171–180 of 207 posts

Re: Alan Kay on Lisp

#171

Post by mpweiher »

mpweiher wrote: post #77
pmoriarty wrote: post #68

Earlier quoted context omitted.

"smalltalk cutest feature is the named parameter syntax trick..." make-range from: 10 to: 20 calss (make-range.from:to 10 20) or something similar. Free nanodsls For the uninitiated among us, what does that do and what's so magic about it?

So the example would be: 1 to: 10. Sends the "to:" message to the number 1 with the parameter 10. Returns a range representing the numbers from 1 to 10. You can then iterate that range with by sending it the "do:" message with a block argument. 1 to: 10 do:[ :i | ]. And so on. Looks a lot like syntax for a for-loop, but is just message sends to collections with keyword syntax. Every type of collection implements do:…

Found the paper on generalized method names in Grace:

From APIs to languages: generalising method names

https://dl.acm.org/citation.cfm?doid=2936313.2816708

pdf: https://michael.homer.nz/Publications/DLS2015/paper.pdf

morning paper: https://blog.acolyer.org/2015/11/09/from-apis-to-languages-g...

Re: Alan Kay on Lisp

#172

Post by masklinn »

astrobe_ wrote: post #154
masklinn wrote: post #149

Earlier quoted context omitted.

Sorry to "well actually" you, but 1 to: 10 do:[ :i | ]. would be a single message `to:do:`, not a chain of messages.

well actually-actually :-), (1 to: 10) do: [ :i | Transcript show: i ; cr]. also works in Pharo. Both are valid because: "to:do:" is a message understood by the Number class "to:" is a message also understood by the Number class that yields an Interval object, which understands the "do:" message.

> well actually-actually :-),

I didn't say you could not build a message chain to do that, only that to:do: as shown in mpweiher's original comment is a single message ;)

Re: Alan Kay on Lisp

#173

Post by eropple »

Mikeb85 wrote: post #126
eropple wrote: post #92

Earlier quoted context omitted.

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?

> How is Haskell a Lisp? The same way Lisp is a functional language. It has to do with how both languages are built from only a few basic primitives, and how both are based on Lambda calculus.

An ML is also not a Lisp, though.

Re: Alan Kay on Lisp

#174

Post by astrobe_ »

masklinn wrote: post #172
astrobe_ wrote: post #154

Earlier quoted context omitted.

well actually-actually :-), (1 to: 10) do: [ :i | Transcript show: i ; cr]. also works in Pharo. Both are valid because: "to:do:" is a message understood by the Number class "to:" is a message also understood by the Number class that yields an Interval object, which understands the "do:" message.

> well actually-actually :-), I didn't say you could not build a message chain to do that, only that to:do: as shown in mpweiher's original comment is a single message ;)

Yeah. My reply was more meant to show off more Smalltalk to pmoriarty and others that to one-up everyone :-)

Re: Alan Kay on Lisp

#175

Post by kbp »

SolarNet wrote: post #98
pmoriarty wrote: post #68

Earlier quoted context omitted.

"smalltalk cutest feature is the named parameter syntax trick..." make-range from: 10 to: 20 calss (make-range.from:to 10 20) or something similar. Free nanodsls For the uninitiated among us, what does that do and what's so magic about it?

It's keywords as sentences. It basically allows a function signature to be spelled out as a sentence with infix operators. These days you can see the lineage of smalltalk in keyword arguments. For example, python vs. smalltalk: obj.do_thing("string", with_factor=8, log_to=logger) obj do_thing: "string" with_factor: 8 log_to: logger One of those reads as a sentence a little better. But to be fair python learned this f…

In Smalltalk, the 'keywords' are actually part of the method name; when you say '1 to: 10 do: [ ... ]', you're not calling to: on 1 (which is an entirely different method) with a keyword argument, you're calling to:do:.

> This shared syntax makes the language read better. It makes function calls and keywords look like a normal infix language (e.g. the math expressions in most languages).

Ironically, since Smalltalk also applies this uniformity to arithmetic operators, they don't behave how most people would expect: a + b * c - d is executed like (((a + b) * c) - d).

Re: Alan Kay on Lisp

#176

Post by SolarNet »

kbp wrote: post #175
SolarNet wrote: post #98

Earlier quoted context omitted.

It's keywords as sentences. It basically allows a function signature to be spelled out as a sentence with infix operators. These days you can see the lineage of smalltalk in keyword arguments. For example, python vs. smalltalk: obj.do_thing("string", with_factor=8, log_to=logger) obj do_thing: "string" with_factor: 8 log_to: logger One of those reads as a sentence a little better. But to be fair python learned this f…

In Smalltalk, the 'keywords' are actually part of the method name; when you say '1 to: 10 do: [ ... ]', you're not calling to: on 1 (which is an entirely different method) with a keyword argument, you're calling to:do:. > This shared syntax makes the language read better. It makes function calls and keywords look like a normal infix language (e.g. the math expressions in most languages). Ironically, since Smalltalk a…

Yea I was eliding some points to try and explain it better.

Re: Alan Kay on Lisp

#177

Post by [deleted] »

merlincorey wrote: post #84
jcrites wrote: post #76

Earlier quoted context omitted.

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…

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.

[deleted]

Re: Alan Kay on Lisp

#178

Post by loup-vaillant »

gnulinux wrote: post #136
Silfen wrote: post #89

Earlier quoted context omitted.

"Compile time" is artificial, but the difference between static and dynamic is natural (in some sense, I realize these words are quite slippery). It emerges from the underlying mathematics. There's a real difference between correctness properties that I can prove without running my program and correctness properties that will introduce failures at runtime.

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 for which you can't prove the property holds (you will reject correct programs), or accept programs for which you can't prove it doesn't (you will accept incorrect programs, and may use runtime checks to compensate).

Rejecting correct programs is a problem only to the extent one would like to write such a program in the first place. Take this expression for instance:

  if 2 + 2 = 4
  then "Yay!"
  else 0
It is a perfectly fine expression, of type `string`. Most type systems will reject it however because the two branches of the conditional don't have the same type. Thing is, we don't care about this program in practice, since the constant test expression screams code smell to begin with.

Re: Alan Kay on Lisp

#179

Post by coldtea »

erikpukinskis wrote: post #90
coldtea wrote: post #17

Earlier quoted context omitted.

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

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.

Re: Alan Kay on Lisp

#180

Post by igouy »

rahoulb wrote: post #143
igouy wrote: post #113

Earlier quoted context omitted.

> by making all the parameter names mandatory For example?

In smalltalk the parameter names aren't mandatory in the sense of many other languages. They are actually part of the method name. So robot put: thing in: container. And robot put: thing on: shelf. Are two separate messages that are both understood by the robot instance - "put: in:" vs "put: on:"

I asked hota_mazi to provide an example which demonstrated what they were talking about, to explain why they said "Smalltalk got it wrong by making all the parameter names mandatory".

Are you hota_mazi ?

Post reply on HN