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

Greg McLeod cleod9 at gmail.com
Thu Jun 18 16:41:10 UTC 2015


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 <brendan at mozilla.org> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150618/e237668c/attachment.html>


More information about the es-discuss mailing list