Does Company-Wide Language "Standardization" Work?

RMX asks: "In our company, we're currently going through the debate of standardizing on a computer language for our next set of products. The pro-standardization guys say that a single language (like Java) will save everyone time. The anti-standardization guys are advocating a mixed environment (of languages like Python, Ruby, and C#), and argue that the whole discussion is as silly as a manufacturing firm standardizing on screwdrivers for all their screw/nail/glue fastening needs. Have any of your companies standardized on a language? How well did it go?"

Comments

Solutions Should Be Natural

[eldavojohn]

Problems and needs are naturally occurring things.

They take on unforeseen forms with non-standard characteristics. If your tool can't solve the problem or satisfy the need, you build a new tool that does. It's the human way.

Likewise, your company can standardize methodologies and practices all it wants. But should they ever standardize the tools they use to solve problems ... well, let's just say it won't be long before a problem or need comes along that the standard doesn't fit.

And then someone might be tempted to work hard at trying to make your standard fix it and work. They might spend hours re-inventing the wheel. And what will that get them?

Why, the ability to say, "Yep, and we did it all with one language."

The customer doesn't care how a solution is created. They care that it works and meets their requirements. Rarely have I seen requirements that read "... and it must all be done in the same language."

I am a computer programmer. I make computing devices do what I want. I will use any tool at my disposal, to hell with my employer's proposed "beneficial" restrictions.

In my dictionary, fatalism is the inability to cope with change. Adapt or fail. I am required to adapt to each new language I learn and I hope I never get rusty at that. Confining employees to one language does just that, it gives them a false sense of security and teaches them to think inside their box.

Re:Solutions Should Be Natural

[Duhavid]

I've worked with code like that in the "language of choice".

Do these introducers never get asked to justify their actions?

I dont see a problem with mixing languages, as long as the
choice is a defensible one that moves the project forward.
Making project choices on the basis of "gee, this will look
cool on my resume", or "gosh, I really want to play with this"
on any level ( in language or out ) should, generally, be
disallowed.

Re:Solutions Should Be Natural

[Wdomburg]

And then someone might be tempted to work hard at trying to make your standard fix it and work. They might spend hours re-inventing the wheel. And what will that get them?

Why, the ability to say, "Yep, and we did it all with one language."

At the other extreme you've got people writing in whatever they want whenever they come across a problem and end up re-inventing the wheel because either "I don't like Perl!" or "Numbnuts wrote this code in Object Intercal 95, which doesn't have a compiler/interpreter on the platform I need."

And what does that get you?

Why, the ability to say, "Nope, we don't confine our employee's choice of languages." Well that and a morass of code based as much on individual whim as any logical need.

As always, there is a middle ground - having a standard (or standards) with an allowance for justified exceptions.

Re:Solutions Should Be Natural

[MonaLisa]

There are two issues here: using a single or mixed language approach for a particular application, and using a single languange (or not) across an entire organization for all projects.

I worked for a long time at a big national lab that was mostly a FORTRAN shop. They wanted to use FORTRAN for everything, and it was technically a bad choice for everything, but culturally it was the only solution that would fit without causing a jihad among the old timers. I much prefer C++ for these sorts of things (big complex simulations that must run fast), but had little success in converting the masses, even though it was always faster, more portable, much easier to maintain and handle complexity, and also you can actually hire good C++ programmers.

We were able to do some mixed language solutions (C++, FORTRAN, C, perl, etc.) and they were a nightmare to maintain. in hindsight, I think it would be better to keep the apps all in one language rather than mixing. The biggest problem here is portability. These applications have incredibly long lifecycles, and the platforms change severals times underneath you, which seems to affect the inter-language interfaces the most.

Anyway, it depends a lot on the type of application, lifecycle, target platform(s), etc. but I think in general it is best to pick a single language if at all possible for a particular application that is the best single tool for the job. But, if a different application would be better suited for a different language, go with the different language. Mandating a single language policy across an organization for all projects is counterproductive: use the right tool for the job.

