Dr. Dobbs: "C++ vs. JEE"

Discussions

News: Dr. Dobbs: "C++ vs. JEE"

  1. Dr. Dobbs: "C++ vs. JEE" (90 messages)

    Dr. Dobb's Journal has posted an article by Stefan Wörthmüller called "C++ vs. JEE," described as "One C++ programmer's experience and impressions when moving to Java." He starts the article off with this statement:
    Of course, I've always been open minded towards Java -- especially J2EE -- and using the JBoss application server solved a lot of the work for free. But as the project proceeded, I saw that we didn't have fewer problems, just different ones.
    The run-time library is a strength of Java, he says, but the JVM is a liability:
    The main differences between Java and C++ are Java's lack of pointers and its garbage collector. The downside is the introduction of a third-party -- the Java Virtual Machine (JVM) -- between your program and the operating system. This sounds good if you're planning on a simple application or if you need GUI portability. But it also introduces new problems, especially if you haven't installed the "right" JVM version, or haven't installed a JVM at all.
    Even the application server has the problems associated with third parties: he questions their scalability and performance: "... application servers are often used in environments that have lots of users, generating heavy loads. Why use a computing and memory-intensive platform such as JEE for that?" He also says the strength of the JVM is the garbage collector, which is also a weakness, due to the pauses the GC introduces through a full GC. His conclusion tends to be biased towards C++:
    Thesis: JEE is better suited for writing server applications. Many mistakes can be avoided by the language, and much work is already done for you. Average programmers will make average mistakes. Thereby for an average and not highly demanding application, things like a garbage collector or prevention from pointers are an advantage. Antithesis: C++ is better suited for writing server applications. It gives you more control, more flexibility, and much more performance. Good developers will with ease take care of the problems of memory management, and they will be happy to manage pointers sometimes. C++ is not sophisticated, not simple, and there are deep pitfalls. Synthesis If you plan on large server applications that you expect will be used for a long time, you might be better of writing it in C++ if you have good C++ developers. For instance, consider Apache, written (of course) in C. In other cases, you might rather use JEE, but get a experienced administrator. Conclusion I still wonder why there are so few approaches for Web frameworks/toolkits or application servers written in C++. C++ is made for such a task. If you are in the situation of planning such a system, consider starting such a framework yourself. It might cost (much) more in the short term, at least until you have a working application. But in mid and long term, you (and maybe others too) will have many advantages. I think it will pay off.
    It's an odd conclusion. Most of his statements concerning the weaknesses of Java seem to be based on inexperience or organization limits. For example:
    1. The Garbage Collector He says that the GC introduces pauses, and that it would be preferable to be able to free resources explicitly. However, he doesn't show any awareness that there are alternate garbage collectors supplied with most VMs, or that some vendors supply solutions that eradicate GC pauses entirely (such as Azul, or BEA.)
    2. The Virtual Machine as a platform He doesn't actually state what his issues are with the VM in detail, other than to say that you might not have the right VM installed (or have a VM installed at all.) This seems like a red herring, however - for a server application, it should be fairly easy to make sure that a given software package is installed, and that it's the right version.
    3. C++ performs better ("much more performance") This is his "antithesis," his rebuttal of his original thesis that Java EE was a better solution for server applications. Benchmarks are misleading, of course, but most comparisons of C++ to Java performance in normal circumstances show that Java's performance is at least par with C++, and can exceed C++ performance as the Hotspot compiler (or equivalents, for non-Sun VMs) manages bytecode.
    What do you think of his conclusions? His bias is obviously towards C++, but it's worth considering his reasonings, even though it doesn't seem like his Java experience made the comparison fair. Your thoughts?

    Threaded Messages (90)

  2. Dr. Dobbs vs. C++[ Go to top ]

    This article merely reflects the fact that DDJ has reached a rather low level for its C++ articles. They swallowed CUJ years ago. Now they cannot even filter out articles like the above.
  3. Re: Dr. Dobbs vs. C++[ Go to top ]

    My work in the 90s involved C++ development for server applications. I moved to Java reluctantly. There are pluses and minuses to both environments, but what's excerpted here has to be the worst advice I've seen in print in a long time: specifically, the advice to build an application server like framework to save time in the long run. This is almost never a good idea and doing it from scratch in C++ is a horrific idea. At a minimum, if you're writing server codes in C++, you really want to be working with a toolkit to help with the networking. Our productivity went up dramatically writing network code with the ACE framework in C++. Another note: I was at Bluestone after the application server was rewritten from C to Java. I think there were plenty of concerns at the time, but every developer I talked to felt the productivity boost in development was huge.
  4. I was at Bluestone after the application server was rewritten from C to Java. I think there were plenty of concerns at the time, but every developer I talked to felt the productivity boost in development was huge.
    You may compare e.g. Java to .NET, Servlets/JSP to RoR or Ruby to Python. But it makes no sense to compare a platform to a language (as in the DDJ article).
  5. You may compare e.g. Java to .NET, Servlets/JSP to RoR or Ruby to Python. But it makes no sense to compare a platform to a language (as in the DDJ article).
    Exactly! Wrong comparison in this case.
  6. Re: Dr. Dobbs vs. C++[ Go to top ]

    but most comparisons of C++ to Java performance in normal circumstances show that Java's performance is at least par with C++, and can exceed C++ performance as the Hotspot compiler (or equivalents, for non-Sun VMs) manages bytecode.
    That's such a load of crap and again shows why benchmarks are meaningless. In real world apps, the fact is that Java cannot compete performance wise in general. The fact is that a NIO based server cannot compete with a native AIO or IOCP server scalability-wise. The fact is that a native GUI is snappier than one that isn't native (all things else beeing equal) But that doesn't mean anything, except that C++ is right for some tasks, Java for others.
  7. Re: Dr. Dobbs vs. C++[ Go to top ]

    I have experienced particular situations where C++ had a bigger performance compared with Java. Mostly in I/O programming with UNIX systems, but even in some of these cases I found it useful to integrate these low level layers with the Java frameworks through JNI. From my experience I think these two technologies (C++ and Java) have their own place in the enterprise world and with the correct architecture can even coexist and integrate when necessary to deliver fast, reliable, easy scalable solutions.
  8. Re: Dr. Dobbs vs. C++[ Go to top ]

    The fact is that a NIO based server cannot compete with a native AIO or IOCP server scalability-wise.
    Really ? I have seen some test results where performance of NIO is not significantly slower than C++ based server.
  9. Re: Dr. Dobbs vs. C++[ Go to top ]

    I have seen some test results where performance of NIO is not significantly slower than C++ based server.
    Why should it? NIO ist just a thin wrapper over navtive code.
  10. Re: Dr. Dobbs vs. C++[ Go to top ]

    I have seen some test results where performance of NIO is not significantly slower than C++ based server.

    Why should it? NIO ist just a thin wrapper over navtive code.
    Exactly. I have written some NIO based servers and I was happy about performance. Even guys who have written servers in both java and c++, prefer java.
  11. Re: Dr. Dobbs vs. C++[ Go to top ]

    The fact is that a NIO based server cannot compete with a native AIO or IOCP server calability-wise.
    This may be true for Windows but it's certainly not true at all for Linux and OpenSolaris. I've spent a great deal of my graduate studies researching various network server architectures and I can tell you based on experience that NIO based servers scale just as well as any native server and the performance difference is negligible. I hope to publish a paper soon that illustrates our findings.
  12. Re: Dr. Dobbs vs. C++[ Go to top ]

    but most comparisons of C++ to Java performance in normal circumstances show that Java's performance is at least par with C++, and can exceed C++ performance as the Hotspot compiler (or equivalents, for non-Sun VMs) manages bytecode.


    That's such a load of crap and again shows why benchmarks are meaningless.

    In real world apps, the fact is that Java cannot compete performance wise in general. The fact is that a NIO based server cannot compete with a native AIO or IOCP server scalability-wise. The fact is that a native GUI is snappier than one that isn't native (all things else beeing equal)

    But that doesn't mean anything, except that C++ is right for some tasks, Java for others.
    +1 A few years after converting a Fat Client app from C/C++ to JavaSwing, loads of memory and cpu upgrades...we happened to run the "old" C++ windows app and it was so much fater and snappier than the JavaSwing...we had to hide it to prevent the users from wanting the old one back! Its OK to accept that for some tasks C++ is faster....sometimes there can be other factors which help Java win
  13. Re: Dr. Dobbs vs. C++[ Go to top ]

    A few years after converting a Fat Client app from C/C++ to JavaSwing, loads of memory and cpu upgrades...we happened to run the "old" C++ windows app and it was so much fater and snappier than the JavaSwing...we had to hide it to prevent the users from wanting the old one back!
    Its OK to accept that for some tasks C++ is faster....sometimes there can be other factors which help Java win
    It could be the case that this slowness is an inherent part of moving to Java but how do we know? It could be that the app is slower because of poor design. I've never seen a performance problem in Java that was unavoidable. There have been a lot of really bad approaches that were pushed as effective ways to approach application design in Java. In addition, Swing was slow in it's own right for a number of years. It's improved greatly as has the general speed of the JVM. Anecdotal stories about how the Java app is so much slower than the C++ version are more meaningless than any benchmark you want to criticize. I have to use an application written in C++ that's dog slow. I know that I could write an app in Java that does this same thing and does it much faster. Does this prove that Java is faster than C++? Not by a long shot. If a house falls, down do you assume it happened because of bad bricks?
  14. Re: Dr. Dobbs vs. C++[ Go to top ]

    Just to some everyting up, C++ lost its place in the server side programming world. Because, most people are under time pressure and cannot spend manyears to kill broken pointers and memory leaks. Because most people want to rely on standardized libraries for most tasks not just basic io and collections. The downside is somewhat of a speed hit, which is bearable, because most applications do not need heavy processing. As for the garbage collection breaks, others have pointed it out already...
  15. Re: Dr. Dobbs vs. C++[ Go to top ]

    Because, most people are under time pressure and cannot spend manyears to kill broken pointers and memory leaks.
    Well, at least with respect to complexity, the Java language has successfully caught up with the C++ language in recent releases.
  16. Legacy vs. legacy[ Go to top ]

    Someone's got more time than sense. -John-
  17. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    C++ lost a lot of its territories to Java mainly because it doesn't have a standard, robust library that a developer can depend on regardless of version and vendor differences. C++'s attempt to do that was the introduction of STL, based on templates, a very ill-conceived idea from day 1. Instead of an inheritance oriented design like Java, which allows run-time flexibility, C++ template is a compiler pattern matching feature that has no run-time behaviors. Even worse is the fact that STL implementations were vastly different among different vendors, hardly standard at all. C++(or really just native code) performance is a shining spot for the language, especially in processing-intensive software such as graphics and scientific programs. The business data processing world, where Java is king, has little need for that kind of power. Business systems take large number of inputs but rarely do any intensive mathematical data manipulation. This is why there is always a need for powerful native languages like C++ do the heavy lifting. Good C++ developers see Java's garbage collector(or really the lack of direct access to memory) as a limitation. But to most average programmers who loath debugging memory leaks in their code, Java is the answer to their prayer. Overall, I think Java is a very suitable technology for business system software, which is where most of the software development needs are, because it boosted productivity for the majority of programmers who may not be the elites of the industry.
  18. I thought the thing of C++ vs Java was done in the 90's and those guys should know that almost everybody moved from C/C++ to Java. Is He still living in the dark age?. I use C++ sometimes but just for a few low level tasks or graphics programming that's all for now. Also he should note the world is moving towards and I think is moving to higher level of abstraction and Dynamic (Python, Ruby) Programming languages. Of course Java is here to stay for a long time still. Long live Java!.
  19. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    I thought the thing of C++ vs Java was done in the 90's and those guys should know that almost everybody moved from C/C++ to Java. Is He still living in the dark age?.

    I use C++ sometimes but just for a few low level tasks or graphics programming that's all for now.

    Also he should note the world is moving towards and I think is moving to higher level of abstraction and Dynamic (Python, Ruby) Programming languages. Of course Java is here to stay for a long time still.

    Long live Java!.
    Well there are even people nowadays who think they can program everything in assembly language... It is all a matter of having an infinite amount of time to solve a problem, then you even can use state machines ;-)
  20. He wrote "Java comes with 100-percent portable libraries, including (as does C++)" !! I guess C++ is 100% portable! Who knew!
  21. Memory management[ Go to top ]

    The real pain, though, is the need to tell the JVM on startup how much and what memory to use. That's like running MacOS 7.
    He's got a good point there though which I've never thought about. I don't know how many times I've had to go into various startup scripts and tell the JVM that yes, I have plenty of memory installed and yes, you're more than welcome to use it!
  22. Re: Memory management[ Go to top ]

    The real pain, though, is the need to tell the JVM on startup how much and what memory to use. That's like running MacOS 7.


    He's got a good point there though which I've never thought about. I don't know how many times I've had to go into various startup scripts and tell the JVM that yes, I have plenty of memory installed and yes, you're more than welcome to use it!
    Well in a server environment exactly this limiting of server ram is heavens sent, that way a program cannot gobble up all the system ram, it is live with the ram assigned to you or die. This increases server stability a lot. In a pure client envioronment this is a pain, I agree, especially since the default values of the jvm are way too low.
  23. Is this post a bad joke ? The guy makes false assumptions based on ignorance, then openly wonders why "there are so few approaches for Web frameworks/toolkits or application servers written in C++". Hilarious ! Maybe because it's not the right tool to do it ? Did he think about it ?
  24. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Is this post a bad joke ? The guy makes false assumptions based on ignorance
    He even claims that Hibernate introduced more problems than it solved. And he says that JEE needs experienced administrator. It's pure nonsense.
  25. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Is this post a bad joke ? The guy makes false assumptions based on ignorance


    He even claims that Hibernate introduced more problems than it solved. And he says that JEE needs experienced administrator. It's pure nonsense.
    Well it depends, orm mappers in a plain request based stateless environment can be a pain, but it is more a pain due to the fact that the people applying those things do not know enough about the environment and pitfalls they apply them too. Hibernate is not really at fault if you fight 90% of the time with errors like lazy instantiation excepton or object already loaded exceptions. I think the issue here is really that there is too few guidelines on how to apply orm systems to webapps in a decent manner.
  26. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Is this post a bad joke ? The guy makes false assumptions based on ignorance


    He even claims that Hibernate introduced more problems than it solved. And he says that JEE needs experienced administrator. It's pure nonsense.


    Well it depends, orm mappers in a plain request based stateless environment can be a pain, but it is more a pain due to the fact that the people applying those things do not know enough about the environment and pitfalls they apply them too.
    What is a plain request based stateless environment ? I think orm suitability depends more on the complexity of domain model rather that the interaction style (if I understand what you mean).


    Hibernate is not really at fault if you fight 90% of the time with errors like lazy instantiation excepton or object already loaded exceptions.
    Well, hibernate should be handled with care. Other ORMs play a little nicer ;)
    I think the issue here is really that there is too few guidelines on how to apply orm systems to webapps in a decent manner.
    No, I would not say so. I think that a lot of people are not used to design applications anymore. They think that is sufficient to put the products puzzle pieces together, as explained in the single tutorials, forcing their application to fit in that model. (Use hibernate, use spring, use JSF/Struts/whatever, shake for 20 seconds and voila' the architecture is done!! Now code and don't waste time with already solved design issues!!) Guido.
  27. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Is this post a bad joke ? The guy makes false assumptions based on ignorance


    He even claims that Hibernate introduced more problems than it solved. And he says that JEE needs experienced administrator. It's pure nonsense.
    I know a pretty good Unix administrator who won't touch Java stuff because his perception is that if you don't know Java you can't make any sense of the problems with Java applications.
  28. Is this post a bad joke ? The guy makes false assumptions based on ignorance


    He even claims that Hibernate introduced more problems than it solved. And he says that JEE needs experienced administrator. It's pure nonsense.


    I know a pretty good Unix administrator who won't touch Java stuff because his perception is that if you don't know Java you can't make any sense of the problems with Java applications.
    When a C++ app brings down the whole C++ appserver, what will the unix admin do? Will he know if it was caused by the app, or by the app server? Will he use gdb on a core file and figure out what caused the problem? How will your normal unix admin fix the defect in question? Java apps on JEE servers usually don't bring the server / jvm down (using JNI on the other hand to integrate C, C++ libs will usually bring the JVM down due to a seg fault).
  29. Is this post a bad joke ? The guy makes false assumptions based on ignorance


    He even claims that Hibernate introduced more problems than it solved. And he says that JEE needs experienced administrator. It's pure nonsense.


    I know a pretty good Unix administrator who won't touch Java stuff because his perception is that if you don't know Java you can't make any sense of the problems with Java applications.


    When a C++ app brings down the whole C++ appserver, what will the unix admin do? Will he know if it was caused by the app, or by the app server? Will he use gdb on a core file and figure out what caused the problem? How will your normal unix admin fix the defect in question?

    Java apps on JEE servers usually don't bring the server / jvm down (using JNI on the other hand to integrate C, C++ libs will usually bring the JVM down due to a seg fault).
    He'll restart the process and any junk it logged, the core dump, etc to the developer(s) or vendor responsible for the app. But throw the JEE app server in and there a whole new thing to administrate. Not only do you have to tune the OS, but you have to tune the JVM. You have the CLASSPATH to worry about, in addition to the regular paths. You have nested classpaths within the app server. So it requires an additional set of skills, a set of skills that blurs the lines between an admin and a developer. There's nothing inherently wrong with that. The bottom line is someone needs to have the skills.
  30. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    It seems to me that if you move from one language that you have a lot of experience with to a new language that you are fairly ignorant of and you say you have roughly the same amount of problems, it's a pretty good compliment for the new language. Of course you will have problems when you move to a new language. Does anyone think the author had the same number of problems with C++ at first as he does now?
  31. What most people fail to factor in is how much JEE gives you out of the box that a C++ solution does not (and thus would force you to either develop yourself or purchase). Oh, they may mention these things off hand, but they still fail to factor it in. For example, most JEE containers (JBoss included) give you a management interface for much less "cost" than the equivalent in C++. Moreover, because these management interfaces are usually based on a standard (JMX, for example), it is easy to register and manage your own custom components. Also, JEE and the Java community as a whole, have matured to the point where the solutions already available are immense timesavers, such as JPA (or Hibernate), etc. With Seam and other solutions, I can get an application up in no time. With JEE being a standard, much of what I need is already provided to me on a silver platter. All I have to do is wire it all together into the app I'm building. With C++, I'd be back to the drawing board on many of these things - either having to develop them myself, or pay big bucks to purchase a library. As for the JVM, garbage collection, scalability, etc... these are all now well understood problems, with solutions readily available via the Java community. Sure, you may be able to get C++ to scale better than Java, but it is going to take a lot of effort. In fact, I would argue that the development cost to scale C++ that way would outweigh the cost of adding more machines to a JEE cluster (built using freely available JEE containers). The open source app servers are getting much better at clustering these days.
  32. Migration trouble[ Go to top ]

    What we see with this article is typical for the migration problems. Stefan W. wrote that he used C++ for 18 years. I assume he has a fair amount of experience with C++, his golden hammer. Now he has to use something new, and who wonders he has problems. The real problem is that the amount training is usually underestimated. "C++ looks like Java, it can't be hard to learn that" is what I heared once to often. What is missing is the amount of changes involved, new language, thousands of new classes and new patterns to learn. New internet resources for information and a new tool set. All this is written in a short sentence but it might cost you weeks to find out what you are doing wrong, only because you don't know about X. And that's the trouble, the JEE environment provides so much that you can only use if you have the skills. And last but not least these people use screws which always break if I hammer them in. Screws are bad!
  33. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    The Power of the Java not only its maturity on server side but also its wide community.
  34. The main differences between Java and C++ are Java's lack of pointers and its garbage collector.
    As a long-term developer I had spent few Years developing serverside systems in C++ before I have switched to Java. I found this discussion quite interesting, but cannot resist to discuss above statement. First - this is not true - there are few GC implementations for C++, few of them were available before Java. IMO the main difference between Java and C++ is lack of standard library. Saying standard I mean - STANDARD - available for most flavors, compilators, platforms... Can You imagina language without standard support for multibyte strings? Can You imagine language without standard multithreading concurrency? Maybe You can live without standard primitives for threads? Or maybe databases? Definitelly, person comparing C++ to Java in the serverside context never ever used C++. Artur
  35. Another major difference between Java and C++ is reflection. These days, a great deal of the functionality and flexibility we take for granted on the Java platform is enabled by reflection (or byte code manipulation). These techniques are not available in any standard form for C++. (I'm referring to Standard C++, not C++/CLI.) Regards John Hurst Wellington, New Zealand

  36. The main differences between Java and C++ are Java's lack of pointers and its garbage collector.


    As a long-term developer I had spent few Years developing serverside systems in C++ before I have switched to Java. I found this discussion quite interesting, but cannot resist to discuss above statement. First - this is not true - there are few GC implementations for C++, few of them were available before Java.
    Now that you mention it, saying that Java lacks pointers is not true either. It lacks pointer-arithmetic, not pointers.
  37. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]


    The main differences between Java and C++ are Java's lack of pointers and its garbage collector.


    As a long-term developer I had spent few Years developing serverside systems in C++ before I have switched to Java. I found this discussion quite interesting, but cannot resist to discuss above statement. First - this is not true - there are few GC implementations for C++, few of them were available before Java.


    Now that you mention it, saying that Java lacks pointers is not true either. It lacks pointer-arithmetic, not pointers.
    No, the value of a C++ pointer is the physical memory address of a variable. It is not possible obtain the physical memory address of any variables in Java. So the author is right. Java lacks pointers.
  38. Pointers[ Go to top ]

    No, the value of a C++ pointer is the physical memory address of a variable. It is not possible obtain the physical memory address of any variables in Java. So the author is right. Java lacks pointers.
    Honestly: Do anyone except garbage collector writers care whether the value is a memory address or not? If you have a pointer to something you are usually interested in the something. Whether the implementation-specific value is an address or not does not matter to the higher-level programmer as long as the pointer can be copied, changed or dereferenced as needed. Java, Pascal and C++ pointers are therefore pointers. Except in C++ you have the necessary access to the innards to be able to wreck them. :) When you cast a pointer to an int because you are interested in its address, or you use pointer arithmetic to e.g. navigate an array, you are not using the "++" part - you are writing C.
  39. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    No, the value of a C++ pointer is the physical memory address of a variable. It is not possible obtain the physical memory address of any variables in Java. So the author is right. Java lacks pointers.
    No, a C++ pointer is not the physical memory address on most archs. It's the virtual memory address. And can you reference virtual memory addresses with Java? Yes, through jni.
  40. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    No, the value of a C++ pointer is the physical memory address of a variable. It is not possible obtain the physical memory address of any variables in Java. So the author is right. Java lacks pointers.


    No, a C++ pointer is not the physical memory address on most archs. It's the virtual memory address. And can you reference virtual memory addresses with Java? Yes, through jni.
    You CANNOT reference(read from or write to) any memory addresses, virtual or not, in Java code. JNI provides a window for you to call native code and transport the data into or out of the Java world. It is the native code, mostly written in C/C++ that access the memory. Technically you are right that pointers are virtual addresses, not physical. The "virtual" in virtual memory is not the same as the V in JVM. Virtual memory address is applies mainly to the OS. To software running on the OS like the JVM, virtual memory addresses are used the same way as physical addresses.
  41. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    You CANNOT reference(read from or write to) any memory addresses, virtual or not, in Java code.
    Technically, it has been possible to access memory in Java for a few years now, but it is considered Unsafe. The "how" is left as an exercise to the reader ;-) Peace, Cameron Purdy Oracle Coherence: The Java Data Grid
  42. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    You CANNOT reference(read from or write to) any memory addresses, virtual or not, in Java code.


    Technically, it has been possible to access memory in Java for a few years now, but it is considered Unsafe. The "how" is left as an exercise to the reader ;-)

    Peace,

    Cameron Purdy
    Oracle Coherence: The Java Data Grid
    I'm not really not into exercise and more of couch potato - so I'll wait for the DVD. :) ;)
  43. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]


    The main differences between Java and C++ are Java's lack of pointers and its garbage collector.


    As a long-term developer I had spent few Years developing serverside systems in C++ before I have switched to Java. I found this discussion quite interesting, but cannot resist to discuss above statement. First - this is not true - there are few GC implementations for C++, few of them were available before Java.


    Now that you mention it, saying that Java lacks pointers is not true either. It lacks pointer-arithmetic, not pointers.

    No, the value of a C++ pointer is the physical memory address of a variable. It is not possible obtain the physical memory address of any variables in Java. So the author is right. Java lacks pointers.
    Saying you can't access something and that it doesn't exist are not the same thing. The JLS states that the value of a reference is a pointer. You can only assign and dereference this value. It definitely is there. A 'pointer' is something that points. If the value of a reference doesn't point to something, what does it do?
  44. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Now that you mention it, saying that Java lacks pointers is not true either. It lacks pointer-arithmetic, not pointers.

    No, the value of a C++ pointer is the physical memory address of a variable. It is not possible obtain the physical memory address of any variables in Java. So the author is right. Java lacks pointers.


    Saying you can't access something and that it doesn't exist are not the same thing. The JLS states that the value of a reference is a pointer. You can only assign and dereference this value. It definitely is there.

    A 'pointer' is something that points. If the value of a reference doesn't point to something, what does it do? I believe the author was referring to a more strict definition from the C++ perspective, where a pointer can read from and write to an address in memory. A Java reference is restricted from that, with very good reasons. Pointer arithmatic, even in the C/C++ world, it is strongly discouraged because the programmer may not know where the word alignment boundaries are. So pointer arithmatic, while possible in C/C++, is not what distinguishes a C++ pointer from a Java reference.
  45. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    I believe the author was referring to a more strict definition from the C++ perspective, where a pointer can read from and write to an address in memory. A Java reference is restricted from that, with very good reasons.
    How does a Java pointer not read and write to an address in memory? If the argument is that it's different because whether the pointer points to a literal memory address, a virtual memory, or some other indirection layer is not specified by the JLS, I don't see why that's a significant difference in the context of this article.
    Pointer arithmatic, even in the C/C++ world, it is strongly discouraged because the programmer may not know where the word alignment boundaries are. So pointer arithmatic, while possible in C/C++, is not what distinguishes a C++ pointer from a Java reference.
    What can you do with C++ pointers that you cannot do with Java pointers other than pointer arithmetic. What does distinguish them in your mind? Saying Java has no pointers implies that Objects are copied on assignment. I've seen many people (usually C++ proponents) claiming that 'Java is slow because it doesn't have pointers.' In terms of what pointers do from a design perspective, there is no difference between Java pointers and C++ pointers. C++ pointers are just naked. I've never been convinced that dangers this presents is warranted by the supposed advantages.
  46. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    How does a Java pointer not read and write to an address in memory?
    What can you do with C++ pointers that you cannot do with Java pointers other than pointer arithmetic. What does distinguish them in your mind?
    Given a memory address, say 0x40000000, you cannot read the value at that location of memory in Java, but in C++ you can. In other words, try to do this in Java char* p = 0x40000000; printf("value of p = %c", *p);
    Pointer arithmatic, even in the C/C++ world, it is strongly discouraged because the programmer may not know where the word alignment boundaries are. So pointer arithmatic, while possible in C/C++, is not what distinguishes a C++ pointer from a Java reference.




    Saying Java has no pointers implies that Objects are copied on assignment. I've seen many people (usually C++ proponents) claiming that 'Java is slow because it doesn't have pointers.' In terms of what pointers do from a design perspective, there is no difference between Java pointers and C++ pointers. C++ pointers are just naked. I've never been convinced that dangers this presents is warranted by the supposed advantages.
    I would say that pointer is more of a C/C++ thing than any other languages. Everything else that can't access an arbitrary memory location should be called references. The difference is that with references, you can only access the memory locations that the run-time environment gives you. C++ pointers allows you to read any memory locations in the address space and even in other processes' address space in some cases.
  47. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    How does a Java pointer not read and write to an address in memory?


    What can you do with C++ pointers that you cannot do with Java pointers other than pointer arithmetic. What does distinguish them in your mind?


    Given a memory address, say 0x40000000, you cannot read the value at that location of memory in Java, but in C++ you can. In other words, try to do this in Java

    char* p = 0x40000000;
    printf("value of p = %c", *p);

    Pointer arithmatic, even in the C/C++ world, it is strongly discouraged because the programmer may not know where the word alignment boundaries are. So pointer arithmatic, while possible in C/C++, is not what distinguishes a C++ pointer from a Java reference.




    Saying Java has no pointers implies that Objects are copied on assignment. I've seen many people (usually C++ proponents) claiming that 'Java is slow because it doesn't have pointers.' In terms of what pointers do from a design perspective, there is no difference between Java pointers and C++ pointers. C++ pointers are just naked. I've never been convinced that dangers this presents is warranted by the supposed advantages.


    I would say that pointer is more of a C/C++ thing than any other languages. Everything else that can't access an arbitrary memory location should be called references. The difference is that with references, you can only access the memory locations that the run-time environment gives you. C++ pointers allows you to read any memory locations in the address space and even in other processes' address space in some cases.
  48. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    How does a Java pointer not read and write to an address in memory?


    What can you do with C++ pointers that you cannot do with Java pointers other than pointer arithmetic. What does distinguish them in your mind?


    Given a memory address, say 0x40000000, you cannot read the value at that location of memory in Java, but in C++ you can. In other words, try to do this in Java

    char* p = 0x40000000;
    printf("value of p = %c", *p);
    To me this is just a form a pointer arithmetic and the least useful form of it.
    Pointer arithmatic, even in the C/C++ world, it is strongly discouraged because the programmer may not know where the word alignment boundaries are. So pointer arithmatic, while possible in C/C++, is not what distinguishes a C++ pointer from a Java reference.




    Saying Java has no pointers implies that Objects are copied on assignment. I've seen many people (usually C++ proponents) claiming that 'Java is slow because it doesn't have pointers.' In terms of what pointers do from a design perspective, there is no difference between Java pointers and C++ pointers. C++ pointers are just naked. I've never been convinced that dangers this presents is warranted by the supposed advantages.


    I would say that pointer is more of a C/C++ thing than any other languages. Everything else that can't access an arbitrary memory location should be called references. The difference is that with references, you can only access the memory locations that the run-time environment gives you. C++ pointers allows you to read any memory locations in the address space and even in other processes' address space in some cases.
    I understand what you can do with C++ pointers. I've developed plenty code in C++ (back in the day.) What you are describing is all pointer arithmetic. There are pointers in Java. You just can't point them wherever you want. That doesn't mean they don't exist. If my car prevents me from throwing my car into reverse while I am moving forward, it doesn't mean the reverse gear doesn't exist while I'm moving forward. Pointers in Java are very similar to C++ pointers. The difference is that Java limits what you can do with them and C++ allows you to modify them in arbitrary ways.
  49. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    I understand what you can do with C++ pointers. I've developed plenty code in C++ (back in the day.) What you are describing is all pointer arithmetic. There are pointers in Java. You just can't point them wherever you want. That doesn't mean they don't exist. If my car prevents me from throwing my car into reverse while I am moving forward, it doesn't mean the reverse gear doesn't exist while I'm moving forward. Pointers in Java are very similar to C++ pointers. The difference is that Java limits what you can do with them and C++ allows you to modify them in arbitrary ways.
    A safe pointer has a different name in both C++ and Java already. It is "reference". I failed to see how reading from an arbitrary memory address can be "arithmatic" since there is no arithmatic operations involved. But I think we both understand the difference between what C++ and Java can do. I do like your analogy. There are situations, though rarely, where you do need to shift your gear into reverse when driving forward.
  50. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    I failed to see how reading from an arbitrary memory address can be "arithmatic" since there is no arithmatic operations involved. But I think we both understand the difference between what C++ and Java can do.
    How can you do arithmetic on a value that you cannot read or set? You can do arithmetic on any value you have access to. The only thing that would be required to support pointer arithmetic in Java is access to the pointer values as Java already comes with support for arithmetic. Java has pointers. The value of a Java reference is a pointer. The language just doesn't have any syntax that allows you to retrieve this value as a number. In any meaningful sense the statement that 'Java doesn't have pointers' is incorrect and at best misleading.
    I do like your analogy. There are situations, though rarely, where you do need to shift your gear into reverse when driving forward.
    For the sake of argument can you name one such situation? Or more to the point what kind of situation requires direct access to the pointer value?
  51. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    I failed to see how reading from an arbitrary memory address can be "arithmatic" since there is no arithmatic operations involved. But I think we both understand the difference between what C++ and Java can do.


    How can you do arithmetic on a value that you cannot read or set? You can do arithmetic on any value you have access to. The only thing that would be required to support pointer arithmetic in Java is access to the pointer values as Java already comes with support for arithmetic. Java has pointers. The value of a Java reference is a pointer. The language just doesn't have any syntax that allows you to retrieve this value as a number. In any meaningful sense the statement that 'Java doesn't have pointers' is incorrect and at best misleading.
    Tell me then, what arithmatic is this code doing? char* p = 0x40000000; printf("value of p = %c", *p);
  52. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Tell me then, what arithmatic is this code doing?

    char* p = 0x40000000;
    printf("value of p = %c", *p);
    Assigning it to a literal. The term pointer arithmetic is a technical one that is not just a qualification of the general term. Why are you wasting time arguing semantics anyway? What difference does it make? The point is the same whether you assign the pointer to a literal or assign to any other integer value. The term for this kind of thing is pointer arithmetic and you are merely demonstrating ignorance.
  53. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Tell me then, what arithmatic is this code doing?

    char* p = 0x40000000;
    printf("value of p = %c", *p);


    Assigning it to a literal.

    The term pointer arithmetic is a technical one that is not just a qualification of the general term. Why are you wasting time arguing semantics anyway? What difference does it make? The point is the same whether you assign the pointer to a literal or assign to any other integer value. The term for this kind of thing is pointer arithmetic and you are merely demonstrating ignorance.
    That fact you always resort to personal insults shows how much confidence you have in your own arguments.
  54. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    That fact you always resort to personal insults shows how much confidence you have in your own arguments.
    No, I'm absolutely confident. There is nothing to argue about. The point is not to insult you it's to get you to stop with your insistence on arguing pointless minutia as if it were meaningful. I think you are trying really hard to prove to yourself that you are never wrong. Do you really believe that there's something fundamentally different between setting a pointer to 0x40000000 and setting it to a value that was calculated (other than that the latter might actually work)? They both modify the pointer as a raw integer value. Anything that does this is classified as pointer arithmetic, regardless of whether it's mentioned in a given web-page about pointer arithmetic or not. Actually I don't even care everyone in the universe thinks I'm wrong about the definition of pointer arithmetic. It's unimportant. The point is that Java has pointers. It just doesn't allow you to treat them as numbers.
  55. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Tell me then, what arithmatic is this code doing?

    char* p = 0x40000000;
    printf("value of p = %c", *p);


    Assigning it to a literal.

    The term pointer arithmetic is a technical one that is not just a qualification of the general term. Why are you wasting time arguing semantics anyway? What difference does it make? The point is the same whether you assign the pointer to a literal or assign to any other integer value. The term for this kind of thing is pointer arithmetic and you are merely demonstrating ignorance.
    Here is a little lesson on pointer arithmatic for you. Pointer arithmetic is a processing calculating memory address locations. Simply assigning a variable is not point arithmetic. http://www.eskimo.com/~scs/cclass/notes/sx10b.html
  56. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]


    The main differences between Java and C++ are Java's lack of pointers and its garbage collector.


    As a long-term developer I had spent few Years developing serverside systems in C++ before I have switched to Java. I found this discussion quite interesting, but cannot resist to discuss above statement. First - this is not true - there are few GC implementations for C++, few of them were available before Java.


    Now that you mention it, saying that Java lacks pointers is not true either. It lacks pointer-arithmetic, not pointers.

    No, the value of a C++ pointer is the physical memory address of a variable. It is not possible obtain the physical memory address of any variables in Java. So the author is right. Java lacks pointers.
    Pointers to what ? To memory location ? For doing what ? Well, I like to think that Java has **only** pointers. What do you pass on the call stack when you invoke a method with an object as argument ? Can you pass an object by value ? Guido
  57. What about the null pointer?[ Go to top ]


    The main differences between Java and C++ are Java's lack of pointers and its garbage collector.


    Now that you mention it, saying that Java lacks pointers is not true either. It lacks pointer-arithmetic, not pointers.

    No, the value of a C++ pointer is the physical memory address of a variable. It is not possible obtain the physical memory address of any variables in Java. So the author is right. Java lacks pointers.
    Java *mostly* lacks pointers. Of course, we've somehow managed to keep the null pointer, as evidenced by the NullPointerException. -Patrick -- Patrick Linskey http://bea.com
  58. The author seems to have a 'culture shock' and still longs for the cozy past of C++. Memories are golden, and it is easy to forget how horrible C++ can be. I had similar withdrawal feelings after moving to use Java, but I never really looked back. Back in 1998 that was justified, but today trying to do typical server things with C++ is just insane. I even believe that many bad things in J2EE got so much blind support just for the sake of having some standard at last.
  59. Seriously ...[ Go to top ]

    does anyone actually give a shit about C++ anymore?
  60. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Did server-side development and client GUI development in C++ for over a decade. C for an additional 3 or so years (but my first professional programming language was Object Pascal, circa '86, '87). In 2003 got into Java and JEE/JMS development. Java and a JEE app server are a huge leap forward for productivity and for being conducive to producing quality software. Have had no experiences that concurr with anything this author argued as to being positives for C++ vs Java/JEE. C++ just has nothing to offer for any manner of development that I and my staff engage in for server-side development.
  61. Neither is perfect[ Go to top ]

    I have been a programmer of FORTRAN, LISP, C, C++ and finally Java, and I must say both C++ and Java have their pros and cons. Here I wont go into details, thinking that there have been enough debates on this subject. I just want to say that compared to C++, Java has lots of advantages, in particular, its rich, standardized class packages and memory management by JVM, all these greatly ease the life Java developers. It is clear. However there are real performance issues with Java, due to, IMHO, two things: 1. Garbage collection Memory management has a price. The algorithm used by the garbage collector has evolved and perfected itself, but at the same time become more and more complicated. It is common to see the overhead of garbage collection goes beyond 8%. With more and more web service Java applications coming, more and more XML parsing, more and more memory will be needed and the garbage collector will "play" with a Java heap bigger and bigger. Not only to the garbage collector, but even to the brave people who have to analyze these huge Java heap dumps when there are problems. Another problem related to the garbage collection is there are pause times. It is a fact. Even with the recent techniques which allow to use multiple processors in garbage collection, but still some tasks in the garbage collection must be synchronized. For people who have ever worked JMeter to do performance tests, with high workload they would have wrong numbers such as the reported transaction response time is incorrect: it is the real response time plus the garbage collection pause time in the workload injector running in a JVM. Similar issues with Rational Performance Tester. 2. Java programmer skills Many software service companies hire young graduates, train them during two weeks then put them on development projects. You can easily imagine what would happen with the final Java code. There are so many "expert" Java programmers who work like a pig. It is true they are very productive in "producing" code, but leave a huge bomb in the delivered code. Those who will test and manage such applications will suffer. At the end the programming productivity will be deemed by the lost of time and of energy in a later time. For instance, as JVM takes care of memory management, many Java programmers feel free to create Java objects not trying to reuse them when possible. In a real core banking application, I see each transaction consumes more than 4 MB in average. You can imagine at a transaction rate of 1000TPS, how busy will the garbage collector be! I can say that lots and lots of performance problems are hidden by the more and more powerful and cheaper machines with more and more cheaper memory. Many argue that why we care about this? why we spend more time to in optimize our code? just look at the price of machines! I can hardly agree with them. Machines in our days are "eating" more and more electricity and processors are getting hotter and hotter. We must save energy, we must optimize our software to reduce energy consumption we must take care of our living environment. The bottom line is both C++ and Java have their raison d'ĂȘtre and have progress to make. Writing an application server in C++ will certainly cost more than in Java but the resulting product, if well done, will run faster for sure. Franck
  62. CG is slow? What about malloc ?[ Go to top ]

    To the people that keep saying that GC is slow, how about a discussion about speed on malloc ? Here's a piece of pstack output: fe62ada0 _mutex_adaptive_lock (... . fe62aab4 _cmutex_lock (.. fe541cd0 malloc (... fed686e8 .... Memory allocation is way slower in C than in Java because of that mutex and the linked list that must be searched for a free block. Compare this to incrementing and returning a pointer.
  63. To the people that keep saying that GC is slow, how about a discussion about speed on malloc ?
    Here's a piece of pstack output:

    fe62ada0 _mutex_adaptive_lock (... .
    fe62aab4 _cmutex_lock (..
    fe541cd0 malloc (...
    fed686e8 ....

    Memory allocation is way slower in C than in Java because of that mutex and the linked list that must be searched for a free block. Compare this to incrementing and returning a pointer.
    C++ is way faster because it gives the programmer the ability to declare large objects on the function stack, thus avoiding memory allocation(like malloc) on the heap altogether. Java only allows primitives on the stack. I still don't understand till this day why Java decided to do that. At least it should let internal method variables that have no visibility outside the function scope live on the stack.
  64. To the people that keep saying that GC is slow, how about a discussion about speed on malloc ?
    Here's a piece of pstack output:

    fe62ada0 _mutex_adaptive_lock (... .
    fe62aab4 _cmutex_lock (..
    fe541cd0 malloc (...
    fed686e8 ....

    Memory allocation is way slower in C than in Java because of that mutex and the linked list that must be searched for a free block. Compare this to incrementing and returning a pointer.


    C++ is way faster because it gives the programmer the ability to declare large objects on the function stack, thus avoiding memory allocation(like malloc) on the heap altogether. Java only allows primitives on the stack. I still don't understand till this day why Java decided to do that. At least it should let internal method variables that have no visibility outside the function scope live on the stack.
    Escape Analysis was added to the HotSpot in JDK6. This will be used to enable stack allocations in JDK7, as I understand it.
  65. C++ is way faster because it gives the programmer the ability to declare large objects on the function stack, thus avoiding memory allocation(like malloc) on the heap altogether. Java only allows primitives on the stack. I still don't understand till this day why Java decided to do that. At least it should let internal method variables that have no visibility outside the function scope live on the stack.


    Escape Analysis was added to the HotSpot in JDK6. This will be used to enable stack allocations in JDK7, as I understand it.
    That will do some serious damage to C++'s performance advantage if it is true. Thanks for the info.
  66. Hi, I was forced to write some C++ a few years back (2003) and after doing Java for a few years, I kind of enjoyed it in a strange way. I think it was getting close to the metal that was fun. Also coping with all that clever pointer stuff felt... clever:^). Spending weeks tracking down bugs wasn't fun at all though and definately wasn't clever. Unless you really do need to be close to the metal (e.g device drivers, VMs, embedded software, system software, etc),then C++ is a big expensive waste of time for most things. Java has got it's problems but it does 'borrow' some good things from Smalltalk. It's a shame that it doesn't borrow more, but then again there is always Ruby :^). Seriously though, C++ is a big mistake for high level, application development, and it's strange that it was ever considered seriously for this role. More to do with the ready market of C/Unix programmers at the time, then applicability I think (the industry repeated the same mistake when moving from C++ to Java). Isn't progress a consequence of raising the level of abstraction? So who wants to deal with raw pointers unless they really have to? After all no one uses Assembler anymore, or do they? :^). Paul.
  67. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Isn't progress a consequence of raising the level of abstraction? So who wants to deal with raw pointers unless they really have to? After all no one uses Assembler anymore, or do they? :^).

    Paul.
    Everyone knows that true programming is done on punch cards on a converted loom driven by a water wheel. Well, you could use a steam engine if you don't have a stream nearby.
  68. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    I very much like the comments from Paul Beckford. Just more productive, both in terms of development time (memory management, std libraries etc) and support time (exception stack traces - your bug happened right at this point - in clear text). And each version of Java seems to get faster too. I hear that java6 is faster than java5.
  69. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Seriously though, C++ is a big mistake for high level, application development, and it's strange that it was ever considered seriously for this role. More to do with the ready market of C/Unix programmers at the time, then applicability I think (the industry repeated the same mistake when moving from C++ to Java).
    It seems to me that a lot of people that make decision about what language to use feel that these low-level concepts are easier to understand than high-level concepts. In a way, it's true, it's easy to understand an 'if' statements and 'while' loops. Concepts like polymorphism take a leap of faith. I've seen a number of comments in Java code about how "this supposedly works" around some 'higher' level feature like a finally block. I've had a number arguments at my current job with people who feel that abstracting out repetitive tasks into some (relatively) sophisticated code will make it too hard to understand. Personally, I can't see how that math works out. Flushing hours and dollars down the toilet so that no one gets confused makes no sense to me. I think a lot of shops would rather have an army of technical typists rather than one guy doing something that someone might not understand right away.
  70. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Hi James, Music to my ears...
    Seriously though, C++ is a big mistake for high level, application development, and it's strange that it was ever considered seriously for this role. More to do with the ready market of C/Unix programmers at the time, then applicability I think (the industry repeated the same mistake when moving from C++ to Java).


    It seems to me that a lot of people that make decision about what language to use
    Stop right there. That's just the problem. They don't decide, they just follow the crowd. I've read several blog entries by programmers who were writing the next wave of OO frameworks at places like IBM etc in the early nineties and failed. They failed because they were forced to use C++. They knew C++ was the wrong language for what they wanted to do. C++ is not OO, I will expand on this later.. The decision to use C++ was made by the marketing department who knew that C++ would be a better sell then Objective-C or Smalltalk. After all, all those C programmers out there could carry on writing C with C++.
    feel that these low-level concepts are easier to understand than high-level concepts. In a way, it's true, it's easy to understand an 'if' statements and 'while' loops. Concepts like polymorphism take a leap of faith.
    Like I say C++ is not OO. Full polymorphism relies on messaging passing. C++ does not support a polymorphic message send, so C++ is not true OO, neither is Java. But I agree that even the restricted form of polymorphism available in C++/Java is often misunderstood and avoided. Like with C and C++, procedural programmers can happily continue writing procedual using the familiar case statement in C++ and Java.
    I've seen a number of comments in Java code about how "this supposedly works" around some 'higher' level feature like a finally block. I've had a number arguments at my current job with people who feel that abstracting out repetitive tasks into some (relatively) sophisticated code will make it too hard to understand.
    People are very good at justifying bad decisions after the fact, especially when like I say they didn't decide, they just followed the crowd.
    Personally, I can't see how that math works out.
    It doesn't. People just waste time and money, but in the same way no one got fired for buying IBM, no one gets fired for using C++ or Java. Like I say safety in numbers, just follow the crowd.
    Flushing hours and dollars down the toilet so that no one gets confused makes no sense to me. I think a lot of shops would rather have an army of technical typists rather than one guy doing something that someone might not understand right away.
    Yes this ist it. You are spot on. It is called Taylorism. It is the technique that Henry Ford used to make his Millions. Split the work up into simple mundane tasks that way you can hire and fire a bunch of low skilled monkeys. In software people think they can do the same by buying the "silver bullet" tool (Java/J2EE and the Application Server) and with the help of an all knowing Architect, hire and fire a bunch of typist. The problem with programming though is that it is an intellectual exercise and as such it doesn't lend itself to being dumbed down. To write good Software you need intelligent creative people - Like Fred Brooks said, there is no silver bullet. The time and money people spend on tools and consultants, they could spend a fraction of it educating and developing their programmers and they would get much greater rewards. BTW, educated, well informed programmers are in a position to decide on tools themselves. So all you need to do is focus on good people and they will choose the right tool (language, framework etc) for the job at hand. It is that simple! Paul.
  71. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Yes this ist it. You are spot on. It is called Taylorism. It is the technique that Henry Ford used to make his Millions. Split the work up into simple mundane tasks that way you can hire and fire a bunch of low skilled monkeys. In software people think they can do the same by buying the "silver bullet" tool (Java/J2EE and the Application Server) and with the help of an all knowing Architect, hire and fire a bunch of typist. The problem with programming though is that it is an intellectual exercise and as such it doesn't lend itself to being dumbed down. To write good Software you need intelligent creative people - Like Fred Brooks said, there is no silver bullet.

    The time and money people spend on tools and consultants, they could spend a fraction of it educating and developing their programmers and they would get much greater rewards.

    BTW, educated, well informed programmers are in a position to decide on tools themselves. So all you need to do is focus on good people and they will choose the right tool (language, framework etc) for the job at hand. It is that simple!

    Paul.
    I disagree with the statement "It is that simple!" If it were, I would think it would qualify as a silver bullet. Some of the reasons I disagree are: 1. Even without today's brain-damaged hiring procedures, it still isn't that easy to find good people - even through you'll need fewer people, you may still have difficulty finding enough good people. 2. Intelligent, creative people eventually get tired of making applications that are essentially variations on "querying a database and slapping it on a web page". Can you keep good people interested, engaged, and happy with work that used to be done by COBOL programmers? 3. People aren't all going to pick the same tools when given a choice, people have different preferences and experience. What happens when Haskell-Bob goes on a 2-month sabbatical and his applications break? I'm not saying that you shouldn't focus on getting good people, but that it doesn't solve all your problems. There needs to be a balance of standardization vs. innovation, and a balance of skill levels (maybe variations of Brooks' "surgical teams" concept).
  72. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    2. Intelligent, creative people eventually get tired of making applications that are essentially variations on "querying a database and slapping it on a web page". Can you keep good people interested, engaged, and happy with work that used to be done by COBOL programmers?
    This exactly the problem. Instead of letting developers eliminate the boilerplate code in a way that allows non-technical people set up the web page, the approach is to get some people that can copy and paste together the same app again and again. I just worked on some code that takes some data from a table and builds a web page based on another table. Before this, every time a one of these pages was needed, a variation of the same basic code would be hand written. That I could build a table driven implementation without changing a single line of the existing code is the perfect example of the problem. The app was completely able to handle this kind of dynamic approach but no one thought to do it. They just copied and pasted the previous developers' work (bugs and all) and made some minor changes.
  73. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Yes this ist it. You are spot on. It is called Taylorism. It is the technique that Henry Ford used to make his Millions. Split the work up into simple mundane tasks that way you can hire and fire a bunch of low skilled monkeys. In software people think they can do the same by buying the "silver bullet" tool (Java/J2EE and the Application Server) and with the help of an all knowing Architect, hire and fire a bunch of typist. The problem with programming though is that it is an intellectual exercise and as such it doesn't lend itself to being dumbed down. To write good Software you need intelligent creative people - Like Fred Brooks said, there is no silver bullet.

    The time and money people spend on tools and consultants, they could spend a fraction of it educating and developing their programmers and they would get much greater rewards.

    BTW, educated, well informed programmers are in a position to decide on tools themselves. So all you need to do is focus on good people and they will choose the right tool (language, framework etc) for the job at hand. It is that simple!

    Paul.


    I disagree with the statement "It is that simple!" If it were, I would think it would qualify as a silver bullet. Some of the reasons I disagree are:

    1. Even without today's brain-damaged hiring procedures, it still isn't that easy to find good people - even through you'll need fewer people, you may still have difficulty finding enough good people.

    2. Intelligent, creative people eventually get tired of making applications that are essentially variations on "querying a database and slapping it on a web page". Can you keep good people interested, engaged, and happy with work that used to be done by COBOL programmers?

    3. People aren't all going to pick the same tools when given a choice, people have different preferences and experience. What happens when Haskell-Bob goes on a 2-month sabbatical and his applications break?


    I'm not saying that you shouldn't focus on getting good people, but that it doesn't solve all your problems. There needs to be a balance of standardization vs. innovation, and a balance of skill levels (maybe variations of Brooks' "surgical teams" concept).
    Hi Mark, No it's never that simple :^) My focus was more on "building skill" rather then buying it! There are some obvious things you can do. You can provide your programmers with language agnostic training. So for example training on OO should be training on OO, looking at its roots in Smalltak and how it as morphed into different forms in languages like Java/C++ and in a language like Self say. Secondly, programmers should spend some of their time doing pure "research and investigation". So for example, why not schedlue 10% of the working time as "green field" investigation. That way your programmers can get to look at new concepts like AOP and new tools of their own interest, and at the end of this they get a chance to present to their peers and the team gets to decide whether there is anything new they should be using. This is a much better approach then waiting for the Oracle or IBM salesman to swing by with his latest bang-whiz product :^) Another good outlet for creative and intellectual juices are seminars and symposiums. Again I think cross language ones are best. So the dynamic languages synposium would be of interest to some staff, others may be interested in OOPSLA. Staff could attend, or even better if they feel they have something new to offer the community, then they could even present. Once you stop thinking of programmers as the lowest of the low, to be hired and fired willy-nilly, then a whole arena of possibilities open up before your eyes :^). Lastly, I disgree with your point that programmers have varying preferences. Ill informed programmers tend to stick to what they know, true - but mostly through ignorance and fear, I believe. Informed people however tend to be more willing to switch and change and choose the right tool for the Job. Martin Fowler for example readily admits to loving Ruby, but he also uses Java too. Dave Thomas of the pragmatic programmers suggests that all programmers (and yes that includes Java programmers :^)), should learn at least one new language a year. Personally I agree. Once informed in this way, then programmers can really exercise choice, and I tend to find that informed programmers tend to make similar choices. C++ for this, Java for that and Ruby for the other. Which is why at one level, this whole discussion missses the point :^) Paul.
  74. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Lastly, I disgree with your point that programmers have varying preferences. Ill informed programmers tend to stick to what they know, true - but mostly through ignorance and fear, I believe.

    This sounds a little like Paul Graham's thing about the "blub" programmer. Maybe if you threw laziness in there I might be more okay with it. Even then, I don't think it is particularly helpful to accuse people of being ignorant or afraid (or lazy, as I just did).

    Informed people however tend to be more willing to switch and change and choose the right tool for the Job. Martin Fowler for example readily admits to loving Ruby, but he also uses Java too. Dave Thomas of the pragmatic programmers suggests that all programmers (and yes that includes Java programmers :^)), should learn at least one new language a year. Personally I agree.

    Once informed in this way, then programmers can really exercise choice, and I tend to find that informed programmers tend to make similar choices. C++ for this, Java for that and Ruby for the other.

    Which is why at one level, this whole discussion missses the point :^)

    Paul.

    There is more to a solution than just a choice of language, and there are many circumstances where there is no clear "right language", or "right tool/library/framework" within a specific language. I'm pretty sure you aren't trying to suggest that all intelligent, informed programmers are actually going to agree on the superiority of a particular tool (emacs vs. vi comes to mind). Take typing as an example. Some people swear by static typing, some people swear AT it. So one person may have a preference for Lisp, Ruby or Python, while another might prefer Haskell or OCaml. The more variation you have, the harder it is for one person to step in and work on someone else's project. It's not that you have to think of people as replaceable parts, but you do have to realize that people come and go. It's not that I disagree with the rest of what you are saying. You touch on a lot of things that I frequently complain about. Even before learning new languages, a lot of people could stand to learn how the machine actually works. I know an awful lot of people who only know Java and have no idea about what is going on at the lower levels, which means that their ability to identify certain classes of problems is pretty much non-existent. I think this whole discussion misses points on many levels. Just comparing language features, for example, ignores the surrounding libraries and tools. I could probably go on and on, but I won't. Mark
  75. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Lastly, I disgree with your point that programmers have varying preferences. Ill informed programmers tend to stick to what they know, true - but mostly through ignorance and fear, I believe.



    This sounds a little like Paul Graham's thing about the "blub" programmer. Maybe if you threw laziness in there I might be more okay with it. Even then, I don't think it is particularly helpful to accuse people of being ignorant or afraid (or lazy, as I just did).




    Informed people however tend to be more willing to switch and change and choose the right tool for the Job. Martin Fowler for example readily admits to loving Ruby, but he also uses Java too. Dave Thomas of the pragmatic programmers suggests that all programmers (and yes that includes Java programmers :^)), should learn at least one new language a year. Personally I agree.

    Once informed in this way, then programmers can really exercise choice, and I tend to find that informed programmers tend to make similar choices. C++ for this, Java for that and Ruby for the other.

    Which is why at one level, this whole discussion missses the point :^)

    Paul.



    There is more to a solution than just a choice of language, and there are many circumstances where there is no clear "right language", or "right tool/library/framework" within a specific language. I'm pretty sure you aren't trying to suggest that all intelligent, informed programmers are actually going to agree on the superiority of a particular tool (emacs vs. vi comes to mind).

    Take typing as an example. Some people swear by static typing, some people swear AT it. So one person may have a preference for Lisp, Ruby or Python, while another might prefer Haskell or OCaml. The more variation you have, the harder it is for one person to step in and work on someone else's project. It's not that you have to think of people as replaceable parts, but you do have to realize that people come and go.

    It's not that I disagree with the rest of what you are saying. You touch on a lot of things that I frequently complain about. Even before learning new languages, a lot of people could stand to learn how the machine actually works. I know an awful lot of people who only know Java and have no idea about what is going on at the lower levels, which means that their ability to identify certain classes of problems is pretty much non-existent.

    I think this whole discussion misses points on many levels. Just comparing language features, for example, ignores the surrounding libraries and tools. I could probably go on and on, but I won't.
    Mark
    Hi Mark, I can tell that we mostly agree. Posting here is pretty low bandwith, so discussing nuanses probably doesn't make sense. My point is more to do with attitude, and I agree name calling doesn't always help. Programming languages do have broad categories of applicability though. So for certain situations certain languages are a natural choice (e.g. CRUD web apps in a business domain that requires quick releases - well PHP is a quick solution or perhaps Rails, whilst J2EE is a bit slower and heavier). In my experience sensible, informed people are able to discuss, compromise and come to a sensible decision. Like I say, the most dogmatic also tend to be the least well informed :^) And if you can't decide, then the team lead can always put his foot down and make an executive decision :^) You sound pretty sensible, and I'm sure you and your team could work through the issues you raise. At one level saying that everything needs to be done the same is nice for the vendors. So everything must be Java means that the Java vendors have an unquestioning market at their feet. As developers we should be in the driving seat, and we should use the tools we believe are best. I'd rather an honest argument with a peer, then being forced to use Oracle or IBM products because "everything we do must be Java and from Oracle". Then you get into the whole thing of the "Strategy Team" who make technology and tool choices for every body without ever looking at real requirements and without ever having to deal with the realities of a real project. I agree with much of what you say and I could go on too... I guess we mostly agree - end of rant :^) Paul
  76. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Hi Paul,
    In my experience sensible, informed people are able to discuss, compromise and come to a sensible decision. Like I say, the most dogmatic also tend to be the least well informed :^)
    In your experience, how many informed, sensible people are there relative to the usual narrow minded, reationary people that seem so common? Are people just more sensible across the pond? -Erik
  77. This hardly seems like a fair comparison. I find it a bit strange that the JVM installation is mentioned as a problem. In practice installing a JVM is very easy and can be done in a matter of minutes. Also memory usage is something you always need to plan no matter what language you're developing with and whether you need to specify maximum heap size on application startup or not. A quick analysis on Java 5 SE/EE API documentation provides the following numbers for reference: - Java 5 SE public API: 2464 classes (excluding interfaces) - Java 5 EE public API: 508 classes (excluding interfaces) The number of classes may not be the best measure for API coverage but I think that if you compare these numbers with what you get with C++ (Standard Library) the picture is quite clear. Java EE 5 provides a server-side, distributed component architecture with support for WebServices, asynchronous messaging, distributed transactions, authentication and authorization, service pooling, persistence, web UI construction and support for integrating with legacy systems (i.e. JAX-WS, JAX-RPC, JAXB, SAAJ, StAX, JSF, JSP, JSTL, Servlet, EJB, JCA, JAF, JavaMail, JDO, JMS, JPA, JTA, JAAS). I would be very interested in seeing alist of C++ software products that you would typically use in order to get a similar platform. If you're in the business of building business applications as opposed to frameworks you might want to minimize the time you put in building the platform. The author mentions that C++ comes with 100% portable libraries for threads. Is thread support really part of the C++ Standard Library nowadays? As to performance I've found that typically bad application design is a much bigger issue than the language or frameworks. Per user session memory usage is one thing you have to limit especially if the user base is going to be large.
  78. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Hi Paul,
    In my experience sensible, informed people are able to discuss, compromise and come to a sensible decision. Like I say, the most dogmatic also tend to be the least well informed :^)


    In your experience, how many informed, sensible people are there relative to the usual narrow minded, reationary people that seem so common?

    Are people just more sensible across the pond?

    -Erik
    Hi Erik, No, I've just had the good fortune to soley work on Agile projects over the last 4 years or so, and I have found the Agile community to to be less dogmatic over these things. (The fact that many in the Agile community are fluent in several programming languages, often includng ones that bear no relation to C, does seem to help here). The Agile Manifesto clearly states that it values people over processes and tools, and this key value is one of about four corner stones values that summarise Agile thinking. So perhaps that explains it :^) Paul.
  79. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Dave Thomas of the pragmatic programmers suggests that all programmers (and yes that includes Java programmers :^)), should learn at least one new language a year. Personally I agree.

    I meant to point out that this practice is not necessarily to increase the number of languages you actually use from day-to-day, but to make you better at the ones you do use. Being familiar with the functional style of programming might lead you to structure your Java code better, for example. I agree with it as well, although I have to say that I probably haven't done 1 a year. Mark
  80. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    feel that these low-level concepts are easier to understand than high-level concepts. In a way, it's true, it's easy to understand an 'if' statements and 'while' loops. Concepts like polymorphism take a leap of faith.

    Like I say C++ is not OO. Full polymorphism relies on messaging passing. C++ does not support a polymorphic message send, so C++ is not true OO, neither is Java. But I agree that even the restricted form of polymorphism available in C++/Java is often misunderstood and avoided.
    I don't mean to imply that this is the ultimate high-level feature. It's the gateway to high-level features, in my estimation. The point is that a lot of people are uncomfortable even with this level of abstraction. They can't 'see' how the code will work.
    It doesn't. People just waste time and money, but in the same way no one got fired for buying IBM, no one gets fired for using C++ or Java. Like I say safety in numbers, just follow the crowd.
    I don't think you understand my pain. Java is so much higher level than what the people I am talking about are comfortable with. I have to listen to people saying that COBOL is just as good as any other language. And the 'modernists' want to use a tool that combines the most limiting parts of functional programming with the worst parts of procedural style in a shitty (gotta love messages like "something happened in blah.cpp") and it's wonderful non-resizable dialog boxes.
    Yes this ist it. You are spot on. It is called Taylorism. It is the technique that Henry Ford used to make his Millions. Split the work up into simple mundane tasks that way you can hire and fire a bunch of low skilled monkeys. In software people think they can do the same by buying the "silver bullet" tool (Java/J2EE and the Application Server) and with the help of an all knowing Architect, hire and fire a bunch of typist. The problem with programming though is that it is an intellectual exercise and as such it doesn't lend itself to being dumbed down. To write good Software you need intelligent creative people
    I think that it's even more flawed than that. The whole analogy is mis-directed. The part of software development that is analogous to people on an assembly line doing repetitive tasks are computers. All proper software development is a design exercise. I've felt this for a while and now I can see that it's the case. What we end up doing is writing 'design' documents that are nearly completely explicit instructions for coding the solution. It's basically a form document. There's no reason that a programming language equivalent of this document could not be defined. And the most galling thing is that people actually believe we've eliminated code by using this tool. It's GUI development, so there's no code, so the theory goes.
  81. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    Hi James,
    I don't think you understand my pain. Java is so much higher level than what the people I am talking about are comfortable with.
    Oh James I do, believe me. I work as an Agile coach so I get to pair program with a number of developers. The grasp of basic OO concepts out there is pretty poor. Java as a language is so much more than what a lot of people know, and OO as a concept is so much more than Java. The problem is that with Java, if you choose you can carry on programming the same procedural way you did with C, there is no reason to change, and that's the rub. The result: A marketing success for Sun - but an intellectual failure for the programming masses.
    Yes this is it. You are spot on. It is called Taylorism. It is the technique that Henry Ford used to make his Millions. Split the work up into simple mundane tasks that way you can hire and fire a bunch of low skilled monkeys. In software people think they can do the same by buying the "silver bullet" tool (Java/J2EE and the Application Server) and with the help of an all knowing Architect, hire and fire a bunch of typist. The problem with programming though is that it is an intellectual exercise and as such it doesn't lend itself to being dumbed down. To write good Software you need intelligent creative people


    I think that it's even more flawed than that. The whole analogy is mis-directed. The part of software development that is analogous to people on an assembly line doing repetitive tasks are computers. All proper software development is a design exercise. I've felt this for a while and now I can see that it's the case. What we end up doing is writing 'design' documents that are nearly completely explicit instructions for coding the solution. It's basically a form document. There's no reason that a programming language equivalent of this document could not be defined. And the most galling thing is that people actually believe we've eliminated code by using this tool. It's GUI development, so there's no code, so the theory goes.
    Yes, spot on. We are in the new product development business. Our work is pure design, pure thought. Nothing to do with production. As professionals we are partly to blame I believe. In which other profession can you find titles like "Learn Java in 21 days". Imagine learning brain surgery in 21 days:^). There is always this underlying assumption, that the tools are more important then the people - and until this myth is questioned and put to rest we will continue to have sub-standard Software produced by sub-standard programmers. Count the number of news articles on TSS about tools, and compare those to articles on programming concepts and you'll see my point.
  82. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    The biggest thing C++ has over Java is the language itself. C++ is way more expressive than is Java. The preprocessor and templates alone are a big advantage.
  83. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    The biggest thing C++ has over Java is the language itself. C++ is way more expressive than is Java. The preprocessor and templates alone are a big advantage.
    Java Generics are as abstruse as C++ templates.
  84. The biggest thing C++ has over Java is the language itself. C++ is way more expressive than is Java. The preprocessor and templates alone are a big advantage.

    Java Generics are as abstruse as C++ templates.
    Obviously you've never tried to figure out compile errors generated by C++ templates.
  85. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    The biggest thing C++ has over Java is the language itself. C++ is way more expressive than is Java. The preprocessor and templates alone are a big advantage.
    The biggest problem C++ has compared to Java is the language itself. C++ is way more hopelessly complex than is Java. The preprocessor and templates alone are impossible to explain. ;-) Peace, Cameron Purdy (ex-C++ coder) Oracle Coherence: The Java Data Grid
  86. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    (I programmed C++ for many years before Java) Problems w/C++: 1. No standard libraries that leads to a non-invented here syndrome 2. Hoplessly complex languaje (read Effective C++ and compare to Effective Java for proof). Wrong defaults, like methods not-virtual, destructors not virtual when they should be.. too many rules to remember. 3. Implicit copying.. very easy to mess up and end up creating copies of things.. then if you're not careful you may not delete them. 4. Too many half baked features added too late in the game: STL, reflection, exceptions do more harm than good, etc.. 5. Did I mention no libraries? 6. No concurrency features (none native at least) 7. Networking is complex compared to Java 8. No standard error handling 9. Did I mention no libraries? C++ was a nice attempt.. it's still fun to program in. But it lost the simplicity and cleanness of C. Java is a better designed language. And Java has real libraries (did I mention that already?). Microsoft tried pushing server side development w/Microsoft Transaction Server to C++ developers. They just moved on to Java. Much simpler.. less work.. already debugged for you. I still love programming in C++. But I'm kind of sick. Java is just better. I'm not sure Java is good enough for graphics, games and even GUI programming yet. But server side it kills C++.
  87. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    I'm not sure Java is good enough for graphics, games and even GUI programming yet. But server side it kills C++.
    You'd be surprised, the highly acclaimed flight sim IL2 Sturmovik was written in Java with JNI bindings to D3D. And it's still one of the best WW2 combat sims around.
  88. Re: Dr. Dobbs: "C++ vs. JEE"[ Go to top ]

    The biggest thing C++ has over Java is the language itself. C++ is way more expressive than is Java. The preprocessor and templates alone are a big advantage.
    Do people actually remember why they mainly used preprocessor stuff? -To create an ugly 'macro' that really could have been a method call? -To do selective compiling to try to create 'platform independent' code? Does it compile with Linux, Solaris, BSD Unix, huh? I never missed any of these things with Java. One of the most impressive demonstrations of the 'expressiveness' of C++ must be the ... auto pointer. Dr. Dobbs and C++ Report used to run numerous articles on the topic for years. In each article someone came up with a new clever way to improve the auto pointer with yet another operator overload trick, or an exotic template feature. I loved the auto pointer tricks. At the end of my C++ programming career my C++ programs worked very much like Java programs with automatic garbage collection. Just allocate objects and forget about ever releasing memory because the auto pointer did it with a beautiful ballet of destructors, operator over loads, and traits templates. I really nailed down that one. With Java you just did not have to know any of it. Very frustrating.
  89. Preprocessor[ Go to top ]

    The preprocessor
    sucks because it's inherited from C. Basically what it does is create a situation where you need the source to see if you safely can put an expression as argument, because macro arguments are put in literally instead of being evaluated. #define danger(a) a;a; /* Calls i++ twice instead of once had danger() been a method */ danger(i++); That said, nothing prevents you from using any preprocessor/macro system you want in a Java development environment.
  90. C/C++ is great for web servers. However, web servers are rather simple animals. JEE, otoh, is used to implement domain layers atop persistences layers, above which reside service layers, about which are cast transactional boundaries, into which connect multiple clients, some stateful, some not, some developed by 3rd parties, often expected to run 24x7 with hot failover...
  91. Language benchmark[ Go to top ]

    At least in this benchmark Java is the winner: http://lukewelling.com/2006/08/03/java-programmers-are-the-erotic-furries-of-programming/ ;-)