The case was correct, but I misspelled "van" as "von"... how embarassing! Fixed on the website.
2,351 karma · joined August 30, 2011
I'm amazed. Most of the people on here responding as such are, I'm guessing, are people from my generation: "millenials" who grew up natively on the internet, probably even hung out on Slashdot and etc when that was big. Slashdot had a lot of problems (so does this site, not gonna lie) but OMG I can't imagine a post like this appearing on 2005 era Slashdot and 1/3 of the people being like "but why not this probably is a good idea".
I thought when my generation grew up and had kids, we'd try to stand up for digital rights as being important for the next generation, because we experienced why it was important ourselves. I am depressed by just how wrong I was.
This blogpost feels very ironic to me... I know I'm not the first to point it out, that the blogpost's obsession with a feeling of productivity is just way too meta given the blogpost itself, but the point where about 5 self-help resources are all quoted is the point where the whole thing started to feel a bit doomed to me.
I guess that's yet another reason to re-theme my website....
"she didn't mention any of these"... my name is Christine, it's right at the top of the post...
At any rate, most of the approaches you're taking resemble Chicken Scheme's "compile to C" approach, which is all good and well, but doesn't accomplish the (questionable, and the post questions it) quasi-definition of "systems language" I was exploring in the post... it's something that compiles to it, but doesn't have the underlying characteristics of something written directly in it. More in the post I wrote in reply https://news.ycombinator.com/item?id=32058142
Also fun fact: Guile was already a pun on Guy L. Steele, I just finished the pun :)
My post was specifically aiming at talking to the Guile community as in terms of something useful and befitting of that community's use. A "Lisp Flavored Rust" would be interesting if someone wanted to do it though.
- Common Lisp is the only real lisp and anyone who's not using it reinvented it badly? Check.
- Questioning what is "systems programming" and yes I actually already did that in the post itself, it's a large portion of the post's text? Check.
- "It really ought to be in Rust because Rust is awesome?" Check.
The point of this post is, to the Guile community, "This would be an interesting thing for us to explore, here's what I've been loosely thinking about exploring it... what do you think? Anyone else excited to talk about this with me?" (It turns out, within that community: yes.) It's not hating on Common Lisp, it's not saying that existing lisps aren't already "systems languages" (I agreed on that in the post), and no I'm not aiming for this to be Rust because we have Rust and you can use Rust and that's cool!
And the other point of the post is: this is a hilarious name, "Guile Steel"... "Guile" + "Guy L. Steele" + "close to the metal". And also, PreScheme is a pretty cool thing that's been underexplored outside of Scheme48 and hey maybe we should think about whether that's a cool direction we should modernize on!
So anyway, if you feel annoyed because this isn't targeting Your Favorite Thing, that's cool... it isn't! You're super welcome to read the post, just know who the audience is, following the above. :)
Again, this is a tutorial, for newcomers, which happens to include a tree walking interpreter. I think you've pushed the goalpost pretty far back just because a reasonably interesting one was hit at all.
If you read SICP, chapter 4 is basically a long-form introduction to the tree walking interpreter I introduce in the document, and chapter 5 gets into how to write a register VM with the lower level details you describe. However chapter 4 is where the most important unlocks of demystifying how programming languages work. Much design of programming languages in lisp has happened within metacircular evaluators first, and the efficient implementation later. Within a few tweaks, you can change your language to a logic programming language like Prolog, or switch from lexical scoping to dynamic scoping. This is power. And it isn't possible in most other programming languages. SICP was recently ported to Javascript, and it's an amazing conversion, but there's an extra step for parsing the source text which turns it into something that doesn't look like javascript anymore, whereas a lispy evaluator looks just like lisp.
Again, this is a primer. Showing off that you can do such a thing in 30 lines of code is something that few primers which are less than 30 pages would dare to do. It's possible to demonstrate in lisp/scheme partly because of lisp's language choices. And it's hopefully useful: I know when I wrote my first metacircular evaluator at the end of reading The Little Schemer, it demystified programming languages for me in a huge way. I hope a bit of that demystification shows up here for others too.
But in the comments here and as with most articles about Lisp, the conversation moves to... can newcomers understand Lisp's syntax? My spouse and I gave a talk about this very topic: "Lisp but Beautiful; Lisp for Everyone". https://fosdem.org/2022/schedule/event/lispforeveryone/
There's a lot in there (including demonstrations of representations of lisp which don't have parentheses at all). But the biggest point in the talk is that lisp isn't scary for new programmers... it's scary for experienced programmers. As we talk about in the video, my spouse and I co-ran introductions to programming using Racket aimed at humanities students with no required prior programming experience whatsoever.
What we found was that the students who had no prior programming experience, after just a few minutes, had no problem with the syntax (and DrRacket made it easy enough to pick up the language). But we did have complaints in the class about lisp's syntax... from those who already knew how to program. They already had a frame, and within that frame, lisp's syntax looked alien. Without a frame, students just accepted it and did fine with the syntax... great, even. (Many of them praised its clarity; like any decent lisp editor, DrRacket helps identify the kinds of parentheses-oriented errors that users think they're going to encounter.)
Anyway, I do more work in Guile these days than Racket, but both are really great systems with great communities. The thing I miss most about Racket though is that DrRacket gave an easy entry point for students which wasn't "and now start learning Emacs". (Guix is pretty great, however.)
Yes, Goblins' "vat" model descends from E, which supports the "hybrid worldview". http://www.erights.org/
I have a tendency to call Goblins objects "actors", though some people in the community like to point out that "distributed object" is preferable since synchronous call/return is not supported in actors. But yeah.
https://dustycloud.org/blog/sussman-on-ai/
I had some further conversations with Sussman and some other oldschool AI researchers from MIT later, the shortest summary of their comments would be that "We knew that neural nets could do this kind of thing, we didn't have the power to do it yet though. But an artificial intelligence system that can't explain why it's doing what it's doing doesn't seem very intelligent." Sussman and his students' work on propagators provide a very interesting alternative direction where explanations are a key part.
And yes it's true, humans also construct imperfect versions of their own thinking. That's because these systems are combined: the fast gut-feel type neural-network'ish systems and the slower symbolic reasoning systems that are associated with language. And probably the right design combines both of these.
A view into how this might work can be found by first reading Alexey Radul's dissertation on propagators: https://dspace.mit.edu/handle/1721.1/49525
And then on top of that, Leilani Gilpin shows how propagators can be used to analyze neural network systems and create retroactive explanations for decisions that were made: https://groups.csail.mit.edu/mac/users/gjs/lgilpin-PhD-EECS-...
By the way, the "open source version of E" does do distributed garbage collection, but it can't collect cycles across a network barrier. However, the original version of E did collect cycles across the network too: http://erights.org/history/original-e/dgc/
However, you needed hooks into the garbage collector for it to work, since you had to do some introspection of how things were rooted iirc. Mark S. Miller told me that originally they thought this could be fixed because Sun had promised to make Java open source, but they took a damn long time to do it. In the middle period, apparently the E folks said "please! just take this patch... you can have it even!" but Sun didn't merge it.
But Mark also told me that he learned not to push for this, because the cycles-across the network stuff turned out to not be common enough to bother, and you could build distributed acyclic gc using just weakrefs (and weak maps) and gc finalizer hooks, which are much more common than the rooting-introspection stuff.
Not sure if I got all that right, but there you go.
Anyway, I'll fix the tagline for Goblins for next release to make it clearer. Thanks for the feedback.
But here's some more background: I'm co-author/co-editor of the ActivityPub specification, which might give you some idea that I have some experience with trying to build networked systems. Goblins is part of the Spritely project, or even more accurately, the foundation for it: https://spritelyproject.org/
Spritely has some pretty wild ambitions... I won't go into them in detail, the video near the top of the above site explains better. But achieving those in a feasible timeframe means we need some better tooling. Goblins is the foundation of that; it's implemented as a Racket library, but can/will be ported elsewhere. The docs linked above explain some of the core ideas, but honestly I think the video linked from this section of the site explains it better: https://spritelyproject.org/#goblins
In general, people tend to realize that something interesting is happening when they see a cool shiny demo. So here are two pages that might give you an idea with some cool shiny demos:
- Demonstrating "time travel" in a space shooter game (no special code added for this other than exposing it in the GUI): https://dustycloud.org/blog/goblins-time-travel-micropreview... - "goblin-chat", which doesn't look quite as shiny but is interesting more that the code you see above is "end to end encrypted", but is written in a mere 250 lines of code for the whole protocol http://dustycloud.org/blog/spritely-goblins-v0.7-released/
What? How can the last one be only 250 lines of code? (And a mere 300 more for the GUI!) Well, that's because we're implementing a peer-to-peer distributed object programming protocol called CapTP (which includes wild things like distributed garbage collection over the network (for acyclic references), "promise pipelining", and is object capability secure). The next release will be advancing that work significantly. The Agoric organization is also implementing CapTP, but their stuff is in Javascript instead of Racket; we plan to have our CapTPs to converge. Thus it shouldn't really matter whether you write your code in Javascript or Racket, your code should be able to talk to each other.
Anyway, new release coming out soon. Hope that answers some things since the docs page might not convey what's fully interesting about it (and indeed, neither does this text, but the videos mentioned above do a better job).
Goblins already supports distributed (acyclic) GC! And yes ocap security does tie in nicely. In a sense ocaps make this really easy... if you think about an ACL approach the user has to point at the object they have access to and the object has to point back, but since ocaps are based on "having references to objects", in general GC locally can just be the very GC that the native runtime provides. Across runtimes (in the distributed code), distributed GC likewise falls out easier, though the algorithm doesn't know how to handle cycles when Alice on machine A points at Bob on machine B which points at Alice on machine A again. So you have to manually cycle break in those cases, but they're relatively rare.
Amazingly, Electric Communities Habitat had distributed cyclic garbage collection, which just blows my mind: http://erights.org/history/original-e/dgc/
But that requires special cooperation to traverse the object graph held by the runtime's garbage collector, which we don't have access to in Racket (or most languages) unfortunately. It would really be cool to see that tech revived somewhere though.
Hope that answered your question somewhat!
But I think part of the problem is that it's very hard to explain to people in words how something is going to work. In general people better understand from experiences. That's why Spritely is actually taking a demo-centric approach... people understand better from experiences than from being told. I wrote about this more here recently: https://dustycloud.org/blog/if-you-cant-tell-people-anything...
Which is a response to Chip Morningstar's article, "You Can't Tell People Anything": http://habitatchronicles.com/2004/04/you-cant-tell-people-an...
... which has a really interesting quote in it about how baffled people were about the idea of hyperlinks:
> Years ago, before Lucasfilm, I worked for Project Xanadu (the original hypertext project, way before this newfangled World Wide Web thing). One of the things I did was travel around the country trying to evangelize the idea of hypertext. People loved it, but nobody got it. Nobody. We provided lots of explanation. We had pictures. We had scenarios, little stories that told what it would be like. People would ask astonishing questions, like “who’s going to pay to make all those links?” or “why would anyone want to put documents online?” Alas, many things really must be experienced to be understood. We didn’t have much of an experience to deliver to them though — after all, the whole point of all this evangelizing was to get people to give us money to pay for developing the software in the first place! But someone who’s spent even 10 minutes using the Web would never think to ask some of the questions we got asked.
I think that the level of incredulity that we're seeing here is understandable then, in that sense... human beings are better equipped to understand something in retrospect than to think ahead and try to join you in envisioning it. Oh well... as more demos come out (we've already done a few, a couple are shown in the video but not all), maybe people will believe more and more. When it gets in peoples' hands, even more so.
But my point was that when beginning work on ActivityPub as a standard, the kinds of comments on here were similarly negative. Of course you're not going to get a universal social network standard! Nobody's been able to do it, it's just out of reach. Might as well give up now.
Of course, now that ActivityPub has succeeded, people take it as a given that it was going to succeed. Criticism instead moves to certain design decisions, and that's fair and warranted. But hindsight makes those things that have been done seem as if they were always going to be done.
But at a time, it looked like ActivityPub itself, the thing we do have, could not possibly succeed, and people told me as such in many places, especially on here. Nobody questions that it happened now of course. So now I am proposing a multitude of layers in which we can make things better.
But it hasn't happened yet, and so of course the response is going to be, once again, that of course it's not possible...
So, Spritely isn't just an end-user thing because it's multiple layers, though a few of them are end-user layers (it's more of a laboratory for advancing the federated social web). It's true that it isn't a web standard itself, even though it aims to enhance the ecosystem that uses that web standard. But the point is: it's really demoralizing to get these kinds of comments, but they're the most common kinds of comments one gets on HN. Sometimes I did think about giving up on ActivityPub standardization. Ultimately I'm glad now that I didn't. So I think we can do cool and interesting things here with Spritely, and my lesson from the past is to not give up now either.
Now ActivityPub is the most widely adopted federated social network standard on the web ever, with dozens of projects using it, thousands of servers, and millions of users.
I did sometimes feel like giving up when I heard that kind of feedback then, but I'm glad I didn't. I'm not going to give up here either.
The project is ambitious. It's broken into many subprojects so that even if the larger goal doesn't succeed, we might still get a number of useful pieces out of it.
But I've learned not to let comments like this dissuade me. If I had, ActivityPub wouldn't have happened. We might fail, but more likely, we'll have a partial success, which is still useful. And it's worth trying.
And it's true that it doesn't give a definition; presumably at this earlier stage, the people most interested in the website are people who are already interested in some way in the federated social web. The ActivityPub spec is linked to though, so it's not hard to find out more info about it.
(Also, I hope we can get to the point where we dogfood Spritely for Spritely communications, but I think that's ~1-1.5 years out from now.)
In fact, we're in talks with the wonderful folks at Agoric, who are building very similar things in Javascript-land: https://agoric.com/
And we want our two CapTP implementations to be compatible. If we do that, you can have programs written in Scheme/Racket talking to programs written in Javascript just fine.
Hope that makes sense!
So, Spritely's approach to vaporware avoidance is to break things into subprojects and show how we're making progress with demos. If some of the subprojects fail, but the others still exist and are useful independently, that's a big win.
Spritely Goblins is already quite usable, and does quite some interesting things: https://docs.racket-lang.org/goblins/index.html
Even if that's all that succeeds from Spritely (and I don't think it will), I think that's a useful contribution.
But seeing is believing, and skepticism is well warranted. All I can say is, I hope that in two years we can come back to this post and re-evaluate it and see how far Spritely is along. I hope we can prove ourselves. I'm working very hard to do so.