Alan Kay on Lisp • Hacker News Board

Re: Alan Kay on Lisp

#81

Post by hota_mazi » Fri, Oct 27, 2017, 9:50 PM UTC

agumonkey wrote: post #56

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…

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.

Re: Alan Kay on Lisp

#82

Post by lomnakkus » Fri, Oct 27, 2017, 9:50 PM UTC

pmoriarty wrote: post #75

conistonwater wrote: post #52

Earlier quoted context omitted.

> ML has metaprogramming? The only thing I know approaching that is template haskell, which is a weak form of metaprogramming (still powerful obviously). Of course, it has had it for a very long time (a decade at least?), see camlp4/camlp5.

How often is camlp4/5 used among the typical OCaml programmer compared to how often macros are used among typical Lisp programmers? How easy is camlp4/5 metaprogramming to read and write compared to Lisp macros? This reminds me of Alan Perlis' admonition to "beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." [1] and of a question John McCarthy asked Peter Norvig after the l…

> How easy is camlp4/5 metaprogramming to read and write compared to Lisp macros?

Having implemented a non-trivial 'macro' in camlp4 and likewise in Scheme, I can confidently say: It's about the same level of difficult/pain. Which is to say that it's much too painful/annoying.

Though, I should say that Racket by all accounts from the literature has improved things massively, even going to so far as to implement "macro-based" type systems (search for "turnstile racket").

EDIT: Just a side point, but:

    A witty saying proves nothing
       - Voltaire

