Function Syntax

Claus Reinke claus.reinke at
Wed May 11 08:52:31 PDT 2011

> ECMAScript has a large set of problems. I think that the fact that 
> 'function' has eight letters is at the bottom of the priority list. 

- fixing ECMAScript's oddities would be worth a language revision,
    even without adding anything new
- ECMAScript's oddities have been deployed, resulting in a big
    momentum against change
- adding new features stirs up discussion, but much less so than
    changing old features
- if new features allow programmers to avoid the oddities in old
    features, the reasons for clinging to odd-but-deployed disappear,
    at which point the old features can be deprecated

- fixing ECMAScript problems is great; offering alternatives to
    problematic features that resist immediate fixing is a slower
    path, but sometimes the only way to make progress 

- good functional programming support allows to build abstractions,
    both to work around some of the remaining language problems, 
    and to provide new solutions to application domain problems

- a large number of ECMAScript problems intersect with functions
    (including but not limited to: implicit this, arguments, mutability, 
    scoping, expressions vs statements, blocks vs objects, restricted 
    production for return, ..)

So, progress on the function front (beyond shorter keywords) has
a high payoff and is difficult, unless the issues can be treated one
by one; if the issues can be treated one-by-one, then syntax is one 
of them; if the syntax issue is easy to solve, progress there can 
provide motivation for going back to work on the harder issues. 

More concise function syntax is important, as long as the deeper
issues get resolved, too. As long as new syntax does not introduce
new issues, does not try to patch over real issues with mere sugar, 
and does not distract from tackling the other issues, there is 
nothing wrong with concise function syntax. 

It might be easier to converge on a syntax after solving the other
issues, though, and syntax always induces intense discussions, 
which leads others to fear that their work on other issues gets
drowned and ignored among the flood of syntax threads.

> I look at ECMAScript as serving four groups:
> 1. The beginners for whom the language was designed.
> 2. The web developers who owe their livelihoods to the language.
> 3. The scientists who will use the language for greatness.
> 4. Language designers and critics.
> I want to improve the language for the first three groups. I don't 
> believe it will be possible to please the fourth group, so we 
> shouldn't even try.

Sorry to be the bearer of bad news, but if we contribute to es-discuss,
we are involved in language design, acting as language designers. We
can acknowledge this, and try to do the best we can, including profiting
from previous design experience, or we can try to hide from this fact,
probably resulting in a botched design job.

I don't understand your group 3, and I don't think denial of group 4 
is helpful. Also, there are several groups missing, so let me try to
start revising that list:

1. beginners (also: casually interested web designers)
2. professional web developers
3. language implementers
4. library/framework providers
5. tool builders 
6. theory providers (static analyses, optimizations, ..)

I haven't listed language designers separately, both because 
most of what goes on here on es-discuss involves language 
design, and because language design is still mostly experience-
driven, without direct formal foundations. Some day, there
might be a science of language design, but for now, we have
to make do with the fragments provided by all those groups.

And that still doesn't account for all middle men: eg, model-driven
development and domain-specific languages seem to have reached
the programming masses ("mass" in the Java sense, not the even
larger Javascript sense of the term). One core aspect of these is 
that the "professional developer" group gets split into "abstraction 
builders" (using Allen's term) and "abstraction users".

That also means that support for language-design-in-the-small is 
now an important factor, too: if professional developers working
as abstraction builders cannot embed their DSLs in Javascript, 
they are going to compile their DSLs to Javascript (or bypass 
Javascript alltogether, for instance, by generating native code 
for multiple mobile phone platforms from Java-backed DSLs).

The growing number of Javascript pre-processors in production
use (not to mention the steady stream of experimental pre-processors) 
is another indication that the language is lacking the flexibility that 
professional developers need. Those abstractions should expressible
as library code, not as bolted-on source transformations.

> The language has difficult syntax due to its C/Fortran heritage 
> which daily makes the use of the language unnecessarily painful. 
> I would like to repair the traps and confusions so that the language 
> can be practiced more productively. 

That would be great. It isn't a popular task, needing solutions to
difficult problems in the face of deployed-code inertia. It also 
does not advertize as well as fancy new features. But I agree that
working out the kinks would be a very important contribution.

> Some of the proposals and wishes for new syntax are alarming, 
> in that they appear to be increasing the problem set, rather than
> reducing it. For example, the language has a confusion between 
> blocks and object literals. Any new  syntax should reduce or 
> eliminate this confusion, not amplify it.

Again, an important consideration to keep in mind. Assuming
the motivation is to provide alternative language constructs,
in order to ease the long-term transition away from problematic
existing constructs, it is essential to separate the consolidation
aspects (how is this feature going to improve the language
foundations) from the experimentation aspects (what else 
can we do with this feature?).

It is also worrying that the old features have taken so much
of the available syntax, and that the new features are trying
to fit into the gaps. If the new features are going to replace
the old, we do not want to end up with a syntax that was
build from left-overs; nor do we want to have to explain that
JavascriptX looks the way it does because its features had
to be built around the limitations imposed by oddities of ES5.

Which is another way to say that fixing those problems
should have a higher priority: unrewarding and long-term
it may be, but if the old problems keep interfering with
the design of desirable new features, tackling the old hard
problems first might be the only way to make progress.

> I see this design problem as an intricate puzzle. There are 
> many conflicting goals, and the solution is far from obvious. 
> If we can solve it, and I am unreasonably optimistic that a 
> solution is possible, then we will have  obtained a language 
> that is easier to read, easier to write, and more resistant to
> error. If we get it wrong, then we will have accomplished 
> something far worse than having done nothing.

Which is what language design is all about!-)

> I want to make the language easier to beginners to learn, 
> streamlining the syntax, replacing automatic semicolon 
> insertion with statements that are by design semicolon free.
> I want to smooth over the language's rough areas so that 
> web applications can be developed more effectively, with 
> fewer nasty surprises.
> And I want the language to help us better harness the power 
> of the function. I think that is the best path for keeping this 
> language viable for many years.



More information about the es-discuss mailing list