Jay Fields is a software developer at DRW Trading. He has a passion for discovering and maturing innovative solutions. His most recent work has been in the Domain Specific Language space where he's delivered applications that empowered subject matter experts to write the business rules of the applications. He is also very interested in maturing software design through software testing. Jay is a DZone MVB and is not an employee of DZone and has posted 116 posts at DZone. You can read more from them at their website. View Full User Profile

Targeted Languages

12.17.2008
| 7580 views |
  • submit to reddit

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.

From http://blog.jayfields.com

Published at DZone with permission of Jay Fields, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jeroen Wenting replied on Wed, 2008/12/17 - 1:05pm

Yippee, you managed to make a "Java iz ded" post read more or less interesting!

J Szy replied on Wed, 2008/12/17 - 3:16pm

[quote]I mention that I'm skeptical that there will be one language that is perfect for solving all possible problems in the future.[/quote]

The only perfect language is HQ9+. It solves only four problems, but does it perfectly.

[quote]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.[/quote]

You can't be more wrong. Java became the standard because the right people were making decisions based on adequate information and teams of decent programmers. Only those decision makers were not programmers, and they had no programmer's heaven in mind, but user experience and financial aspects. You know, like profits.

[quote]However, I do think it's inevitable that we move to languages targeted at specific domains and problems eventually.[/quote]

No, it's exactly the opposite. We used to have C or even assembler for systems and devices programming, C++ for desktop programming and video games, Perl and PHP for web programming, Perl and SH for scripting, Lisp for AI programming, BASIC for learning how not to program and Python for showing the ugliness of Perl.  Now Java or C# is the default choice for many of those things. More and more devices can be programmed in Java (and on some of them it's the only way), Java is the choice for web applications but C# is a strong competitor, Java is the language to learn and it's still neater than Perl. 

I'd say that in the future there will still be C with assembler for very low level tasks, a language based mostly on Java and C#, maybe even one of those for writing most applications, Lua or something similar for high level scripting and Ruby for bragging about.

 

Arek Stryjski replied on Wed, 2008/12/17 - 6:55pm

[quote]If you're a bank and you write your trading applications (...) [/quote]

I believe there is something wrong if bank writes any application. If bank builds new brunch they just get local builder and architects. They don't ask if tools they are using for building are specialized for "financial industry", and there is no problem if same people where building hospital last year.
Yes, hospitals are not a banks and you need to know how to build each type of building, but you don't make doctors and accountants decide about building tools and equipment.

I believe there will be very specialized API's and library's for each industry in future. However I'm not sure about DSL's (even I was very enthusiastic about them few year ago).
Maybe in future languages with which you will "glue" different parts of application will be less important. 

Probably we will need to decide if we should use scripting language, traditional OO like Java, or functional language before we start any project. However I hope it will be not dictated by client industry, but by type and size of application.
Let's hope IT will be independent industry in future...

Otengi Miloskov replied on Wed, 2008/12/17 - 8:28pm

This is pretty easy to guess, It is not rocket science.The future are Virtual Machines platforms, It is not programming languages.

For Example, Games need lots of performance for AI, Gameplay and Graphics, that it will be with a combination of GPU programming with also a GPGPU, Games in the future will be programmed so they take the advantage of the parallel power and computer power that exist in the GPU using a Virtual Machine. Do you know LLVM that will be the next VM for GPU and you could use C, C++, Java, Python, Haskell and Lua, etc.

For the Enterprise and business software there is the JVM and the CLR. For the JVM we have Groovy is our Lua for JVM and Enterprise software, Check SpringSource they acquired the company behind Groovy on Grails because Groovy matters a lot for the future for the JVM and Java development.

Many people still thinking in the future there will be the Next Big language but it is not, The future is the VM as the JVM or LLVM or CLR and languages running above those Virtual Machines.

Jeroen Wenting replied on Thu, 2008/12/18 - 7:30am

not just banks but ALL large companies have internal departments to create and maintain custom software. This is simply because their business has unique requirements that are best served by custom solutions and having the entire process in-house is ultimately cheaper and more convenient than relying on external resources.
Most such internal software companies will rely to some degree on external expertise, mainly for implementing new products and taking up the slack for maintenance work.

There's nothing wrong with that, this isn't a theoretically perfect world as preached by Richard Stallman and his adepts where everyone is served perfectly by one of a select set of standardised open source packages (which he, Saint Richard, of course, is the Great First Brother and Suppreme Ruler over).

Dmitry Leskov replied on Fri, 2008/12/19 - 7:09am

[quote] 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.[/quote]

It is very hard to hire a good developer, period. I think "Java" or any other popular language does not belong to this sentence. I'd never hire a person positioning him/herself as a "Java developer" or "C++ developer". You are a software engineer or you are not. In the former case, you'd study the language, the tools, the APIs, the frameworks, etc., and will be as productive as other software engineers using them.

Legacy languages are a problem, because they don't add to people's resumes. We helped a few customers convert their code bases, e.g. from a proprietary Pascal dialect to C++, and in most cases one of the primary motivations was the inability to compete for human resources. They were having hard time trying to hire somone able and willing to program in those languages using ancient tools.

Finally, domain expertize is a different thing, strictly orthogonal to software engineering skills (except of course when the domain is compiler development or something like that. :)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.