Re:Solutions Should Be Natural

[rve]

Are you the only programmer at your company?

Support and maintenance costs go way up when every programmer writes his little chunk of the application completey in his own style. By standardizing, on tools, coding patterns, naming etc, a company makes it less difficult for someone to debug or modify code that someone else wrote.

Re:Solutions Should Be Natural

[NitsujTPU]

I have to say that I agree with both your and the parent's point of view, but I think that you're taking what the parent is saying a bit too far.

The parent is speaking of company-wide decisions. It makes a lot more sense to write a video game in C than in PHP, in the general case. It makes a lot more sense to write a web site in PHP, than in C, in the general case. You don't want to force your developers into an awkward scenario by having a company standard tool.

You, surely, can picture the conversation where the writer of the interpreter from your game is told that he cannot use LEX/YACC, because his company standardized on C++. You can't? I was once told this at a meeting.

On your point, however, I can also agree. Needlessly writing code in other languages makes debugging a pain, and reduces your ability to share code inside the project, a place where I imagine that the most reuse is likely to take place.

Still. I can't really see the need for a company-wide decision to standardize on a single language for all of their development.

Re:Solutions Should Be Natural

[Jeremi]

Mixing langauges essentially means that a person who introduces a new langauge gets to build themselves (and a few of their pals) a little ghetto where other programmers are afraid to walk at night.

Just to be contrarian... it can work the opposite way as well. Many of my co-workers are scared of C++, but when I added a Python interpreter to the codebase and started implementating some of the program's functionality in Python, they felt comfortable creating and editing Python code.

Re:Solutions Should Be Natural

[The_Wilschon]

or "gosh, I really want to play with this" on any level ( in language or out ) should, generally, be disallowed.

Except that "Gosh, I really want to play with this" is, especially among hacker types, probably the single most powerful motivator there is. Disallow that, and not only do you lose out on the drive that hackers have to play with something cool, but they get annoyed and disgusted, and probably wind up working less hard on the things that they are told to work on.

Re:Solutions Should Be Natural

[TheRaven64]

You dont learn a language, which is just basically a syntax and keywords, you learn abstract concepts like iterations, paralellization, recursiveness, object orientation, etc.

You learn all of these things. Then you look at Visual Basic code, and realise that a lot of other people didn't.

depends on what you code

[Pavel Stratil]

Among my collegues we discussed this about a year ago. After doing some performance tests and after trying to write "problematic" pieces of code in some other languages, we dropped the standardisation idea. You either end up with bad performance or some long bizzare code (when you have problems with translation). There are also times where interpreted/scripting languages are of much higher value. Naturally you shouldnt end up using everything...

There are a few languages groups:
Special: Sql, Fortran, ASM
Brute force: C,C++
Object: C++, Py, Java, Ruby, Lua
Scripting: Perl, PHP, asp
High level: Haskel, LISP

As Python, Ruby, Lua are all the same and closely related to Java I definitely wouldnt use all of them. You might be well of with one, maximally two from each of the groups you use (appart from the special group:)).

That's my point of view being a person solving a very wide range of problems. But if you just write stuff that doesnt have much inovation (i.e. basic desktop apps.), a single language might suite well enough.

Re:depends on what you code

[shutdown -p now]

First of all, there is no such language as "ASP". Classic ASP is VBScript/JScript out of the box (and you can also have e.g. PerlScript if you want to). ASP.NET applications can be written in any language that targets .NET, but typically it's C# or VB.NET. Also, it's very interesting how you lump Perl and PHP together and call them "scripting". If it means what it normally does, than why Python, Ruby and Lua aren't there as well? Or did you mean to write "web development", perhaps? but then it's even stranger, because Python and Ruby are also just as good as Perl in that regard (ever heard of those things called Zope and Rails?), and Perl is also a decent generic-purpose language which supports OOP (arguably to a better extent than C++ does, in fact). Lua, on the other hand, is not an object-oriented language by itself.

