How to choose the best programming language

Inspired by a new blog-article "Best programming language" there are some more open points to discuss on how to choose the best programming language for life, universe and everything. Let me give 5 of them.

First things first: Is choosing the right language even remote possible? And if so, how can it be done? Well, to set things clear let's have a real-world-example: Which (spoken) language shall I learn to succeed at most? If it's only a matter of understanding and talking to the most people this would be chinese. Do you achieve your goals with that? Most probably not.

Why wise selection is necessary

You can speak with one billion people in case you choose to learn chinese, but you could not read this blog (in case you prefered learning chinese before learning english). And how many people in your neighbourhood do speak chinese? Is it worth learning (under respect of this argument)?

Choosing a programming language too depends on many factors which you have to name and select with care. You want to show the best performance in programming (be it in programming-speed, stability, scalability ...), here is how:

5. Complexity of setup is not counting for evaluation

So, setting up an environment to evaluate the new programming language will last one to two hours (or even more)? Be honest: Setting up a testing environment for two hours is more easy than living with a not at all appropriate programming language for the next 6 month on a eight-hour-per-day-working-base in your new project. And of course you have to think about administration workload later on (which too reflects in evaluation, of course), but there are tools, workflows etc. which, done right, may help you to get rid of this point. Test the availability of tools, too.

4. The most hyped language may not be the best to choose

What is a hype (spoken in language selection)? Well, there is a new language out in the market. All people talk how easy and neat it is to work with it. Pretty cool so far. The drawback is that these languages are not widely "broadcasted" out there, mostly information is sparse on both the language and the usage/projects done with it. Of course you may use it, but be sure not to see things through rose-colored glasses.

3. Programming for fun is one, doing a project the other thing

Think of team-working, releasing, "changing one little bit might affect many others (and how can I prevent/check this)". This will help a great lot in case the project gets bigger and you will have to hire new people.

2. Prototyping and "getting things done (as fast as possible)" is not your daily work

Of course, most bosses and clients want to see what you do as fast as possible. They are more eager to compare your work with their business plan than to hear "no, we are setting up servers/software/configurations - please stand by". But on the long trail, as a programmer, you only can win if your work is profound and, in best case, solves problem other peoples like your bosses and clients do not even think of now. Test your desired language(s) if they fulfill your own personal claims on that regard, then test the language if it serves well in a programmers team and client-centric manner.

1. A fool with a tool is still a fool

Do not blame the programming language if you run in first problems (at first sight). Search for other ways if your goal cannot be reached with your first shot. Use Google to find new ways and thoughts (a good test to show if enough people using it / documentation on how to use it is out there, too). And even if you used the language for some years and think that the new project does not fit to it, give it a try on Google/the community. There are other people who might help you to solve a brain-nut-problem, sometimes on-the fly.

Not sure what langauge to choose now?

Watch out! There are a couple of languages on the market. And there is no easy answer to this question, if someone provides you with an easy answer, be most careful! Evaluate some languages, program some more in the languages that reach the "inner circle" for you and never forget the old but true saying: Use the right tool at the right time.


Other "Thoughts on" and "how to" articles:

• 10 thoughts on successful server programming
• Thoughts on successful exception handling
• How to successful log in programming
• Thoughts on successful logging

Related posts:

• Different types of programmers
  

What, exactly, is XML?

This seems a dumb question: What, exactly, is XML? But, being honest to yourself, can anybody out there explain to me in a few words what XML really is? Or, to be more precise, what is XML all about?

For a couple of years I tried to just listen to the guys 'n ladies who should know the answer and, believe it or not, I got a couple of answers depending on whom I asked for:

Listening to consultants it is the one-and-only salvage to our new computer-century, solving all problems you ever had. Not even enough, it is capable to solve problems you are not yet aware of ever to have.

Listening to the techies you might learn that all you want to achieve technically may be done using XML.

Listening to the decision-makers it is the answer to life, the Universe and everything, and that all doing one big shot.

But, honestly, can anyone out there answer the simple question: "What, exactly, is XML"? Doubt so. This is because merely (in first sight) it only is a format but then (in second sight) everyone put their hopes in it to solve problems XML never was ment to solve. I still can remember the hype in IT where, at a meeting, someone simply said: "Well to solve this problem we provide a XML interface, that should do.". Needless to say that it didn't.

And it is easy to process. There are so much frameworks, tools and API's to cover all that unconvenient stuff of "reading", "parsing" and "testing" XML (configurations) that most people may suggest to you that using XML is pretty more simple than doing without it. Never had the sensation that you needed one hour to do something in XML which could have been done in a couple of minutes without? I had.

To be more precise, the troubles I have with XML are the following:

- It is not defined which element (or tag) to use if there are more than one in one realm. As far as I know all the tools and API's take the first value they find, but it might be a source for errors, especially if you insert a new element which overrides (or better: does not override) the previous value.

- XML is not human readable. It is an exchange format with fault-tolerancy. This is the one advantage XML has (compared to, say, a fixed size record-driven format): In case an elenment is not defined, the structure is kept (mostly). But reading XML as a human reader is painful.

- XML is a format and no programming language. XSLT is a cute way to transform XML into another XML (or text or u-name-it), but XSLT is no programming language either. The moment you stop thinking of XML as a language is the moment you will better recognize how often it is misused nowadays.

- XML produces overhead. Huge overhead. Only think of SOAP-WebServices (or BLOBs represented in XML): To send one bit of information you will need to process, assemble and send some kilobytes round the corner. Agreed, SOAP-WebServices are well-defined and can simply be extended. But do you need XML-ish things for each and every problem?

So what, exactly is XML? An all-intention-problem-solver? Definitely not. An extensible exchange-format with fault-tolerancy and many available tools to deal with and transform or show it? I bet on that one.