On second thought, I was wrong: parallelism is a big obstacle in the same vein as C++ memory management.
First, almost any GUI application will completely lock up during a networking related stall or hiccup, when perfect use of parallelism could handle this more gracefully. And this isn't just amateur software either. Even among the major streaming movie players (Apple, Flash, Microsoft, Gnome), none of them handle networking stalls gracefully without locking out the user. Secondly, there are very delicate "rules" to writing proper multi- threading code just like there were with writing C++ memory handling code. Personally, when writing solo projects, I never had a problem with either. With C++, I was 100% consistent about using Boost pointer wrappers and didn't have problems. But when tons of people are contributing to a group project, even the well intentioned and well educated programmers write bad C++ memory management code and bad multi-threading code that is impossible to detect at the source code level and a nightmare to debug through. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