Also, what makes Lisp high-level over, say, Ruby? And Haskell is a very different thing from Lisp, you know, probably deserving a category of its own (together with Scheme and OCaml).

Then... WTF? Python and Ruby are closely related to Java?!! And Lua, too? Gosh... Lua isn't even object-oriented, for one! Ruby is essentially a bastard child of Smalltalk semantically, highly dynamic, closure-centric - nothing even remotely close to what Java is. Python - it has multiple inheritance and multimethods, again, something Java avoids on purpose. So... er... looks like you don't know what you're talking about, really...

Re:depends on what you code

[Anonymous Coward]

We need a new moderation option: (Score:5, Pwned)

Re:depends on what you code

[root-a-begger]

I agree with your concept of categorizing based on type/style of programming. I don't especially agree with your categories, but that's just my opinion.
About 2 years ago, I went through the same thought process as asked in the original post. I was not encumbered by a large IT department that would dismiss my opinions if I came up with non-mainstream ideas. This led me to a very broad and lengthy search. Here is the result of my quest for an answer:

1 - Application language - Erlang
2 - Brute furce / close to the metal - C
3 - System scripts - Bash

I chose erlang after 8 years of Java programming which was followed by 8 years of Smalltalk. The main reasons for departing the mainstream OO world were concurrency, distribution and conceptual integrity. I found that in large systems what kept me worried most is being able to "prove" that my code worked as the system scaled and became distributed over local and worldwide "clusters". I wanted to be certain that no race conditions or locks occurred (just being able to monitor and restart VMs was not the answer for me). You can get concurrency assurance with Java or any "shared memory" / object pointer based langugage but you need very well written and tested frameworks to fully encapsulate anything that may be touched by more than one thread/process. Solutions like JBoss or other widely encompassing application servers also were not the answer for me as I had to trust that everything the app server did was correct and wading into these projects to find out if things are correct or to fix anomolies is a big challange.
I simply grew tired of writting the frameworks required to encpsulate concurrency and limiting my application code to the nature of the frameworks. Sure, there are many existing frameworks in the Java world that encapsulate the hard work and concurrency for you. But thats exactly the problem: there are many of them. This gets me to the last point of my rational: conceptual integrity. Each Java framework unleashes its own concepts and patterns. I wanted one small set of patterns that are used everywhere. I found this in erlang. It turns out that by making concurrency a first class priority in the language design, the need to invent frameworks and other patterns to encapulate the hard work mostly dissapears leaving behind a clean slate to write your app.

The second category, C, speaks for itself. Occasionally, I need to touch the OS or even bare metal and want a very straightforward way to do this. My C code ends up being very limited, well tested and compartmentalized.

The third category was a tough call. I was tempted to pick Python/Ruby/Lua/Tcl for system scripts. But the bottom line is I didn't really need them and for anything complex, I could write system tools in erlang that were called by Bash. This keeps my usage of Bash simple and maintainable without introducing yet another language.

I realize that my first choice, erlang, brings up the obvious issues of how do you replace programmers easily when you can't find resumes with erlang expertise. I have found that no matter what lagugage you choose, you have to re-train programmers to do things your way and there is a learning curve to introducing anyone new to your IT group. My choice in erlang has not increased the learning curve for good programms I bring on board.

I realize this seems like a giant plug for erlang. It is and it isn't. My rational stands on its one regardless of your choice.

good luck to you...

Comment removed

[account_deleted]

Comment removed based on user account deletion

That's dumb.

[Max Threshold]

Speaking from experience: use whatever tool works best for the job. Let me guess... the guy advocating using one programming language for everything wears a suit and has never written a single line of code in his life?

Now, one thing that does need to be standardized is terminology. I'm working on a contract right now for a wireless telco. The hardest part of this project was getting managers from various departments to agree on how this system we're trying to automate is supposed to work, and describe it to me in a way that would allow me to translate it to software. Compounding the proverbial six-blind-men-describing-an-elephant problem was the fact that everybody was using different vocabulary.

