His code not ‘functional’ or ‘elegant’

In the middle of another gold card, this one on Actors (PDF), a concurrent programming abstraction that Scala borrowed from Erlang. The Scala short tutorial on actors isn’t much help, at least not to someone who’s spent as little time with Scala as I have; mostly Mr. Haller just seems to show you the source code from the examples directory and say “see”? But I persevere.

In the course of said perseverance, I did run across one interesting link, which I post by way of bookmarking: Functional Java, “an open source library that aims to prepare the Java programming language for the inclusion of closures [and] serves as a platform for learning functional programming concepts by introducing these concepts using a familiar language.” Which sounds like exactly what Code Monkey needs.

Imperative knowledge

As part of my ongoing project to get a do-over on my misspent youth, I’ve started reading the lecture notes for MIT’s EECS 6.001: Structure and Interpretation of Computer Programs.

And I have to say: damn.

I mean, I actually feel like I’m learning something from about Slide Four. Contrast this with the freshman introductory C course I dropped in week one (I wanted to program Macs, not VT100s! — I was an awful hacker), and I can really see why smart people complain that CS is turning into Java vocational training. It’s not at MIT, but it was already on its way (to vocational training, I mean; Java wasn’t yet a twinkle in James Gosling’s eye) when I was at UCSC.

Which is probably one reason I ended up a Japanese major. And that it took me six years after high school to get back to programming. If they’d made CS sound half as interesting as linguistics…

Anyway, I’m hoping to go through the whole course, and write it up as I go. My track record on projects like this is not stellar, but we’ll see. I wish there was someone I could pay to grade me on it.

Meanwhile, speaking of writeups and track records, I still haven’t written up the monad project, but I did throw together a Scala “brush” for Alex Gorbachev’s syntax highlighter (basically just the Java brush with a different set of keywords and an extra regex for the non-alphabetic keywords like => and <: that confuse the regex engine, but it works) so when I do finish writing it up there will be pretty-printed examples:

package pizza;

object ListExample {
  def main(args: Array[String]) {

    val list = List(1, 2, 3)
    println(list)
    println(list map { x => x * 2});
  }
}

(Also I managed, for purely decorative purposes, to work this diagram into the novelette I finished drafting this weekend. I think for the final version I might prefer this one — it’s fancier, and less completely unrelated to what’s going on in the text than the other one. But I’m not sure I can be arsed recreating it in Illustrator. It seems like I ought to be able to just generate a PDF from the TeX source and use that, but when I try — I have only the barest exposure to TeX — I only get error messages.)

Substantial forms of being

So I gave my pizza lunch talk on monads today, having over the past couple of weeks snuck in considerably more than a single Gold Card day’s worth of work. I think it went fairly well and was mostly comprehensible, though on the comprehensibility front it probably helped that a lot of my statements were wrapped in “I’m not sure what…”, “I’m not sure whether…” and “I’m not sure why…” —

— which, if you think about it, is really just a kind of Option (a.k.a. Maybe), so it’s totally appropriate.

At least, that’s (provisionally) my story and I’m (for now) sticking to it.

I got as far (I think) as figuring out what a monad is (mostly), and (I think) how the Scala List and Option monads work (mostly), largely by porting (partially) List and Option to Java. I mean to turn the talk into a post here, but that’ll take a couple of days — maybe longer if I get ambitious about cleaning up the code examples.

What I didn’t get to in any detail was Dan’s question about state, which was sort of the main point of this investigation, along with I/O and error handling. Always leave yourself some work for tomorrow, I’ve been told….

Unit, bind, flatten

I’m 3/4 of the way through my Gold Card day, and I think I can finally tell a monad from a modron, and even from a maenad. Whether this will translate into a presentation anyone else can understand is still an open question.

Meanwhile, I’ve discovered:

  • A whole folder of monad examples in the Scala distribution.
  • That trying to do higher-order functional programming in straight Java does, in fact, really blow. An example that takes 74 lines in Scala takes… well, I don’t really know how many lines it takes in straight Java, because nine classes and 195 lines in, I’m only up to line 37 in the original (single) Scala file. We could extrapolate and guess 390 lines, but I wouldn’t bet on it. Maybe those BGGA closures aren’t such a bad idea after all…
  • James Iry’s “Monads are Elephants,” an introduction to Scala monads that’s got more words and less math than Burak Emir‘s. (Nothing against math — or Dr. Emir — but we language majors like our human-readable variable and function names.)
  • Scala for Java Refugees,” a nice tutorial from Daniel Spiewak.

