Notes to self

What have I been up to, code wise, in my spare time? I felt like talking about this because I think it has gotten mildly interesting lately.

It hasn't been Fabric. I started Fabric, not because I thought it would be a fun thing to do, but because I absolutely needed a tool that did exactly what Fabric does. And ever since Fabric got to the point where it more or less completely scratches my deployment itches, my time-investment in it has pretty much retreated to maintenance mode.

No, my spare time is now primarily spent on the Clojure programming language, in some form or another.

When it comes to programming languages, I learn by doing and I think most people feel the same way; you can't learn how to write code if you don't write code. I learned Python by writing a blogging engine (how original) in it using Django, and then Fabric.

Now, I'm learning Clojure. I started out with the Euler problems but ran out of steam; the math problems just wasn't my thing. Then I was mostly idling around the clojure.core source code and the Java code, looking for a cool idea to try out but nothing really jumped out at me. I proposed a number of what I thought would be language improvements - with patches'n'all, but each and every one of them was turned down. Oh well.

Then, drifting aimlessly around Github, I stubbed my toe on a tiny little thing that Chris Houser had done. I was a text editor, but hardly even complete enough to be called a prototype.

I downloaded it and fired it up. I was mildly surprised the thing actually started and showed a little window with two parts: and editor panel and a build-in Clojure REPL that actually worked.

The interface wasn't terribly exciting, though. The window was tiny and placed in the top-left corner, and the program could not be started without naming a file to open.

I dug into the code - what little there was of it - and fixed those things. Made the window chrome-less and full-screen, and pivoted the editor/repl-split to a left-right configuration to better utilize my wider-than-tall screen resolution. It actually worked ad wasn't terribly difficult.

Then I found out that the thing actually had no functionality in the way of opening and saving files. Also, the key-binding looked messy. I turned to these issues next.

One thing leads to the next, and textjure is now slowly shaping up to be a genuinely useful text editor, though it is still woefully underfeatured.

The code is in my fork of Chris Housers repository: http://github.com/karmazilla/textjure/tree/master

The feature that I'm currently working on is syntax coloring. Following this, is stuff like indenting, incremental search and REPL-history. Then I guess I'll properly announce my work on the Clojure Google Group.

I always knew that I would eventually find something fun to hack on with Clojure, but I would never have imagined it would be a text editor.

My collegues say I don't post anymore. Well, here's a post with a couple of memorable programmer quotes just to prove them wrong.

Let the hard problems BE hard
so that the simple problems will BE simple.
-- Kevin Barnes.

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
-- Tony Hoare.

You're full of shit!
-- Donald Ervin Knuth, in reply to Steve Jobs' claim that he had read all of his books.

Apparently so. Turns out a guy named Aaron VanDerlip did a "lightning talk" at the 2008 Plone Conference. I didn't even know Plone had a conference.

And there's proof that Aaron really did a talk; day 3, near the bottom, at Standby 1.

The keynote of the day was with Richard Gabriel and Guy Steele and the talk, or rather show, was called "50 in 50." These two anecdotal gentlemen were reading 50 "poems" of 50 words each in 50 minutes, all about programming languages and their history. It was an entertaining potpourri of programming language history presented in a novel way. Green card.

Yesterday I decided not to go to the agile architecture talk, but that talk was apparently so popular that James Coplien held a rerun. So I went to that instead of the Master or Jack-of-all-traits talk by Roman Pichler. This turned out to be a good choice. His main point was that object-oriented programming had been done all wrong and nobody had got it right, until "two months ago." His idea of object-orientation is explicitly distinct from the class-oriented programming that Java is doing. He introduces the notion of Roles. A role is a concept that the user has for what an object is suppose to do. When a user interacts with the system as a whole, the objects takes different roles and behaves in accord. So roles is behavior - it is not interfaces because interfaces themselves cannot have behavior, and it is not like classes because classes are the forms that produce concrete things, like objects, and concepts are not concrete things. So he highlights that there's something missing in object-oriented languages like Java. Something that is able to embody the notion of roles and the algorithms they participate in. This is what traits are in Scala, and John also has an implementation for this concept in C++ and Smalltalk. Traits are like interfaces that can have methods, but they cannot have state. They can access the member methods of the objects that mixes in the trait, and this allows them to be the implementation and embodiment of concepts such as MoneyTransfer. Examples of objects that would mix in such a trait, include InvestmentAccount and LoansAccount. Among the audience for this talk was the author of Qi4J, which is an framework-like implementation of this trait concept in Java. I gave this talk a very green card.