(No idea if Voltaire ever said that, but that's kind of the point.)

Re: Alan Kay on Lisp

#83

Post by mpweiher » Fri, Oct 27, 2017, 9:52 PM UTC

mathieuh wrote: post #78

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?

You can put the parameter names in method calls, which makes for much more readable code. Like a makeRange method may take parameters `from` and `to`, when calling this method you could do `makeRange(from: 0, to:10)`. That’s a fairly trivial example but it demonstrates how readability is improved. You can imagine how this becomes even more useful with methods that take many parameters. An interesting document to look…

> makeRange(from: 0, to:10) [..] Swift’s guidelines on naming methods.

The syntax you show is Swift, which is a weird mash-up of C/C++ style function call/method call syntax with keywords jammed into them. To me, actual Smalltalk syntax is just so much cleaner:

   0 to: 10.

It manages the "reads like english" trick without trying to be english-like or natural-language-like. (See Applescript for the disaster that results from that: "Many of the current problems in AppleScript can be traced to the use of syntax based on natural language" http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf).

Re: Alan Kay on Lisp

#84

Post by merlincorey » Fri, Oct 27, 2017, 9:56 PM UTC

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…

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.

Re: Alan Kay on Lisp

#85

Post by Mikeb85 » Fri, Oct 27, 2017, 10:14 PM UTC

tomjakubowski wrote: post #46

krapp wrote: post #42

Earlier quoted context omitted.

And it's not a Lisp per se, but WebAssembly's text format uses s-expressions[0]. It's likely that the "oddity" of Lisps will seem less odd as adoption increases if they stick with that. [0] https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...

gcc’s IR, “GIMPLE”, is also commonly printed in s-expression form.

As is LLVM's. I think JVM's might be too, but not 100% sure.

Haskell is also pretty much just a lisp with a whole lot of sugar added on.

Re: Alan Kay on Lisp

#86

Post by lobster_johnson » Fri, Oct 27, 2017, 10:15 PM UTC

hota_mazi wrote: post #80

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…

Isn't Objective C exactly that, a C family language with a Smalltalk inspired syntax?

ObjC is a completely backwards-compatible superset of C that bolts a Smalltalk-like syntax on top. The first implementation was a preprocessor that emitted C, as far as I remember, until first-class compiler support arrived (GCC and Clang have native support).

Re: Alan Kay on Lisp

#87

Post by shalabhc » Fri, Oct 27, 2017, 10:17 PM UTC

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…

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

The internet is dynamically typed. I just don't see static verification scaling to that level. But verification is still great - so maybe we need a way to verify connections between components as and when they bind. If we build a good model for this late bound 'negotiated safe' binding, the static model might become unnecessary (because you can do the verification whenever you choose, or at multiple times and different scales, as the 'bundle of code' integrates with larger and larger systems.)

Re: Alan Kay on Lisp

#88

Post by jcrites » Fri, Oct 27, 2017, 10:25 PM UTC

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.

The notation uses S-expressions, that’s true, but the point that I was trying to make is that you can’t understand anything about the meaning of those S-expressions without parsing them in a context-aware way.

It’s not as if there is just one form `( ... )` where the expression means invoking `op` with some arguments.

A human or machine interpreting the code needs to be aware of these forms and the meaning/semantics of each one. Consider the following S-exps:

    (if a b)
    (set! a b)
    (define a b)

They’re all three-term S-expressions, but you can’t understand their meaning without contextually interpreting the first term. There is a second layer of contextual syntax. Similarly:

    ((lambda (x y) (list y x)) 1 2)

Consider the term `(x y)` in that expression. Without context, it looks like a call to the procedure `x` with `y` as input. With context, it’s a list of argument names for the lambda function.

In languages like C# and Java there is just one meaning of:

    f(a, b);

You know this is actually a procedure invocation with some arguments.

There are trade offs to each approach. I’m not saying that one is better, just that there’s more to Scheme syntax than S-exps. Concatenative languages like Forth and Factor have even less syntax than Scheme.

Re: Alan Kay on Lisp

#89

Post by Silfen » Fri, Oct 27, 2017, 10:28 PM UTC

shalabhc wrote: post #87

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…

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

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

Re: Alan Kay on Lisp

#90

Post by erikpukinskis » Fri, Oct 27, 2017, 10:29 PM UTC

coldtea wrote: post #17

kazinator wrote: post #4

I disagree with the "single ... language" right off the bat before any deeper considerations. Lisp is a great collection of design patterns for making languages. > The key was not so much “Lisp” but the kinds of thinking that this kind of representational approach allowed and opened up regarding all kinds of programming language schemes. > A fun thing about it this is that once you’ve grokked it, you can think right…

> 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 tools in first class language structures, not only do we have to learn 15 different “languages” but we have to wait for each author of each tool to go through all of the stages of programming language design theory. We watch webpack.config.js slowly morph into a poorly designed Haskell, and again and again.

But here’s where you expect me to descend into the classic graybeard “if only these kids would write everything in Lisp and make use of the Great Works of Academic Software” style speech.

No...

Quite the opposite.

I think both camps are wasting their lives. The graybeards are blowing smoke up their own asses about how useful their meta-control structures are, and 97% of those Great Works could be implemented with an isomorphic interface made entirely of functions and literals. The trouble is any person with a masters degree who smells an opportunity to do metaprogramming gets a raging hard on that clouds their judgement until the coding is completed and has a cute name announced on a mailing list. That’s certainly what felt like the glamorous lifestyle to me growing up in the web development world.

But then the Modern coder, using layer upon layer of frameworks and “tools” on a thousand different run times, “getting the job done” and remarking how ergonomic the latest tool is and how much nicer things were than back in the nasty era where you had to write everything from scratch and there were no standards and no consistency... well their codebases, brittle, and calcified by the demands of their customers, are condemned to corrode and become unworkable as declarative control structures rise and fall. Because each piece of the metaprogramming logic is a completely different language, the interfaces between components can’t move as fluidly as a simple function signature, written in the same language your application is written in.

So who cares if it’s Lisp or PHP. Kotlin. Lua. Whatever it is, stop using fancy control structures to prove how smart you are. And stop using fake programming languages that operate as command line parameters or config file grammars, or “Controllers” that magically pick up attributes you sprinkle about.

Then we’ll really find out what Lisp can do.