Angel Studios is starting to plan a round of screen tests for the people interested in being a part of our films and stage productions. We’d essentially like a database of actors we can flick through and find a list of people who might be suitable for a given role. We also need to do a bunch of auditions for our upcoming short film which is just starting production. There are a few people I want to get back in touch with to particularly invite along to do a screen test but we need to sort out exactly how we want to do it yet. Even so, if anyone’s interested in getting involved in film or stage productions, no experience is necessary, give me a yell (adrian at intencha dot com) and I’ll let you know when we’re actually ready to start doing some. It’s a lot of fun.

This is a great example of getting stuck in a mindset. A piece of very poorly written Java code is presented followed by a much shorter piece of Groovy code and Groovy is declared the winner.

The original Groovy:

list = ["Rod", "James", "Chris"]
shorts = list.findAll { it.size() <= 4 }
shorts.each { println it }

Java:

for ( String item : new String[] {"Rod", "James", "Chris" } )  if ( item.length() <= 4 ) System.out.println(item);

oooo, one line! It must be good… Of course if I were actually going to write that, I’d write it as:

Continuing my journey of learning regarding scripting languages (starting here):

I like it because it saves typing. There was a good example of a 20-line Java program that was reduced to 3 lines in Groovy. I’ve lost the link though. Posted by: Jonathan Aquino I like readability. Java can definitely be overly verbose at times, particularly with IO:

BufferedInputStream in = new BufferedInputStream(new InputStreamReader(System.in()); however, number of lines required to do something isn't something that I really consider when choosing a language. Obviously if it's at either extreme it matters, but few languages are either so short or so long that it really impacts readability. I'm also far more concerned with maintenance time than with development time because maintenance time almost always outweighs development time. Having said that, many people do like really compact languages and some scripting languages provide that (HyperTalk certainly doesn't). Greg Black adds some 

interesting comments as well. I certainly see the benefits of scripting for quick and dirty solutions or small programs as I tried to point out. Greg also quotes me as saying:

As much as the title seems to suggest one of my rants, this is actually a valid question along with a bit of my own pondering. Scripting languages seem to be the flavor of the month these days and I’m not really sure why. I’ve got nothing against scripting languages but I don’t see why they should be considered the be all and end all solution that people seem to think they are. Interestingly, when I first seriously got into programming, it was using HyperCard and there was a constant barrage of insults coming from the “real programmers” about these hobbyists using scripting languages. More than ten years later and all of a sudden you’re just not groovy (pardon the pun) if you’re not using a scripting language. I love being able to write a quick perl script to munge a text file in an odd format or to run through the Xalan codebase and change the package so that it doesn’t conflict with the version in the JRE. Our support auto-responder at work is a cool little perl script that I wrote to take the incoming (evil MS HTML formatted email) that comes from the web form, parse it, log the details in our tracking system and fire back an email to the user with the tracking number. Works a charm. It would be a real pain to write that stuff in anything but perl because of perl’s awesome support for text parsing and abundant if unwieldy and occasionally unreliable libraries in CPAN. I’ve also written a major business system in perl with database interaction, workflow and all that jazz. It worked well but it was certainly no easier to do it in perl than Java or most likely C given appropriate libraries. I wouldn’t consider C an option unless performance was absolutely critical for server systems however because it leaves open the risk of buffer overruns and similar security holes that can be completely eliminated automatically by most other languages. Even if speed were critical I’d recommend buying faster hardware or using a distributed system before writing a server in C. I’ve also written little scripts and smallish sites in PHP. It’s a nice language that I enjoy using but again I don’t see anything hugely wonderful about it. Everyone seems to be very python oriented these days and I must admit to having almost no knowledge of the language but from the code I have tried to modify in python I really don’t see any reason to be overly excited about it. Again, there doesn’t seem to be anything particularly wrong with it, but I don’t see why it would be so much better than C, Java, Visual Basic, C# etc. I also use JavaScript a lot at work and use it as a full programming language, not just to do roll over graphics. It can do some cool things but the resulting code is far from easily maintainable and again, I don’t see the advantage other than it’s the only option for code-in-a-browser when working cross-browser. The most common reason I hear people giving for why they like scripting languages is because they “just flow better”. I just don’t buy that. I grew up on scripting languages and I just don’t find that they flow any better than any other languages. They do tend to be easier to learn because you get to ignore most of the rules of good programming while you learn (think perl without the use strict directive). If you want to write good code though, you should put that use strict line back in and pay attention to all those little details that make initial coding harder but maintainability easier. Once you’re thinking about all those little things I find scripting has the same feel as “programming”. So am I abnormal or am I just missing something? Maybe it’s both….

