
Ask HN: What happened to PG's Arc and Bel? - azhenley
I&#x27;ve had an interest in PG&#x27;s Arc and Bel languages (see [1, 2]) for a while. But the Arc forum [3] hasn&#x27;t had a post in 107 days. On the other hand, Bel was only announced [4] less than a year ago.<p>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.<p>[1] http:&#x2F;&#x2F;paulgraham.com&#x2F;arc.html<p>[2] http:&#x2F;&#x2F;paulgraham.com&#x2F;bel.html<p>[3] http:&#x2F;&#x2F;arclanguage.org&#x2F;forum<p>[4] https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21231208<p>[5] https:&#x2F;&#x2F;github.com&#x2F;jeremyschlatter&#x2F;chime&#x2F;
======
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](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.

------
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](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.

------
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.

