Am Sat, 12 Jul 2014 11:38:08 +0100 schrieb Russel Winder via Digitalmars-d <[email protected]>:
> > 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. -- Marco
signature.asc
Description: PGP signature
