Slashdot Mirror
Q&A With James Gosling, Father of Java
Minaloush writes to tell us that in a recent Q&A with Sun's James Gosling, the father of Java fielded questions on the GPL, security, the role of Java in the enterprise. "If you come up with a good software development tool, that makes life easier for the developers and they can get their job done quicker, then the first thing the manager says is 'oh you've got free time on your hands. Do this extra thing'."
Either great minds think alike or he is stealing from the best.
Warning: The intelligence of this post may be larger than it appears.
Crafting tools is not wasting time. Frequently the fastest way to accomplish s six-week project is to take a month to write the tool...which will then complete the project in under a week. Management with your attitude will a) never see tools produced that increase the department's overall productivity and b) you won't have the best people working for you. No one likes working in a hamster wheel, and your shop smells of cedar shavings from here.
I'd really like to ask him what he is doing about Microsoft's efforts to poison Java.
I have been doing some peripheral help with a Java converter that converts from GML to Java, and it doesn't seem very cross-platform to me, even though it has no dependencies. The converter gives odd errors on different platforms - even on different XP machines! And the pure Java code it outputs doesn't run on Macs.
IMHO, using platform-specific dependencies (like DLL's) should be the only possible way to make Java that isn't cross-platform.
The government can't save you.
"No one likes working in a hamster wheel, and your shop smells of cedar shavings from here." - TaleSpinner
After all, you have to use a Java IDE a lot longer to get a GUI layout right. Netbeans and Eclipse should catch up in ease of use in GUI development circa 1990 any day now.
"The reason Java isn't a footnote in history is because of the enormous efforts people and companies other than Gosling and Sun have invested in fixing up its problems and turning Java into a decent platform for server-side development."
Bollocks. The Java API is rather brilliant in both its usability and its extensive features, not to mention its documentation. The Java language is rather easy to learn (many, many universities use it as the first language of choice) and isn't too far from C++ to be easily learned. And it's memory protection and garbage collection make life *much* easier and safer. That is the reason why Java succeeded, and most, if not all of it (in the first years) by extensive help by Sun. And Sun is also responsible for keeping Java the clean language it is today, without pre-processor, without operator overloading, properties and all the other things that makes maintaining C++ so much *fun*.
Java is in no way shape or form an analogy to COBOL. It's a fast, maintainable, highly portable language that's used to write a huge amount of new software today.
Your predjudice is baseless. The reasons behind the existence of both languages have a great deal of overlap.
No language, no matter how "fast, maintainable, [or] highly portable language", can prevent an enterprise app from becoming a total maintenance nightmare after 20 years of feature creep. That's why it's analogous to COBOL. A few decades from now, extensive and current Java experience will command some nice consulting fees. I also predict Ruby/Python knowledge to become about as useful Pascal.
I imagine a few years after the last piece of the staggering amount of enterprise Java code out there has been phased out.
Seeing that COBOL is still being maintained, and Java is getting taken up more and more atm, I guess that'd make it around 50 years from now.
Frequently the fastest way to accomplish s six-week project is to take a month to write the tool...which will then complete the project in under a week. Management with your attitude will a) never see tools produced that increase the department's overall productivity and b) you won't have the best people working for you.
What are you talking about? Are you saying you should be able to sit on your ass for two weeks, because you brought in something ahead of schedule? Guess what: you're being paid to work. If you bring in something ahead of schedule, you should expect a "nice job" with points that count eventual promotion and pay raise -- along with a new assignment.
Or to put it another way, when you're late with an assignment, do you pay the company back for the time you've wasted? Thought not.
Respect is a two-way street. No one like working in the hamster wheel, but no one likes managing (or working with) the prima donna who thinks he can just put in solid work when he feels like it.
Sometimes it's best to just let stupid people be stupid.
Java is a miserable failed academic experiment. It is written for the people who enjoy a healthy dose of philosophy in their work life, yet never actually need to work on anything practical. For the developers of Java, a programming language is not a tool to solve problems. It's an exercise in philosophy.
I work with Java professionally and I spend a frightful amount of my time just fixing the underlying system. Swing, lack of closures and multiple inheritance, lousy string handling, fantastically bloated code base, and so forth, are just some of the things that threaten my sanity on a day to day basis.
Not so...
;-)
The 'super' classes wouldn't be abstract, sure, but you would implement an IVehicle interface, then wrapper any IVehicle object (presumably Vehicle) as a private member object in a Car class, forwarding all the methods you wished to forward. Car would implement both ICar and IVehicle of course.
The forwarding could be done manually; automagically through an IDE; via a keyword to be interpreted by the compiler (such as 'private forward IVehicle myVehicle = new Vehicle()') on the member variable object; even assumed(!) such that if one and only one private member object implements the same interface it would implicitly receive forwarded calls, rather like the way the compiler adds implicit super constructor calls for null constructors.
A Mustang class would contain a private member declared as ICar, but would not necessarily have an IMustang interface as it would be redundant.
This takes nothing away. All objects simply define what interfaces they support, and can then be treated as such in each processing context. We would not have two different methods for defining typing of objects, leading to a 'strong type' for objects.
As a bonus, it would provide polymorphism. CarBoat for example would have private member variable objects declared as ICar and IBoat, and CarBoat would implement ICar, IBoat and IVehicle. Forwarding of IVehicle methods would of course have to explicit as both the ICar and IBoat objects would be eligible targets as they both implement IVehicle. A compiler error would occur if this explicit forwarding was not provided.
Simple and elegant. Perhaps we should fork Java as described and call it Kava
Justin.
You're only jealous cos the little penguins are talking to me.