Size of your company

[erbmjw]

It can depends on the size of your company. I worked for a fairly small shop that specialized in Java and SQL work, because of that we became known for it in a positive way. It also was very useful because we all had a decent grounding in Java and our constant work in it had all of us improving our own skill sets quite rapidly.

But the firm had only 9 geeks, so as I said ... small shop. In other situations I can see why multiple languages would be more useful than a standardized company one.

Danger, Will Robinson

[Gorobei]

If you can, avoid the discussion/meetings/emails.

Firm-wide standardization drives are

a) usually politically driven, and if you voice the wrong opinion you will be disliked.
b) driven by the incompetents - if they could do something profitable, they would be doing that.
c) out of date by the time they are finalized.

There is no upside here because there is no magic standard that will make things better.

Pick Two

[Tablizer]

Pick one static/strong-typed language like Java or C#, and one "scriptish" language such as PHP, Python, or Perl. Some tasks will be best suited to one or the other.

Re:Pick Two

[samkass]

I think the parent is exactly right. All the people talking about "use the best tool for the job" have probably not worked very long in the industry. Being able to build on each other's successes, re-use code across projects that gets more vetted with each project, and build expertise with all the "gotchas" in your language of choice will make your company's product better and the company more profitable. These days, you can do almost anything with any of the popular languages, so there's no point in using more than one or two of them.

I'd say, standardize on Java, C#, or C++ (depending on your needs) as your primary language, add your scripting language of choice, then fire anyone who can't handle that. You'll be better off five years down the road than if you'd all built your fiefdoms around the tower of babel and every project becomes a throwaway codebase as the next "best tool" comes along 4 months later.

Any company that can't standardize on a language doesn't really have a coherent vision anyway, and probably is either a bunch of folks pretending to be a consulting firm or will disappear before too long.

(I'm sure I'm going to lose mod points for this reply, seeing what other people have written, but I don't see how any other approach is practical in the long term.)

We chose Java

[Andrew Tanenbaum]

but then we weren't allowed to use SQL or XML anymore!!

Like a single screwdriver?

[PornMaster]

Why wouldn't it be more like standardizing on torx vs. phillips head, or standard vs. metric?

We all know that monoculture can be bad. Besides platform uniformity, strict monoculture opens you up for enterprise-wide vulnerability, and even getting people with a similar, closed mindset. But it also provides for the ability to have a common dialogue with one another. It can be a shared jumping-off point. It keeps you from getting screwed when the one guy at the company who knew mindfuck leaves, and nobody else knows how to read his code.

There are costs and benefits to having, and to deviating from, a standard operating environment. Deviations should be allowed, but the deviations shouldn't be up to the developers, they should be weighed by management (who shouldn't be idiots), and risks and benefits weighed.

Business needs shouldn't be determined by developers. Developers tend to believe in nifty hacks. Code monkeys can love the elegance of using nuance in their code, but there's also a reason that they're not in charge. And it's not just because managers are stupid. Processes may be tedious. They may even be a reason for a developer to hate his job, which isn't good for productivity. Knowing 4 languages, and having the business be dependent upon him may be wonderful from his point of view. But having an employee dictate how things will be done can be destructive to the business. Particularly when he leaves the company for another job, and the new Java guy can't do shit with the Ruby and python.

Some of the pros and cons

[alangmead]

A single language makes each developer easily replacable. You quit, they just hire another Java programmer. If the collection of software you develop with is sufficiently unique (XSLT with extention functions written in both Groovy and Jython on IKVM running under .Net) you can create a position that would be nearly impossible to fill.

On the other hand, having each developer work on projects with their own collection of technologies tends cause the maintainance tasks of those projects go back to the original developer. This is generally a bad thing. Having a developer know that no one will ever see their code gives a temptation to take shortcuts that they wouldn't take others. Even more than code reviews, splitting maintanance across developers encourages quality code. You don't want a co-worker cursing your name as they try to add one minor feature to something you've done. ("F'n Andrew! Why'd he do that!").

