PRE-PROPOSAL: Source and Encoding keyword
Talden
talden at gmail.com
Sun Mar 15 13:12:40 PDT 2009
> 2. Many proposals for the language jump through hoops it trying to
> avoid new keywords (I'm talking about you BGGA). These proposals end
> up looking nothing like Java as a consequence. Java uses unabbreviated
> keywords, e.g. extends instead of :, this is part of the character of
> Java. You need a source statement to enable new keywords and hence
> enable future extensions that don't appear alien.
You have to be careful not to characterise that aversion to
abbreviation as an absolute. 'enum' instead of 'enumeration' for
example.
Of course we also don't say
MULTIPLY x BY 2 GIVING x
We instead say
x *= 2;
but then we wouldn't want to reinvent the overly verbose wheel.
I agree though that there is a challenge to make Java language
extensions feel like language growth rather than mutation but I would
still hope the aim is to enhance function and maintain readability -
I'm less worried about 'style' given that this language is a tool and
not some fashion item.
I'm also just not sure it's as objectively black and white as you make
out nor am I sure that everything java is a good thing (such as the
verbosity of some constructs).
I for one wouldn't mind adding keywords if they clearly and surely
improve readability. Altering programs that are broken by such
changes are generally fairly easily corrected with tools to help --
and unless we choose poorly, it's unlikely a new keyword will have the
impact that introducing assert did. Assert was so heavy used in
testing frameworks, pervasively used across the market and across each
source-base - not every word is so heavily used as identifiers in
code.
I look forward to seeing more proposals, there are some (in part and
sometimes in full) that sound quite reasonable and I can see myself
finding a use for them.
--
Talden
More information about the coin-dev
mailing list