Wednesday, August 30, 2006

the Java closures that aren't

I admit to not reading the much-blogged closures proposal all the way through for the simple reason that I use Java version 1.4.2 at work (frankly, I have little to no say in the matter). I'm still waiting to throw out xdoclet for language-level annotations.

Nevertheless, I'm still glad to read Java Closures? Or just functors? Or just confusion? . Antonio does a great jorb defining real closures and functors, and thereby skewering the value of the proposed Java "closures". I especially appreciate this because I am consistently annoyed whenever people refer to a mere anonymous code block as a closure. Back when I used Perl more, I remember understanding code blocks (and references to code blocks) just fine, but having trouble understanding closures. I suppose it's a fine line, since languages with anonymous code blocks probably have lexical context and allow the code access to it, but try to answer the question "can someone create a full closure in Python?" and see how complicated the difference can be.

I didn't know about C++ functors until now. Of course, the term functor also represents a different technique in ML languages...*sob*

Tuesday, August 29, 2006

is haskell hot or not?

So, Haskell is one of those languages that I keep hearing great things about, but I'm still not convinced enough to take a long, serious look at it. A journal entry by Ziggy makes Haskell sure smell like nirvana. Then I see something like Algebraic Topology in Haskell over at, and Damian Conway's turn of phrase from another context, "brain-meltingly complicated", comes to mind. Maybe the moral here is that once you adjust to monads and lazy evaluation and other unique features, you can use Haskell to manage any level of complexity you wish--there is no artificial limit on expressiveness. But I'm only speculating. The usual caveat applies: if you write your software too cleverly, you just might have to maintain it for life. Don't forget another factor too: a powerfully expressive language without the particular libraries you need simply isn't as practically useful as a lesser language with those libraries. On a common VM platform, any language can use any library, so this is admittedly becoming less of a concern.

Ziggy's post is really about a perceived (I don't believe that the majority of developers out there truly care at this point) mainstream rise of functional programming. He (she?) links to Joel on Software's Can Your Programming Language Do This? as an example, which by the way is a brilliantly concise but easily understood explanation of how convenient some functional programming features can be. I must say that I would prefer Ruby versions of his code snippets. Ziggy also links to Kingdom of Nouns, which I've commented on before. I wonder if the people who use Ruby as a poster child of not being a kingdom of nouns are self-aware enough to notice that everything in Ruby is a noun (object)?

Bonus observation: Adam Bien's Weblog says that you shouldn't compare Javascript/Ruby to Java. Why? Because as I said in "clash of programming language civilizations", the values are different.

Saturday, August 26, 2006

the two species of programmers

Along the same lines as that "clash of programming language civilizations" post, I have long had the idea that there are two basic species of programmers. I have no hard evidence for this blurry distinction, but only my own experience and hyperactive generalization. I'm also sure that I'm not the only one to have stumbled upon this. Anyway, in alphabetical order, the two species: linguistic and mathematical.
  1. Linguistic. This species spells correctly most of the time. In fact, the linguistic can often be observed lecturing or poking fun at the mathematical's egregious spelling errors. Per its name, the linguistic has excellent language intelligence or aptitude, and perhaps may study little-used languages like Esperanto. The linguistic may be good at abstract algebra, but may not be as quick as the mathematical when it comes to, say, listing the first 23 prime numbers. A program is a series of sentences and clauses for a linguistic. Functional programming may come more naturally to the linguistic than the mathematical. The linguistic may take excessive pleasure in the logical elegance of a program's design. He or she may be more apt to comment "if the computer can't run my beautiful program efficiently, then that's the compiler or interpreter's problem". Top-down or UML-style design may be a preferred mode of operation for the linguistic.
  2. Mathematical. This species often has difficulty spelling correctly. But to the mathematical, correct spelling doesn't really matter so long as the idea gets communicated. Per its name, the mathematical has excellent mathematical intelligence or aptitude, and may know practical trivia about timekeeping. The mathematical's intuitive feel for numbers allows for good estimation, such that the mathematical can arrive at an answer but have trouble explaining how he arrived at it. A program is a series of individual calculations for a mathematical. A mathematical would view the statement a = 5 + 2 to be "add 5 to 2 and store the result in a", while a linguistic would view the same statement as "define a to be the evaluation of the expression 5 + 2". Assembly programming may come more naturally to the mathematical than the linguistic. To the mathematical, complex program design is not necessarily a joy; to the contrary, it may be more likely to obscure the real functioning of a program. He or she may be more apt to comment "perfect theroetical purity isn't worth anything if it doesn't adequately solve this particular problem in the real world". Bottom-up or eXtreme Programming may be a preferred more of operation for the mathematical, in which program modularity evolves naturally.