Different languages and other technologies have their strengths and weaknesses. If they are chosen based on their strengths and not just their familiarity (let alone out and out prejudice) then their should be productivity gains achived from the choices. Of course, that means that this would increase the ramp up time a new developer needs to be very productive.

So if you have high turnover, you want to get new developers productively quickly (which would imply standardizing on as few languages and technologies as possible) and you want to get projects seen by as many developers as possible before the original developer leaves. (If Andrew is long gone, then "F'n Andrew!" can be an excuse given by the maintainance programmer, even if it is groundless.) If you have a lower turnover, then developers start getting a better feel over which technology choices fit in which business scenarios.

If this standardization is being driven by upper management, they are hoping to turn the developer positions into a cookie cutter role.

I just read a blog article on what Google does:

[John Harrison]

http://panela.blog-city.com/python_at_google_greg_ stein__sdforum.htm discusses the fact that Google has three official languages: c++, Java, and Python. It then goes into some detail about the use of Python at Google. It is a worthwhile read.

Pondering further

[deadlinegrunt]

What item should I pick to always win in rock, scissors, paper?

Re:Pondering further

[j-cloth]

Rock.

Next question?

Re:thats just stupid

[gmack]

A few years ago the company I worked for was pretty much all PHP with a couple of projects in perl. I ended up taking over a project and redoing it in C. The downside of that was that when my boss saw that my C based app outdid the perl code it was supposed to replace and could be used to replace some of the PHP as well he started to want to standardize on it.

I've never been quite as nervous as when I was asked if I could redo the websites in C.

Thankfully we talked him out of it and he came to his senses.

Better reasons than that...

[cfulmer]

"Save everybody time" is the best the pro-standardization folks could come up with? How about: (1) save training and support expenses for multiple sets of tools & languages; (2) specialists in the language & its quirks can benefit the entire enterprose not just the single group; (3) integration between different pieces of software is significantly easier if they're all in the same language; (4) easier to reuse code; and (5) easier to adjust when developers leave.

It's impossible to know whether it's a good idea in your case without knowing a lot more about what your company does, but in general a bad technical decision made for a good business reason is better than a bad business decision made for a good technical reason. The first one will cause you headaches down the road, but the second will make sure there's no road to go down. The key is deciding which decisions are good and which only appear to be good.

We settled on python

[ubikkibu]

at the pharma company I work at. We were all java, C++, LISP, Smalltalkers before. It's been four years now, and it was a wise decision. It's a very adept glue language that has been easy to integrate with other systems, both at the source code and network level. YMMV, and I think perl or ruby both fill this niche well too. We just wanted to have a standard platform for new development, and have been pleasantly surprised that python has been a productive choice for legacy integration and utility tasks as well. We had a requirement recently to integrate with a Java system. I used jython and it took three days, with no curly braces to be seen. We get a lot done every day now, and it's quite motivating.

Dilbert - GO FOR IT!

[ratboy666]

If you can get yourself on the "Standardization Committee", you can probably even have REAL fun! Like -- ask stupid questions: how does the language express factorial 10,000? Can I see some sample code? How about implementation of Knuth's Algorithm for sorting tape runs (whatever). How about dynamic programming? Backtracking? Functional programming? OOP support? Report generation from databases. GUI interfacing? Multi-threading?

You get the drift. I am sure that you could generate at least 1,000 pages of samples, criteria, &etc.

Ratboy

For a product line, ok. For a company, god no.

[gte910h]

Unless your company is an ungodly narrow sort of business, you should rule out the use of other languages entirely.

If you're hiring programmers who are totoally hopeless in other languages, you're not getting very smart programmers.

However, it makes oodles of sense to restrict languages for a certain product. That makes everyone on the team interchangable, and it makes it easy to have a place to plop new hires (who know that language).