Then I rushed to Reviewing, Refactoring and Regaining Control of Code with Kevlin Henney. In his talk, Henney presented 13 generally applicable good advice, primarily for Java programmers. All the classics were there; what good naming was (turns out hungarian notation wasn't it - who'd'a thunk?), law of demeter and a bunch of other things (11, to be precise) I can't remember right now. He also presented the visitor pattern and polymorphism as a good thing, even though John Coplien had just highlighted that as a thing to get rid of in the previous talk. I had to agree with Coplien on that point. Polymorphism introduces non-determinism. Only sad that Java, as previously shown, isn't really suitable to completely avoid polymorphism, but such is life I guess. Also, I've heard that HotSpot (the JIT) really likes monomorphic call sites as they are much easier to inline, so avoid polymorphism can also be a performance boon - and on that note, I think that you can still have multiple implementations of a virtual method and it will still be monomorphic as long as only one implementation is in active use, and the others aren't loaded. But that's a tangent. I think I gave Henney a green card.

Then I went to the real-world refactoring talk with Neal Ford. That wasn't such a great success. The points he quoted from other people were good and relevant on their own, but his examples were really bad. He worked through the points by presenting some "bad" code and then showed how he could apply some refactoring to turn it into "good" code. This was in and off itself a novel approach, except that the end result of his refactorings were only marginally better - no, actually I'd say that he ended up with worse code in these examples than he started out with, and in one case even introduced a possible concurrency bug by simultaneously introducing and hiding some state in the object he was refactoring - a possible concurrency bug. His resulting code also had a lot of temporal coupling between the "refactored" methods. The points he made were good, but he executed very badly on the examples he showed. I was very close to giving him a red card, but ended up giving him just a yellow card. The points were still good and the presentation wasn't dull, so there.

Then I decided on another change of plan and went to see Erik Meijer talk about JavaScript as an assembly language instead of hearing Martin Fowler talk about patterns of internal DSLs (which, on a second thought, did sound pretty dull anyway). The JavaScript talk was about a compiler called Volta that Meijer was working on, that took MSIL as input and then split the application in two, so that one part was running on a server and the interface part was running either in Silverlight in a such enabled browser, or in any browser through JavaScript. Meijer is always entertaining it seems, but the technology didn't really strike any chords with me. I suppose you could describe it as GWT, but for .NET and better. GWT doesn't interest me either. Even so, I think I ended up giving him a green card. I guess I just like the guy.

The final talk of the day was Erik Doernenburg on Test Driven Development, Take 2. This talk wasn't terribly exciting, but it wasn't too dull either. The most interesting bit, to me, was that he was showing how he was using the Mockito mocking library. I've only tried using jMock and Mockito looked to be much less cumbersome or verbose to use. Apart from that, he was just re-iterating standard testing practices and JUnit. In other words, it was pretty old news, at least to me. Still, it's an important topic and he managed to get many good points across, even though he was running out of time at the end. Green card.

And that pretty much concludes my experience with this years JAOO.

Day started with opening keynote with Anders Hjerlserg. It was allright. His talking about his background and how little programming languages have progressed in last 50 years is always intertaining, although I've heard i before. The news in his talk was the C# 3.0 release and the added semi-functional features, and he also ahd a section on F#, and what this all meant in a concurrent world. We were asked to give all the talks we attended a red, yellow or green card based on how good we thought it was, and I gave Anders a green card.

The next talk was with Patrick Linskey, on Designing for Scalability. It was interresting, though he said some half-truths with regards to how CAS operations worked. Nonetheless, he had many good points regarding vertical and horisontal scalability in general, and how deviding an application into tiers could improve its scalability. Most of it was th kind of stuff that people already know - nothing ground breaking - but still good to be reminded that these techneques are still relevant and useful. I think I gave him a green or yellow card.

Then I went to a talk about XML persistence with John Davis. It was mostly about the problems that investment banks face with a certian insidiously complex FpML standard, which is an XML schema that apparently changes every two months. The problem these banks had, was that the schema was too complex to feasibly turn into a relational representation for storage in a database, and so the XML had to be persisted in some other way, which turned out to be data-grids or compute-grids. That was his (the speakers) idea anyway. The real takeaway was that you shouldn't just put a database into your architecture ust because that's how you've always done things - a database should only be used if it really adds value in its own and there are no other more suitable alternatives. It was an intertaining talk. Green card.

Following lunch (which was pretty good considering the scale and the amount of food that had to be produced) I went to a talk about aesthetic programming in ruby. At first, the guy was just rambling nonsence trying to find a proper definintion for the word aesthetic and how it could possibly have anything to do with code. But then towards the second half of the talk, he turned the talk around and made a case about clarity and readability. To such a degree, in fact, that he told a story about when he once had a non-coder sit with him and he was guiding this person, which was a stake holder on some project, through the (readable) code he had written (in an internal Ruby DSL), and this stake holder was able to fully understand how the code understood the business domain. This mutual understanding inspired confidence in the correctness of the code and turned out to be an important factor in the success of that particular project. So the talk ended up being about how language, both code and english, are used to convey ideas and concepts, and how these can be best expressed. He (the presenter) attributed Rubys forces in expresiveness, succunctness and readability, and highlited them as important factors for creating DSLs that are able to accurately describe concepts of the domains he used as cases in his talk. The idea was that these forces/advantages of using Ruby, could be generalized to most projects and especially those that used DSLs to some degree. The takeaway was that creating a DSL can be very important to a given project, because of their ability to accurately and concicely work with the concepts of the projects problem domain. And following this, Ruby was a very good language because of its powerful ability to create internal DSLs. I gave this talk a green card.

The next two talks was about the Fortress programming lnguage with Guy Steele, and an introcuction to the Scala programming language with Bill Venners. Guy's talk was interresting, but the language seemed very academic. It had some very powerful concepts with regards to concurrency, but it really looked like it was aimed at scientists rather than ordinary programmers with ordinary problems, like myself. The Scala talk.... oh, I almost fell asleep. Bill kept fiddling with his microphone and had many uhh's and umm's. Scala may be an interesting language but Bill really didn't look like he was properly prepared for the talk and that reflected in how he presented Scala. I gave Guy a green card for the nonetheless intertaining talk, and Bill got a red card.

The final talk of the day - the "party note" or whatever they called it - was with Erik Meijer. Meijer talked about why functional programming (still) matters, and he did so in a very intertaining and (to some, like me) convincing way. Perhaps he only seemed convincing because I was already convinced about the points he made. This was really the most interresting talk of the day. He started by laying out a battle plan: he would convince management that functional languages mattered by showing them a trend curve showing 100% year-over-year increase in the userbase of, as he called it, "fundamentalist functinal languages". The curve started this year with two people: himself and Simon Payton-Jones, and then next year he would have convinced two other people, and then 8 the year after that. So with management convinced, all he had to do was to make that trend curve come true by convincing us programmers, and he would do so by a brain-washing technique: he would first break us down with fear, and then slowly build us up again. He showed how these newfangled self-proclaimed functional languages really wasn't all that functional, and how they broke down in the face of complex interactions with side-effects. He also showed how the type systems of C# and Java was lying to us programmers. For instance, System.currentTimeMillis() claims it returns a long, but that is untrue because it is a different long every time we call it - so it really ought to be a sequence or iteration of longs. He also showed how side-effects had a particualry dark side when combined with closures, and the lazy-evalutation nature of Linq in C#, and even how Erlang wasn't really thread-safe. With the programming crowd thoroughly broken down, he then proceded to show how a real functional language, namely Haskell, handled side-effects and concurrency. Learning Haskell, or some other proper functioanl langauge was his takeaway and secret evil agenda. I gave him the greenest card in the stack.

After all the talks, there were a break before the Conference Party started at 19:00, with some nice foods, beer and Jazz. I got to sit next to some people from Version2, and danish online IT publication, and a guy from a software house called Demit, they were building custom software for companies and government institutions in .NET - apparently a troublesome thing to do in many ways, though that wasn't really a surprice.