On 1/27/13 8:56 AM, deadalnix wrote:
On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
On Sunday, 27 January 2013 at 13:24:31 UTC, TommiT wrote:
But, joking aside, I think that all hate against optional parentheses
stems from the increase of ambiguity they indisputably cause.
However, let's imagine a future where your perfect D IDE paints
function calls red, and variables blue. Then, it will be obvious to
you which identifiers are variables and which are function calls
based on their color. In this situation it will feel silly to have to
write those empty parentheses, because they don't make the code any
less ambiguous (it's already perfectly unambiguous because of the
colors) and, infact, those empty parentheses make the code (a bit)
harder to read.
If we require clever IDE to distinguish visually something as basic as
data semantics and callable semantics it is an indicator language
design is screwed. Relying on IDE features is what made Java unusable
for expressive, robust code. I may use an IDE help when I need to
learn architecture level connections in new project, but at scope
level semantics for reader should be perfectly clear and unambiguous
even if opened in notepad.
2 cents from vim user and optional parens hater here.
You're being an extremist here. From a vim user and automagic function
call hater as well ;)
First many reliable code have been written in Java. Quite a lot of it in
fact. And refusing IDE help make no real sense. Even vim is an IDE, and
not a simple editor.
Language adoption is a complex phenomenon with many variables, and it's
easy to neglect certain aspects when assessing the impact of others.
Java started as a well-designed language albeit small and underpowered.
It enjoyed the benefit of unwavering support from a large corporation
and an estimated one billion dollars in marketing budget. (I remember in
1998 non-programming managers in NYC were talking "we must adopt Java!"
without even knowing what Java meant. Java may as well be the only
programming language in history to enjoy management support before
programmer support.)
That has caused Java to evolve quite differently from languages with
grass-roots support (e.g. C++, Ruby, PHP, or Python). Generally the
latter languages grew with little tooling support aside from the
traditional Unix toolset, and that is to some extent reflected in the
languages themselves.
The same goes about C#, which was designed from day 1 assuming resources
are available for dedicated tooling support. It would have evolved
differently otherwise, and I assume many people would have a dimmer view
of either Java or C# if they had to use it with vim and emacs.
Andrei
