Thought for the Dazed

I've had to give up that Distance Learning course as I was having trouble seeing the teacher.

Flickr
www.flickr.com
RobMiles' items Go to RobMiles' photostream
Twitter
C# Yellow Book

Search entire site
« Word of the day: Snodchortle | Main | Imaginationgamers »
Sunday
Mar252012

Best Programming Language?

IMG_7331-Edit.jpg

There’s a program in the App Store called “Best Camera”. It takes as its starting point the idea that “The Best Camera you’ve got is the one that you have with you at the time”. The application then goes on to provide all kinds of useful tools that make the iPhone camera as good as possible.

I was reminded of this when there was a tiny bit of debate on my post about the CodeAcademy site, which teaches JavaScript. Now, JavaScript is not a great language, but it works and can be used to create useful stuff. So it is automatically a candidate for “Best Language”. In my opinion, the Best Language is the one that you are using at the moment. I base this on “Robs Rules for Programming Languages”:

  1. You can write great code in any language.
  2. You can write horrible code in any language.
  3. The user does not care what language you used to write the program they are using. The user only cares that it works and does what they want. And that they can afford it.

I’ve written programs in loads of languages. At the moment my personal favourite language is C#, but I have really fond memories of writing embedded C, since in that I could do anything I wanted and I could build all the underlying bits myself from scratch.

This is usually the point that people say things like “But blah doesn’t have blah.” or “Blah programs are really hard to use because the debugging support sucks.” So what. This brings me to the Rob’s Other Rule

  1. Having a nice place to work is much more important than the programming language you are using.

If the language you are using doesn’t have a feature that you need, find a way of programming around it. I’ve written lots of object oriented software in C. C doesn’t support objects, but I arranged the code so that it looked like it did and then programmed by “object rules”.

If the development/debugging support is horrible, wrap something around your program to make it easy to work with. I’ve built emulations of LCD panels and even lasers to avoid having to debug my programs on the real hardware. I’ve written code to make ten thousand customers from nothing, to save me having to type things in by hand. And I’ve added cheat buttons to games so that I can skip levels and inflate my scores and avoid having to play the game all the way through so that I can debug the last bits. 

Remember, when you are writing a program you don’t just control what the code does, you also control the environment the code sits in. Bending this to make things easier is something that will pay off tenfold. Can’t debug your program without a network connection? So what. Fake the web request responses so that you can feed the answers back yourself. This also makes test driven development much easier.

Of course, given the choice, you should pick the most appropriate language for the task. Give me an AI problem and I’ll be looking hard at what Prolog (or perhaps F#) can do for me. But for me programming is not about the language, it is about the problem solving, and that means a programmer should be able to turn their hand to whatever the occasion demands. Even if it is JavaScript.

Reader Comments (2)

I agree with the main points raised. Having a nice working environment may be more important than the particular language in use, but I would say that a certain freedom in the choice of language by the developer, if given sufficient latitude by his/her boss, is also key to a pleasant environment. Labouring with clunky old languages, especially for legacy systems where the company is too tight to upgrade, can be soul-destroying as well as de-skilling.
Javascript is a special case because it is code which executes in the user's browser which is probably the main reason why so many security exploits use javascript. Firefox add-ons such as NoScript mitigate this vulnerablilty and return control to the user. Add to that the single-threaded and the 'not fully' object orientated nature of javascript, as well as the differences between browsers and you end up tools such as jquery to simplify it, abstracting out browser differences as far as possible. Jquery is really good, but jquery is also a testament to the lack of standards across browsers. Let's hope with the advent of HTML 5, browser standards will be more convergent.
Lastly, I should just say that notwithstanding the arguments about the choosing the best language for a particular task, one should bear in mind that all languages end up as machine code after compilation. So there is a powerful argument in favour of assembly language since the developer doesn't have to rely on third party libraries or compilers. (Compilers can make mistakes too, albeit rarely). Speed is usually much faster and memory consumption can be controlled more easily to avoid bloat. If anything, these are considerations which would be useful when programming for mobile devices, but most manufacturers require the use of their own SDKs and even prohibit calls to the native API, not to mention anything at a lower level. Of course it takes longer to code in assembler, but coders who use it tend to build up their own libraries of trusted assembler routines that they have written over time, helping to cut down development time. Hope that adds a few ideas into the mix.
March 26, 2012 | Unregistered CommenterBri
Yep OK Agree on the principles ...... but I rather like to be given the choice

If we really have to be forced to write in Javascript/ HTML5 for wider Web reach, then OK thats best for the job. I just love writing in C# as a compiled OO language in Visual Studio. (previously liked java, loved Pascal, sort of got by on Basic and Z80/6800/6809 assembler) For me it doesn't get much better than C#, given the choice I want to concentrate on delivering the Applicaiton to the user, in a robust and reliable way. I simply have confidence in the productivity, robustness and reduced debugging I can acheive with Managed code, over script based code.
March 30, 2012 | Unregistered CommenterJules

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.