One comment brings up haXe as an alternative to ActionScript, a language that can target Flash, PHP, JavaScript or native applications. Another similar alternative to JavaScript is GWT. I worked at a company a year ago that decided to adopt GWT for our next product. That didn't pan out as well as hoped because GWT hasn't really taken off. There's little example of best practice, limited support libraries, and some features are so immature that they are ridiculously difficult to use.

And, worst of all for something like haXe or GWT, it's nearly impossible to find programmers who are already familiar with the platform and are ready to go, let alone bring their own expertise when you lose a developer (or want to grow). With a language like Java, it's not terribly difficult to find a rock star programmer to jump in and immediately make a difference.

So my question is, even though there are many complaints about established languages, and many innovative improvements, variations, or completely new languages, are the alternatives simply too dangerous or costly for the corporate environment?

If so, how will these innovative languages ever become adopted? It seems like technology moves too fast for innovations, even really good ones, to have time to build a following big enough to stay around when things start to change.

5 Answers
5

So my question is, even though there
are many complaints about established
languages, and many innovative
improvements, variations, or
completely new languages, are the
alternatives simply too dangerous or
costly for the corporate environment?

If there's few libraries, little support, and almost no talent that can work in a language, few companies are inclined to adopt a brand new language.

If so, how will these innovative languages ever become adopted?

Adopted through a combination of the following

You have a major corporate backer, such as C# from Microsoft, Google's Go or Objective C/Next Step from Apple. These companies become strong supporters of languages and maintain associated frameworks.

You have a strong online community that fills in the support and library/framework creation roles.

Much of the decisions on what language to support are made by engineers, who may want to use the "cool new thing" and not the language that makes the most business sense.

I'm not sure if 1 is correct for C++. Depends from your viewpoint I guess. From one point, you can say it's backed by several company, from the other it's still a "community" effort.
–
KlaimMar 2 '12 at 20:32

I don't see C++ mentioned on #1. I will comment that in the case of C++, companies were promised that moving C code to C++ was easy, and were offered libraries with useful features as a sweetener. So, there was less scary innovation involved.
–
BrianMar 2 '12 at 21:37

And, worst of all for something like
haXe or GWT, it's nearly impossible to
find programmers who are already
familiar with the platform and are
ready to go, let alone bring their own
expertise when you lose a developer
(or want to grow).

On the other hand, are you comfortable hiring developers who are only willing to stick to what they know and aren't willing to learn anything new? If you're hiring a great developer, it's worth the ramp-up time for them to get familiar with the new language and/or tools.

@Jason - The problem is that you are presenting a false dichotomy. It is not a cannot find programmers for XXORyou must chose from programmers who don't want to learn anything beyond Y which is what they know. It is an ample spectrum, and among the popular technologies (say Java for example), you'll find an large number of programmers who know that technology well; know other technologies as well; and can (and are willing) to adopt other technologies should a good opportunity arises.
–
luis.espinalOct 19 '10 at 14:10

@Jason - con't. In other words, with all things being equal (and assuming we are not privy of other factors), probability dictates that we have a greater chance of finding a) a good developer that is 1) versed in a popular technology to hit the ground running, and 2) is willing/capable of adopting new ones over b) a good programmer equally versed in a much more obscure technology and with the same desirable attributes. Depending on the context and scope of projects, good engineering economics dictate to prefer the popular technology just because of that.
–
luis.espinalOct 19 '10 at 14:13

1

@luis - I have yet to run into a project that has trouble finding developers. I also have yet to run into projects that don't have trouble finding good developers. And guess what? You find a lot more good developers around those more obscure technologies. All other things being equal, I'd rather hire a Haskell programmer who hasn't done Java than a Java programmer who hasn't done Haskell for a Java project. Why? Because I know the Haskeller will pick up Java much easier, and is more likely to be a better programmer.
–
Jason BakerNov 1 '10 at 10:28

@Jason - you seem to be missing the point I'm making (about the false dichotomy). I'm not debating that better programmers exist with the so-called obscured languages. I'm debating that it is a false dichotomy that the opposite of the former implies only one-trick pony developers. Either way, your experience might be different from mine, for I have witnessed projects and companies having a hard time finding qualified developers. That is a constant in the industry (an indictment to the bad state of our current CS education.)
–
luis.espinalNov 5 '10 at 22:04

@Jason - furthermore, though the statement that a Haskell developer who has never done Java will have an easier time learning Java than the other way around might ring true, it is an unquantifiable statement. Almost every Java developer I know is well-versed in several programming languages. Myself for example, I've never done Haskell, and I've done almost nothing but Java for the last 12 years. However, I've done a plethora of other languages, from Lisp, C++, Ada, Assembly (even weird things like mimicking FP with FoxPro).
–
luis.espinalNov 5 '10 at 22:10

From a Software Engineering perspective it's bad to choose the most innovative technology available,
this will introduce delays in the schedule because people are not experienced and thus work slower...

These will become adopted because people will learn them in the time that's scheduled for that puprose,
so for example one might introduce time after the project is done to be able to learn new technology.

Sometimes new technologies build on older or more popular ones, and this can make them simple enough to ease their uptake. For instance, node.js uses JavaScript (and Google's JavaScript engine developed for Chrome). The additional code related to the project is quite small. Also, it has a niche in network programming that it fills very well even with a very slim core, and it can integrate readily with a larger codebase through HTTP, sockets, and JSON.

Good point, jQuery is another great example - there are probably as many jQuery questions on SF as JS. Some of them coming from people who don't even know JavaScript. Yes, it's just a framework, but the way it is used is almost like a different language.
–
NickCSep 17 '10 at 15:46

It depends on what you mean by calling them "Innovative languages". For example, what's the innovation behind Scala? Scala is trying to blend two widely accepted programming paradigms (imperative and functional) in a nice and elegant way. The case is similar with Clojure. Clojure is a modern Lisp designed with concurrency on mind and offering a more "friendly" syntax than the rest Lisps (but that's just syntactic sugar).

Of course the language designers are smart enough to help programmers adopt their languages. In the cases of Scala and Clojure, people who use the Java API can still make use of it.

So there is always a small risk involved in adopting such a language, but if it already has an established community and the learning curve is relatively small, don't be afraid to go for it (provided of course that it does something better compared to the mainstream languages).