Pain and Glory from the Trenches of the IT World

We’re beginning to enter a new era in computing. We’re rapidly leaving the days of uniprocessor systems. This has been the trend in the enterprise world for some time now. But with Intel and AMD releasing dual- and quad-core CPUs, and these CPUs being used even in low-end systems, they will soon become near-ubiquitous. Unfortunately, few of our programming languages and development platforms are truly equipped to handle the parallelism that we will be seeing on the typical desktop system in the near future.

At far too many companies I have witnessed the effects of homogenized enterprise-grade networks. While many claim that it’s easier to support such networks, I often find that difficult to believe. The benefit brought on by the widespread similarity is often overshadowed by the severe negative consequences when things go wrong.

Today I was reading an article about JyRCP/RAP. In that article, there was one paragraph in particular that caught my attention: Although I’m convinced of the future of rich web apps, there is always this little voice inside my head that says that web technology is meant for document presentation and rich user interfaces are better off with client side GUI technology. You can abuse document presentation elements to fake a rich user interface and you can combine a large set of GUI widgets to look like a document, but you’ll always keep running into practical issues because the technology wasn’t meant for that purpose. Even the best solution is basically no more than a very clever workaround.

Chris Diggins has written a great article about the power that visual programming languages might hold. One specific example he mentions is Scratch. Another is Logo. Perhaps we will see a much greater use of such languages in the future. But I am hesistant to think that such will be the case. Part of the reason is the impact that modelling lanuages like UML, and the tools built around such modelling languages, have had on today’s developers.

I recently wrote an article entitled ‘JRuby cannot save Swing’. Well, Danno Ferrin has written a rebuttal of sorts that I’d like to address.

He does bring up a good point about performing heavy operations in the event dispatch thread. Such things can become a real problem, in terms of the application’s performance and responsiveness. However, I’m not convinced that such developer mistakes are the only problem.

Over the years I’ve done more work that I’d care to using Swing, the main GUI framework included with Java these days. But myself and other developers I know have become disenchanted with it, for a number of reasons. So I became quite interested when I read an article suggesting that JRuby could help save Swing. But after reading the article, I have come to the conclusion that Ruby will not be able to save Swing.

A while back I wrote an article clearing up several popular Java myths. One such myth is that Java can be considered a “compiled” language. It seems that a link to my article was submitted to Reddit, and one of the comments there concerned this very issue. This is a topic I would like to address further.

Slashdot recently ran a story about the early release version of a Java 6 SDK from IBM. Reading through some of the comments to that story, I noticed that a number of them mentioned some common misconceptions about Java that I think we need to clear up. Having used Java for quite some time now, in a variety of client and server-side environments, I think we can get these misconceptions cleared up pretty quickly.

Over the years I have done much in the way of C++ and Java development. Each language does have its benefits and drawbacks. Today I read an article that suggests that Java is better than C++ for software development, and I think it failed to touch on some pretty significant issues. I’d like to discuss some of the problems I saw with parts of the article.