I make no value judgments here about which species is "better". For what it's worth, I identify more with the linguistic species. Of course, my taxonomy is a failure in the sense that any actual programmer may "switch species" in any given situation. For instance, I know that whenever I write a shell script, I do it like a specimen of the mathematical species: look up some quick examples on the Web, use trial-and-error to figure out which utility parameters do what I need, and basically learn as little of the syntax as I must. My two categories also fail in the sense that any actual programmer probably exhibits features of both species. I think it should go without saying, but the best, well-rounded programmer should be a chimera.

Wednesday, August 23, 2006

commentary on personality traits of the best software developers

Personality Traits of the Best Software Developers seems fairly insightful and honest. Some of the many comments also make some good points, although enumerating more and more desireable personality traits is really tangential to the original post. The author, Rob, condensed the most essential traits into an exceedingly compact list. Other traits are fine, but simply not as worthy of inclusion.

Naturally, I believe that I have the described traits, and furthermore that the four traits have a characteristic in common: a focus on reality (the code's effects) as opposed to a mere focus on idealized abstractions (the code itself). Developers focused on reality don't dream up a solution, code it, and then see how it turns out. Developers focused on reality 1. consider possible problems ahead of time (pessimistic trait), 2. believe that each problem is a logical effect from a root cause in the code (angered by sloppy code trait), 3. create and stick to a long-term plan that protects them against real threats (long term life planners trait), 4. keep abreast of as much reality as they can (attention to detail trait).

Of course, I can't help adding in a couple other traits that I value: 1. curiosity, 2. creativity. Developers with those two traits always have more alternatives available to them in any given situation. Ever play a game called Mindtrap? It has cards with short little puzzles, each of which has no obvious solution until the listener stops limiting his answers with assumptions and preconceptions. Life is Mindtrap.

Tuesday, August 22, 2006

clash of programming language civilizations

Why yes, the title of this post is sensationalist and even a little insulting to the real, violent culture clashes in the world. Thanks for noticing.

A few days ago I pointed to a blog posting that I saw through the feed. This time, I'll be pointing to blog postings through the feed. (I'm subscribed to those feeds because I frequently use Java and Perl at work. Outside of work, I experiment with whatever.) A proposal to add closures to Java has brought out some interesting arguments for the status quo. Java 5 Language changes were a bad idea even argues that the status quo, Java 5, isn't all that much an improvement over previous versions. Here are two quotes from there, one short, one long: "Verbosity is a good thing(tm)!", "Encapsulation is very important and is defined using several levels of hiding: class, package, protected and public... Simple and powerful. Why is this powerful? Because I can rely on the scope and find the usage of X (X being a field or method) within his scope far more easily.".

What I find so intriguing is that the same valued characteristics this blog used to support an exceedingly lean, simple Java are what Java detractors routinely trot out as arguments for Java being weak, wordy, and over-engineered. The same characteristics! It's as if one person's language vice is another person's language virtue. Contrast the above quotes to quotes from the dynamic-typing, stop-calling-us-scripting-languages camp: "do what I mean (DWIM)", "convention over configuration", "the first postmodern computer language". With values this different, neither "side" even has an agreed-upon ruler for comparing, syntax.

This clash in values is even more dramatic when you start considering examples. About Microsoft's "Delegates" transparently explains why Java chose not to have delegates. One blogger compared Hani's Bile Blog to some of the oh-so-friendly Ruby resources, and got some surprisingly shrill replies in spite of the fact that one's attitude has no correlation to one's programming language. A blog entry which is not so tongue-in-cheek is Our long Java nightmare. He says this isn't an anti-Java rant, but with a title like that, I wonder what would be. An irritated individual over on javalobby has the legitimate complaint that Ruby users keep discussing Ruby on Java sites. There's even a guy who feels compelled to argue that Java is not in the midst of a close battle with the Next Big Thing.