A while back Kyle Rankin questioned why people would use InstallShield under Linux. He suggests people use the standard package management schemes that the various distributions provide and he’s dead right. You should make things consistent for the user because it’s consistency that makes a user interface easy to learn and makes it more productive (once you’ve learnt it once you can use it in a whole heap of places at once without taking the time to think of the right way to do it). There is however a problem with this. There are just way too many linux distributions. Even taking into account the fact that there’s a lot of overlap in package management tools, it’s a big ask to expect a company to provide different packages for all of the different systems. Given that, they now have two choices:

On a more positive note, if you need to work with the Swing Text APIs in any detail,would like to do something with text that you currently can’t or for some reason are implementing a text API, take a look at this overview and the articles here (the text articles are towards the bottom). Some of the docs seem to be fairly old but the basic features of the API really haven’t changed all that much and it’s far more important to understand the design than the specific methods that are available anyway. Once you understand the design, you’ll know where to look for the methods.

I’m getting really tired of the amount of bigotry in regards to programming languages. First let me admit that I’m certainly guilty of technology bigotry – I’m definitely biased towards Mac OS and Java to name a couple of things, but I’m at least aware of it and willing to admit it. Furthermore I can provide reasonable explanations as to why I like them if not actually explain in every situation why I favor them (read: at times I’m just being bigoted about it). When it comes to programming languages and in fact most things in technology, there are few things that are not the best choice in at least some situation – even if it is only one incredibly specific situation. This is even more true when you only take into account the things that are widely used. Lately Java has been coping it (more than usual) with people actually booing at demonstrations that used Java and a lot of fairly immature comments being made. Lets take the view point that Java is a pathetically hopeless, good for nothing language. Everything about it sucks, the people who use it are obviously idiots and it’s too slow to do anything useful with. Obviously the company I work for made a massive mistake implementing their product in Java and at long last we’ve realized it and want to reimplement it in a good language (we’ll probably have to fire all those stupid java developers too but one step at a time). Lets look at the (highly informal) requirements for these products:

I ranted earlier about dependencies and the way Java programmers are always pining for the latest and greatest. The comment by Stephen Thorne to the article deserves being published with the same level of visibility as the original post so I quote it below. It also deserves some rebuttal which is also below.

I’ve been saying this for years, and yet I still run into rabid pro-java programmers who managed to rattle off a list of reasons why java is the bestest programming language in the world include “good library support” to which my response is “hold on, slow down, good library support? let me tell you a story…” and I recite any one of a dozen anecdotes about dependancy hell in java. The only java project I’ve seen that manages to avoid this without extreme pain is kowari, which takes the slant “We’ll distribute the ENTIRE DAMNED THING as a .jar, libraries included, just make sure you have a recent enough JVM.” They don’t have the windowing troubles because its a database. ;) The first thing I want to correct is the implication that java doesn’t have good library support – it absolutely does. Look around at the huge range of libraries available for Java and particularly look at the fantastic standard library that comes with it. Plenty of top quality libraries for pretty much every moderately common task. There is however a separate issue of dependency management. Problematic dependency management (aka dll hell) is caused by two things:

