From time to time, I’d write a post that will fall a touch on the controversial side. What’s great about those articles is how they end up being a rewarding experience for me. After wading through the messages of the over-offended and the hyper-defensive, I always leave having learned a thing or two, often more.

The technical knowledge acquired from these situations, I surely classify as my undisputed number one. But there’s more than one ways to enhance understanding…

I particularly enjoyed the reaction to Rails: Not a DSL, specifically by the ruby-ists out there. Seems like the piece hit a nerve, because it’s the first time I saw Rails peeps behaving like Java guys when they first heard Ruby will kill Java. Not everyone, of course, but certainly some of the ones who got over excited about DSLs after attending the recent RailsConf…

The other insight I was provided with by the reaction to the aforementioned post was what a large slice of the DSL-tastic pie regards DSLs as. The popular notion seems to be that DSLs are programming language agnostic: You don’t write a Domain Specific Language. You write on any programming language in a Domain Specific Language. Apparently, what you do is express your code in syntax that is expressive to the business or application domain. DSLs, thus, are all around us. Rails is a DSL. JMock is a DSL. The parts that we got right from the last few projects I worked on are DSLs.

Under those assumptions, allow me to add another name for DSL. It’s called Writing Good Code.

How such a basic principle suddenly became the focal interest point of the restless programming world I do not know, but I’ll let you draw your own conclusions. To be honest, I can only be happy about it, because happy is what I’m going to be next time I read somebody’s code and it reads well and it makes sense in the context of the world it is written to express and it makes me want to work on it instead of complaining (my hobby). And if that’s because of DSL-Mania, go for it, people.

But I can’t deny that a DSL to me is something completely different.

This might be old news to many out there, but I just got my New Black MacBook, subsequently throwing myself on the joy of Setting Up Your New Awesomely Cool Machine. After going through the basics (stripped-down OSX, Developer Tools, and a few of my favorite apps), I decided I’d maybe have to stoop down to actually consider running Windows on my New Black Macbook.

Now why the hell would I want to do that? Easy. I’m running a small web app development business, meaning I need to do a lot more things than a straightforward hardcore programmer would.
I need to assist never-getting-it-straight clients with their applications , troubleshoot, configure and generally deal with all the things a sane developer wouldn’t want to touch with a 12-foot stick. And I can’t start sentences with “Press the Apple icon top left”, because 0% of my web application clients up to date are Mac users.

I also need to test my web apps on as many system configurations I can, and this means I at the very least need a WindowsXP Machine filled to the brim with browsers and email clients and whatnots.

Up till now I had this Win Machine that everyone seems to have at his place, but doesnt really remember when he bought it exactly, or indeed, if he bought it. You know the one: It used to be gray, but now it is aged-iced-coffee-scars all over that yellow-gray depressive-looking color you can only get by getting you and your friends to smoke a lot in a confined space with a lot of hadware stashed around you.

I hated sitting in front of that thing.

I had tried the pre-MS Virtual PC on my trusted G4 Dual 867Mhz. Didn’t work for me. I couldn’t get a definite user experience by sludging through app pages like I was running a 486 box. Hence the aforementioned Machine From The Gray-yellow Lagoon.

So back to the MacBook. Now that I had the ability to run windows natively, I naturally tried it out. After the initial shock of finding myself looking at that ghastly black Windows loader screen on my New Black Macbook’s screen, and a failed attempt at installing the Apple drivers CD bootcamp burns, all was as expected. Good. Good. Of course, now that I was here, I’d probably have to install a copy of Photoshop (being a designer) and maybe a couple of editors, probably a FTP client… You catch the drift. Can’t log in and out of Windows just to change that .PNG file to .GIF because once more you forgot that IE STILL doesnt correctly render opaqued and transparent PNG’s.

Cue Parallels. Big downside, not free. But, pretty cheap. So I gave it a go. I still had VirPC freezing flashbacks back then, but tried it anyways. Not bad. Not bad at all. Pretty fast actually… by now I had also discovered that Firefox plugin that Embeds IE tab right into FF, which actually expains far better than I can why Parallels is a better development tool that Boot Camp. You can’t beat the flexibility of having two engines both running at the same time, and doing so smoothly enough to leave you work between them undistracted.

Yes, the 8 MB VideoRAM parallels forces on the virtual Win system messes with the interface a bit while performing memory demanding operations, but hey, now you got windows running side by side with OS X, you dont really need anything in there other than your IE Tabbed FF!