Another twist on this deep clash in philosophy is the group who works in Java for a living, and is recreating (mostly server-side) Java development "from the inside". Truth be told, if you want to use closures along with Java-ish syntax, you can just use Groovy right now and use Grails to develop a website around an EJB 3 object. Web service development isn't that hard at all if you use Glassfish. Even sticking with Eclipse is easier than it used to be with Callisto. If you prefer VB-like development, you may be able to do that sometime in the future. Want the source for the language implementation, so you can solve the most obscure bugs? It's on the way. Java programmers are not buffoons. Whether they cash in on it or not, they (we?) know how hard it has been to get things done in Java.

Conclusion? There is none. The rationale behind a choice of programming language is up to you, or your managers. Which punctuation marks or paradigm a language uses is only part of the equation..."it's how you use it". As Ovid explains, Perl probably wouldn't have the reputation it does if people used it better. More to the point, in another place Ovid advises his readers to ignore language holy wars and use the language whose strengths best fit your problem.

I would also advise that rather than choosing 1. the side of Turing Machines and statefulness and efficiency and static typing, or 2. the side of lambda calculus and statelessness and runtime interpretation and deferred typing, pick both. Think laterally. Use a convenient RAD language for most of the program and a speedy language for the parts that are a performance bottleneck. Use a language that can check types at run time OR compile time. Use a language that is functional but statically typed, like F#. There doesn't have to be One Language to Rule Them All, as long as there is One Interoperable Platform To In the Darkness Bind Them. But it certainly is entertaining to watch the two programming language civilizations clash.

Saturday, August 19, 2006

make a combinator from a MOP

Where would I be without RSS? In Firefox, you can make a Live Bookmark folder from a feed, then put that folder into the bookmarks toolbar folder. Turn on the bookmarks toolbar from the view menu, and then you have one-click access to checking up on your feeds.

