jamesladdcode.com

For me the expressiveness of a language is your ability to write the things you need to write without cognitive friction between the languages constructs and what your writing. This is probably most common when integrating one system with another like an application and a database. How often have you had to context switch between strings of SQL code and <insert your language here> and each time loose a little recognition of where SQL starts and your code ends. The same friction exists when embedding HTML strings into <insert your language here>.

This cognitive friction doesn’t exist in LISP (or is so greatly reduced as to not be as painful). The language is more conducive to expressing yourself without cognitive friction. For example, the following integrates an SQL select in LISP (using the CLSQL library):

;; Employees of Widget's Inc.

(clsql:select 'employee

     :where [and [= [slot-value 'employee 'companyid]

 		   [slot-value 'company 'companyid]]

 		[= [slot-value 'company 'name]

 		   "Widgets Inc."]])

Where does the LISP end and the SQL begin ? Of course if you don’t have a basic understanding of LISP then this will all look like a mess. The point here is that LISP supports an expressiveness that is unparalleled in most every modern language.

So why are you not using LISP?

A lot of people I have worked with, admire and respect have turned to using Ruby. I don’t find this a big surprise, after all, we like to get our applications out and used and Ruby is great at helping to do that. There are even some funny spoofs on the Apple advertisments about Ruby vs other approaches.

Why are people moving to Ruby?

As Paul Graham says in ANSI Common Lisp, “Progamming languages teach you not to want what they cannot provide. You think in a language to write programs in it, and it’s hard to want something you can’t describe.” and Ruby provides a lot out of the box and the flexibility to think and do things in different ways.

I asked a Ruby convert why he isn’t using Smalltalk (which he knows very well) and he said because it lacked the invigorated community that is behind Ruby.

I asked a Ruby convert why he isn’t using Java anymore and he said because he had too many hoops to go through before he got started on the code that mattered.

I really like Ruby, although I have to own up to not having written a full application in it. I’m becoming more interested in it as the “smart” people I know are using it and that says a lot to me.

So I’m off to introductory training on Ruby to get to know more. However, this doesn’t mean I have given up on my favorite languages, Lisp and Smalltalk, since these are as expressive if not more so than Ruby; they have just lost their sparkle, for now.

Here is a screen cast of adding a new control structure to Smalltalk as an example of expressive flexibility in a language.

I find it interesting and almost spooky how a lot of things I think about and work on have parallels with things happening elsewhere. For example, I’ll think of a new software tool or product and within a few weeks or even a month someone else has released it.  I don’t take this as some special thing or ability I have but that there is a global consciousness.

Recently I was talking with a friend about faster software development and the people it requires, then along came this article, sent to me by another friend. I hope you will find interesting.

http://worsethanfailure.com/Articles/The-Great-Pyramid-of-Agile.aspx by Alex Papadimoulis

I don’t agree with all of the article but I agree strongly that it takes talented people to write good software and a methodology will not magically make people talented developers.

So if the people you have are not talented then you have a problem and what can you do about it?
If they are willing to learn and improve their craft then over time they may become better. However, what if they don’t want to learn or for some reason they just don’t get it?  For me the answer is to manage them out of core software development and into the supporting areas. This may seem harsh to some but if you can think of a better idea then I’m keen to hear it ?

At the client site we had a need to write many widgets that render HTML output. The way I approached the problem was not as efficient as I could have approached it and it led to me being stressed about what was able to be achieved in the allotted time frame.

I hope that this tip will save you that same stress.

I wrote a widget and then I wrote a builder to help build the fragments of HTML the widget would put together and output. The solution was neat in my eyes but the builder was a complete waste of time, since a simpler solution was ok for now. The builder will be used later but since I didn’t need it right now, as there was a simpler way, it was a waste of my time to even think it through, let alone implement part of it.

When assigned a task, do the simplest thing that could work, then write a story to refactor it. When the story is functionally complete you can then go back and do the refactoring before moving onto the next story or if time doesn’t permit you can come back to the story later.

So what is the simplest thing that could work?

In my case we had a widget that looked like this when using a html builder:

class ThingWidget {
void renderOn(Writer writer) {
HtmlBuilder html = new HtmlBuilder();
html.divClass(”Widget”)
.with(html.iframe(”someurl”))
.renderOn(writer);
}

This looks simple enough but the fact is, the smarts in the builder took some time, a lot more time than what would have worked for now. This is how the widget was made to be the simplest thing that could work:

class ThingWidget {
void renderOn(Writer writer) {
writer.write(”<div class=\”widget\”><iframe src=\”someurl\”/></div>”);
}

The test in both cases was the same, and this is an important fact:

class ThingWidgetTest {
void testCanRenderWidgetOnWriter() {
String expected = “<div class=”widget”><iframe src=”someurl”/></div>”;
Widget widget = new ThingWidget();
StringWriter writer = new StringWriter();
widget.renderOn(writer);
assertEquals(”Widget rendering invalid.”, expected, writer.toString());

The code in the Widget isn’t how I would want to leave it for some other developer to change, but it is at a point where it does what it is supposed to, it’s backed by a test and it can be checked in. Only now after this simple solution is tested and checked in is it the right time to consider the refactoring or to delay the refactoring by making a story for it.

I’m not a big fan of having lots of refactoring debt so I’d probably try and work on the refactoring rather than card it for later but this depends on the project.

Doing the simplest thing does not mean leaving the code as the simplest thing forever. The first code check-in should be the simplest thing, since others could use it now and if time doesn’t permit the refactoring you still have something that is complete.

I stopped using the HtmlBuilder for now since the complete range of features required of it would take more time than the simpler approach. Leaving it until later also has the added advantage that I will know more about the various scenarios required of the HtmlBuilder when I start to do it. This is a much better situation.

So take small simple steps and avoid the stress of a deadline. I’m putting a print out of the title on my monitor to remind me to do it, always.

Attached is the East Orientation presentation (including example code) that I gave at the Melbourne Patterns Group. If you try it out and need some help drop me a line and I’ll see what I can do.

There is only one rule to apply to make an improvement to your code so please give it a go and let me know the results.