Using D

[Chris via Digitalmars-d]

On Monday, 25 August 2014 at 07:47:45 UTC, Marco Leise wrote:
> Am Sat, 12 Jul 2014 11:38:08 +0100
> schrieb Russel Winder via Digitalmars-d
> <digitalmars-d at 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.

The main thing that put me off Java was not so much the fact that 
you're restricted to OOP and that it's verbose etc., but that it 
caused all sorts of problems when shipping the actual programs. 
"Write once run everywhere" is a myth, if you ask me. D is much 
closer to that than Java. In the end we encountered so many 
problems that I dumped Java for cross platform development (and 
for development in general). Nobody in the Java world ever talks 
about this, but cross platform doesn't really work (apart from 
running simple programs).

But the points you made about IDE's and naming conventions etc. 
are good points insofar as they explain why Java was embraced by 
the industry. It's a bit of a no-brainer, people just have to 
follow the same well trodden path, which in turn enables 
companies to train people fast (= cheap) and to hire loads of 
intermediate (and in some cases mediocre) programmers whom they 
pay less, of course.