And, last but not least:

  • That “Introductions to monads are bit of cottage industry on the Internet.” (James Iry again.)

So much for my plan to get rich writing Monads for Dummies.

Code monkey get up get coffee

I think I’ve mostly recovered from houseguests, bronchitis, a Hugo award nomination, and several days spent driving a zippy little turbo diesel Alfa Romeo at high speeds over narrow French country roads. (And yes, I did spend all my recovery time listening to Jonathan Coulton MP3s, why do you ask?)

Meanwhile, Neal Gafter’s posted some further notes on his Neapolitan ice cream puzzler, including a couple of solutions that should be interesting to anyone trying to decide what does and doesn’t constitute “enum abuse.” And Eric Lippert’s corrected my conclusions on C# readonly vs. Java final; the C# approach is rather interesting, I think.

Eric’s also commented on Dan’s question about state management in functional languages. I’ve got a gold card coming up; maybe I should do something with this Scala monad tutorial

Humility

Paul Buchheit, Google employee #23:

I wrote the first version of Gmail in one day. It was not very impressive. All I did was stuff my own email into the Google Groups (Usenet) indexing engine. I sent it out to a few people for feedback, and they said that it was somewhat useful, but it would be better if it searched over their email instead of mine.

And another nice bit, from an earlier post about undo:

…one comment that was so remarkably wrong that it brightened my whole day:

While an Undo feature could be useful, isn’t this just coddling people who should otherwise be paying closer attention to what they are doing? A mistake is a mistake, and people need to learn to live with the consequences of the mistakes they make.

This comment may have been a joke, but I really like this “tough love” approach to usability, because in just a few words it perfectly captures the exact opposite of what we should be doing.

To design great products, we must truly empathize with our users, and understand that if they are having problems using our products, is more likely our fault, not theirs.

…[T]he more we can lower the costs of making mistakes, the faster we can move.

Java vs. C#: More fun with initializers

Or, proof by example that C# isn’t just Java with different capitalization conventions.

On the heels of Neal Gafter’s ice cream puzzler we have the less closure-rific but still interesting “Why do initializers run in the opposite order as constructors?” from Eric Lippert. Here’s my Java version of Eric’s C# code:

class Foo {
	public Foo(String s) {
		System.out.printf("Foo constructor: %1$sn", s);
	}
}

class Base {
	private final Foo baseFoo = new Foo("Base initializer");

	public Base() {
		System.out.println("Base constructor");
	}
}

class Derived extends Base {
	private final Foo derivedFoo = new Foo("Derived initializer");

	public Derived() {
		System.out.println("Derived constructor");
	}
}

class Program {
	public static void main(String[] args) {
		new Derived();
	}
}

I’ll spare you the suspense and just print the answer — the Java answer, that is.

Foo constructor: Base initializer
Base constructor
Foo constructor: Derived initializer
Derived constructor

Whereas the C# code equivalent of the above, Eric’s original, prints:

Foo constructor: Derived initializer
Foo constructor: Base initializer
Base constructor
Derived constructor

What’s going on?

The Java code does this because when a Java object’s initialized the JVM works its way down through its superclasses, starting at the root (that is, Object), and for each class first runs the initializers, then the constructor. This can have some wacky side-effects. For instance, sooner or later everyone gets the bright idea to define an abstract method in the base class and call that method from the base class constructor — which works fine until some subclass’s concrete implementation depends on a field that’s only initialized in that subclass, and suddenly you’re getting NullPointerExceptions in impossible-looking places.

This happens whether the field’s initialized in the subclass constructor or in a subclass initializer, and while it’s fairly obvious what’s going on in the constructor case, it’s a little more confusing the first time you have, say,

private final long timestamp = new Date().getTime()

come out 0 (or null, if you use a capital-L Long) when you know your clock’s not set to January 1st 1970 — and then later on come out 1203338390828 or whatever, even though final fields are supposed to be immutable.

The constructor case, I think we’re stuck with. The initializer case, though, the folks at Microsoft apparently decided they were sick of. So C# instead runs all the initializers in reverse order (subclass to superclass), and then runs all the constructors (in the order you’d expect). This means final fields in C# really are final, or rather, readonly fields really are read-only — they’ll only ever have one value, no matter when you look at them. [Looks like I didn’t have that quite right — see Eric’s comment below.]

Now I wonder what happens in ActionScript? The Adobe folks claim my const bug in FlexBuilder is fixed; I’ll have to download the latest build and see.

Comments closed due to spam.