The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

Tim Disney tim.disney at gmail.com
Thu Jun 18 19:48:30 UTC 2015


>  I suspect that (2) deserves a look in about a year, but welcome thoughts
from Tim Disney et al (@natefaubion @jlongster).

Yep, that sounds about right.

Sweet.js design is all about dealing with use-cases like this; start with a
small core and then grow the syntax needed for your domain.

If anyone is curious here's the macro that implements the proposed extra
let form (asuming I understand it right):

```
let let = macro {
    rule {
        ( $($var:ident = $init:expr) (,) ...) {
            $body ...
        }
    } => {
        {
            let $($var = $init) (,) ...
            $body ...
        }
    }
}
```

> Of course, there's tons of technical problems here. sweet.js is cool
> but you still have to compile, so macros need to be native.

Some better tooling would help the dev experience but yeah native would be
the dream.

> sweet.js
> is also a bit slow at the moment. I don't know if it's possible for
> hygienic macros to be fast enough (Tim Disney, creator of sweet.js,
> would need to answer that). It may be possible to use sweet.js's
> pattern matching mechanism but avoid hygiene altogether for speed (and
> provide gensym capability).

Hygiene isn't actually the performance problem. It's just that sweet.js
started out as a research prototype and I've never taken the time to step
back and really do the right engineering to make it better. I have a long
list of things that will hopefully make things way better and now that I'm
almost done with my dissertation I hope to start addressing them soon.


On Thu, Jun 18, 2015 at 11:22 AM, James Long <longster at gmail.com> wrote:

> I've worked with sweet.js a lot, and someone pointed this email out to
> me. I can't agree more. I love all the ES6 features, and some of ES7,
> but looking at some of the future ES7 stuff (like decorators, etc)
> makes me wonder what a "finished" JavaScript will look like. I'm not
> bashing on decorators specifically, just that every new feature (like
> classes) seems to require rethinking of so many other things (how do
> we wrap class methods?) that we didn't have to do before.
>
> I think Scheme and Lisp have had the most success as small languages,
> particularly because of macros. Users weren't just stuck with a small
> language, they could extend it when they really needed to.
>
> I think JavaScript needs macros. It's the hardest language to change,
> and yet one of the most used languages. Macros would let it thrive and
> new features like await/async could be implemented by the community in
> a matter of weeks. Babel has already pioneered an environment where
> new ES7/8 features are available instantly to everybody, but the
> problem is that you have to compile, and nothing is composable. I
> can't release a new async library on npm that implements CSP channels
> and provides a `go` form which is new syntax for firing off a
> blockable process.
>
> Clojure was able to release core.async, precisely the above channel
> implementation, as a library that provides that new form. Immediately
> people could start using it without having to update Clojure at all.
>
> Of course, there's tons of technical problems here. sweet.js is cool
> but you still have to compile, so macros need to be native. sweet.js
> is also a bit slow at the moment. I don't know if it's possible for
> hygienic macros to be fast enough (Tim Disney, creator of sweet.js,
> would need to answer that). It may be possible to use sweet.js's
> pattern matching mechanism but avoid hygiene altogether for speed (and
> provide gensym capability).
>
> I thing someone should take a serious a look at this, though. TC39
> would certainly not have to hand-hold JS quite as much.
>
>
>
>
>
> On Thu, Jun 18, 2015 at 10:37 AM, Mark S. Miller <erights at google.com>
> wrote:
> > On Wed, Jun 17, 2015 at 7:27 PM, Kyle Simpson <getify at gmail.com> wrote:
> >>
> >> I'd like to ask if there's anyone on TC39 that would be willing to
> >> champion a proposal to add the let-block (let-statement) syntax?
> >
> >
> > I am not. Further, if anyone were, I would work to kill it. Here's why.
> >
> >
> > The Algol, Smalltalk, Pascal, and early Scheme languages were prized for
> > being small and beautiful. The early C and JavaScript languages were
> > justifiably criticized for many things, and rarely mistaken for a
> language
> > that was generally beautiful. But they were small, and this aspect was
> > properly and widely appreciated. When a language is small, our
> appreciation
> > of it is often driven by the sense "I can learn the whole thing, and
> then I
> > will have a mastery of it", and later "I know the whole thing. I love the
> > fact that there are no corners I don't know." For C and JavaScript, few
> who
> > thought they knew the whole thing actually did -- the details were
> actually
> > fiendishly complex. Nevertheless, this sense drove much of the
> satisfaction
> > with everyday usage.
> >
> > The esthetic of smallness of JS lasted through ES5. I participated
> heavily
> > in both ES5 and ES6 and in both cases I am proud of my contributions.
> ES6 is
> > much larger, but nevertheless it is a much better language. Given where
> we
> > started, we could not have achieved these gains in the utility of JS
> without
> > such an increase in size. I do not regret most of the additions that grew
> > ES5 to ES6. For many of these, had we the ES6 standards process to do
> over
> > again, I would likely make similar additions.
> >
> > But each of the additions that grew ES5 into ES6 had to pass a very high
> > bar. Psychologically, this made sense to all of us because we were
> starting
> > from a language, ES5, whose smallness we could still appreciate. When a
> > language is small, every additional feature is viscerally felt as a
> > significant percentage increase in the size of the language. The specific
> > benefits of a feature are always visible to its advocates. But for a
> small
> > language, a new feature's general costs in added complexity are also
> still
> > visible to everyone.
> >
> > Once a language gets beyond a certain complexity --- say LaTeX, Common
> Lisp,
> > C++, PL/1, modern Java --- the experience of programming in it is more
> like
> > carving out a subset of features for one's personal use out of what seems
> > like an infinite sea of features, most of which we become resigned to
> never
> > learning. Once a language feels infinite, the specific benefits of a new
> > feature are still apparent. But the general costs in added complexity
> are no
> > longer apparent. They are no longer *felt* by those discussing the new
> > feature. Infinity + 1 === Infinity. Even aLargeNumber + 1 ===
> > approximatelyAsLargeANumber. This is the death of a thousand cuts that
> > causes these monstrosities to grow without bound.
> >
> >
> > So please, I beg all of you, when considering a new feature, please
> apply a
> > higher bar than "Wouldn't it be nice if we could also write it this
> way?". I
> > believe that ES6 is in that middle territory where unrestrained growth is
> > not yet inevitable, but only if we all restrain each other with high
> > standards for any proposed new feature. As a community, we need more of a
> > shared sense of panic about the size that ES6 has already grown to.
> Ideally,
> > that panic should increase, not decrease, with further growth from here
> as
> > our size approaches the point of no return.
> >
> >
> > --
> >     Cheers,
> >     --MarkM
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
-Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150618/1c9c8212/attachment-0001.html>


More information about the es-discuss mailing list