The Arc Language Forum
arclanguage.org
arclanguage.org
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...
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
[1]: https://legion.stanford.edu/pdfs/cr2017.pdf
[2]: https://legion.stanford.edu/pdfs/parallelizer2019.pdf
Whoah. That's super interesting. Is it still running on Arc?
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.
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.
Okay, here you go: https://news.ycombinator.com/edit?id=30576525
The reason this took four hours is because every time this topic comes up, I get terrified, and I can't bring myself to check HN at all. So I didn't see your request till now.
(The fear is much the same as his: https://www.youtube.com/watch?v=QxTMbIxEj-E&t=16s&ab_channel...)
As I mentioned there, you can contact me via Twitter (https://twitter.com/theshawwn) or by email (shawnpresser@gmail.com).
I recently started using Telegram too. It's pretty nice. (https://t.me/theshawwn)
Otherwise, it looks like there's no way to reach you, so I'll simply say that I hope you have a wonderful week. Take care.
The fact that your fork of the Arc language and HN forum software has the same name means the same autokill applies to it as well. I suppose if you changed the name of the language/software fork to something else, it would no longer be subject to the ban. (I am assuming the intended target of the ban is the website not the language/software which runs it.)
Here it is: https://github.com/laarc/laarc
I put years of work into it.
As I said, this comment is dead: https://i.imgur.com/JmMdQ8i.png
I'm pretty sure this comment can't be vouched, too.
> 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.
Heh. It was intentional. Though if Dan ever reverses the decision, he might try to claim otherwise, since technically the goal was to ban mentions of our HN competitor.
Feel free to DM me on twitter if you want to discuss it further. https://twitter.com/theshawwn