HN Explorer

Ask HN: What happened to PG's Arc and Bel?

4 points by azhenley ↗ HN
I've had an interest in PG's Arc and Bel languages (see [1, 2]) for a while. But the Arc forum [3] hasn't had a post in 107 days. On the other hand, Bel was only announced [4] less than a year ago.

Whatever came of Bel? Nothing has been released about it since. All I can find is one hobbyist implementation [5] based on the few details released.

[1] http://paulgraham.com/arc.html

[2] http://paulgraham.com/bel.html

[3] http://arclanguage.org/forum

[4] https://news.ycombinator.com/item?id=21231208

[5] https://github.com/jeremyschlatter/chime/

4 comments

[ 3.3 ms ] story [ 21.3 ms ] thread
sevensor
Last I heard, HN itself runs on Arc. From what I can see, Bel is more a kind of art project than a language for writing other things in. PG evidently has some ideas about what the most timeless, eternal version of Lisp would look like. Both languages are sketches of the Platonic Lisp he has in his head.
PaulHoule
I think 'arc' and 'bel' are maybe 30 years too late.

By 1990 Common LISP had a lot of momentum but LISPers on the ground were about as excited in Common LISP as programmers were interested in programming in Ada. The "cool kids" back then were inventing their own LISP dialects such as Emacs LISP, Scheme, etc. LISP had lost the 1980s to Microsoft BASIC and it would have been easily to conclude that "bloat" was to blame, and with the 32-bit age just starting to open, Common LISP was well planned but lacking a constituency.

It's almost impossible for 1980's language to look bloated in 2020 and now the "cool kids" who want to use LISP for the use value gravitate to Common LISP and secondarily the Schemes, Clojures, etc.

In 2020 if you were interested in programming languages for their own sake I would point you towards FORTH (e.g. not at all bloated) or towards something post-LISP. Say a language with LISP's internal data structures but with a PEG parser deeply integrated with the runtime. (e.g. write a parser for a random query language in less than two hours, write code that manipulates the parse trees, get the 'unparser' for free)

Sometimes I think the faculty at MIT had a grudge against Noam Chomsky for inventing modern computer languages (transformational grammar is great for that, acceptable for 'stand up in front of a bunch of language-using animals and give a talk about how their language works that the animals might get something out of', and not useful at all for artificial understanding of natural language) and opposing the Vietnam War, DARPA, JASONs, thus most of the research funding at the CS department.

masak
So, I've been thinking about this comment a lot over the weekend.

It is interesting to consider a "cool kids" demographic, of developers who stray far enough outside of the mainstream to find small but worthy languages. These would include Scala, Haskell, Kotlin, Clojure, Racket, and Rust. (Plus anyone's favorite non-mainstream language, which I in my haste totally forgot!)

Earlier this year I found that, at a rough approximation, language mind-share in 2020 consists of 25% Java, 25% JavaScript, 25% Python, and 25% everything else. (My source for that is https://www.youtube.com/watch?v=Og847HVwRSI -- and I'm sure there are any number of possible objections against those numbers... but I think my point holds even if they're several percentage points off.) We live in the strongest language oligoculture since FORTRAN and COBOL in the 1960s. These top three languages, and their communities, act as strong attractors. People flock around these languages because they're popular and established.

Despite that, I'm hopeful. I think there's room for experimentation and playfulness. I think evolution in programming languages is still happening, and that solid/interesting ideas are coming mostly from that fringe, not from the established languages.

Both Arc and Bel have a decidedly hobbyist feel. Maybe that's why they are not drawing large crowds. I think the target audience consists of people who like to "sketch in code" and whip something up in 10 minutes using a REPL and highly interactive development rather than something heavyweight and serious-feeling. A language that "sparkles joy" a little bit, where easy things feel easy. And I don't think it's too late for that, or that the fringe has run out of room for such language attempts.

masak
There are a few more hobbyist implementations out there, at various stages of completion:

    - https://github.com/ajlopez/beljs
    - https://github.com/erdos/carillon
    - https://github.com/luksamuk/believe
I also have an implementation: https://github.com/masak/bel -- you can see the stage of completion in the SVG diagram in the README.

Due to how Bel is specified, all the mentioned implementations have "speed issues". I believe I can fix most of these, and the path forward is fairly clear (faster internal data representations, compiling to efficient bytecode). But I want to hold off announcing/releasing the project until most of the egregious performance problems are fixed. I'm biting my tongue so I don't make any promises/deadlines... but it's coming along. Help appreciated.

The good news is that it seems to be possible to make Bel run fast. I just need to put in the work to get there. Really looking forward to having a fast Bel at my fingertips.

Along the way, I've also discovered a few (minor) bugs in the Bel specification, as well as some things that are underspecified and don't really have answers. I'm also actively thinking about how to build a static type system around Bel's runtime typechecking, analogously to how TypeScript extends JavaScript with static types.