briancarper.net (λ) (Tag: Java)

Java timestamp (in)equality

Fri, 23 Oct 2009 00:17:22 -0700

user> (let [milli (.getTime (.getTime (java.util.Calendar/getInstance)))
            ts (java.sql.Timestamp. milli)
            d  (java.util.Date. milli)]
        [(= (.getTime d) (.getTime ts))
         (= ts d)
         (= d ts)])
[true false true]

Really, Java? Really? Come on now.

Documenting it doesn't make it any better either:

Note: This type is a composite of a java.util.Date and a separate nanoseconds value. Only integral seconds are stored in the java.util.Date component. The fractional seconds - the nanos - are separate. The Timestamp.equals(Object) method never returns true when passed an object that isn't an instance of java.sql.Timestamp, because the nanos component of a date is unknown. As a result, the Timestamp.equals(Object) method is not symmetric with respect to the java.util.Date.equals(Object) method. Also, the hashcode method uses the underlying java.util.Date implementation and therefore does not include nanos in its computation.

The internet is strewn with the wreckage of people being gnawed upon by this bug.

No accounting for taste

Fri, 18 Sep 2009 00:20:26 -0700

Somehow my post from yesterday about Church numerals in Clojure hit the front page of Reddit briefly. I don't understand why. It wasn't that interesting. It was an interesting topic, but there are other sites with better information about the topic. (Even Wikipedia has more/better info. This one is nice too in spite of being C#.)

I think it's because it was submitted to Reddit with a vague and inflammatory title about brain explosions, and people click links without thinking too much about what they're doing. Even programmers do, I guess.

My blog got around 14,000 visits yesterday, which is not much these days, but a lot by the standards of my tiny blog. If you added up everyone I ever had a conversation with in real life, would it be 14,000 people? I doubt it. Kind of crazy.

I run three websites out of one JVM/Clojure instance on my lowly VPS server and it didn't crash, so I'm kind of happy about that. I've crashed from lesser loads than that in the past. So either my programming is getting better, or my new host is better than my old one, or it was dumb luck.

All of my data is persisted in Tokyo Cabinet nowadays but mostly it's read from caches in Clojure refs, so maybe that helped a bit too. Maybe. Who knows? I know nothing about scaling websites. Slashdot would reduce this site to a puddle of goo.

In any case I appreciate the opportunity to blather about things and have people listen.

Making image thumbnails in Clojure

Sun, 02 Aug 2009 23:32:38 -0700

I'm making a new website (in Clojure of course) and I have a need to resize uploaded images to make thumbnails. At first I tried to use JMagick because I'm familiar with ImageMagick already and it seemed like an OK library. But on the crusty old OS my VPS uses, I had a really hard time getting it to build, and even once it built it started segfaulting like mad.

Should've gone with something simpler first. Java has built-in libraries for this. It only took a few seconds to adapt this code on Stack Overflow into Clojure code.

(use 'clojure.contrib.java-utils)
(defn make-thumbnail [filename new-filename width]
  (let [img (javax.imageio.ImageIO/read (as-file filename))
        imgtype (java.awt.image.BufferedImage/TYPE_INT_ARGB)
        width (min (.getWidth img) width)
        height (* (/ width (.getWidth img)) (.getHeight img))
        simg (java.awt.image.BufferedImage. width height imgtype)
        g (.createGraphics simg)]
    (.drawImage g img 0 0 width height nil)
    (.dispose g)
    (javax.imageio.ImageIO/write simg "png" (as-file new-filename))))

Clojure and Markdown (and Javascript and Java and...)

Sun, 22 Feb 2009 14:12:39 -0800

Writing up a blog replacement for Wordpress (in Clojure) is coming along nicely. Clojure + Compojure are awesome. Most fun I've had making a website in a long while.

One problem I've run across is that I want to use Markdown for both post content and visitor commenting. I like Stack Overflow's live Javascript previews, so you can type text in Markdown and see what it'll look like as HTML, as you type it.

As I mentioned before, Markdown is very nice because it (partly) solves one longstanding issue I've had with programming blogs (including my own), namely the proper escaping of HTML and the proper formatting of source code. In Markdown you just put code in backquotes or indent it four spaces and there you go, properly escaped. Markdown is also easy and to type and read, which is a plus. I hate hate hate writing HTML by hand.

Anyways, there is no Markdown parser for Clojure, so I was going to write one. (There is MarkdownJ but it has unresolved issues.) The problem with writing my own Markdown parser in Clojure is that Markdown is not a well-specified language. There is no "official" grammar, just an informal "Here's how it works" description and a really ugly reference implementation in Perl. Most implementations (with the exception of peg-markdown and pandoc and friends) are implemented as a bunch of global regex-replacements passed repeatedly over some text.

The result is that there are a lot of Markdown parsers in a lot of languages, and they all give slightly different results in a lot of corner cases (and a lot of not-so-corner cases). The best I could do in Clojure is pick one implementation and try my best to match it.

Now, for each blog post, the server needs to store both the Markdown text and the HTML text. It needs the Markdown because if someone wants to edit content later, they need to edit the raw Markdown. It needs the HTML so that it can be cached and served to people viewing the website, obviously.

But a consequence of the above mess is that if you use a Javascript Markdown library (i.e. Showdown) to show a live preview, and then use a different Markdown library (my own or any other) to do server-side parsing of the text after it's POSTed, there's a good chance that the preview isn't going to match the real output.

One non-solution to this is to do all the parsing client-side, and POST both the Markdown and the post-Markdown HTML to the server so both can be stored, so no server-side parsing is necessary. Aside from being a horrid idea, it's a huge security risk because it leaves open the possibility of someone POSTing some clean Markdown along with some evil, un-matching HTML.

Another non-solution is to do all the parsing server-side and use AJAX to send the preview back to the client. That wouldn't be nearly as smooth or responsive as I want; on Stack Overflow for example the preview updates instantly after every keyup event in the textarea.

The ideal solution is use the same Javascript library client-side for previews, and server-side for parsing the text. Then the preview and content have a very high chance of matching. This requires some way to run Javascript on the server. Thanks to Clojure and Java and Rhino, this turns out to be trivial.

(ns bcc.markdown
  (:import (org.mozilla.javascript Context ScriptableObject)))

(defn markdown-to-html [txt]
  (let [cx (Context/enter)
        scope (.initStandardObjects cx)
        input (Context/javaToJS txt scope)
        script (str (slurp "showdown.js")
                    "new Showdown.converter().makeHtml(input);")]
    (try
     (ScriptableObject/putProperty scope "input" input)
     (let [result (.evaluateString cx scope script "<cmd>" 1 nil)]
       (Context/toString result))
     (finally (Context/exit)))))

This also saves me from having to write a Markdown parser in Clojure, for which I am thankful.

Once again I'm also thankful we live in times when CPU cycles are cheap and abundant. I'm running a Markdown parser, in Javascript, in Java, via Clojure, and this still runs essentially instantly even for very large input strings. If I had any chance of my blog becoming famous and getting a million hits a day, it might matter, but in real life I'm set.

Stack Overflow

Thu, 15 Jan 2009 22:06:52 -0800

For my programming entertainment needs, I frequent Slashdot and Reddit, but lately also Stack Overflow. Stack Overflow is turning out to be a good source of information. I've posted some very obscure Emacs questions and gotten great answers in a few hours. Any question you post, no matter how obscure, is likely to be pounced upon by rabid reputation-seeking answerers.

What is it about a slowly-increasing numeric representation of your value as a human being that is so appealing? This is one thing Perl Monks got right early on. People there always say XP points don't matter, but I think it does on some level. It's just a silly number, but even knowing it's silly, on some deep dark level, you look at someone with 10,000 XP differently from someone with 400.

I think one of the best things you can experience as a programmer is for other programmers to think (and say) that you're smart. Maybe that's true of all professions and hobbies, but I know it's true of most programmers. Anything which takes good advantage of that fact of programmer psychology is on track to become successful.

Only bad thing about Stack Overflow is how saturated it is with .NET and Java. If you can wade through that crap, you can find some cool stuff.

Clojure, Qt4, memory leaks

Fri, 05 Dec 2008 00:13:18 -0800

I'm still exploring Clojure + Qt Jambi as a nice way to build GUI apps. I have some code to upload, if I can ever figure out how github works. The learning process really never ends for a programmer, does it? Not that I mind it, I actually love it. I love learning new tools and new languages. Git seems interesting and so many people say such good things about it that I almost have to learn it now.

Anyways, anyone who uses Qt Jambi should be aware of issues with memory leaks. Turns out you need to explicitly dispose of toplevel Qt objects or else they're never garbage collected. (This isn't as bad as it might be... most Qt objects aren't toplevel, they have parent objects.) I made a long-running system tray app and I noticed it slowly but steadily increasing in memory usage over the course of a week. I added a few calls to dispose and so far so good.

On that note, while Clojure is awesome and I think a lot of people's "OMG it's on the JVM, run!" reaction is unwarranted, the JVM still does seem to have some memory issues, on my system anyways. You do pay a RAM tax for using the JVM. A simple Clojure Qt4 app that just sits in the system tray and checks my email every couple seconds:

  PID  PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  TTY      COMMAND
 3282  20   0  282m  54m  17m S    0  2.7  11:08.75 pts/3    /usr/lib/jvm/sun-jdk-1.6/bin/java ...

54MB seems excessive. I need to look into ways of reducing that. I've passed in all kinds of parameters to the JVM limiting the heap size etc.; it was actually MORE than that before, which is even sadder.

One of the things that's either really good or really bad about Clojure, depending on your perspective, is that it forces you to learn Java and the JVM better. You don't need much Java knowledge to use Clojure, but it surely helps as soon as you want to interoperate with Java libraries. As much as I dislike Java, I recognize the need to have a job and acquire money with which to purchase such things as food and shelter. Java is good for that kind of thing.

Making Java not suck

Mon, 07 Jul 2008 21:45:32 -0700

There are some good things about Java. The virtual machine has been refined for quite some time. The garbage collector is likely to perform well. The standard library has gone through many iterations and is very encompassing and complete and amazingly well-documented. The community is enormous. The language is as cross-platform as you could reasonably expect any huge program to be. It has nice GUI frameworks (which nowadays even look native on Windows and Linux, if you use SWT), a good threading library, good socket libraries, and all the things I wish Ruby or Common Lisp had.

The one unignorably bad thing about Java is that you have to write it in Java. It's next to impossible to write Java by hand, and it's still a whole lot of pain even if you use one of the massive Java IDEs that trick you into not noticing the pain. The language is way too verbose. The syntax is busy and full of mandatory brackets and parens and punctuation and bullcrap. The demand that you catch every conceivable exception is tiresome. The ability to abstract all of those things away isn't present. The package / import scheme is way too much typing for any human being. No Lisp-style macros, no easy-to-use anonymous functions, clunky iterators, primitive looping constructs. Everything is forced into a Object Oriented mindset even if it doesn't fit well. And so on.

But the good thing is that nowadays you don't have to write Java in Java. You can write Java in Ruby using JRuby, or write Java in Lisp using Clojure. I gave both of these a try in the past week or so, and both are awesome. You can write the bulk of your program in a nice powerful fun-to-write language, and call out to Java to handle the GUI bits or whatever Java is good at handling. You can write tasty Ruby or Lisp abstractions that hide the horrible mess that is Java's syntax. (There's also Jython, if you swing that way.) You'd think it'd be more effort to write Ruby code that translates to Java than just to write plain old Java, but Ruby is so much better than Java that it actually ends up being easier. For me anyways.

It seems like the lines between programming languages is awfully blurry nowadays. Most languages have some way to interface directly with C code. There are GTK and QT bindings for everything under the sun. We have people writing Lisp interpreters in Javascript, Python interpreters in Lisp, and so on. You have all these VMs (JVM and .NET and Parrot (if it ever gets done)) which let you write the same program in whatever language you feel like. And most of them are cross-platform to some degree or other.

It's an interesting trend which makes a lot of practical sense. No language is great at everything, so why bother limiting yourself to one language per program? Especially with computers being so fast today, we can get away with layering language on top of language. It's a nice situation, if you want to get programs done as fast and with as little effort as humanly possible.

A calm and rational discussion of Java

Thu, 27 Mar 2008 16:15:29 -0700

In the past I believe I may have said that Java was god-awful. I was mistaken. Java is far more evil than any god. Java sucks like the black, empty vacuum-void of nothing that existed before time began.

I'm tasked with maintaining and updating some Java code at work. Today I wandered in to work in a chipper mood. The sun was shining, the birds were singing, life was good. Oblivious, I sat at my computer and fired up Eclipse. 20 minutes later it opened and I was looking at some Java code.

Events played themselves out like they usually do As Java flowed across my computer screen, at first it was a slight twinge in the back of my mind that something was wrong. All too quickly that twinge became a dull sort of deep-seated pain. As the minutes passed, my good mood drained from me like my life-blood draining from an open wound. Joy was replaced with horror at the programming atrocities being committed before my eyes. I'm not exaggerating to say that a few times I've looked at my screen wide-eyed, mouth agape, as involuntary mad laughter escaped me.

Whatever my many other faults, I'm pretty fast at reading code and understanding it. Still it took me over an hour today just to locate the place I needed to add five lines of code to get my job done. Generally I'll start at the top of some 20-level-deep hierarchy of classes and interfaces and abstract classes, and work my way down into it until I look back and realize I have no idea where I came from or what I'm even looking for any longer. You see, public abstract class com.someDomain.project.client.model.table.AbstractEditableTableModel, which extends AbstractTableModel and implements EditableTableModel, which itself is a superclass of GenericTableDataModel and MultiTableDataModel, may contain the stub of a method I have a vague notion I may want to look at someday, but the fun thing about Java is that I get to search the whole hierarchy of imaginary insubstantiatable classes top to bottom until I find the overridding method that really implements the logic I need to see. Then I get to re-search the whole tree to find all the methods that method calls, along with the many separate trees of classes of all the objects the first class uses.

The code I'm dealing with is 210 classes and interfaces worth of Java that does little more than fetch some data from a database and display it in a GUI in a couple of grids. Those 210 classes of course extend and implement many bits and pieces of standard classes from the Java's standard library, meaning the number of classes I really have to deal with is far higher. And most of them DON'T DO ANYTHING.

Most of this code is completely without comments of course, and important variables are named things like s and data. And methods have names like good old actionPerformed; so if the program, you know, performs any actions, I guess I'm covered.

But I shouldn't say it's entirely without documentation. Here's one method along with its documentation.

// used to propogate [sic] privilges [sic] down to the lowest node
public void pushPrivileges()
{
    int myPrivileges = getPrivileges();
    Iterator i = tables.keySet().iterator();
    while( i.hasNext() )
    {
        tableModel tbl = tables.get(i.next());
        tbl.addPrivileges(myPrivileges);
        tbl.pushPrivileges();
    }
}

This is one of the hundreds of boilerplate methods in the code I'm dealing with. I often wonder what proportion of code in Java actually directly works to solve your problem, and what proportion just flips buttons and turns knobs on hundreds of objects which in turn flip buttons and turn knobs on other objects, most of which have no need to exist, while Java spins its wheels in the mud. The above method would be one or two lines of straightforward Lisp or Ruby code, if this method even had a need to exist. Java is much like a 100-armed monster, who will put 3 of those arms to work to solve your problem if you very carefully tell it how to use the other 97 arms to masturbate itself.

The highpoint of my day though was finding a method called "isHasDeletePrivilege". Only Java could inspire such madness in a programmer. I very barely managed to keep myself from right-clicking in Eclipse, selecting refactor => rename and typing canHasDeletePrivilege. If you try to read Java code from the perspective of a group of retarded pseudo-sapient cats living on the internet, it actually makes a bit more sense.

The worst thing about Java is that it actually just barely can be used to solve most problems, which only continues to encourage people to use it.

SBCL on Gentoo (rules)

Mon, 28 Jan 2008 22:51:21 -0800

The SBCL download page shows version 1.0.14 released today, and it's already in Portage (masked). The gentoo-lisp list says we got a new Lisp project lead recently. Looks like there's plenty of Lisp going on in the Gentoo world. Personally I am very pleased with the state of Lisp in Gentoo.

Sometimes I wonder what purpose this blog serves. One purpose I found for it today was looking back through my old entries, to see how things have changed over the past couple years. I very strongly believe in introspection for the purpose of refining beliefs to make them more accurately reflect reality. In other words, I know I'm probably wrong about a lot of crap and I really don't like the thought. It bugs me. So I'm always looking for ways to change my perspective on things, if it needs changing.

I first tried Lisp in August 2006, it seems. Some of what I said was somewhat amusing, and wrong. Quoth myself:

My prediction is that Ruby will end up being mostly a superset of Lisp except for a few areas Lisp is specifically targetted at.

Oops! In fact just the opposite is true. Common Lisp is easily a superset of Ruby in all the ways that matter, specifically meta-programming and the flexibility of the object system, to name a few.

Lisp is sadly just a subset of Ruby in terms of the amount of libraries available. Ruby has tons of people writing tons of code for it. But I am finding that Common Lisp actually has a LOT more libraries than you'd guess from a quick glance. The problem is that Common Lisp is so much less "mainstream" than most languages that you have to do some digging to find the libraries you need. Once you do find them, they tend to be of high quality and great utility, from my brief experience.

Then again, Ruby itself is a subset of Perl in this regard. There's a critical mass where you probably have "enough" libraries to get the job done. Perl+CPAN is probably over the top in this regard. Ruby is there. Common Lisp is pretty close.

Quoth myself:

I must admit, properly formatting Lisp seems confusing.

Yeah, I do remember indentation of Lisp code to be pretty confusing back then. In PCL Seibel talks about how "experienced Lispers" use indentation to tell them if something funky is going on with their parens. I realized today I actually do this too now (though I am not an "experienced Lisper"). LET forms look a certain way, IF forms look a certain way, standard function calls look a certain way. You can tell immediately if something fishy is going on if the indentation is being screwy.

Actually I think people probably do this in most languages. If you've written any amount of Ruby, you know that eventually you often end up with 87 end's in a row, some closing if-then statements, some closing iterator blocks, some closing method definitions, some closing class definitions. If you type an end in Vim and it launches all the way to column 1, but you weren't expecting it there, that can tell you that you have something wrong (an extra end somewhere).

But it's much more necessary in Lisp. It seems to me that it would be extremely difficult to write good Lisp code without an editor's help. There are way too many parens for a human to keep track of. That's not to say that Lisp requires a full-blown IDE just to make the language usable (*cough*Java*cough*). Lisp syntax is regular enough that it's REALLY EASY for an editor to very consistently help you keep your parens balanced. The rules are highly logical, simple, and surprisingly standard across the Lisp community (compared to the tabs vs. whitespace, 2 vs. 4 vs. 8 spaces, curly-braces-on-newlines-or-not sorts of wars you'll find in some other languages' communities). If you use paredit or something similar, keeping your parens balanced and indented nicely is a no-brainer.

Lisp quibbles

Fri, 09 Nov 2007 20:50:55 -0800

At night to relax I've still been reading about Common Lisp. There's a lot to like about it.

But there's one thing that drives me crazy:

Let's define a variable: DEFVAR, DEFPARAMETER.
Let's define a method: DEFMETHOD.
Let's define a macro: DEFMACRO.
Let's define a package: DEFPACKAGE.
Let's define a class: DEFCLASS.
Let's define a symbol macro: ~~DEFSYMBOL~~ Whoops, nope, it's DEFINE-SYMBOL-MACRO.
Let's define a condition class: ~~DEFCONDITION~~ Sorry, nope, it's DEFINE-CONDITION.

...

Let's access an element of a plist: (GETF SOMELIST :KEY)
Let's access an element of an array: (AREF SOMEARRAY INDEX)
Let's access an element of a vector: (ELT SOMEVECTOR INDEX)
Let's access an element of a hash: ~~(GETHASH SOMEHASH KEY)~~ Wrong! It's (GETHASH KEY SOMEHASH).

For some macros, you have to quote your arguments. For some others, you don't. For some it's a mixture. Sometimes a symbol will evaluate to a variable. Sometimes it'll be read as a symbol, not evaluated. Sometimes it'll be evaluated but you never want it to be evaluated so you always need to quote it.

Sometimes parameters to function calls need to be grouped into lists and sublists. Sometimes you just pass in a big flat bunch of arguments and the method sorts them out. Often it's an arbitrary mix of the two.

Yeah, my problem is consistency. Programming is hard enough without throwing in a requirement for a bunch of rote memorization of the wording and ordering and grouping of things. Especially when those things are arbitrary, and there's no reason NOT to have them be consistent. In Lisp they're probably even more arbitrary than other languages.

This is Lisp, and if I wanted, I could write my own macros that translate new, consistent versions of those things into the inconsistent default versions. Lisp gives you the power to do that easily. But if I do that, I'm no longer writing the same Lisp everyone else* is writing. I'm writing my own derivative where I'm replacing standard things with non-standard things of my own.

There's more to a language than being syntactically correct, after all. There are dialects and idioms, and those are very important. If you learned English from a textbook, but never spoke it aloud with anyone speaks English natively, would you be able to communicate well? Would someone from England or America or India understand you? Likely you would be just barely intelligible to all of the above. It's the same English language, but how you use the language matters as much as being strictly grammatically correct. Your accent, your word choice, your general style, those things matter a whole lot.

It's the same with programming languages. If I wrote Ruby and used C-like for loops and 8-character-wide tab-indentation and CamelCase and ended every line with a semicolon, anyone very familiar with the language would cringe to read it. In Lisp, where you can change pretty much everything about the language, there's even more potential for writing things that are unintelligble to the community at large.**

Lisp does have a beautiful consistency to it overall though.*** Everything is an s-expression. (Well, except LOOP. Oops!) Everything returns a value. Code and data and code that writes code are all the same thing. It's only a few little quirks like the ones I mentioned above that drive me crazy. Consistency is also a large part of why I like Ruby: everything is an object, (almost) everything returns a value. And horrible inconsistency is one reason things like Java and PHP drive me absolutely insane.

The power of programming is in abstraction. When a group of things aren't consistent, there is no abstraction that can represent them. Or if there is, the abstraction is likely to be as nasty as the original problem. That's a bad thing.

( * "everyone else" is probably around 17 people worldwide.)
( ** "at large", for lack of a better term.)
( *** Jokes about how nobody uses Lisp aside, I do like the language plenty.)

C#... kind of doesn't suck?

Fri, 26 Oct 2007 18:50:05 -0700

At work recently (as in, yesterday) I was faced with the problem of re-writing a scientific app written in the mid-nineties. This thing was a full-screen DOS sort of app and today what with laptops and their widescreen huge-resolution displays, the program wasn't readable for the average human being. All it does is display text in different colors and take keyboard input.

So I got to pick a language to re-write this app from scratch. My first thought process was "Ruby!", but this app is a multi-threaded, GUI app running on Windows laptops that don't have Ruby installed, which is about the worst possible kind of program to try to write in Ruby, aside from maybe device drivers.

So I considered Java. A brief search reveals that even in present-day Java, you still apparently don't have the ability to easily compile Java programs to a native Windows exe. There are some Java compilers but they seem like hacks and many of them are non-free (as in money). Then I remembered that I've never seen an easy-to-use wysiwyg tool for building Java GUI apps. A google search turned up nothing, and the last version of Eclipse I used didn't let me do it either.

So then I decided oh well, I may as well bite the bullet and try C#. I've never used it before. There's a free version of Visual Studio called Visual Studio Express that you can download. (Note: I remember always wanting such a thing about 10 years ago in high school when I was just learning programming for the first time. Maybe if such a thing had been available for free back then, I would have been indoctrinated into the church of Microcrap early on rather than wandering in Linux. Their loss.)

I don't know what's missing in the free version of Visual Studio compared to the thousand dollar shyster version. The free version has a draggety-drop GUI builder, and it has the standard IDE with the auto-completion etc. It's no Vim, but it's better than anything I've ever tried to use to write Java, certainly. It's also better than writing Java in Vim, because writing Java in anything is pure unadulterated pain.

So far as the language itself, C# is noticeably more pleasant to deal with than Java, while at the same time being a blatant ripoff of it in almost every way. But some of the stupid Java annoyances are gone. For example C# doesn't make you catch every single exception that every single bit of code ever throws, which is a blessing. And it doesn't seem to try to force you to keep your files in certain kinds of directory trees. On the other hand, there are of course incredibly stupid limitations to C# for no reason I can tell. e.g. it doesn't support default parameters and doesn't allow constant arrays.

In any case, having never even seen a line of C# as of yesterday, I was able to almost finish my app in about 2 days with relatively little pain. And it's a native Windows app that can easily be deployed. If I ever find myself forced to write a Windows GUI app again (God help me) I'll probably start off with some form of .NET. If good GUI-builder tools or native-exe-producing compilers exist for Java, they need to be better advertised or something.

So given that it's Windows programming, i.e. automatically worse than almost everything else in existence, C# isn't bad, relatively speaking. I'd still rather be writing Ruby.

Java woes

Mon, 06 Aug 2007 07:44:03 -0700

I found myself having to write a Java program this weekend. At first I tried to do it in Vim. I've decided that writing Java in Vim is approximately as enjoyable as having your eyebrows burned off.

So I tried out Eclipse 3.3. It's actually quite a decent tool. It handles some of the bullcrap Java puts you through, like organizing your classes and packages into the rigid file and directory structure Java foists upon you. It can somewhat intelligently supply import statements for the seventy thousand libraries you have to import to get anything done. You can right-click and "Wrap my statements in a try/catch block" to handle the mandatory exception handling Java demands from you. Auto-completion of Java's 73-character class names is probably almost essential to avoid errors from typos in Java.

Eclipse also compiles your scripts every time you save them, which is nice, because the Java compiler chokes if you look at it the wrong way and you need to keep on top of the compiler errors last they achieve critical mass and collapse in on themselves like a black hole.

It probably says something about Java when you need a huge program that half-writes the code for you in order to be productive in the language.

Class instance variables

Wed, 02 May 2007 11:02:42 -0700

Previously I rambled about Ruby singleton classes. It turns out class instance variables are apparently actually recommended over class variables by many people. One big reason is that class variables are shared between classes and subclasses, which can lead to ugly behavior, but class instance variables are not. A google search leads to plenty of other people talking about this (example).

Today I saw on Ruby Forum some more discussion of class instance variables and it seems like a place for potential evil silent bugs. Look at this:

class A
    attr_reader :x
    def initialize
        @x = 1
    end
    def A.test
        @x = 2
    end
end

inst = A.new 
A.test
puts inst.x

This obviously prints "1", not "2". The reason is A.test operates in the context of the class, so you're really setting a A's class instance variable @x to 2, not the normal instance variable @x. But at a glance, in a program of significant size, I'm not sure how easy this would be to spot. I remember Java for example throws a fit if you try to access instance variables from inside a static method. Ruby silently allows it, which is a good thing in that it lets you do neat stuff with class instance variables, but it seems also like an easy way to create hard-to-identify bugs. I guess that argument applies to Ruby as a whole though.

SCJP continued

Tue, 16 Jan 2007 23:53:47 -0800

Another SCJP study chapter down. I no longer feel bad about missing some questions in the last chapter, because THIS chapter is the one that talks about abstract classes being able to implement interfaces etc. Nice to ask questions about things before actually covering them.

Those silly default no-arg constructors in Java. I missed one review question about those. This is an example of the opposite of the "principle of least surprise" so touted in Perl and Ruby. Default constructors are magically automatically created in Java, but only if you don't supply any constructors of your own. Calls to superclass constructors are magically inserted in all constructors including those you define yourself, but they're always calls to super() with no arguments, and those super() calls aren't inserted into any constructor that calls another constructor as its first line. And so on and so forth.

Interesting that interfaces can extend multiple interfaces, while classes cannot extend multiple classes. One of the reasons behind forbidding multiple inheritance is supposedly so that you don't have to deal with method name collisions when multiple parent classes each let a child inherit methods with the same name. I tested what happens when there are name collisions in interfaces:

interface Blarg {
    public void test();
}

interface Blarg2 {
    public int test();
}

public class Test2 implements Blarg, Blarg2 {
    public void test() {}
    public static void main(String [] args) {}
}

It appears in this case there is no way to actually implement both the Blarg and Blarg2 interfaces in one class. (If there is, I can't see it.) You can't have two methods with the same name, same argument signature, and different return value. Trying to compile this fails with a "Hey you forgot to implement Blarg2's test() method" error. Similarly if I try

interface Blarg3 extends Blarg, Blarg2 {}

I get an error about Blarg and Blarg2 being "incompatible" because both define a method of the same name. That's handy. (Why not use the same error and allow multiple inheritance, and forbid it only whenever there are method name collisions? Who knows. Not I. I'm sure there are reasons. I hope there are reasons.)

I have a very good grasp on overriding vs. overloading. I remember going over it in my very first C++ class at college. I've somehow carried it all the way with me. Same goes with typecasting. Perl/Ruby don't have an equivalent, but I remember enough of it from C++. I also don't seem to have any trouble remembering which things happen at runtime and which things happen at compile-time. That should serve me well on the exam.

Sun Java on Ubuntu

Tue, 16 Jan 2007 12:23:45 -0800

Note to self, Ubuntu uses GCJ for Java by default. To get Sun's Java and set it as default,

sudo apt-get install sun-java5-jdk
sudo update-alternatives --config java

SCJP

Tue, 16 Jan 2007 00:20:32 -0800

I plan to move to the west coast sometime within a few months, and that means job searching. That means time to hunker down and get this SCJP overwith. I don't know if it'll help me find a job, but it can't hurt me. I'm going to keep track of what I learn here, and I'm going to write about things I found troublesome in hopes that the act of typing it will help me remember, and that I'll have some kind of record of it.

Today I went through one chapter, dealing mostly with Java class/method/member access modifiers. In the practice questions I missed a couple questions, which was depressing after having just studied it for nearly two hours.

One I missed because I didn't know abstract classes can implement interfaces. But it makes sense that when an abstract class DOES implement an interface, it doesn't need to provide all the methods in the interface.

Another I missed due to Java's screwy syntax. Java will supply an implicit public abstract on any methods in an interface, but when you implement those methods in a concrete class you have to specify them explicitly public. Otherwise they revert to default and that means they don't properly implement the interface's methods at all.

Similar to above, I forgot that even though an interface provides an implicit abstract to its methods, and abstract class does NOT. That makes sense after I think about it for a second, because abstract classes can contain both abstract AND non-abstract methods. However given that abstract and non-abstract methods have different syntax themselves (abstract methods end with a semicolon, and non-abstract methods end with curly braces containing or not containing code) you'd think the compiler could figure it out. But nope.

It's amazing how I studied Java for two years at college and I never got these kinds of rules spelled out in so many words. I sort of picked it up as I went. And I took a class on compiler theory / general computer language design theory, which helped IMMENSELY whenever I need to understand things like scoping rules and inheritance rules and parameter-passing methods. I think those very subtle things are one of the more difficult aspects of computer programming, especially because they differ so often between various programming languages.

Java?

Thu, 19 Oct 2006 23:04:18 -0700

I'm studying for a Java certification. I haven't used Java since college, so it's a nice refresher. The one I'm after is SCJP. You basically study for a while and then pay $200 and take a test and you're done. You could take classes, I imagine, but they're optional and having looked at the material, I doubt they're necessary. I've started to study and the subject matter is not that advanced. Scoping rules and inheritance methods and some of Java's awkward syntax, for the most part. It's the kind of stuff you'd pick up anyways if you used Java for any extended period of time, which now that I think of it may be the whole point.

I'm not really sure a Java certification is "worth" anything. In any case I surely wouldn't consider someone whose ONLY qualification was this certification any kind of expert in Java; I likely wouldn't even consider them necessarily competent. But I think it's good to have the certification anyways, because 1) It shows I give a crap about programming enough that I'm willing to continue my education, 2) It shows I'm at least smart enough to study and pass a reasonably difficult exam, and 3) It MAY not help me in the future, but it surely can't HURT to have it on my resume. And it's only $200. Assuming I pass the first time.

After being immersed in Ruby for so long, Java feels cumbersome and awkward to me. There are so many artificial barriers built into the language. You can't test anything other than a boolean value in a if() expression. What kind of language doesn't make everything true by default? Ruby handles it so nicely; false and nil are "false", and everything else is "true". In Java you can't have anything other than an INT in the test conditions of a switch block. Why? I can't possibly imagine the motivation for that decision; I'm sure there was one, but it's beyond me. I know there are advantages to having a firmly structured language specification, and I'm not one to proclaim "OMG JAVA SUCKS" to the world as though I'm on a religious crusade; thankfully I retain that much sanity. But the advantages of a highly structured language just don't mesh with my personality, I guess. I find it tedious and constricting.

However if someone wants to pay me good money to write Java all day, I'll do it with a smile. I love programming. Any programming. Some kinds more than others, but any programming job is automatically better than every non-programming job, in my book. Even if I was writing QBASIC for a living I could be happy. Heck I'm fairly happy right now and I use Windows all day.

Theseus and the Minotaur

Sat, 03 Jun 2006 23:03:57 -0700

Here's a little Java game that I found pretty entertaining.

When I got to the sixth puzzle I decided to see if I could write a program to solve these kinds of puzzles. I did; here it is in Ruby, featuring OOP goodness and a bit of recursion, but otherwise just brute force.

It only takes about .04 seconds to solve maze 9. It doesn't find an optimal solution; it tends to have Theseus wander around like a drunkard. Maybe it could be improved with heuristics, but I couldn't think of one. "Move towards the goal" doesn't work in general, because Theseus has to backtrack a lot on purpose to strand the Minotaur behind walls. It'll save one or two moves at most. "Move away from the Minotaur" or "Move toward the Minotaur" don't work because both are necessary many times. So I don't know. I only tried it on puzzle 6-9, but it seems to work.