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.
Claus
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
