I echo this. E is a dynamic language with many similarities with JS,
including a similarly C-like syntax. In E I use
everything-is-a-pattern-or-expression all the time. When I first moved to
JS I missed it. Now that I am used to the JS statements-are-not-expressions
restrictions, I no longer do, with one exception:
When simply generating simple JS code from something else, this restriction
is a perpetual but minor annoyance. By itself, I would agree that this
annoyance is not important enough to add a new feature. However, if rather
than "adding a feature", we can explain the change as "removing a
restriction", then JS would get both simpler and more powerful at the same
time. Ideally, the test would be whether, when explaining the less
restrictive JS to a new programmer not familiar with statement languages,
this change results in one less thing to explain rather than one more.
On Thu, Jul 16, 2015 at 6:38 AM, Andreas Rossberg <rossb...@google.com>
wrote:
> On 16 July 2015 at 15:21, Bob Myers <r...@gol.com> wrote:
>
>> With all "do" respect, none of this syntax tinkering makes any sense to
>> me.
>>
>> I've been programming JS for 15 years and never noticed I needed a try
>> block that returns a value.
>>
>> Long ago I programmed in a language called AED that had valued blockl,
>> which I was quite fond of, but never felt the need for that in JS for
>> whatever reason.
>>
>
> I've been programming in C++ for 25 years, and didn't have much need for a
> try expression or nested binding either.
>
> I've also been programming in functional languages for 20 years, and need
> them on a regular basis.
>
> It all depends on how high-level your programming style is. Also, Sapir
> Whorf applies as usual.
>
> /Andreas
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
