Wednesday, August 1, 2007

Pander to familiarity

The first step of getting out of the familiarity trap is to feel confident in sizing up what else is on offer.

A simple set of criteria as defined by Sebesta in 'Concepts of Programming Languages' includes:

  1. Readability

  2. Writability

  3. Reliability

The invisible 4th criteria I belive is Familiarity. Unfortunately, in reality I believe that familiarity takes precedence for the majority. You might argue that familiarity is a construct of readability and writability but I disagree. It may be a fuzzy line; but to me something isn't purely readable and writable just because you've twisted your mind to think that way.

For example:

1 for (int i = 0; i < 5; i++) {
2   Console.Out.Write("hi ");
3 }


That looping construct makes sense to a veritable legion of programmers (pick your printf or println statement). Is it readable and writable because you've done it a gazillion times or is it inherently simple?

Contrast that with:

1 5.times do
2   print 'hi '
3 end


If you pulled a layman off the street and showed them both I could take a guess at which one would be considered more readable.

In Steve Yegge's (in)famous next big language post his number #1 rule for the next triumphant language is 'C like syntax'. I can tell he feels oh so dirty saying that, but 'you gotta give the programmers what they want'.

Things like orthogonality, control structures and data types don't seem to rank as highly. Whatever happened to the best tool for the job? If I know there is something out there that works I don't care whether it's functional, applicative, imperative, logical, whatever. It's just a side-effect. If you have a brain in your head, you can work it out.

2 comments:

Ingo said...

Familiarity also means knowledge base and client acceptance.
You'll need to find individuals who can write the language and later more to maintain it.
You also will have to pander to customers 'requirements' and 'standards'.
One more criteria to add would be the amount of existing frameworks/toolsets. Having a more effective language doesn't help if you will have to rewrite a lot of tools you would otherwise have already available to you.
Let's face it, these days programming becomes more and more a job of integrating existing applications using exisiting toolsets and frameworks. This will make it very hard for any new language to become large. This will create more and more J* and *.net languages who will have a nicer syntax but who are really just a wrapper around the two largest existing languages

dan said...

Thanks for the post ingo.

I see where you're coming from and I definitely agree. I was referring to my 'ideal' world. You mention the J* and *.net languages. I can only really speak for JRuby but it is not a wrapper around Java. It is a Java implementation of Ruby. So if you have a JVM, you've got Ruby. The integration between the 2 languages is just icing on the cake. In fact, it complements your statement regarding the integration of new and legacy applications. If you have substantial time and money invested in legacy Java code then with JRuby, you can call it from Ruby.