there are undoubtedly a lot of very intelligent people writing Java, better programmers than I will ever be. I just wish I knew why
For many developers Java is a stepping stone from the world of C and C++. Compared to those languages Java isn't verbose or restrictive at all. For many of those developer Java is their first taste of a language with built in objects and a garbage collector. It makes for a smooth transition.
Re: Java is Object-Oriented COBOL
Steve Holden · 2004-04-01T14:22:00
For many developers Java is a stepping stone from the world of C and C++
Fair point. Would you care to estimate the proportion of java developers for whom this is true? I can see that Java would seem attractive in some ways, but I'd say C was terser. And, of course, Java explicitly prohibits many of the things that C specifically used for in a systems environment (casts are easy in C, union types allow implicit conversion, and so on).
I may not be in touch with your average C programmer, but I'd have thought many of them use C precisely to get at these aspects of the systems they program.
I haven't used C++ enough to comment.
Re: Java is Object-Oriented COBOL
Greg Gaughan · 2004-04-01T15:32:00
> Thing aThing = new Thing(); > ...Java is so type-strict, surely the type > of the result of calling the Thing() constructor can be > inferred, making the type at the start of the declaration > unnecessary?
The type at the start of the declaration is there for cases when the constructor is for a sub-class and you want your code to use polymorphism, e.g.
Shape s = new Square();
s.draw();
Where you want to be able to use s.draw() even if you decide to create a Circle or something else descended from Shape. Declaring s as Shape keeps its generality so you can use a common set of method calls to handle all Shapes and still have compiler-time type-checking.
By the way, I agree with your point: after using Python, Java and C# seem over-elaborate and less expressive. Far too many curly brackets, type specifiers and hard-to-remember libraries.
Re: Java is Object-Oriented COBOL
Javid Jamae · 2004-04-01T16:02:00
Variable Name vvvvv Thing thing = new NotThing(); ^^^^^ ^^^^^^^^^^^^^^ Type Instantiation Declaration
Are you saying that you would only get rid of the type declaration when you are declaring the type and instantiating the object in the same statement? What about when you are instantiating an object in a separate statement?
Thing thing; . . thing = new Thing();
or
Thing thing = getOneOfThoseThings();
If you are arguing that the type declaration should go away all together, then it sounds like you are arguing that Java should be weakly typed. I disagree with that, but to each his own. I don't understand how you could maintain strong typing without type declarations. Then again, there are many things that I don't understand.
If you are not arguing that the type declaration should go away all together, but just when the variable is instantiated and declared in the same statement, then I would say that the only harm/difficulty is breaking an existing idiom.
Re: Java is Object-Oriented COBOL
Isaac Gouy · 2004-04-01T16:54:00
I will scream. Java is so type-strict, surely the type of the result of calling the Thing() constructor can be inferred, making the type at the start of the declaration unnecessary?
Yes, it's nothing to do with being type-strict, this works fine in other statically checked languages that run on JVM, like Nice and Scala and ...
> While I understand the need for integer and Integer Why do we have to deal with this int/Integer nonsense in Java 1.5?
List<Integer> myList = new ArrayList<Integer>();
myList.add( new Integer(4875) );
The Nice version is... Nicer
let myList = new ArrayList();
myList.add(4875);
// now myList has type ArrayList<int>
> Do we really have to design our languages > with execution efficiency as a foremost consideration in > the twenty-first century?
For 2 or 3 languages yes, for the rest no - and wouldn't designing languages for efficiency mean designing clean languages with few special cases, like Oberon-2.
the title of this piece does COBOL a disservice Yes it does. OO Cobol is Object Oriented Cobol. Some are choosing to move their mainframe apps to Cobol on .Net rather than rewrite them on J2EE.
Re: Java is Object-Oriented COBOL
Michael Feathers · 2004-04-01T17:20:00
All I can say is that if you think that Java is OO COBOL, you mustn't have seen VB.NET yet. To make an abstract class you use the keyword 'mustinherit.' To make an abstract method you use the keyword 'mustoverride.'
Re: Java is Object-Oriented COBOL
Malte Finsterwalder · 2004-04-02T02:38:00
Yes, Java is verbose in a lot of ways. But it is in it's own way somehow consistent, when I think about it.
Why is Java used so widespread? - Big companies are commited to Java. - Java was or still is hype. - There are tons of (cheap) Java developers. - There are a lot of standardized libraries. - There are a lot of other libraries (Open source as well as commercial). - There are tons of tools. A lot of them are free, incl. the basics: compiler etc., IDEs - Everybody else does it.
It boils down to: Java is mainstream
Are these good reasons? Decide for yourself...
Greetings, Malte Finsterwalder
Re: Java is Object-Oriented COBOL
Wolfhart Bauer · 2004-04-02T03:06:00
> Yes, Java is verbose in a lot of ways. But it is in it's > own way somehow consistent, when I think about it.
Why is everyone here suggesting that verbose code is a bad thing? When there is code that I do not understand, it's not because it's too verbose, but because it does not reveal its inner working by use of structuring, variable names etc. I could show you some Perl code that is absolutely not verbose but actually quite difficult to understand.
When I'm writing code, the bottleneck is not how fast I can type (luckily quite fast), but how fast I can think of what to do. However it may be different for others.
Maybe the question of verbosity is just a question of personal taste.
Re: Java is Object-Oriented COBOL
Dmitry Beransky · 2004-04-02T10:15:00
I've shut myself in a foot so many a time in C, Perl, PHP and the likes that Java's imposed type strictness is nirvana to me. Wouldn't have any other way for an extensive, long run and intricate project. On the other hand, yes, if I need a quick, dirty and non-lasting solution, a dynamically typed language would be my choice. It always comes down to choosing the right tool for the job.
> Relative import and class path management
Relative import sounds like something potentially interesting, but I haven't had any problems with the current way of importing classes.
As far as path management goes... This has nothing to do with either Java or JVM. It's just how the bootstrap class loader is implemented. You can always write your own bootstrap code and load the classes from a database if you really want to.
> While I understand the need for integer and Integer (and > similarly for many other primitive types and their > corresponding wrapers) for efficiency reasons, it > certainly doesn't make Java easier as a first programming > language
this is moot with JDK 1.5's auto-(un)boxing feature.
> which supports my suspicion that there are a lot of > "cut-and-paste merchants" masquerading > as programmers
Yeh. what's your point? :) When a language matures and development commoditizes, that's what you get. I don't think one can escape this trend. In fact, when this does happen, it is IMHO an unmistakable sign that the language is ready for prime time use in serious enterprise level projects.
> Last time I looked, I found a closely-printed book of > over a thousand pages documenting the many and varied > interfaces the programmer can use to do whatever he or > she needs. I don't imagine this has been simplified or > streamlined in the intervening years
I agree that some of those libraries can use revisioning. However, let's not confuse the language with the libraries. The language is quite compact (at least pre 1.5) and easy to learn. But hey, if you want to use Java for sophisticated projects, you better use sophisticated libraries. If not, there's an abundance of much simpler libraries thanks to Java's vibrant developer community.
Re: Java is Object-Oriented COBOL
Ian Phillips · 2004-04-01T11:42:00
"Do we really have to design our languages with execution efficiency as a foremost consideration in the twenty-first century?"No. See http://www.paulgraham.com/arc.html for a language being designed awith quite the opposite in mind.
Re: Java is Object-Oriented COBOL
Pete Lyons · 2004-04-01T12:19:00
there are undoubtedly a lot of very intelligent people writing Java, better programmers than I will ever be. I just wish I knew whyFor many developers Java is a stepping stone from the world of C and C++. Compared to those languages Java isn't verbose or restrictive at all. For many of those developer Java is their first taste of a language with built in objects and a garbage collector. It makes for a smooth transition.
Re: Java is Object-Oriented COBOL
Steve Holden · 2004-04-01T14:22:00
For many developers Java is a stepping stone from the world of C and C++Fair point. Would you care to estimate the proportion of java developers for whom this is true? I can see that Java would seem attractive in some ways, but I'd say C was terser. And, of course, Java explicitly prohibits many of the things that C specifically used for in a systems environment (casts are easy in C, union types allow implicit conversion, and so on).
I may not be in touch with your average C programmer, but I'd have thought many of them use C precisely to get at these aspects of the systems they program.
I haven't used C++ enough to comment.
Re: Java is Object-Oriented COBOL
Greg Gaughan · 2004-04-01T15:32:00
> Thing aThing = new Thing();> ...Java is so type-strict, surely the type
> of the result of calling the Thing() constructor can be
> inferred, making the type at the start of the declaration
> unnecessary?
The type at the start of the declaration is there for cases when the constructor is for a sub-class and you want your code to use polymorphism, e.g.
Where you want to be able to use s.draw() even if you decide to create a Circle or something else descended from Shape. Declaring s as Shape keeps its generality so you can use a common set of method calls to handle all Shapes and still have compiler-time type-checking.
By the way, I agree with your point: after using Python, Java and C# seem over-elaborate and less expressive. Far too many curly brackets, type specifiers and hard-to-remember libraries.
Re: Java is Object-Oriented COBOL
Javid Jamae · 2004-04-01T16:02:00
Are you saying that you would only get rid of the type declaration when you are declaring the type and instantiating the object in the same statement? What about when you are instantiating an object in a separate statement?
or
If you are arguing that the type declaration should go away all together, then it sounds like you are arguing that Java should be weakly typed. I disagree with that, but to each his own. I don't understand how you could maintain strong typing without type declarations. Then again, there are many things that I don't understand.
If you are not arguing that the type declaration should go away all together, but just when the variable is instantiated and declared in the same statement, then I would say that the only harm/difficulty is breaking an existing idiom.
Re: Java is Object-Oriented COBOL
Isaac Gouy · 2004-04-01T16:54:00
I will scream. Java is so type-strict, surely the type of the result of calling the Thing() constructor can be inferred, making the type at the start of the declaration unnecessary?Yes, it's nothing to do with being type-strict, this works fine in other statically checked languages that run on JVM, like Nice and Scala and ...
http://nice.sourceforge.net/index.html
> While I understand the need for integer and Integer
Why do we have to deal with this int/Integer nonsense in Java 1.5?
The Nice version is... Nicer
> Do we really have to design our languages
> with execution efficiency as a foremost consideration in
> the twenty-first century?
For 2 or 3 languages yes, for the rest no - and wouldn't designing languages for efficiency mean designing clean languages with few special cases, like Oberon-2.
the title of this piece does COBOL a disservice
Yes it does. OO Cobol is Object Oriented Cobol. Some are choosing to move their mainframe apps to Cobol on .Net rather than rewrite them on J2EE.
Re: Java is Object-Oriented COBOL
Michael Feathers · 2004-04-01T17:20:00
All I can say is that if you think that Java is OO COBOL, you mustn't have seen VB.NET yet. To make an abstract class you use the keyword 'mustinherit.' To make an abstract method you use the keyword 'mustoverride.'Re: Java is Object-Oriented COBOL
Malte Finsterwalder · 2004-04-02T02:38:00
Yes, Java is verbose in a lot of ways. But it is in it's own way somehow consistent, when I think about it.Why is Java used so widespread?
- Big companies are commited to Java.
- Java was or still is hype.
- There are tons of (cheap) Java developers.
- There are a lot of standardized libraries.
- There are a lot of other libraries (Open source as well as commercial).
- There are tons of tools. A lot of them are free, incl. the basics: compiler etc., IDEs
- Everybody else does it.
It boils down to: Java is mainstream
Are these good reasons? Decide for yourself...
Greetings,
Malte Finsterwalder
Re: Java is Object-Oriented COBOL
Wolfhart Bauer · 2004-04-02T03:06:00
> Yes, Java is verbose in a lot of ways. But it is in it's> own way somehow consistent, when I think about it.
Why is everyone here suggesting that verbose code is a bad thing? When there is code that I do not understand, it's not because it's too verbose, but because it does not reveal its inner working by use of structuring, variable names etc. I could show you some Perl code that is absolutely not verbose but actually quite difficult to understand.
When I'm writing code, the bottleneck is not how fast I can type (luckily quite fast), but how fast I can think of what to do. However it may be different for others.
Maybe the question of verbosity is just a question of personal taste.
Re: Java is Object-Oriented COBOL
Dmitry Beransky · 2004-04-02T10:15:00
I've shut myself in a foot so many a time in C, Perl, PHP and the likes that Java's imposed type strictness is nirvana to me. Wouldn't have any other way for an extensive, long run and intricate project. On the other hand, yes, if I need a quick, dirty and non-lasting solution, a dynamically typed language would be my choice. It always comes down to choosing the right tool for the job.> Relative import and class path management
Relative import sounds like something potentially interesting, but I haven't had any problems with the current way of importing classes.
As far as path management goes... This has nothing to do with either Java or JVM. It's just how the bootstrap class loader is implemented. You can always write your own bootstrap code and load the classes from a database if you really want to.
> While I understand the need for integer and Integer (and
> similarly for many other primitive types and their
> corresponding wrapers) for efficiency reasons, it
> certainly doesn't make Java easier as a first programming
> language
this is moot with JDK 1.5's auto-(un)boxing feature.
> which supports my suspicion that there are a lot of
> "cut-and-paste merchants" masquerading
> as programmers
Yeh. what's your point? :) When a language matures and development commoditizes, that's what you get. I don't think one can escape this trend. In fact, when this does happen, it is IMHO an unmistakable sign that the language is ready for prime time use in serious enterprise level projects.
> Last time I looked, I found a closely-printed book of
> over a thousand pages documenting the many and varied
> interfaces the programmer can use to do whatever he or
> she needs. I don't imagine this has been simplified or
> streamlined in the intervening years
I agree that some of those libraries can use revisioning. However, let's not confuse the language with the libraries. The language is quite compact (at least pre 1.5) and easy to learn. But hey, if you want to use Java for sophisticated projects, you better use sophisticated libraries. If not, there's an abundance of much simpler libraries thanks to Java's vibrant developer community.
Page 1 of 4 · Newer comments
Back to post