Greg Black comments on the IBM donation of code to the ASF (at least I think that’s what he meant). Ken Coar has already provided the explations. For the record Greg, your site just gives me “access denied” so I can only read your blog via Planet Humbug and can’t leave this as a comment.

James Strachan puts forward a proposal that Sun opensource the standard Java libraries and I see no problems with it. In general I don’t think we’ll see all the benefits James predicts from it though we would see some. In particular I want to point out one benefit that James claims we’ll get but that we definitely won’t get:

more eyeballs are now looking closely at the code This is the biggest advantage opensource proponents put forward for opensourcing any code but it just doesn’t apply to Java. Why not? The source code to the standard Java libraries are included with every copy of the JRE. You can already go and inspect the source code, find bugs and submit patches to Sun. The fact is, most people can’t be bothered. They have real work to do and don’t want to be wasting time analyzing the source code for the library their using, they just want it to work. When it doesn’t work then people tend to turn to the source and people are already doing that. I also don’t believe that people really want to write Java code that can run on the .Net platform. Java has always suffered from people feeling that it was second rate due to it’s cross platform nature. This is true to some extent, when writing any cross platform code you inherently make it harder to use the platforms native resources due to the extra layer of abstraction. Why would you use the .Net platform when all of the extra functionality it would provide (like tie-ins to word, infopath etc) wouldn’t be available from Java (because they’re not cross-platform). You’d have to use JNI or similar to call “native” .Net code and so you have to learn C#, the .Net libraries and their toolsets etc. Also, opensource developers who are refusing to use Java now will refuse to use Java then. Read some of the blogs coming out of OSCON at java.net and you’ll realize that the majority of the opensource world is just unreasonably bigoted against Java. That’s okay though, I’ve grown to really dislike the GPL anyway.

This article entitled “Great Hackers” really pissed me off. It is just so far off-base that it’s annoying. It’s not the kind of article that is generally wrong on facts, but just wrong on intentions and the concepts of what’s good and what’s bad. There are a few really, really stupid and outright wrong statements in it though. The worst of these is:

The programmers you’ll be able to hire to work on a Java project won’t be as smart as the ones you could get to work on a project written in Python. That statement referenced a footnote as well which I thought might point to some scientific survey of Java programmers vs Python programmers so that the statement at least had some backing. Sadly, the footnote was:

I’ve never understood Java programmers attitudes to dependencies. The Java runtime and libraries was designed specifically to allow cross-platform deployment and increase compatibility. Write once, run anywhere. What confuses me then is this obsession Java developers seem to have with being incompatible or rather, using the absolute bleeding-edge, never released, not available anywhere version of stuff – particularly the JRE. Now certainly Java is unusual in that it is rapidly developing. Not only that but the language, the runtime and the libraries are all tied in together so if you want to live on the bleeding edge with one you have to live on the bleeding edge with them all. Contrast this with the C world where the language is effectively static, the standard library is minimal and evolving relatively slowly and the “runtime” (I’m thinking of the ABI) is fairly static (if platform specific). It’s not often that C programmers have to make a decision to update to the latest version and it rarely impacts deployability if they do. Most of the time if a C program requires a specific version of a library it just statically compiles it. In the Java world however, people are always pining for the latest enhancements. Suddenly generics are a huge deal when everyone’s been getting by without them just fine for years. Suddenly it’s too much effort to work around bugs in the libraries and it’s better to just force users to upgrade. Frankly, that’s simply not good enough. If I develop an application for Windows, I have to decide which versions of Windows I’ll support. I could use APIs that are new to Windows XP and thus tie my application specifically to it, or I could not use those APIs and let any Windows version run it. Better yet, I could design my system in such a way that I can optionally use those APIs if they’re available and fail gracefully otherwise. C programmers are really good at this, most likely because they’ve spent so much time trying to write C code that’s cross platform (it’s possible, but you have to be good at doing this kind of thing). Unlike C, Java actually makes it easy to optionally use APIs because everything is dynamically bound. Consider the class: