Can you please explain to me what a "non-lambda interpreter" is and why it matters?
Can you please explain to me what a "non-lambda interpreter" is and why it matters?
It matters because gensyms suck. More generally, if you are building a two-layered system in which a compiler targets the interpreter, symbols, functions, and scopes are concepts that belong in the high-level language, not the low-level interpreter. (I think Shen is one example of a typed Lisp that targets an untyped Lisp, but obviously I know nothing about Lisp.)
So the lambda calculus is a classic layer violation.
Where I went to school in operating systems, which was Brown and Berkeley, we were taught to avoid layer violations and always separate mechanism from policy. Not sure what Lisp people are or were taught -- honestly, there were not a lot of them left, even in the '90s -- but it never seemed to include this.
I always look at a stateful Lisp machine, or Emacs, or whatever, and see a giant structureless blob of symbols. That said, this is probably a totally unjustified prejudice on my part, and at this point I really have no excuse except lack of time for refusing to learn more.
> It matters because gensyms suck.
That makes no sense. The lambda calculus has nothing to do with symbols. Lisp introduced the concept of symbols, but Lisp and the Lambda Calculus are not the same thing.
> obviously I know nothing about Lisp
That is indeed becoming rather obvious.
For example, given "λx.x+1" then "(λx.x+1)(z) => z+1". This reduction process is formally defined by the beta reduction rule, which says that "(λx.t)s" evaluates to "t[x:=s]".
"t[x:=s]" means "substitute the value s for the symbol x in expression t". E.g., x+1[x:=5] => 5+1
https://en.m.wikipedia.org/wiki/Lambda_calculus#Beta_reducti...
If by symbol you mean something different than variable, then I might agree, but the heart of lambda calculus is the rule set for lambda abstraction, application, beta reduction. Due to alpha equivalence you could say that lambda calculus is agnostic to symbols however. I suppose it depends on what you mean. (Lambda calculus is defined in terms of capture avoiding substitutions.)
Well, the real question is what Curtis means by symbol, as the answer he gave is rather cryptic. But since he specifically raised the issue of "gensyms", that seems to be a reference to a standard Lisp function that generates symbols, a first-class Lisp data structure, at run-time or, more usually, at macro-expansion time. Since Curtis has complained about macros in the past, I assumed this was what he was referring to. "Symbols" that exist only in the textual representation of the language and not as first-class data types are usually called "identifiers" rather than symbols precisely to avoid this sort of confusion.
In any case, it is an elementary exercise to define a formal computational system equivalent to the lambda calculus that uses integers rather than identifiers. Instead of λx.x you write λn where n is an integer. 0 refers to the value bound by the innermost scope, 1 to the value bound by the next outer scope, and so on. So, for example, λx.λy.x becomes λλ1. But of course, no one does this because it's completely pointless.
As you may remember, I'm really not the person to answer that question sufficiently. But I would like to see you and Curtis have this out at greater length.
Sorry, I didn't recognize your handle. (And just for the record, I wasn't trying to start an argument, just asking a question.)
> it's my fault
OK ;-)
> I'm really not the person to answer that question sufficiently.
OK.
> But I would like to see you and Curtis have this out at greater length.
Well, we're already having something out in another branch of this thread (https://news.ycombinator.com/item?id=11819810). But it's rather hard to get a straight answer out of him. He has this weird theory that the only way to avoid being sucked into the Lisp Failure Vortex is to not learn Lisp. But at the same time he professes his intentional ignorance of Lisp he also takes these weird pot-shots at it. That is, alas, not a good foundation for a constructive discussion, which is why I was hoping (and continue to hope) that you (or someone) might be able to explain it to me.
No problem. Just, you know, hi! I'm actually happy to pick this thread up. I remember really enjoying the last discussion.
As (I think) we discussed last time I basically have two views:
- Urbit actually works. Like, I actually build stuff on top of it. That's really the layer I'm most interested in. If it were built in Lisp, well, I probably wouldn't know the difference. I'm not sure I'm able to understand the implicit criticism at the user level.
- Shaking off the cruft of existing systems is actually pretty hard. I don't have as much experience with this as a programmer as Curtis does, but it's a problem near and dear to me. It's very difficult to think clearly inside of someone else's intellectual framework. So, maybe Hoon looks like a bad Lisp variant today. What does it look like in 50 years? Maybe it's dead, maybe it's everywhere. I'm not sure we can actually make this judgement for certain. That is: whether Nock / Hoon is definitively better or worse in terms of its long-term adoption and performance.
What Nock does seem to unlock is incredible amount of enthusiasm. The feeling of disillusionment can easily be converted into excitement. I've seen this done by Urbit — and that's pretty difficult to do. My intuition is that Lisp suffers from the opposite: the feeling that breaking from its history is impossible.
Either way I'm serious about getting you two to have this out in some kind of organized way. Ideally, on Urbit somehow.
Very happy to hear that.
> I'm not sure I'm able to understand the implicit criticism at the user level.
Let me make the criticism explicit then: inventing a new language is not hard. People do it all the time. It's an elementary exercise. However, inventing a good new language, i.e. one that actually advances the state of the art and provides a substantial advantage over existing languages -- that is very hard. That happens very rarely, probably less than a dozen times in the history of computing.
Although I have never heard Curtis say so explicitly, the rhetoric surrounding Urbit strongly implies that Nock and Hoon are languages of the second sort, that is, that they provide some benefit that existing languages lack, and without which developing Urbit would be substantially more difficult or even impossible. My question for the last four years has been: what is that benefit? Do Nock and Hoon really advance the state of the art in programming language design, or is their sole purpose to be the Shiny New Thing that gets people excited? Because if it's the latter, that does not bode well for Urbit's long-term prospects. Nothing gets to be the Shiny New Thing forever.
> It's very difficult to think clearly inside of someone else's intellectual framework.
That may be true, but do you not see the irony here? You didn't invent Nock/Hoon, Curtis did. So if you are thinking clearly, then you are doing it in someone else's intellectual framework, precisely the thing you say is very difficult.
> What Nock does seem to unlock is incredible amount of enthusiasm.
That I don't doubt. Curtis is a master marketeer. But Donald Trump is unlocking an incredible amount of enthusiasm too. Just because a lot of people get enthusiastic about something doesn't necessarily mean it's a good idea.
The last time anyone built a computer that was typed all the way down to the hardware was (ironically) Lisp machines.