Wednesday, May 26, 2010

Becoming popular

There is an excellent article titled How to design a popular programming language. The whole formula is very simple:
1. Find a new platform that will be a huge success in a few years.
2. Make your language the default way to program on that platform.
3. Wait.

I can't agree more with the author, excluding language enthusiasts and religious zealots, programming languages are mere tools that enable the programmers to write software that (usually) solves some problem . So nobody gives a damn does a language has tail recursion, multiple inheritance or monads. I mean those who know about such things would whine for some time, sometimes even for a long time, but you could safely ignore them as in the end the problem will be solved with either simple workaround or using a different approach, this is guaranteed if the language is Turing complete.

However the author is quoting two languages as exceptions (Java and Python) to this rule. But these two languages only make his definition of a platform oversimplified. To counter with an oversimplification of my own the platform can be seen as nothing more then a market. From this point of view both exceptions aren't exceptions at all, rather a fine examples of riding a platform. Java's platform is writing cross platform enterprise applications, the whole promise of "Write once, run, anywhere" enabled the programmers to rely on JVM being able to run their code across plethora of operating systems. On the other hand if your market is productive language fallowing There's Only One Way To Do It and batteries included philosophies there is no other choice but Python. To conclude anything could be defined as a platform, but most platform aren't economically viable.

If you understood the value of platform then what choice is left for the unpopular languages. Alessio Stala half jokingly suggested that: all that great but unpopular language has to do to in order to gain popularity is to deeply integrate with a popular platform and make it easy and convenient to use pre-existing libraries written in other languages for that platform.

My humble opinion is that this wont work for two reasons:

First reason is that if the platform is already popular that means that there is at least one standard language for programming in that platform and its impossible to dislodge it, unless it shoot itself in the head and alienates its users. So the only way for the language to become THE language for that platform is to become one before the platform becomes popular.

But why couldn't the new, shiny, perfectly designed language dislodge the old, rusty, haphazardly bundled language? The newcomer will better at everything. Better libraries, better tools, better books, better ...

This concept is best described by the book Crossing the chasm (*). The short story is that life cycle of adopting a new technology starts with early adapters fallowed by a huge ditch called chasm which you need to cross in order to reach the pragmatists which we usually call mainstream. The early adapters are easy to get, you just need to have something interesting, those are the people that want to tinker. The pragmatists are the tough ones. They are hard to get but very loyal once won. They want proven technologies, vendors with credentials and most of all standards. They want to buy from the market leader and you ain't one. Pragmatists control most of the money and are the ones that are fallowed by Conservatives. Try to make problems by disturbing existing market and they will cut your throat.

But what about Clojure or Scala? Bear with me for a while.
The only way for a new language to succeed is to dominate a viable platform. What is the Clojure biggest selling point? Is it Macros? Lisp and Scheme have them for decades. What about interoperability with existing Java libraries? ABCL, Jython should I say more etc. The only killing feature of Clojure is concurrency. In order to successfully cross the chasm you need a pragmatist in pain. Pragmatist that suffers from writing concurrent code in Java so much that he is willing to give a chance to a fledgling newcomer like Clojure. Don't get me wrong aforementioned features help a lot, especially backward compatibility, but if processors were still single core and we all enjoyed the free lunch of increasing gigahertz-es nobody would give a damn about some weird functional language with immutable data structures. Clojure has no chance to dislodge Java as premier language for writing enterprise applications, but it could win as the language for writing concurrent applications. That is Clojure platform.

The second reason why this corollary wouldn't work is because integrating in some platform requires the language to change.But mature languages can't change easily if at all. This situation is described in theory of frozen evolution. Basically the evolution of language is similar of the evolution of a new specie. Evolution happens in short burst when the new language(specie) is created. In this period language design is plastic, there are few if any users, little amount of code and libraries and the community consists of enthusiasts. This short period of plasticity is fallowed by a long period of stability. The evolution of the language is frozen. There are few tweaks here and there but nothing radical. And nobody , not even the original creator could change that. Just imagine if Bjarne Stroustrup says to ANSI C++ committee that he wants to adapt post fix syntax, they would laugh at him just before they send him to mental institution to see what's wrong with his nerves. On the other hand Hickey , Tarver and Pestov could redesign their languages when new opportunity arise, but a new standard for Common Lisp is nothing but a dream.

