On 25.08.2014 10:55, Marco Leise wrote:
Am Sat, 12 Jul 2014 11:38:08 +0100
schrieb Russel Winder via Digitalmars-d
<digitalmars-d@puremagic.com>:
That's not to say that Java, the language, (as opposed to the class
library or the marketing hype) isn't a pretty good language. In fact,
it's quite a beautiful language -- in the idealistic, ivory tower,
detached-from-real-life sense of being a perfect specimen suitable for a
museum piece. Its disconnect from the messy real world, unfortunately,
makes it rather painful to use in real-life. Well, except with the help
of automated tools like IDEs and what-not, which makes one wonder, if we
need a machine to help us communicate with a machine, why not just write
assembly language instead? But I digress. :-P
Now this is mis-direction. Java is a real-world language in that it is
used in the real world. Whilst there are many using Java because they
know no better, many are using it out of choice. Java evolves with the
needs of the users prepared to get involved in evolving the language.
Yes, Java is verbose, but its modularity makes it very
flexible. The classic example is how you read lines of text
from a file. Instead of a special class for that, you take
use simple primitives with descriptive names and assemble
something that reads lines of UTF-8 text from a buffer that
has a file as its input. It actually acknowledges quite a bit
of real-world mess when you look at it, for example different
encodings on stdin and stdout.
Conventions like beans, where every property is implemented as
a pair of getter/setter or naming rules like ...Adapter,
...Comparator make it easy to reflect on unknown code.
On the one hand it is limiting to only have Java OOP in the
toolbox, on the other hand it is cheap to train someone on
Java and Java libraries and actually not a horror to try and
make sense of other people's code, because it wont be
implemented in any of 5 different paradigms + s.o.'s personal
naming conventions.
I've never been a fan of developing in vi or emacs and as far
as I am concerned, a programming language need not be designed
like a human language. There are many graphical programming
environments as well, for example for physics.
The simpler the language the more robust the refactoring tools
can become. The more conventions are in use, the better custom
tailored tools and IDEs can emerge. I.e. in Eclipse you only
type the capital letters of a long class name and have the
auto-completion figure out which class in scope or available
import paths matches these "initials". Heck, it even fills in
the parameters when you call a method using the available
variables in scope. If you were unaware that you need a third
argument, the IDE can generate a new variable with a name
based on the method parameter or place a constructor call for
the required type.
Sometimes you can just focus on the program logic and have the
IDE generate most of the code. Delphi's and C# IDEs similarly
expose properties of GUI objects in tables and generate the
code for event handlers on double-clicks. It saves time, you
cannot misspell anything... I like it.
Agree, follows my experience in the industry as well. Although sometimes
I am a bit dismayed by the skill level of certain programmers we get in
our projects.
I am also an IDE fan. Can master Emacs and dabble in VI, but IDE are the
way to go, since my MS-DOS/Amiga days.
--
Paulo
