Tuesday, December 09, 2008

Targeted Languages

The vast majority of actively evolving business software is written in Java these days. Java has long enjoyed the title of One Language to Rule Them All. However, in a previous post, The Next Big Language, I mention that I'm skeptical that there will be one language that is perfect for solving all possible problems in the future.

I might be overestimating the speed at which our profession is maturing. One of the reasons Java became the enterprise standard was because the wrong people were making decisions based on inadequate information and swarms of terrible programmers. I like to believe that we're moving away from those days, but then again, we definitely still have far too many NNPPs that need to be encouraged to find other employment. However, I do think it's inevitable that we move to languages targeted at specific domains and problems eventually.

We've already taken the first step. Games are a form of business software. Games are consumer products. However, game development has never been dominated by Java. I won't pretend to know about the game industry, but from what I hear it's been largely dominated by C++. However, these days Lua has enjoyed great popularity in the videogames industry.

The game industry has been using the right tool for the job for some time; however, other business are also starting to catch on. Many companies are using Ruby and Rails to build websites. There's no question that having a good group of programmers building your website using Ruby and Rails can provide a significant competitive advantage. Erlang is another language that targets a specific class of applications, and it provides huge advantages over the alternatives for those applications.

I think targeted languages raise some new interesting questions.

For the professional software developer, targeted languages may make it harder to switch domains. These days it's easy to get a job doing Java development in insurance, banking, advertising, and many other domains. If in the future all the banks are using a functional language focused on low-latency, you may find it harder to make the switch to an advertising agency with a shop that's using an object oriented dynamic language. It may not be long before selecting a language implies selecting a domain as well.

There will be implications for firms also. The pools from which companies hire from will get much smaller. It's very hard to hire a good Java developer these days, imagine what the picture is going to look like when there are 5-7 targeted languages that are widely accepted and the developer pool is split 5-7 ways.

There will also be questions about how many languages your organization will support. If you're a bank and you write your trading applications using the best language for the job, would you allow the intranet dev team to use a completely different language?

Companies are already facing these questions. At DRW Trading we use C#, Java, C++, Python, Ruby, Perl, etc. I hear that Google only allows C++, Java, Python, and Javascript. There's definitely a balance between leveraging existing knowledge and using the right tool for the job. However, finding that balance isn't an easy task.

Like it or not, we're headed towards more targeted languages. It's probably worth considering the implications sooner rather than later.

9 comments:

  1. There is another part to consider here. What about developers who choose specific languages for the sake of limiting their field?

    I now that I have done that. I chose a language because I knew what the field was for it and I figured I did not want to go out of the field. For example, even though I am well versed in Java and have plenty of experience in it, I have dropped it from my resume'. I have done the same for visual basic for the same reasons. I am not interested in the fields that these languages tend to be used in.

    Just a thought.

    ReplyDelete
  2. I wonder how tooling support will affect this process. A targeted language may be better in a certain domain but without the proper tools the developers may be less productive than they were with (say) Java.

    Perhaps, this factor will help in striking the balance you're mentioning.

    Moreover, it seems that language designers should provide better support for IDE integration. Or, conversely, that IDEs will finally offer a good abstraction that will allow language specific plug-ins to be easily written.

    Coming to think about it, it means that we are actually waiting for a targeted language for IDEs, which will provide good support for targeted languages.... :)

    ReplyDelete
  3. Tools are for tools.

    Seriously though, using a big and complicated IDE can be good to compensate for the shortcomings and verbosity of Java, C++ and similar languages. Not surprisingly, most of the "tools! must have tools!"-crowd seem to come from that group of developers. Also, they usually are trained code monkeys and have programming only as their profession, not as a hobby and they aren't passionate about it.

    Here's a truth: No IDE will help you become a better programmer if you don't understand the code. Maybe you will manage to create something that works most or even all of the time, but if you don't fully understand programming you are bound to hit the front page of thedailywtf sooner or later, and those who are trying to maintain your code later will probably rather commit suicide.

    If you want quality code, nothing beats a passionate Emacs/Vim (or TextMate/whatever) using nerd with mad UNIX skills when s/he is fully allowed to use the right tools for the job. (Yes, there are exceptions)

    The biggest problem with today's software industry is all the behind-the-scenes "magic" causing "programmers" to not understand what they are doing.

    ReplyDelete
  4. Tuxie,

    Are you also saying that "No IDE will help you become a better programmer if you *do* understand the code" ?!

    ReplyDelete
  5. I'm saying that IDEs will help you when you're using verbose, designed-by-committee languages and APIs, but they are usually overkill (and get in your way) when you use expressive languages and simpler but more niched API.

    ReplyDelete
  6. Tuxie,

    I can certainly agree with your wish for cleaner languages/APIs. However, I don't think it's a binary issue: A clean language => IDE is useless. A Bad language => IDE is helpful. There's a vast grey area between these two extremes.

    I don't know what you think about Smalltalk, but many see it as a clean language. Much of Smalltalk's productivity gain is due to its built-in class browser.

    ReplyDelete
  7. IDEs aren't useless, they make the life easier for some and they are good at some things. The class-browser is a good example of such a thing.

    Personally I prefer a physical file-view though, with filenames representing the classes. I can do about everything an IDE can do and much more by writing (often re-usable) one-liners on the command line.

    I've been using the command line as the primary way of interacting with my computer for about 20 years (Linux since 1996 and the Amiga before that) and I have yet to find a single IDE that doesn't just feel like it's limiting me and holding me back from what is possible.

    I like a smorgasbord of small tools, each one doing only a few things but doing them great.

    What annoys me is the common disregarding of fantastic new technologies just because they lack integration with VisualStudio/Eclipse/whatever or they don't have fancy Next-Next-Next-Finish-wizards. It's so limiting.

    ReplyDelete
  8. Both Python and Ruby in the same shop is interesting?
    Is this for certain frameworks that are only available in that language?

    ReplyDelete
  9. Anonymous11:58 AM

    I wouldn't say it's just a frameworks issue. It's more of just using what makes sense based on the job being done.

    Each language has frameworks, tools, integration stories, etc.

    While they are similar languages, they are quite different when you get to the details.

    ReplyDelete

Note: Only a member of this blog may post a comment.