Archive for September 2010

Jury Duty

Published on September 26, 2010

Earlier this week, I had the opportunity to serve on a jury for the first time. The experience lasted for three full days and I learned a lot about how the process works. Now that the case is closed and I can openly discuss it, I figured I’d write up a little bit about my experience. I’ll go through each day’s proceedings, the case itself, and the outcome.

Read the rest of this entry »

Sound Corruption in Windows 7?

Published on September 21, 2010

Has anyone here run into sound corruption problems in Windows 7? I’m having occasional audio problems with my current system, and I’m wondering whether my Sound Blaster Audigy 2 ZS is to blame (it’s an ancient card). All I need is another hardware failure…

Disliking Java

Published on September 21, 2010

If you were to ask me which programming language I hated, my first answer would most certainly be Lisp (short for “Lots of Stupid, Irritating Parentheses”). On the right day, my second answer might be Java. But seeing as hate is such a strong word, I’ll opt for the statement that I dislike Java instead.

For the first time in probably 7 or 8 years, I’m having to write some Java code for a project at work. In all fairness, one of the main reasons I dislike the language is that I’m simply not very familiar with it. I’m sure that if I spent more time writing Java code, I might warm up to some of its quirks. But there are too many annoyances out of the gate to make me want to write stuff in Java for fun. Jumping back into Java development reminds me just how lucky I am to work with Perl and C++ code on a daily basis. Here are a few of my main gripes:

  1. It’s a little ridiculous that the language requires the filename containing a class to exactly match the name of the class (so, a class named MyClass has to be placed in a file named “MyClass.java”). Other than making it easy to find where certain code resides, what’s the benefit of this practice? The compiler simply translates your human-readable code into machine-specific byte code; filenames get lost in the translation!
  2. It pains me to have to write System.out.println("Some string"); to print some text, when in Perl it’s simply print "Some string";. This leads me to my next major gripe:
  3. Java is way too verbose. I have to write 100 lines of code in Java to do what can be done in 10 lines of Perl. My time is worth something and I’m spending too much of it dealing with Java boilerplate code. In C++, I can use the public: keyword once, and everything that follows is public (until either another similar control keyword is reached or we come to the end of the block). It doesn’t look like that’s allowed in Java. Instead, I have to place the public keyword in front of each and every member variable and function. Ugh!
  4. Surprisingly, Java’s documentation is pretty poor. Examples are few and far between and varying terminology makes it unclear when to use what function. For example, in some list-based data structure classes, getting a count of the items in said list might be getSize(), it might be getLength(), it could be just length(), or it might even be getNumberOfItems(). There’s apparently no standard. Every other language manual I’ve ever used, be it PHP, Perl, or even the official C++ manual, has examples throughout, and relatively sane naming conventions. I can find no such help in Java-land.
  5. Automatic memory management can be handy, but it can also be a bother. I know for a fact that there are folks out there who make competent Java programmers who wouldn’t last 10 minutes with C++ code. Pointers still matter in the world of computing. That Java hides all of those concepts from programmers, especially young programmers learning the trade, seems detrimental to me. It pays to know how memory allocation works. Trusting the computer to “just handle it” for you isn’t always the best solution.
  6. Nearly all Java IDE’s make Visual Studio look like the greatest thing on the planet; and Visual Studio sucks!

All that being said, the language does have a few redeeming features. Packages are a nice way to bundle up chunks of code (I wish C++ had a similar feature). It’s also nice that the language recognizes certain data types as top-level objects (strings being one; again, C++ really hurts in this department, and yes I know about STL string which has its own set of problems).

I know there are folks who read this site that make a living writing Java code, so please don’t take offense at my views. It’s not that I hate Java; it’s just that I don’t like it.

The Future of Graphics Cards?

Published on September 13, 2010

Having recently replaced my graphics card, I was surprised to learn that the latest generation of cards requires not one, but two PCI-E power connections (with recommended power ratings of 20A on the +12V rail). Seeing as graphics cards have gotten larger (they now take up the width of 2 or more PCI slots) and more power hungry, I got thinking about their future. Several questions came to mind:

  • In 5 or 10 years, will graphics cards require their own dedicated power supply?
  • Will computer manufacturers forgo the PCI-E format for some sort of on-board socket, similar to the CPU?
  • If not, how will card size factor in to motherboard and case design?

It seems to me, especially seeing as how some graphics cards have cooling units larger than the card itself, that the PCI-E form factor for GPUs can’t last for many more years. Perhaps smaller-scale, multiple cores will prevent them from growing even larger than they are today. It’s interesting to think about the various possibilities.

Copyright © 2004-2018 Jonah Bishop. Hosted by DreamHost.