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

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Mark S. Miller-2
On Wed, Jun 17, 2015 at 7:27 PM, Kyle Simpson <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Brendan Eich-2
Good points, Mark.

There are two better ways forward that I see:

1. Separate forms and make them compose well. Instead of let (x=y){z}
and the grammatically unsound let (x=y)x*x from ES4, given let in ES6,
and do expressions in ES7, declare victory and use `do { let x = y; z }`.

2. Sweet.js (http://sweetjs.org/), hygienic macros for JS, with
syntax-case-strength matching and enforestation magic.
http://sweetjs.org/doc/main/sweet.html

We try to follow (1) in TC39. It is why we didn't rush the ?.
"null-soaking" operator in. I suspect that (2) deserves a look in about
a year, but welcome thoughts from Tim Disney et al (@natefaubion
@jlongster).

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Greg McLeod
Very well said Mark! You've basically articulated what I've been thinking for a few years now as someone lurking amongst these lists afraid to speak up. Often times I've seen people's questions or criticisms get shut down with a link to lmgtfy often followed by an emoticon or two, which doesn't make posting in these lists seem very inviting.

I really really love JS (it's so fun!), and while there are many features in ES6 that I think are great (such as classes, modules, and import syntax) there are things that quite frankly scare me quite a bit. Such examples include destructuring and arrow functions, which make sense when used in simple use cases but I find confusing to interpret when reading someone else's code due to their terseness.

But you know what? I can live with ES6. I did enjoy, while it lasted, the comfort in understanding 99% of JS due to its smallness. But I don't mind learning a few more new concepts derived from other languages if it means I can become better at both reading and writing code. But with ES6 pretty much set in stone, ES7 will be the next round of discussions. So like you said Mark, I think more of us (including myself) shouldn't be afraid to share our panic. It's extremely easy to agree with someone on something, but I think more often than not those who disagree likely hesitate in contributing to the conversation.

--Greg

On Thu, Jun 18, 2015 at 12:22 PM, Brendan Eich <[hidden email]> wrote:
Good points, Mark.

There are two better ways forward that I see:

1. Separate forms and make them compose well. Instead of let (x=y){z} and the grammatically unsound let (x=y)x*x from ES4, given let in ES6, and do expressions in ES7, declare victory and use `do { let x = y; z }`.

2. Sweet.js (http://sweetjs.org/), hygienic macros for JS, with syntax-case-strength matching and enforestation magic. http://sweetjs.org/doc/main/sweet.html

We try to follow (1) in TC39. It is why we didn't rush the ?. "null-soaking" operator in. I suspect that (2) deserves a look in about a year, but welcome thoughts from Tim Disney et al (@natefaubion @jlongster).

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Gruenbaum
In reply to this post by Mark S. Miller-2
First of all, brilliant post Mark. 

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

As a community, we do - if you look at HackerNews or Reddit or StackOverflow people are constantly hating on JS getting larger. Features like classes and `let` are very often criticised and often languages that did not add these features and are considered 'well designed' are given in comparison (Python's lack of block scoping for instance).

This is a mailing list comprised of people who typically have a much better understanding of the language and its corners than most (even professional) developers have (and dare I say, are interested in or care about having). With ES6 the language already got a *lot* bigger and I'd argue that it's now harder to learn the whole. The tradeoffs were worthwhile but it's definitely an issue.

It's easy to forget here what traps the average user might fall into, and it's easy to forget what they care about and what confuses them.

Fwiw, there are examples of big languages that are well liked, the "canonical" example of a big but very well liked (and well designed imho) language is C#. It has a lot of cruft now (delegates and events, array covariance etc) but it is still a very well liked language in general.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

James Long-8
In reply to this post by Mark S. Miller-2
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 <[hidden email]> wrote:

> On Wed, Jun 17, 2015 at 7:27 PM, Kyle Simpson <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Andrea Giammarchi-2
In reply to this post by Benjamin Gruenbaum
I like Mark's post too, and if I might ...

Features like classes and `let` are very often criticised and often languages that did not add these features and are considered 'well designed' are given in comparison (Python's lack of block scoping for instance).

thing is, ES6 brought in many things that took years to explain in the "JS way" and when finally developers started knowing and appreciating `prototypal` inheritance and started understanding the `var` behavior, to name just few, "we" started promoting ES6 as the universal problem solver for every dev so that `let` is the new `var` (most developers still don't even know what does it mean) and `const` is the better `let` and `class` finally is in the language, something that desugar anyway to prototypal inheritance, something developers still need to understand.

So I agree we should really stop going fancy with syntax, probably think about sweet.js like approches, and fix all the things that will need to be fixed in ES6, improving and finalizing classes bringing in composition like it has always been possible before through prototypal inheritance. I really do hope traits will be highly prioritized and binary/typed data/shapes too 'cause I don't think JS needs many more changes as it is today.

Just my lil'rant and keep up the good work.

Best Regards










On Thu, Jun 18, 2015 at 6:26 PM, Benjamin Gruenbaum <[hidden email]> wrote:
First of all, brilliant post Mark. 

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

As a community, we do - if you look at HackerNews or Reddit or StackOverflow people are constantly hating on JS getting larger. Features like classes and `let` are very often criticised and often languages that did not add these features and are considered 'well designed' are given in comparison (Python's lack of block scoping for instance).

This is a mailing list comprised of people who typically have a much better understanding of the language and its corners than most (even professional) developers have (and dare I say, are interested in or care about having). With ES6 the language already got a *lot* bigger and I'd argue that it's now harder to learn the whole. The tradeoffs were worthwhile but it's definitely an issue.

It's easy to forget here what traps the average user might fall into, and it's easy to forget what they care about and what confuses them.

Fwiw, there are examples of big languages that are well liked, the "canonical" example of a big but very well liked (and well designed imho) language is C#. It has a lot of cruft now (delegates and events, array covariance etc) but it is still a very well liked language in general.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Andrea Giammarchi-2
I don't think JS needs many more changes as it is today.

I mean it does, but mostly on browsers land, not in its core

On Thu, Jun 18, 2015 at 7:27 PM, Andrea Giammarchi <[hidden email]> wrote:
I like Mark's post too, and if I might ...

Features like classes and `let` are very often criticised and often languages that did not add these features and are considered 'well designed' are given in comparison (Python's lack of block scoping for instance).

thing is, ES6 brought in many things that took years to explain in the "JS way" and when finally developers started knowing and appreciating `prototypal` inheritance and started understanding the `var` behavior, to name just few, "we" started promoting ES6 as the universal problem solver for every dev so that `let` is the new `var` (most developers still don't even know what does it mean) and `const` is the better `let` and `class` finally is in the language, something that desugar anyway to prototypal inheritance, something developers still need to understand.

So I agree we should really stop going fancy with syntax, probably think about sweet.js like approches, and fix all the things that will need to be fixed in ES6, improving and finalizing classes bringing in composition like it has always been possible before through prototypal inheritance. I really do hope traits will be highly prioritized and binary/typed data/shapes too 'cause I don't think JS needs many more changes as it is today.

Just my lil'rant and keep up the good work.

Best Regards










On Thu, Jun 18, 2015 at 6:26 PM, Benjamin Gruenbaum <[hidden email]> wrote:
First of all, brilliant post Mark. 

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

As a community, we do - if you look at HackerNews or Reddit or StackOverflow people are constantly hating on JS getting larger. Features like classes and `let` are very often criticised and often languages that did not add these features and are considered 'well designed' are given in comparison (Python's lack of block scoping for instance).

This is a mailing list comprised of people who typically have a much better understanding of the language and its corners than most (even professional) developers have (and dare I say, are interested in or care about having). With ES6 the language already got a *lot* bigger and I'd argue that it's now harder to learn the whole. The tradeoffs were worthwhile but it's definitely an issue.

It's easy to forget here what traps the average user might fall into, and it's easy to forget what they care about and what confuses them.

Fwiw, there are examples of big languages that are well liked, the "canonical" example of a big but very well liked (and well designed imho) language is C#. It has a lot of cruft now (delegates and events, array covariance etc) but it is still a very well liked language in general.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

C. Scott Ananian
It seem semi-obligatory at this point to cite "Growing a Language", by Guy Steele.

I tend to agree with the idea that at this point we need *means to grow syntax* rather than new syntax.  Similarly, JavaScript needs *means to add new lightweight types* rather than more lightweight types.

Once that is done, operator overloading would complete the circle, and allow the community to grow further lightweight types and syntactic forms as they please.
  --scott

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Andreas Rossberg-4
In reply to this post by Benjamin Gruenbaum
On 18 June 2015 at 19:26, Benjamin Gruenbaum <[hidden email]> wrote:
This is a mailing list comprised of people who typically have a much better understanding of the language and its corners than most (even professional) developers have (and dare I say, are interested in or care about having). With ES6 the language already got a *lot* bigger and I'd argue that it's now harder to learn the whole. The tradeoffs were worthwhile but it's definitely an issue.

I dare say that at this point Allen probably is the only person in the world who actually fully knows and understands the complete language. I won't hesitate to admit that I don't. ;)

/Andreas


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Morningstar, Chip
In reply to this post by Mark S. Miller-2
Preach it, brother!

I'd like to jump on the bandwagon of Mark's concern about the death-of-a-thousand-cuts phenomenon.

It is far too easy to make a bunch of small additions, each of which is individually worthy and justifiable, that collectively add up to a sum total that is not so worthy or justifiable.  It's particularly easy when we have a process which considers each proposed change or addition in isolation, considering it individually on its own merits as if it was all that we were doing. There's lots of good stuff in ES6, but the overall mass and complexity of the thing still makes me a little queasy.

I've been observing the TC39 process for about six months now, without plunging into the discussion very deeply yet (still getting the lay of the land, as it were). One thing I find striking is the number of proposals being floated that seem to be based on "this could be useful" or "some other language I like does this" or "I think it's cool" or "I wish I could code like this instead of like that".  In contrast, I see relatively few people responding to these proposals with questions like "do developers really *need* this?" or "what actual problem does this solve?".  I see relatively few advocates for minimalism as a virtue per se, minimalism being a corrective to the kinds of bloat that arises from a horde of wafer thin changes.

Chip

On Jun 18, 2015, at 7:37 AM, Mark S. Miller <[hidden email]> wrote:

On Wed, Jun 17, 2015 at 7:27 PM, Kyle Simpson <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Tim Disney
In reply to this post by James Long-8
>  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 <[hidden email]> 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 <[hidden email]> wrote:
> On Wed, Jun 17, 2015 at 7:27 PM, Kyle Simpson <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
-Tim

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Allen Wirfs-Brock
In reply to this post by Andreas Rossberg-4

On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:

On 18 June 2015 at 19:26, Benjamin Gruenbaum <[hidden email]> wrote:
This is a mailing list comprised of people who typically have a much better understanding of the language and its corners than most (even professional) developers have (and dare I say, are interested in or care about having). With ES6 the language already got a *lot* bigger and I'd argue that it's now harder to learn the whole. The tradeoffs were worthwhile but it's definitely an issue.

I dare say that at this point Allen probably is the only person in the world who actually fully knows and understands the complete language. I won't hesitate to admit that I don't. ;)

And I occasionally have to go and look up details.  

Allen 


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Andrea Giammarchi-2
> And I occasionally have to go and look up details.  

You know nothing Allen Wirfs-Brock (cit)

On Thu, Jun 18, 2015 at 8:55 PM, Allen Wirfs-Brock <[hidden email]> wrote:

On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:

On 18 June 2015 at 19:26, Benjamin Gruenbaum <[hidden email]> wrote:
This is a mailing list comprised of people who typically have a much better understanding of the language and its corners than most (even professional) developers have (and dare I say, are interested in or care about having). With ES6 the language already got a *lot* bigger and I'd argue that it's now harder to learn the whole. The tradeoffs were worthwhile but it's definitely an issue.

I dare say that at this point Allen probably is the only person in the world who actually fully knows and understands the complete language. I won't hesitate to admit that I don't. ;)

And I occasionally have to go and look up details.  

Allen 


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Gruenbaum
This is just a heads up for context that someone published a link to Mark's post in HN here: https://news.ycombinator.com/item?id=9738866 in case we get any more new people posting in the thread. 

-----

> > Features like classes and `let` are very often criticised and often languages that did not add these features and are considered 'well designed' are given in comparison (Python's lack of block scoping for instance).

> thing is, ES6 brought in many things that took years to explain in the "JS way" and when finally developers started knowing and appreciating `prototypal` inheritance and started understanding the `var` behavior, to name just few, "we" started promoting ES6 as the universal problem solver for every dev so that `let` is the new `var` (most developers still don't even know what does it mean) and `const` is the better `let` and `class` finally is in the language, something that desugar anyway to prototypal inheritance, something developers still need to understand.

I completely agree - I think that classes and let as ways to standardise the best practice way of something most people are already doing. This is a noble and very important thing that really helps. By letting wisdom of the masses show us what people need and letting user-land solutions spearhead progress and then specifying the parts that work is an excellent approach - having a TC in charge is really nice and ensures vision and order. The reason I'm trying to get more involved in the process is because I like the way things are heading and the discussions held (and I'm learning a lot). 

I don't know about additional syntax - but the fact the bar is raised is very important. 

On Fri, Jun 19, 2015 at 3:03 AM, Andrea Giammarchi <[hidden email]> wrote:
> And I occasionally have to go and look up details.  

You know nothing Allen Wirfs-Brock (cit)

On Thu, Jun 18, 2015 at 8:55 PM, Allen Wirfs-Brock <[hidden email]> wrote:

On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:

On 18 June 2015 at 19:26, Benjamin Gruenbaum <[hidden email]> wrote:
This is a mailing list comprised of people who typically have a much better understanding of the language and its corners than most (even professional) developers have (and dare I say, are interested in or care about having). With ES6 the language already got a *lot* bigger and I'd argue that it's now harder to learn the whole. The tradeoffs were worthwhile but it's definitely an issue.

I dare say that at this point Allen probably is the only person in the world who actually fully knows and understands the complete language. I won't hesitate to admit that I don't. ;)

And I occasionally have to go and look up details.  

Allen 


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Alexander Jones
In reply to this post by Allen Wirfs-Brock
If people are unable to internalize the whole language, then surely we need a way to remove cruft and idiosyncracies in it, lest the language stagnate beyond repair.

Removing var, typeof, exotic objects, function declarations, IsNaN, ==, enumerable properties, are just a few examples of things we should not be frightened to talk about.

While I don't personally see a need for the proposed let syntax, I think that concerns about the language growing uncontrollably should be directed at its apparent lack of deprecation strategy, rather than shutting down discussion of new ideas that might help us write better programs.

Just my 2p.



On Thursday, June 18, 2015, Allen Wirfs-Brock <[hidden email]> wrote:

On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:

On 18 June 2015 at 19:26, Benjamin Gruenbaum <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;benjamingr@gmail.com&#39;);" target="_blank">benjamingr@...> wrote:
This is a mailing list comprised of people who typically have a much better understanding of the language and its corners than most (even professional) developers have (and dare I say, are interested in or care about having). With ES6 the language already got a *lot* bigger and I'd argue that it's now harder to learn the whole. The tradeoffs were worthwhile but it's definitely an issue.

I dare say that at this point Allen probably is the only person in the world who actually fully knows and understands the complete language. I won't hesitate to admit that I don't. ;)

And I occasionally have to go and look up details.  

Allen 


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Gruenbaum
I don't think anyone is "frightened" about removing these things. The TC has a commitment not to "break the internet", by removing something like `var` or `typeof` you're disabling *billions* of people who are using the internet - it would very much literally "break the internet". Even if the TC unanimously votes on removing 'var' - this is not something browser vendors would do anyway.

This issue has been discussed on the list several times before and even the modest attempt to fix `typeof null` failed when it was attempted. Here is some discussion about it https://esdiscuss.org/topic/typeof-null 

The way forward is pretty much to avoid features like `with` for the most part, understand older code but gradually write newer code. Any breaking changes to the language require extensive research which will likely conclude in not making the change (like `var`) anyway.

Note that strict mode already fixes a lot of things (quirkiness of arguments, with, non-lexical scope, globals, etc). Classes have safe defaults (non enumerability of properties), for... of loops typically do the correct thing based on the new iteration protocol and so on.


On Fri, Jun 19, 2015 at 11:06 AM, Alexander Jones <[hidden email]> wrote:
If people are unable to internalize the whole language, then surely we need a way to remove cruft and idiosyncracies in it, lest the language stagnate beyond repair.

Removing var, typeof, exotic objects, function declarations, IsNaN, ==, enumerable properties, are just a few examples of things we should not be frightened to talk about.

While I don't personally see a need for the proposed let syntax, I think that concerns about the language growing uncontrollably should be directed at its apparent lack of deprecation strategy, rather than shutting down discussion of new ideas that might help us write better programs.

Just my 2p.




On Thursday, June 18, 2015, Allen Wirfs-Brock <[hidden email]> wrote:

On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:

On 18 June 2015 at 19:26, Benjamin Gruenbaum <[hidden email]> wrote:
This is a mailing list comprised of people who typically have a much better understanding of the language and its corners than most (even professional) developers have (and dare I say, are interested in or care about having). With ES6 the language already got a *lot* bigger and I'd argue that it's now harder to learn the whole. The tradeoffs were worthwhile but it's definitely an issue.

I dare say that at this point Allen probably is the only person in the world who actually fully knows and understands the complete language. I won't hesitate to admit that I don't. ;)

And I occasionally have to go and look up details.  

Allen 



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Scott Sauyet
In reply to this post by Greg McLeod


Greg McLeod <[hidden email]> wrote:

> I really really love JS (it's so fun!), and while there are many features in ES6 that I think are great (such as classes, modules, and import syntax) there are things that quite frankly scare me quite a bit. Such examples include destructuring and arrow functions, which make sense when used in simple use cases but I find confusing to interpret when reading someone else's code due to their terseness.

I think the difference between your list and mine exemplifies the tragedy of the commons as so well described by Mark.  Although we both share a liking for modules and imports, my favorite ES6 feature is the arrow functions, with destructuring near the top.   The very bottom of my list, the only one I really, really wish n not been included is `class`.

Covering the desires of both users like you and users like me is what can so easily leaf to bloat.

  -- Scott


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Andreas Rossberg-4
In reply to this post by Alexander Jones
On 19 June 2015 at 10:06, Alexander Jones <[hidden email]> wrote:
If people are unable to internalize the whole language, then surely we need a way to remove cruft and idiosyncracies in it, lest the language stagnate beyond repair.

Removing var, typeof, exotic objects, function declarations, IsNaN, ==, enumerable properties, are just a few examples of things we should not be frightened to talk about.

While I don't personally see a need for the proposed let syntax, I think that concerns about the language growing uncontrollably should be directed at its apparent lack of deprecation strategy, rather than shutting down discussion of new ideas that might help us write better programs.

While I agree that the impossibility of deprecating features is a problem (without a solution in JS), it's also fair to say that deprecation doesn't really work or help. Take C++ as the obvious example. They do deprecate occasionally, with difficulties. Yet the language had already blown complexity out of any sane proportion 25 years ago. Let alone today. Not a chance that there is a single person who _even remotely_ understands the full language, and there probably hasn't been one for 3 decades at least.

Deprecation doesn't solve the problem because new cruft typically gets added orders of magnitude faster than old cruft can ever be removed. That is true for almost all production languages. Because it's so much easier to add stuff.

Thus, the only way to keep a language small (if at all) is being extra careful about adding features. Just about any terrible feature can be justified by "use cases", but that's insufficient reason to add it. Especially "convenience" features are a slippery slope. (I could make a list of ES6 additions that already violate this principle.)

The art in language design isn't what to add, but what to leave out.

/Andreas


 
On Thursday, June 18, 2015, Allen Wirfs-Brock <[hidden email]> wrote:

On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:

On 18 June 2015 at 19:26, Benjamin Gruenbaum <[hidden email]> wrote:
This is a mailing list comprised of people who typically have a much better understanding of the language and its corners than most (even professional) developers have (and dare I say, are interested in or care about having). With ES6 the language already got a *lot* bigger and I'd argue that it's now harder to learn the whole. The tradeoffs were worthwhile but it's definitely an issue.

I dare say that at this point Allen probably is the only person in the world who actually fully knows and understands the complete language. I won't hesitate to admit that I don't. ;)

And I occasionally have to go and look up details.  

Allen 


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

C. Scott Ananian

An interesting wrinkle in language design has been the rise of sophisticated linting and style tools like `jscs`.  If you wish to deprecate `var` for instance, it is straightforward to write a jscs module to enforce that.  Further, several large communities (node, wikipedia, etc) have published jscs "presets" that effectively define the subset of the language they use.

So in a meaningful way we are getting the tools to voluntarily deprecate features in a community-driven way.  Certain quirks may always exist in the spec (although perhaps more and more they will migrate to compatibility appendixes), but can be effectively ignored for communities opting in to jscs presets.

I note that certain ES6 features have also been written specifically to allow opt-in to sane behavior.  For example, a `SaneArray` subclass of Array is often discussed here.  Use of SaneArray instead of stock Array could also be enforced by jscs-like tools.  (Although this means giving up Array literal syntax?  So there's still a bit of awkwardness.  And API boundaries are tricky.  Future work!)

Anyway, I look forward to a continued process of community-driven feature deprecation, and hope that we will continue to look for ways in ES7 to allow further opt-in fixes to our warts. (I also look forward to continued development of interesting rule sets and analyses in jscs and similar tools to shave off warts.)
  --scott


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Alex Russell-4
In reply to this post by Andrea Giammarchi-2
I do not share Mark's view. Contra his sentiment, I was using the "small" version of JS for many years and noted that most non-trivial uses required finding or building a library. That choice of library (which exist to fill in platform and language deficiencies) leads to a a split in common use that's just as pernicious as "choosing a subset". 

Writing JS in the large continues to need more help.


On Thu, Jun 18, 2015 at 11:27 AM, Andrea Giammarchi <[hidden email]> wrote:
I like Mark's post too, and if I might ...

Features like classes and `let` are very often criticised and often languages that did not add these features and are considered 'well designed' are given in comparison (Python's lack of block scoping for instance).

thing is, ES6 brought in many things that took years to explain in the "JS way" and when finally developers started knowing and appreciating `prototypal` inheritance and started understanding the `var` behavior, to name just few, "we" started promoting ES6 as the universal problem solver for every dev so that `let` is the new `var` (most developers still don't even know what does it mean) and `const` is the better `let` and `class` finally is in the language, something that desugar anyway to prototypal inheritance, something developers still need to understand.

So I agree we should really stop going fancy with syntax, probably think about sweet.js like approches, and fix all the things that will need to be fixed in ES6, improving and finalizing classes bringing in composition like it has always been possible before through prototypal inheritance. I really do hope traits will be highly prioritized and binary/typed data/shapes too 'cause I don't think JS needs many more changes as it is today.

Just my lil'rant and keep up the good work.

Best Regards










On Thu, Jun 18, 2015 at 6:26 PM, Benjamin Gruenbaum <[hidden email]> wrote:
First of all, brilliant post Mark. 

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

As a community, we do - if you look at HackerNews or Reddit or StackOverflow people are constantly hating on JS getting larger. Features like classes and `let` are very often criticised and often languages that did not add these features and are considered 'well designed' are given in comparison (Python's lack of block scoping for instance).

This is a mailing list comprised of people who typically have a much better understanding of the language and its corners than most (even professional) developers have (and dare I say, are interested in or care about having). With ES6 the language already got a *lot* bigger and I'd argue that it's now harder to learn the whole. The tradeoffs were worthwhile but it's definitely an issue.

It's easy to forget here what traps the average user might fall into, and it's easy to forget what they care about and what confuses them.

Fwiw, there are examples of big languages that are well liked, the "canonical" example of a big but very well liked (and well designed imho) language is C#. It has a lot of cruft now (delegates and events, array covariance etc) but it is still a very well liked language in general.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12