This technique is most handy for sites that aggregate or host many blogs but offer one, combined feed. It was through the Most Recent Journals feed that I found the provocatively titled post Moose::AutoBox - Ruby ain't got nothin on us . The more that I investigated what Stevan wrote about, the more impressed I was by what he's working on. Moose::AutoBox, strangely enough, uses an autobox module and Stevan's Moose module to enable runtime modification of methods to call on Perl's builtin types. The runtime object modification happens through the Moose module, which as I understand it is for providing a nicer interface to the Class::MOP module. And the Class::MOP module is an implementation of a Meta Object Protocol for Perl 5 objects. It came about because he wanted to use some Perl 6 object features in Perl 5 (he's not alone; there are other modules out there for doing Perl 6-ish stuff in Perl 5).

I'm skeptical about the usefulness of a class morphing at runtime, but once again I admit to not ever doing it. I simply haven't found a need for it in the software I write. Actually, I don't use plain old reflection or introspection much either. It seems to me that a combination of interfaces and runtime composition of objects can accomplish the effect of changing a class's behavior at runtime, but in a cleaner and type-safe way (see strategy or command or dependency injection design patterns). In fact, reading Stevan's post reminded me of a different post I read a while back on Oreilly, Is a Java macro language enough? . It's good reading, and it discusses both a MOP and Lisp-style macros for Java. I think he concludes that bolting on such sophisticated features at this stage in the game would result in a more complicated language, when what we want is to make Java easier not harder to work with.

Back to Stevan's post. He shows an example of using the Code part of Moose::Autobox to apply the Y combinator, which is part of the module, to an anonymous code block to make it recursive. What's the point of this in a language that supports recursion in the usual fashion: by using the function name inside its definition? There is none, unless you really, really don't want to name your recursive function for some if you're defining it on the spot so you can pass it to a higher-order function. Anyway, if you're curious about the Y combinator like I was, be prepared to read many parentheses in links like this ruby example, or this Scheme example . The Scheme link is about several abstract topics, but the Y combinator is at the bottom. They don't teach this stuff in Java class, people. They just don't.

Friday, August 18, 2006

v for vendetta

So, V for Vendetta turned out to be what I expected, based on what I had heard. Fantastic imagery, some bloody action, an enigmatic main character, hairless Natalie Portman. Oh, and some political discussion points. Make that a lot of political discussion points. Er, I mean a continual deluge of political discussion points.

Although still not as pathetically clumsy and obvious as the contrived mention of a "Triad of Evil" in a Star Wars pre-episode III novel, Labyrinth of Evil. We in the know, including George Lucas, have long been aware of how the Old Republic turned into the Galactic Empire; the general process by which this happens has repeated throughout history. Read Rise and Fall of the Third Reich, if you don't mind feeling chills down your back.

I'm also amused by people praising the "boldness" of this movie. The US is not repressive. Hollywood has made "bold", "political" movies for a long time. Not that those movies always do well...anyway, V for Vendetta is a stunning movie in more than one sense, so I recommend that people take a look. And start treating your favorite downtrodden minority nicer today!

Unrelated observation from watching my Klingon Fan Collective DVD set: I've only seen a handful of episodes of Deep Space Nine, but after the episodes on this set, I'm frightened by how deeply I like Jadzia Dax. Her appearance (hey, I'm only human, you know), her fun personality, her many layers of competence, her intriguing backstory(-ies), her rapport with Sisko. How sad is a crush on a fictional character? Pretty dang sad, I'd guess.

Thursday, August 17, 2006

peeve no. 241 - release date slippage

No, I don't mean Vista.

I don't know how long this information has been out and about on the Web, but apparently the muppet show season two DVD will NOT come out in 2006, but in spring of 2007. Season one had some excellent bits, but the celebrity list was...unimpressive. Any fans of Peter Ustinov out there? Joel Gray? Charles Aznavour? Maybe this isn't a fair complaint, since it was the very first season, and admittedly there were some greats (legends) like Vincent Price in some of the episodes too. Another annoying fact of the first season was that not only were the main muppets' personalities not yet firing on all cylinders, but the appearance/design was different at that time. From what I've read, season two was a big step up from season one in regard to these complaints, so I have eagerly awaited it. Then again, I eagerly awaited the continually reschedued Final Fantasy: Advent Children's US release too, and unfortunately the muppet people seem to have taken a page from that playbook. You know you'll get my money. Why must you deprive yourself of it?

Tuesday, August 15, 2006

6 morality lessons from Worf

I bought the Klingon Fan Collective DVD, and as I worked my way through it I realized the episodes centering around Worf illustrated some relevant moral lessons. Of course, it's no secret that stories communicate morals better than any other method. I thought I'd try the oft-proven "make a blog post out of a numbered list" trick.
  1. Victory is not automatically honorable. Or, the ends do not automatically justify the means. Unlike Duras and his conspirators, Worf refuses to consider any convenient shortcuts to power that would compromise a code of honor.
  2. Mercy and justice are as important as strength. Worf doesn't kill Toral, son of Duras, for the sake of revenge.
  3. Unity and harmony are worth the cost of any one individual. Worf accepts a label of dishonor for the sake of at least temporarily averting a civil war. I suppose it isn't as poetic as the quote about the "needs of the many outnumber the needs of the few...or the one", but I think choosing to live with dishonor is in fact a much greater sacrifice than death for a Klingon.
  4. Personal moral satisfaction matters more than societal acceptance. By stating that there is a difference between the "Klingon way" and "my way", Worf demonstrates a mature stage of moral development in which he makes his own decisions. One of the harder concepts for me was the idea that someone has to earn honor from others. I understand not wanting to disappoint your mentors, but it seems like complete horsepucky to jump through hoops just so other people will admit what you know about yourself already.
  5. The greatest loyalty to a specific entity will sometimes be expressed as discontentment with its current state. Worf steadfastly refuses to support a Klingon invasion of Cardassia, but he is no traitor. If he didn't care about the Empire at all, he would let it do whatever. If he followed the Empire just because it was the Empire, he would still let it do whatever, and also participate. His dissent proves that he believes in the Empire as an ideal which the real Empire should strive for.
  6. Different moralities can learn from one another. Picard says that Worf has taken the best of humanity and used it to become an excellent officer. Someone who is too insecure to approach a different morality without bias also is closed off from learning the best of what that morality offers.
As usual, Federation (human) morality is more well-rounded than the Klingon alternative. No surprise there, since the major alien races in Star Trek are exaggerations of particular aspects of humanity. Vulcans would be an exaggeration of logical behavior. Ferengi are an exaggeration of materialism. Borg are an exaggeration of corporate activity. Even races like the Organians, who supposedly have a superior morality, turn out to have the morality of the Federation, but practiced more consistently.

These moral lessons are not unique to Worf. Worf is an instance of a prototypical "honorable warrior" character (maybe originating in the samurai or Beowulf?) whose battlefield honor fuses with an understanding of love, until the warrior learns to avoid war unless necessary to protect the good. I think I read once that a beginning warrior has a weapon in his hand, an intermediate warrior is one with his weapon, and an advanced warrior carries no weapon at all. Dinobot in Beast Wars Transformers is another good example. Don't believe me? Read this, which explains the concept better than I ever will.

Tuesday, August 08, 2006

aw, just read this page

I've been pondering some more posts about data typing in languages, the practical use of functional programming, etc., but after I reread the following page, I decided to just link to it since it makes pretty much all of the points I was thinking and more: Scalable computer programming languages . Even better, it was written by someone who's arguably more qualified than me to opine about any computer science topic whatsoever, and a more effective writer. I must confess, his mention of some language called Dylan has piqued my curiosity. I wonder what he would think about Ruby.
If programming languages were cars... acts like a humorous shorthand for his article's opinion.

Bonus observation (i.e. unconnected topic that doesn't warrant its own post): I saw the Last Exit to Springfield episode of the Simpsons not too long ago. It's so good, so emblematic of what the Simpsons did right, that I want to cry for the series' current state. Homer and Burns misinterpreting each other, Lisa playing Classical Gas on guitar, "dental plan...lisa needs plan...lisa needs braces...", Burns and Smithers running the plant by themselves, a nod to the Grinch cartoon. So many great moments, and so wonderfully surreal.

Thursday, August 03, 2006

commentary on kingdom of nouns

Here's a link that uses the well-known noun-verb metaphor of Computer Science to talk about the Kingdom of Nouns: Java. I say that this metaphor is well known because I seem to recall actually learning about OO design methedologies (UML?) that advise a programmer to identify the nouns of a problem, then figure out the verbs by reasoning about how the nouns collaborate to perform the work.

The simple truth is that ideas about software design don't fall out of the sky; people invent them for a reason. OOP caught on because the ability to bundle data and methods into a single, easily reusable and extendable unit does wonders for promoting code modularity. You can modify your class all you want to, and I can modify mine all I want to, but as long as each of our classes only interact in public, well-defined ways, the code won't break. A class is the logical progression of the concept of an Abstract Data Type, and typing is not evil.

On the other hand, when you aren't "architecting", and just want to get stuff DONE for Bob's sake, all this OO apparatus is beside the point because you care about the verbs, not the nouns. (I'll leave aside the point that anyone could implement a simple one-object facade to make the common use cases of a complicated object hierarchy easier). Hence the group of scripting languages for the JVM. Take your pick: Jython, Groovy, BeanShell, Rhino, others...again, these languages would not have come about unless Java was better optimized for programming in the small and simple.

I like how this article also points to the opposite extreme: what he seems to describe is the (very real and scary) Unlambda language, in which all you do is construct and apply functions. Variables? Who needs 'em!

The practical upshot here is that a language that isn't multi-paradigmatic also isn't best for all situations. That is, a language should be great at working with both nouns and verbs. Or you could just use whatever language is most appropriate for a given situation. If the languages can interoperate on a common platform (see Parrot or JVM or .Net), then even better.

Tuesday, August 01, 2006

.Net: it is you and your abilities the Emperor wants

I haven't mentioned my ongoing .Net indoctrination in a while. I decided to exercise my sub-Padawan F# muscles by reimplementing one of our simplest but still useful portlets. The actual code wasn't anything special: get data, format and show data. The harder part was working out how to write in F# such that the portal would recognize it like a portlet written in the recommended C#. At first, I couldn't get it to work no matter how I futzed with the class declarations, until I realized that by default I was compiling to generic-friendly 2.0, and not the portal's supported 1.1 - d'oh!

An interesting case study of F# vs. C# was my use of Printf.sprintf to substitute parameters into my SQL statement (no, the parameters did not come in from the user, I have heard of SQL injection attacks). The compiler kept complaining every time I tried to separately store the pre-interpolated SQL as a string. It kept telling me, through the handy "mouse over a variable for a type tooltip" F# VS feature, that the first parameter to Printf.sprintf was of type 'a Printf.string_format, or something like that. Eventually the message got through my thick noggin: at compile time Printf.sprintf somehow transforms its first string argument into a function that takes a series of specifically-typed parameters! I had two ways of doing the interpolation: use Printf.sprintf by storing the SQL as a static method that just returns the SQL with a type annotation of 'a Printf.string_format, or use the .Net String.Format method by storing the SQL as an immutable plain string member variable, initialized in the constructor. Either way, I'm storing the SQL as an immutable at the class level.

Some other little tidbits from the experience:
  • The general form of the code was "class member function equals pattern match on argument evaluates to let-binding of intermediate step in let-binding of intermediate step in expression to save to a Page mutable property". In other words, for a class method, perform a data transformation through repeated function application and then use an expression with a side-effect to save the transformation result.
  • Normally a single F# source file becomes a module, but if you want to go C#-style and use the file to declare a namespace with internal class definitions, just put a 'namespace' line at the top and only declare types (such as classes) at the file's top level.
  • Watch out for nulls creeping into your code through variables from non-F# .Net APIs! The very handy ?? binary operator appears to return its left argument if it is not null and the right argument if it is. null can also be used in pattern matches.
  • F# does not appear to support the usual class access modifiers as other .Net languages. Well, it supports only one, I guess: public. F# (and OCaml, I believe) use a different way to hide implementation: signature files, which seem a bit like a C++ header file containing prototypes.
I think it's clear that for frameworks as heavily object-centric as ASP.Net, F# implementations may not be as compelling, since it isn't a context in which F#'s strengths can be best leveraged. To be fair, I'm still a novice at using F#'s object system, so it could also be that I didn't know what I was doing. I could see F# being an excellent language for a library that could be called from ASP.Net, however. F# is not a mere OO language in the crowd for .Net. Presumably the people at Microsoft wanted F# for its unique identity and abilities.

saw fargo for the first time

A long time ago I remember reading a glowing Siskel review of the movie Fargo. AMC had it on, so I saw it for the first time just a few days ago. (Side observation: using "fruity" as a replacement word is almost as hilarious as hearing Austin Powers say "I'm a sexy Brit!".)

Once again, I didn't get it.

That is, I didn't understand what was so fantastic about this movie, although it had no glaring weaknesses. Later, when I checked online, I read that the white, snow-covered landscape is supposed to be bleak and fatalistic. I played in the snow all the time when I was a kneebiter. I remember making snow forts and sculptures, throwing snowballs, sledding, even going skiiing and snowmobiling. I guess the appearance of snow means something different to people in California. Moving along, I've also read that Fargo is valued for its characters. I could see that, especially since its plot didn't feel that inspired and its emotional tide goes from "hmm" to "blah" to "shrug".

I think the crux of it is that I liked many scenes in Fargo, but the movie as a whole was disappointing. It had some of that same dark, quirky humor that I've greatly enjoyed in other Coen-involved movies, and each character displayed more intersting personality moments than all the characters put together in some other movies. In any case, feel free to take my opinion with a grain of salt since I had similar mixed feelings when I first saw Citizen Kane. If I need other people to tell me what's so great about a movie, is it the movie's fault or mine?

EDIT: I later realized that when I wrote that I was a kneebiter, I meant to write anklebiter.