(*) Eric Sink has a very nice article describing Geoffrey Moore ideas, where I shamelessly hot linked the bell curve image.

Sunday, May 23, 2010

Judging the language by its implementation

Paul Graham wrote an article about judging a programming language by its cover, explaining the use of hacker radar to infer knowledge about a language that you never wrote a code in it. I won't comment on his reasoning however while traveling through the land of programming languages I've found another quick method that will tell you a lot about the language without the need to write any code in it. Its called judging the language by its implementation.

First type of languages lack a functional implementation. There's web site saying how this language will be solving whatever is bothering the language designer and you might find paper(s) describing the language. These aren't languages at all, move over there's nothing to see. Unless you are interested in vaporware.

The second type are those with interpreter written in some other high level language that looks like it was bolted together over the weekend by some student hastily preparing the seminal assignment. Just skip those too, if you found the concept really appealing bookmark the site and visit it after few months to see if there is any progress.

The third type is minimalistic interpreter but this time the interpreter feels good, supporting several operating systems and on each it just works without tweaking. Usually this type of languages started their life as a research toys or maybe a scripting tools that proved itself useful thus gaining life of their own. Though minimalistic this languages might be battle proven in production environments for many times. If the field this type of language targets interests you, you might be well served. I believe in this case existence of viable community should be deciding factor. If there are at least 100 active users, go for it as people that gather around this niche languages tend to be very knowledgeable and helpful.

The fourth type are languages that I call pioneering languages. You could recognize them claiming tools that exist only for the mainstream languages, like integrated development environments, code browsers etc but instead of providing their own they piggy back as plug ins on mainstream languages tools. This should be warning sign, if the plug ins work without tinkering the language might be usable, else you are in the land of pioneers and pioneers are the ones with arrows in their backs. Proceed at your own risk.

The fifth types are the ones with development environments of their own but you need to install like gazillion dependencies, many of those are external (usually dated) versions of popular run-times like .NET or JVM or many popular libraries. Avoid this like a plague. This a sign of language that was once popular but has fallen from grace and now instead of choosing its niche is over reaching trying to everything to everybody.

I could mention a sixth type with maybe several mature implementations but those languages are usually in the mainstream or well known, so you could gain enough knowledge about them with 5 minute goggling.

Saturday, May 22, 2010

OpenCL Programming

I've finished the OpenCL Programming Book and I'm quite struck by low-levelness of OpenCL programming. Lisper in me is already tempted to make some scripting language around it but I need more practice first. So next step is going through SDK examples which are plenty. And it seems that literature is growing fast. ATI is finally investing resources into OpenCL, that will help OpenCL define itself as a real standard, NVIDIA would rather have everybody writing CUDA.
I'm buying a new machine with 2 x PCI express slots. Will need it in order to code with both ATI and NVIDIA cards simultaneously. However I'm little puzzled about my gaming subconscious using OpenCL as an excuse for buying new machine in order to be able to play mafia 2.

Friday, May 14, 2010

How to game a technical interview

After reading the Yes, I know article and especially the comment below I thought how easy was to game the interview.
If there is an opening you're qualified for but there will a tough competition and the interviewers value highly candidate technical competency your answers to interview technical questions would carry a lot of weight. So if the interviews are scheduled in different days all you need is an accomplice to be the brilliant at your interview. Choose someone who has a great resume or at least good enough to be called for the interview but isn't interested in that opening. When HR calls let your accomplice schedule the interview day before you then tell you the interview questions.
The interviewers might change the questions afterward but I seriously doubt it. First preparing good interview questions is a tough work and second and more important if the questions are changed a lot it becomes very hard to compare skills of the different candidates without having a common reference point.

And next time I'm preparing a unique question for those looking suspicious on the ones previously asked. Sometimes paranoia is your friend.

Friday, May 7, 2010


I've just bought the OpenCL Programming Book and start to dive in the world of parallelism. In the world of multi-core processors and programmable graphic cards I have an uneasy feeling that my knowledge is becoming dated and that's not something that I feel comfortable with.