Q&A With James Gosling, Father of Java 172
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'."
Expectations (Score:2, Insightful)
Either great minds think alike or he is stealing from the best.
Re:Yeah, so? (Score:5, Insightful)
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.
Questions (Score:3, Insightful)
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.
Re:Another reason I can avoid Java (Score:5, Insightful)
Re:Yeah, so? (Score:2, Insightful)
Perhaps "most used" means more hours (Score:3, Insightful)
Re:ugly child (Score:4, Insightful)
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*.
Re:Declining Popularity? Not quite... (Score:4, Insightful)
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.
Re:Uh yeah... (Score:3, Insightful)
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.
Re:Yeah, so? (Score:4, Insightful)
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.
Re:ugly child (Score:2, Insightful)
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.
Re:Perhaps "most used" means more hours (Score:3, Insightful)
You mean that Java/Swing can get rid of the fantastic dynamic resizing capabilities and return to the days of fixed-size windows? Fantastic, to hell with the user changing monitor sizes, going to bigger fonts, etc...
Re:best Gosling quote ever... (Score:3, Insightful)
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.