8MB VideoRAM will suffice. Unless what you REALLY wanted was finally getting to play FEAR.

Digg BootCamp bashing

Everywhere I turn these days, the most common three letters that I hear are DSL. Let me spell them out: D. S. L. as in Domain Specific Language, but you knew that already.

One great reason why you should go DSL is because you can write one and call it LSD.reverse. Yep, moment of genius.

OK, enough with the dry humor…

The reason I’m sitting here writing this, instead of staring at the Midlands’ cows outside the train’s window (they look delicious), stems from finding it a tad awkward every time I see Rails (as in Ruby on Rails) mentioned in many of those DSL themed conversations. I seriously do not think Rails is a DSL. Last I heard Rails was a web framework.

But what is it that makes a DSL a DSL?

Judging by the name, it must be something along the lines of a programming language that is specific to a domain. So, A, it probably has to be some sort of programming language, or something that resembles one, and, B, it should express a specific, confined and well defined area’s behavior and rules.

One might argue that Rails is specific to the Web Application Domain because it expresses a web application’s behavior in web application native terms. For starters, Rails is not a programming language. If we’re tired of using the term Framework and we’re looking for a new one, then alright, although there must be more than that here… Maybe Domain Specific Framework is closer to what the peeps who view Rails as a DSL might have in mind?

Nah, FSD.reverse doesn’t sound cool at all, and DSF is like DFS which is something that’s always on sale on UK TV, so better not…

Secondly, the web, or the web application, is too broad and generic an area to qualify as a Domain. If we award the DSL For The Web attribute to Rails, we might as well call C a System’s DSL and Assembler a Computer DSL.

A DSL cannot be too generic. The more we generify it, the less of a DSL it becomes. Along with the language being specific to the domain, I believe the domain itself needs to be specific.

I can see how, say, a shopping cart web application could be defined as existing under a domain. So, the shopping-cart-domain is a sub-domain of the web-domain, I hear you say. So, Rails as a DSL can have many sub-DSLs. This in turn, however, makes Rails a sub-DSL of Ruby, which is a sub-DSL of C, and next thing you know, we’re writing a DSL for the Universe.

I find it rather hard to draw the line between a DSL and a library with meaningfully named methods, functions, macros, call them what you will. I also get the feeling this whole idea started from the desire to write something as cool as Rails and, inevitably, buzzword compliance is one of the first things to follow a tech revolution and its followers.

I am tempted to argue that DSL is the Emperor’s new clothes - API or Library being the Emperor, but I’m still quite intrigued by the concept, so I’m not prepared to dismiss it without pursuing it a bit more. In addition, regardless of how much I might like the syntactic sugar that can be achieved with Ruby, it’s just aesthetics and that is not substantial enough to drive something destined to become fairly useful. I can see how the Rails’ principles and practices can be applied to specialized, domain confined software development tools, but I’d rather see the tools supersede the terminology.

At least I got the name right, you gotta give me that…

Digg

Speaking of insects, the common mosquito’s life-cycle is 24 hours. This means that they’re born, fly around for one day and - if they’re lucky - bite you and make you itchy for a while during your holiday in Greece. Just like silly programming language trends do to C programmers (Has anybody ever wondered why C programmers don’t blog?).

I always wanted to say something along those lines…

We have been toying with this idea for a while now. We wanted to make some icons that look different from the standard OS X feel, so we can tell our stuff more easily apart. We made them, started using them, liked them - and then we thought other people might like them, too.

So we bundled them by color (three choices for now, but the set will probably feature more colors after its first update), and they’re available here. Each set consists of 10 folder icons: web, art, script, photo, downloads, documents, music, applications, an empty folder and, well, a nutrun folder.

We also made PC versions of the icons available from the same page.

We hope you enjoy them. Next in line will be a generic application iconset featuring arrows, home buttons, edit buttons etc.

Thanks for sending nuticons related feedback to nuticons [at] nutrun.com

Digg nuticons

The first rule of poker is finding reasons to fold your hand.

That’s what my colleague Marco Tolesano told me yesterday. And what a great metaphor for software development that is. We spend too much time thinking about why we should be doing something. Why not concentrate on why we shouldn’t be doing it?

Here’s a typical scenario: Blog savvy developer finds out about the latest cool magic offered by cool framework X. Promptly downloads the jars, fires up his fave IDE, creates a new project, chucks a bunch of jars in the lib directory and writes a few XML files. Kick-starts the app - NoClassDefFoundError.

Hmmm… I’ve seen this before.

