Re: Idle musings on doing E over again

On Fri, Sep 28, 2012 at 7:41 AM, Kevin Reid <kpreid-M/[email protected]> wrote:
> I was trying to get to sleep last night, and was struck by the thought of: If we were designing E from scratch (with the same goals), what would I actually do differently? […]
> (Sending to friam on the off chance it's an interesting topic.)

I hesitate to write this, since I like to be more of an "underpromise
and overdeliver" kind of guy, but the resonance was just too strong.

I spent the last year or so working in JavaScript and Node (for a
startup; our product is <https://medium.com/>). Going into it a year
ago, I thought that this pair of technologies / products would be a
good basis for doing the next layer of programming language and
platform development. Today, not so much.

Having gotten product out the door, I took a vacation. One of my goals
for the vacation was to start in earnest on what I thought a good
next-language might be, in terms of my own career / life-work arc.
Where I ended up was that I had a few ideas for an ultimate goal — in
particular I'm currently interested in exploring where all of
promise-based computation, a nearly-immutable data model, and software
transactional memory (for the mutable parts) meet — but I was (and am)
utterly dissatisfied with the prospects of exploring this territory
using any of the existing higher-level tools and languages that I
researched. My dissatisfaction stemmed from issues along the lines of
too many dependencies, poor semantic fit for the problem, and
philosophical incompatibility.

This led me to take a week and a bit to prototype what I think will be
a good-enough system to use as a substrate for my own further work. A
bit meta, I know. As with Kevin, I don't know how much progress I'll
be able to make in the short term, particularly because the work isn't
well-aligned with my job responsibilities. That said, I'm currently
quite excited about the prospects and have been spending an awful lot
of my evening and weekend time on it.

One thing that I feel is important at this level is an integral
parsing facility that can be used to write understandable code, and so
the prototype includes syntax for PEG grammar specification. (In a
way, this is a decades-overdue acknowledgment that Snobol had the
right idea here.)

Another high-order bit for me is avoiding gratuitous dependencies.
Getting to a self-hosted system seems pretty sensible to me, but I
don't want to have a ton of prerequisites for getting to that point.
Where I landed was to use C as the implementation language for a
minimal implementation, with the aim being for the code to be correct
and readable, eschewing both completeness and efficiency as primary
goals. Along the lines of how Scheme48 and PyPy are built, this C
implementation is meant to host exactly one program, a compiler for a
complete language implementation.

Because of where I'm positioning this in the stack, I'm aiming for
transparent Posix support but *not* ubiquitous asynchronous I/O (even
though I agree that that's ultimately desirable).

Though Kevin's and my short- to medium-term goals are probably
different, I think he is sensing the same underlying need in the
world. And I'll disagree, and take the stance that inventing a new
language *is* inherently good, and I want to help make it easier to do
so. Wish me luck!

Cheers,

-dan