Why can't we just have data types?

I'm not the biggest fan of object oriented programming. There, I said it.

Also, the world is round, and circles the sun. Regardless of obsoleted dogma.

I just wanted to cook up a hash, containing hashes as values (with a couple levels of nesting). So, what do I end up with, since I'm currently stuck with those, "I know, we'll make everything an object!" languages?

This:

((ArrayList)((HashMap)dicts.get(pattern.get("Dictionary"))).get("Elements")).add(pattern);

That really should have been simple, and it's a great argument for DATA TYPES. Not Objects, not Aspects, just data. Really.

Perl's been accused of being cryptic, but here's the equivalent:

push(@{ $dicts{Dictionary}->{Elements} }, $pattern);

Of course, you don't actually have to do it that way, since perl is actually quite flexible. It has a very limited range of actual data types, but then has many operators that can manipulate the data (in wondrous and fantastic ways!).
Read more...

Computer Science/Engineering, an analogy

Computer science is to programming as pigmentation science is to painting.

I have asked the same question of people that I have worked with for the last 10-15 years (a long time). Here it is:

Is programming an art or a science?

Before I give you the answer, think about this: when you look at a beautiful building, there is a lot of science involved. But the thing that made it beautiful was not the science, it was the artistry that built on that science.

In case it's not immediately obvious, the near unanimous answer was: it is an art. Anecdotally, the better the person was at getting things done the more likely they were to answer "art", and quickly.

The sooner we get over the idea of programming as an "engineering discipline" or "science", the better.

Next time you hear someone going on about how we need "formal proofs" or "stronger engineering" for applications, ask them: "What have you actually built lately?"

(Image from user LukeGordon1 on Flickr, and is Creative Commons licensed)
Read more...

Covington Friday Night Car Shows Getting Ready to Start

It's almost time for the Friday night Covington Car shows to start!

The first Friday in May (May 1, 2009) through the last Friday in September, weather permitting, from 4PM - 8PM.

I have additional information (directions), and pictures, here.

The pictures should be convincing enough, but there are a lot of really nice cars there, the folks are friendly, and it's very family friendly. Take your kids. Read more...

The Hundredth Idiot (or, why not to read business books)

One hundred idiots make idiotic plans and carry them out. All but one justly fail. The hundredth idiot, whose plan succeeded through pure luck, is immediately convinced he's a genius.

--Iain M Banks, MATTER

Iain Banks makes one of the most astute observations I've ever read.

This is so applicable to:

1. The business model de jour: How To Use Social Networks To Facilitate Enterprise Application Development!
2. The development model de jour: Standing On Your Head To Increase Bloodflow and Facilitate New Development Methodologies!

Now, before you hie off on the "next big thing", remember that most of these "big things" are just hundredth idiots. Or, you can read a book like The Mythical Man Month by Fred Brooks and ask yourself: how is it that a book written 35 years ago, about a project completed 45 years ago is still 95% relevant?

Could it be that there's nothing new under the sun? Read more...

Frame-work (an oxymoron)

One of the most difficult things to learn about project management/development is the difference between adaptability and "does the work for you". People who have not worked with the latter might have a tendency to desire the latter (after all, who does not want less work?), but my experience has been that these types of systems always end up extracting their "pound of flesh". There Ain't No Such Thing As A Free Lunch.

The first time I used Struts, I was enamored of it for about a day. Then I realized what a pain it was to work with. It has been a while since I've used it, but my memory is primarily one of, "What magic incantation do I need to stuff in some random configuration file to actually make this page transition work?"

Another example, Ruby on Rails: I always thought this name apropos. You need to jump off and do some 4-wheeling? No dice, dude! You're on Rails!

How about this description of Cocoon:

Apache Cocoon is a web development framework built around the concepts of separation of concerns and component-based web development. Cocoon implements these concepts around the notion of 'component pipelines', each component on the pipeline specializing on a particular operation. This makes it possible to use a Lego(tm)-like approach in building web solutions, hooking together components into pipelines without any required programming. (emphasis mine)

Hint: anyone who suggests that you can program without programming is suffering from a logical fallacy. The Cocoon folks avoid this by offering that you can "hook together components into pipelines" without programming. How pipelines become applications, that I'm curious about.

I don't mean to pick on specific projects, but I'm just pointing out examples. There are certain advantages to having components, but the end goal should be adaptability and maintainability. Not the mess of an MBean talking to an EJB Session Bean that was looked up over JNDI that talks to a JMX Component that I have seen one too many times. ("See, we've got this framework, but it won't talk to this other framework, so now we're writing a Facade class (ooh! Design Patterns! It must be good!) to expose things to the other framework...")

For whatever reason, this appears to be largely a Java phenomenon. There are more Java frameworks than there are applications built on them!

...well over half of the time you spend working on a project (on the order of 70 percent) is spent thinking, and no tool, no matter how advanced, can think for you. Consequently, even if a tool did everything except the thinking for you -- if it wrote 100 percent of the code, wrote 100 percent of the documentation, did 100 percent of the testing, burned the CD-ROMs, put them in boxes, and mailed them to your customers -- the best you could hope for would be a 30 percent improvement in productivity. In order to do better than that, you have to change the way you think.

Fred Brooks [paraphrased] as quoted from Allen Holub's http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html

The main thing that a framework needs to do is stay out of your way. It should not be an impediment to future progress. You should be able to say, "I want to change the sorting algorithm for this list," and be able to accomplish it quickly without the framework getting in the way.

I'm not suggesting that you should go through "Not Invented Here" syndrome, and re-implement wheels, airbags, windshields and turn signals, but that understanding the balance between adaptability and the enforced consistency of a framework. After all:

A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.

Ralph Waldo Emerson

Read more...

Now you have two problems

This is a classic quote from Jamie Zawinski:

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

This has made me laugh many, many times over the years, as I've been trying to not weep over some dreadful regular expression. Read more...

Dear Mom...

My brother sent me this picture, and while I don't normally post "family" articles, this one will have to be the exception.



That's my mom, racing Purple Jeep. I'm guessing circa 1976-1978. I think she threw out the trophies, but she won races. Read more...