Oh - and no, I don't think all things are better in Java; the OP is certainly wrong on that front. I use Java for large server-side systems, C++ for native performance apps, sometimes Perl for small web tools. Horses for courses - sweeping generalisations are for the ignorant.
I sympathise with your position - indeed, managing client-side Java apps / plugins can be a total nightmare when people mess with different versions of the JRE and various optional addons.
However, I think it's unjustified to point this frustration at Java itself. It's the people who write the applications that way that are at fault - basically they've given no thought to the operational practicality of what their developing (a scarily common trait - I've been in both operations and development so I can see both sides).
Java, IMHO, is a very good solution for web-driven server-side applications. In these cases, your servers are configured one way, with one container (WebSphere / WebLogic / JBoss etc), and hence one JRE. The client doesn't need to know any of that - there is absolutely no reason why an ecommerce site needs to download anything at all to the client. I will gleefully jump up and down on anyone who thinks that making an applet (or ActiveX control for that matter) or downloadable client component part of a web application is somehow a good idea. Thin, configuration agnostic client access is the point of a web system, for christ sakes. Just because you _can_ download fat components, doesn't mean it's a good idea.
If your 'Java advocates' are promoting the extensive use of client Java components, then your urge to shoot them can be well understood. I think the problem is that you've been lumbered with the wrong Java advocates. Java, like any tool, is great when used in the right ways. Fat client assemblies is not Java's strong point - large server-side apps certainly are. It's a shame you've had your opinion of what can be a very powerful and practical technology (when used right) tainted by some uninformed people.
I think the whole argument is pointless. I've got 10 years programming experience in a great many languages (including all the ones listed here - including COBOL for gods sake) and there is no such thing as a 'most popular' or 'best' language. Each has it's strengths and weaknesses in different contexts. So you're not going to write an o/s in VB, nor are you going to write a business app in assembler. Horses for courses.
These arguments are all to do with opinion and personal preference rather than describing the 'world order'. And for the record, my personal preference is C++ / assembler for performance code, Java for business apps and pretty much any GUI builder for prototyping (yes, including VB). I consider C# to be a blatant, almost offensive plagiarism of Java (just less mature and with less features) so I see no point using it when I have Java available.
I wouldn't _choose_ to use COBOL for anything, but circumstances have made me learn it.;) But these are preferences, not facts. You'll likely find that a good proportion of the worlds systems are in COBOL or FORTRAN numerically speaking, but that doesn't mean they're the best does it?
Looking down your nose at people because of the language they use is very immature; at the end of the day the content of the code is far more important than the language used to write it.
For info, VC.Net's STL still suffers from serious flaws which is why we still require STLport in all MS builds of OGRE.
They didn't actually fix very much in the STL in VC.Net, they deferred a lot of it until the first service pack.
Cheers
Steve
Well, you're entitled to your opinion but I believe you've formed it prematurely.
Just to clarify, I do design everything before writing code. The documentation generated using doxygen is the API documentation intended to help people use it, it's not a design document.
I happen to believe that design documentation and API documentation are completely different animals - the former is there to explore and document the principles and overall strategy - such a design would be clouded by excessive detail. However API documentation needs to be detailed and precise. I believe doing both in one document is not the best approach. I also provide a set of tutorials to help orient the new user which include snippets of my original UML diagrams.
The rest of your comments just seem to be rants - if you have any comments specifically about the actual design (if you've even looked at it), I'd be happy to hear them. I don't see how just picking quotes off the site and picking apart their grammar to vent your frustration about design practices that you've seen is of much value.
Slashdot Mirror
Precisely, which is why OGRE is completely dynamically linked. We do in fact know our licenses, thank you.
Google would seem to think we're a more common use of the term 'OGRE' now ;)
http://www.google.com/search?q=OGRE
Oh - and no, I don't think all things are better in Java; the OP is certainly wrong on that front. I use Java for large server-side systems, C++ for native performance apps, sometimes Perl for small web tools. Horses for courses - sweeping generalisations are for the ignorant.
I sympathise with your position - indeed, managing client-side Java apps / plugins can be a total nightmare when people mess with different versions of the JRE and various optional addons.
However, I think it's unjustified to point this frustration at Java itself. It's the people who write the applications that way that are at fault - basically they've given no thought to the operational practicality of what their developing (a scarily common trait - I've been in both operations and development so I can see both sides).
Java, IMHO, is a very good solution for web-driven server-side applications. In these cases, your servers are configured one way, with one container (WebSphere / WebLogic / JBoss etc), and hence one JRE. The client doesn't need to know any of that - there is absolutely no reason why an ecommerce site needs to download anything at all to the client. I will gleefully jump up and down on anyone who thinks that making an applet (or ActiveX control for that matter) or downloadable client component part of a web application is somehow a good idea. Thin, configuration agnostic client access is the point of a web system, for christ sakes. Just because you _can_ download fat components, doesn't mean it's a good idea.
If your 'Java advocates' are promoting the extensive use of client Java components, then your urge to shoot them can be well understood. I think the problem is that you've been lumbered with the wrong Java advocates. Java, like any tool, is great when used in the right ways. Fat client assemblies is not Java's strong point - large server-side apps certainly are. It's a shame you've had your opinion of what can be a very powerful and practical technology (when used right) tainted by some uninformed people.
I think the whole argument is pointless. I've got 10 years programming experience in a great many languages (including all the ones listed here - including COBOL for gods sake) and there is no such thing as a 'most popular' or 'best' language. Each has it's strengths and weaknesses in different contexts. So you're not going to write an o/s in VB, nor are you going to write a business app in assembler. Horses for courses. These arguments are all to do with opinion and personal preference rather than describing the 'world order'. And for the record, my personal preference is C++ / assembler for performance code, Java for business apps and pretty much any GUI builder for prototyping (yes, including VB). I consider C# to be a blatant, almost offensive plagiarism of Java (just less mature and with less features) so I see no point using it when I have Java available. I wouldn't _choose_ to use COBOL for anything, but circumstances have made me learn it. ;) But these are preferences, not facts. You'll likely find that a good proportion of the worlds systems are in COBOL or FORTRAN numerically speaking, but that doesn't mean they're the best does it?
Looking down your nose at people because of the language they use is very immature; at the end of the day the content of the code is far more important than the language used to write it.
For info, VC.Net's STL still suffers from serious flaws which is why we still require STLport in all MS builds of OGRE. They didn't actually fix very much in the STL in VC.Net, they deferred a lot of it until the first service pack. Cheers Steve
Well, you're entitled to your opinion but I believe you've formed it prematurely. Just to clarify, I do design everything before writing code. The documentation generated using doxygen is the API documentation intended to help people use it, it's not a design document. I happen to believe that design documentation and API documentation are completely different animals - the former is there to explore and document the principles and overall strategy - such a design would be clouded by excessive detail. However API documentation needs to be detailed and precise. I believe doing both in one document is not the best approach. I also provide a set of tutorials to help orient the new user which include snippets of my original UML diagrams. The rest of your comments just seem to be rants - if you have any comments specifically about the actual design (if you've even looked at it), I'd be happy to hear them. I don't see how just picking quotes off the site and picking apart their grammar to vent your frustration about design practices that you've seen is of much value.