7 ms·
I remember reading about Arc forever ago. I thought it never went anywhere. A quick look at the tutorial and it isn't clear how it deviates from vanilla lisp/
by timmg 5y ago
I remember reading about Arc forever ago. I thought it never went anywhere. A quick look at the tutorial and it isn't clear how it deviates from vanilla lisp/scheme. (I kinda expected a description of how it is different on the first page of the site.)
- gaetgu 5y agoI don't think it deviates much (if at all) from common lisp, except that it has BIFs for web development. Hacker News was created using arc, as was the arc forum.
- timmg 5y ago> Hacker News was created using arc, as was the arc forum. Whoah. That's super interesting. Is it still running on Arc?
- sillysaurusx 5y agoYes.
- gaetgu 5y agoAs far as I know, yes. I think (though I am not sure) that hacker news was a sort of test for the arc language.
- dang 5y agohttps://news.ycombinator.com/item?id=23483715 https://news.ycombinator.com/item?id=23483715
- skissane 5y agoI really wish you'd do another open source release of the HN software. I know there are various bits you want to keep secret (such as aspects of the voting algorithm, voting ring detection, etc), but you could refactor the code into a "private" module containing those secret bits, and release the rest of the code along with a dummy implementation of the private module. And I also realise you may not have enough time/resources to do that, but I hope some day you will find them. I think it would really help Arc as a language – nowadays, one of the things a language really needs to be successful, is some significant open source applications/packages written in it – I know Arc already comes with an older version of the HN app, but it would really benefit from having the real latest version (or as close to that as is possible).
- sillysaurusx 5y agoNever going to happen. There's zero time to do any of that while running HN. pg barely was able to do it, and he cared a lot about whether the world wanted to use arc. > it would really benefit from having the real latest version (or as close to that as is possible). I independently implemented almost every feature in HN. But it exists in a repository that gets autokilled whenever I link to it here, so, that's about par for arc's progress in modern times. Took so much work to get all the features done. Even implemented Dan's thread-local state ideas. Never gonna see the light of day. The fact is, Arc's progress stopped with pg. It's best to accept that and move on. It's tempting to think you need the latest in order to understand arc's power. But take it from a decade-long arc veteran: that's not true. All you need is to tug at the question, "why did pg do it this way? out of all possible ways, why this?" And then realize that HN today could not have happened if pg had done it any other way. If you care enough about this question, you'll come to respect arc. Especially what was left out, as much as what was implemented. Less is more. Over the years I've implemented at least 5 different flavors of arc, including a fusion of lumen and arc, both on lumen (javascript-based) and in arc (racket-based). I always come back to vanilla arc and vanilla lumen as starting points. And there's a reason for that. The more you add, the more you lose. The flexibility is the power, and the flexibility is a result of arc's smallness. By the way, pg did exactly what you said, in the original release of arc. If you grep the codebase for "defhook", those are all the spots where the secret code was refactored out.
- skissane 5y ago> Never going to happen. There's zero time to do any of that while running HN. What if someone volunteered to do it? I assume it would have to be someone whom dang/YC/etc knew and trusted, since they'd learn the "secret sauce" in the process. I don't know if any such person exists right now, but even if they don't, maybe they will in the future (neither motivation nor trust are static quantities.) > But it exists in a repository that gets autokilled whenever I link to it here, Strange. How about you put the link in a reply to this comment, and we'll see if it "gets autokilled" (tagged dead). I'm assuming that if that is happening, it is some kind of false positive, not an intentional moderator decision – in which case, someone should be able to vouch your comment and undead it. > By the way, pg did exactly what you said, in the original release of arc. If you grep the codebase for "defhook", those are all the spots where the secret code was refactored out. I get the impression it hasn't been kept so clean in the current codebase – because I've heard the work involved in separating the secret bits from the public bits is the main reason there hasn't been another public source release. If the current code base kept the secret and public bits clearly separated, then that justification doesn't make any sense.
- math-dev 5y agoThat means Arc is more successful than most lisps
- deleted 5y ago[deleted]
- eslaught 5y agoArc has a very nice implementation that is bootstrapped from an impressively small number of primitives, is easy to understand, and very hackable. It was the first language implemention that I was really able to wrap my head around and modify in useful ways, as someone who (at the time) had no formal training in programming languages. The language itself has a focus on short names. Besides that and a few minor innovations, there really isn't much to it. I think pg considered this a feature (if Lisp is a good idea, you can't expect one to be that different from another). However, having gotten a PhD in programming languages since I messed with Arc, I can't say this is something I agree with...
- dataangel 5y agoWhat did you learn in your PhD that changed your mind?
- mettamage 5y agoSeconding this question.
- eslaught 5y agoComing back to this a bit late, so I'm not sure who will read this, but here goes. Arc tries very hard to be a minimal language. This is good for the implementation (which is short, and therefore easy to read and hack). It was also an expression of pg's thinking about language power, which if I recall he defined as how concise programs in the language can be. The intuition being that a minimal language would naturally be powerful because finding the smallest set of primitives to define the language itself forces them to be orthogonal and expressive enough that you can build anything else on top of that. But I'm not sure this is true; instead I think what actually seems to have happened with Arc is that pg retreaded much of the same ground that Lisp had already covered, just with shorter names and some minor syntax sugar. In short, for a PL PhD, not very interesting. In general I'd say during my PhD I learned that there's a non-trivial tradeoff between minimality, expressiveness, and static analysis (which is related to both safety (via type systems) and performance (via compiler optimizations)). The static analysis problem for nearly any non-trivial property is very hard in most general purpose languages. In fact it's so hard that we've basically given up trying to do aggressive static analyses (for things like whole-program parallel and distributed code generation). And yet, if you're willing to introduce non-minimal features, it turns out that some of these problems are actually tractable. Here are some examples of the sort of thing I'm talking about from my own work: [0][1][2][3]. I'd also add that some of the things I thought were great about Lisps have actually been replicated in more syntax-ful languages (e.g., Terra [4] has metaprogramming with very similar power to Lisp, and also many advantages I haven't seen in any Lisp implementation). And meanwhile, some things that Lisps have traditionally included, like a self-contained, owns-the-world, garbage collected implementation, aren't necessarily all they're cracked up to be, as we've seen with e.g., Rust's approach to safety and performance without a GC. So in general, I think we've seen a lot of interesting developments in the PL world in the last 10-ish years, and most of them have not come from the Lisp community. [0]: https://legion.stanford.edu/pdfs/dpl2016.pdf https://legion.stanford.edu/pdfs/dpl2016.pdf [1]: https://legion.stanford.edu/pdfs/cr2017.pdf https://legion.stanford.edu/pdfs/cr2017.pdf [2]: https://legion.stanford.edu/pdfs/parallelizer2019.pdf https://legion.stanford.edu/pdfs/parallelizer2019.pdf [3]: https://legion.stanford.edu/pdfs/idx2021.pdf https://legion.stanford.edu/pdfs/idx2021.pdf [4]: https://terralang.org/ https://terralang.org/