Registered: Feb, 2004
Re: The Problem with Programming
Posted: Nov 29, 2006 10:00 AM
> I really know nothing about J2EE, but my take on this is
> that a lot of Java code complexity stems from single
> object hierarchy and everything is object approach.
No, this is a red herring (besides, not everything is an Object in Java, which some people like and other people hate. Damned if you do, damned if you don't).
The reality of today's programming is that we are way past the language barrier. It doesn't really matter any more if you support multiple inheritance of operator overloading (which solve micro-problems), but it does matter a great deal if your development environment lets you load classes and introspect them on the fly, if you can easily write dynamic web pages that comply to respected design patterns such as MVC, if you can easily marshal objects between processes or machines, if you can implement and debug multi-thread code with powerful IDE's, if those IDE's support easy browsing, code completion, refactoring, source control and other advanced concepts, etc...
Fifteen years, I understood Bjarne's decision to not include a hashtable to the STL because it was hard to specify and we wanted to hit the deadline, but now...?
C++ is still stuck in the old language wars and has never moved to the next level: standardized frameworks.
> > I have surveyed and even worked on "J2EE-like" solutions
> > written in C++, and trust me, it was not pretty.
> > Why? Because C++ doesn't have standard libraries for
> > "modern programming" (multithreading, remotability,
> > security, servlets, introspection, dynamic loading,
> > etc...), so you end up reusing non-standard ones or
> > rolling your own. Add this to the intrinsic complexity of
> > the language, its non-portability and still very-buggy
> > compilers, and you'll quickly find out why Java is more
> > productive.
> This is a valid point. C++ is not owned by any corporation
> and an international standard, so introducing new features
> and libraries is a long and complex process.
> As far as compilers, things are definitely getting much,
> much better in the recent years. Parsing a monster like
> C++ is not an easy job.
It's not just about parsing, it's also about user-friendliness, with problems such as issuing huge template error messages that don't even reuse your typedefs. We used to have this problem 10 years ago when I was breathing C++ ten hours a day, and I just can't believe it hasn't been solved now. And that's just one example.
> Also, there are serious and high quality C++ frameworks
> available comparable with the richness of Java standard
> Here are a few links:
No doubt, but you are missing my original point: these are not "standard". They are not shipped with C++ (and if they were, they would probably differ in implementation anyway). This results in a heavy knowledge fragmentation with every C++ programmer being an expert on a different domain or framework.
> For most things definitely. But when the rubber meets the
> road and you have to do a critical piece of code, guess
> what you use. As an example, take Google's map reduce:
Most people use Java to access MapReduce :-)
> > How so? Both languages are equally strongly typed.
> What about type erasure in Java?
It only matters at the bytecode level. Source-wise, C++ and Java have comparable levels of type safety.
> I'm no Java pundit by any stretch of imagination, but it
> seems to me that they've got themselves in hot water with
> generics - they are much needed, but nobody seems to be
> pleased with it.
I think you are misreading the community. We all have our personal complaints, but overall, Generics have been widely accepted. Which is not surprising, because the feature was designed and voted in by that community.