Pastes the stacktrace in Google, the people on the forums say that dependencies A and B are unsatisfied. Easy. Downloads a few more jars and adds them to the classpath. Repeats this process a few times. Still doesn’t work, because the developer doesn’t yet fully understand how the framework works and how to set it up. In true developer fashion, the verdict is quite unfavorable towards the framework. What we don’t understand is lame.

Because our developer is persistent, though, and because he’s been reading more and more posts on JavaBlogs about the framework being the one to end all of the world’s problems, he gives it another shot. A few more jars later and a little bit more of reading the documentation and fiddling around with the configuration…

Hey, it works! Boy this is cool. Look, mom, I don’t have to write any code.

As developers, the more we understand something, the highest it scores on our list of what is good and what isn’t. You’ve seen it happen. Knowing how something works somehow makes it part of us. We’re prepared to go to war to defend something we understand if somebody has something negative to say about it.

Back to our story, it is needless to say that by now the lib directory weighs 44.9 Mb. 99.5% of the dependencies introduced are unused, but who cares when code looks so clean, when it’s the framework that takes care of everything behind the scenes.

A few weeks later, the 44.9 Mb have been added to the existing 151 Mb of the .ear bundle of the project the developer is working on for his employer, along with all the issues and bugs that come with 44.9 Mb of framework code. Everyone thinks this addition to their armory saves them time and makes the code cleaner, even though they have to write more XML than the actual code it would have taken them to achieve the same goal. Even though they have to spend 2 days running around when something goes wrong, trying to figure out what it is.

Here’s what I think: I think that we have taken the whole ‘code reuse’ concept a bit too far. Or, perhaps, we got it slightly wrong. We put too much focus on knowing what’s out there, so we can incorporate it in our work to make software better, and most importantly deliver it faster. The ‘velocity through knowledge of the tools for the job’ issue can be very tricky if it isn’t approached with caution.

For those of us out there who have had to deal with legacy code, do you remember how it feels when you figure out that the problem you’re trying to solve is due to a five year old library that’s not supported any more? Five years from now, there are still going to be developers who will have to code on Struts releases that came out in 2004. Surely that can’t be right.

Replacing code with declarative framework configurations doesn’t make the codebase cleaner. It makes it difficult to maintain. And it doesn’t save time, because when something goes wrong it takes hours of effort and frustration to fix. And most of the time, if we spend half an hour to figure out what it is the framework does to attack the problem at the hand, we’ll realize that we can do the same thing in 5 lines of code, most importantly avoiding all the dependency garbage the framework will force in our classpath, because Java frameworks are trying to be too generic, but usually end up just being overweight.

I suppose the need for third party libraries is largely due to the fact that Java’s core libraries justify the existence of something like the Commons packages, but let’s not get into Java’s shortcomings here… On the surface, there’s nothing wrong with that. Code reuse, dude. Until those libraries are out of date and not very well supported.

Everyone loves saying “don’t reinvent the wheel”. But most of the time it’s not about that. It’s about making a better, lighter, rounder wheel that’s exactly fit for the kind of terrain your car will roam and will be easier to change when you get a flat tire.

For my part, I’ll try harder to find reasons as to why I should fold the latest hand I’ve picked.

Seven or Eleven, snake eyes watching you, Double up or quit, double stake or split, The Ace Of Spades , Lemmy Kilmister once said.

Digg gambling

I cannot stress enough how much I appreciate WriteRoom by Hog Bay Software. I don’t even know why it’s great - the last thing I need is an application to type stuff into…

I am, however, typing this into WriteRoom as we speak and then I’m planning to copy it to MarsEdit and post it. And I am enchanted. Despite the extra step - and I am one for eliminating extra steps most of the time.

I have also been thinking along the lines of what Hog Bay describes as User-powered software for the last few months. Great ideas don’t usually cover 90% of the features or effort that will eventually turn your idea into software. So instead of wasting precious time trying to pin down what users will want to see in the first release of your system, concentrate on the the core idea itself, launch it sooner, keep it stripped down and focused and let the people who use it come up with what they want to see there. It’s certainly not an entirely new concept, but ‘real’ companies don’t have the luxury to actively involve their users in the development process before they actually make money out of them. And that probably results in bloated software that tries to keep as many as possible items-with-wallets happy….

Software should be simple and charming…. It should inspire you to do things with it, even though it might not be something you need to be doing. And maybe, just maybe, it should make you (as a user) want to make it better. And Hog Bay got right.

Digg the Bay