However, before you build in a product restriction, you should put an out for performance/library reasons. I think it's silly for a shop to standarize on Java/Python, when you quite often need to make a C/C++ JNI/Swig wrapper to get certain tasks done.

At my firm we do a LOT of Python with C++ performance cores. We do some Expect scripts to interact with interactive programs. If we had standardized down to the point we would have used One And Only One language, then we would have one of many suboptimal situations: Standarizing on Expect would have been silly, TCL is not a full featured language. If we had standarized on Python Only, some of the code that needed to run over HUGE datasets would have taken approximately 15 times longer to complete than the C++ core did. The C++ core took HOURS as it was.

If we had standardized on C++, our dev/debug time would have been much much higher. We also would have had to spend more hiring developers (you can get good python code out of an intern. Good C++ doesn't come out of interns often enough to mention).

Standardizing on C++ isn't really standardizing. For a project to really standardize on C++, you have to pick a subset of that colossus and forbid the rest.

                                  --Michael

Are You Surrounded by Incompetents?

[cheesedog]

Here's how to tell that the people that surround you, um, how to put this delicately... 'lack critical thinking skills':

1. They advocate standardizing all software development on one language
2. They advocate standardizing all development tools in one IDE
3. They advocate standardizing all code formatting into one standard (tabs v. spaces, how far to indent, where to put the curlys, etc.).
4. They advocate standardizing on hitting '60' instead of '100' when you use the microwave and want to heat for 1 minute.
5. They advocate standardizing on one height for all adjustable chairs in the office.

Notice a pattern?

If there are enough people in your organization that this issue actually has to be debated, you might as well start looking for an exit -- the company is doomed to, at best, forever wallow in mediocrity. I'm not exagerating. This type of 'discussion' shows a serious disregard for reason, logic, and a lack of respect for wisdom. It's a serious indication that those spearheading the push have no clue what they should be doing in their roles -- they can't figure out how to do real work that would actually be valuable to the company, so they choose to waste their time on this.

There is something else at play here: whoever is pushing for this doesn't trust their developers to make sane decisions regarding development tools. Maybe that mistrust is warranted, maybe it isn't. Either way, you are screwed.

Now, if you were talking about a 5-man startup, it's almost a sure bet that you are all going to be writing in the same language, and you might even all be using the same IDE. Same if you are working in a small team in a larger organization. But a company-wide push to put all your eggs arbitrarily in one basket? Insane. For one, it means that the company will only attract (or keep) programmers who are not interested in developing new skills. And a programmer who is not interested in keeping their toolset current is generally a very poor programmer.

Smart people don't build monocultures on purpose.

Pick Two: It Does Make Sense to Narrow the Field

[BigTimOBrien]

Pick Two

One from - Java, C#

One from - Ruby, Python, Perl

It makes perfect sense to standardize on both. Scripting languages will always be more appropriate for text processing and other tasks like validation and system administration.

But, from what I've seen, it is important to standardize an organization on one of each. Letting people go off and just write System X in new technology Y might be enjoyable, but it does end up in a great deal of duplication and expense. For example, one environment I've seen has a great deal of Actionscript, a great deal or Ruby, more Perl than I'd ever want to see, and some J2EE applications. This usually occurs when an organization lacks a sufficient level of oversight over architectural decisions.

Just pray that neither side wins. Writing only Java is as silly as writing in a different language every single day.

Standardize on Hindi~

[colin_n]

Your company should standardize around Hindi - the new programming language in India - It is an extremely natural language - you write down your requirements in English (even on paper), send it via e-mail / snail mail to a supercomputer called "India", the "India" machine turns it into Hindi and feeds the information to a cluster of other India machines, known as "Indians" and then these "Indians" break it down into functions, write the code, put it back together, compile and send you the binary - you wont have to worry about what language they code it in!

Re:Standardize on Hindi~

[strider44]

Is the binary Big Indian or Little Indian?

The distinction between standards and uniformity

[jd]

I agree completely with what you're saying. It all comes down to an important distinction between having standards and having uniformity. "Wait!" I hear some cry, "Aren't the two the same?" Well, no. A standard translates, in pseudo-code terms, to "if X then Y". Uniformity translates to "always Y".

What needs to be standardized, then, is not the language per-se, but the rules by which a language is selected. The IF statements. If you read through the standards documents on the IETF's website, you are not looking at a single, all-encompassing rule. You are looking at possibly a few thousand rules, with enough logic behind them to determine which rule applies.

In the case of a company picking a programming language, you probably don't need a few thousand rules. A single side of paper should be more than sufficient to cover all the meaningful languages and the cases they apply in.

Rule 1 might be: "If a more precise rule is not defined, programs should be written to the ANSI dialect of C, revision C-99 with all threading assuming the POSIX threading model and other parallelisms within a single computer assuming OpenMP extensions. Where a more precise rule exists, that rule takes precedence over this default action."

For embedded code in web pages, the rule might be: "Except where a specific project requirement dictates otherwise, embedded code within web pages should be written in PHP, revision PHP-5.1"

For transportable bytecode, you might say: "Web-enabled applications, applications needing to run on clients without installation and applications needing to run on otherwise unsupported platforms should be written in Java and compiled to bytecode using a standard Java SDK version 1.5"

For configuration code, you might say: "Automatic configuration files should be written to the standards specified by Gnu Autoconf and Gnu Automake, using the applicable Gnu M4 macros" (Hey, M4 is a language too!)

You'd then have a few more cases for specific types of work the company does a lot of. This may include additional rules requiring C, but that's fine. You want the specifics in there, so that if you want/need to change the default action, it doesn't screw everything up.

If you're defining standards for languages, I'd also define in the same document some standard coding practices (eg: keep namespaces distinct, if you're using javadoc or something similar then comments should follow javadoc's rules, if you're using a code validator that uses comments to embed commands then state what commands should be used and when, if you're using a SCM - a very good idea - then comments to embed details like revision notes, date, etc, should be included in a standard location, etc.)

The upshot is that there's a lot of different things to consider, nobody can just pick one language for all occasions. Well, they can, but the only language that will ALWAYS work for ALL cases is assembly, and I don't think many people really want to write entire applications in assembler any more.

Libraries - not languages

[StressedEd]

Having read many of the posts here I think people are missing the importance of libraries.

I would hazard a guess that most people want to get a problem solved in the most painless manner possible when programming.

Surely the best way to achive this is by avoiding the reinvention of the wheel.

In some manner I tend to view languages now as nothing more than the glue that binds library calls together!

My approach is:

1. Work out what you want to do.
2. Find libraries that implement the most difficult parts of the problem.
3. See what language bindings exist.
4. Choose the language appropriate to this.

For example, there is a wealth of scientific code out there in F77. Just because F77 is old doesn't mean that the libraries are now wrong. They still do what they did back then. They are still useful. People have spent a great deal of time working out the error propagation in these codes, the efficiency and their validity. Do you really think you will save yourself time and do a better job by rewriting it in Java? No! So. Use them.

Then there are (great) libraries such as ATLAS or FFTW [*] written in C. Why assume you can do better? You can't, use that too.

In the rare case where you need to have something written from scratch, write it in whatever you are comfortable with. In my case C++/Boost (yes another library).

Finally you need to tie all this together, and hack around with it, and analyse the results so what's wrong with a bit of Python and MATLAB?

Perhaps this is an extreme example, and doesn't fall into the buisiness relm but the point is "the path of least resistance". Sometimes that path is dictated by existing code.

Do you really expect someone to rewrite from scratch an XML parser in "DoomJuice", or whatever is fashionable in house, just to please the people that want to standerdise on "DoomJuice"? No, use an existing library!

Ok, I've made my point. I will stop now.

[*] Yes I know FFTW technically uses Objective CAML to generate C code, but that's really only a distinction that a nerd would make.