Thursday, 17 July 2008

Programming Languages - Pour Quá?

Thought Inevitably, in any discussion on new application development, the subject of using the correct programming language comes up.  Usually this comes in the form of "Use the correct language for the situation. Shortly following the consideration of this sage advice, comes a respectable statement along the lines of "it doesn't really matter what language we use, so lets use the one we are most familiar with". But is that really the best advice? Let's explore that a little.

In my discussions of the development of my personal project I am working on, I was simply not considering the language. For me the choice of Delphi was obvious but I was rightly challenged in that decision. Considering a language is not to be taken lightly, however there are usually good logical thoughts behind using a language the team is familiar with. Usually, the main programming language used by a team can do most things required, and the effort involved in learning a new language and coming to terms with its eccentricities would effect the project timeline and could threaten the delivery. For example, if a development team is to move to a new language there is not just the training involved, but the times when a developer spends a week or more trying to get something working as it should, only to find that those experienced in the language know to do that particular process another way due to some limitation or bug in the tools they are using. We've all been there. Add to that the current development still needing support in the old language.

However, the language used is a big decision. What of the market you are looking towards? Would the market require, for example, a Microsoft approach - i.e., best approach be damned, unless it's all written in Microsoft Visual Basic, we're not interested (shudder). Other thoughts may include any of the following:

Pure marketing heavyweight - Oracle (yes even Oracle Forms, still supported by Oracle, but no further development), and PL/SQL. Selling to large corporates, this approach ticks all the boxes and gets you past the elimination process.

Mature large development environment - J2EE. While I concede that every J2EE development project I have been involved in has been fraught with troubles and ultimately has not produced (although these issues can often be attributed to other factors), this does not limit the effectiveness of Java when managed correctly. Invariably developing a large corporate application in J2EE means dealing with numerous technologies and more than one programming language. I'm certain that others can cite many excellent large scale development projects using J2EE. J2EE however is the "expected" development environment these days and often companies will look for that environment as a mark of maturity in the supplier.

Medium scale development - C# perhaps? This environment is the favourite of those moving from Delphi or Visual Basic and has come to be a relatively well accepted development language well suited to Agile development teams.

Web development - While J2EE arguably dominates this area, Ruby for Rails is increasingly being considered for this environment. It is surprising how Ruby for Rails is still an unknown for many executives involved in technology decisions - aren't they the ones who's job it is to know these things? However the conversion rate to Ruby on Rails shows that it's general acceptance is just a matter of increasingly shortening time.

Small scale, Win32 development - Delphi, Visual Basic, C#, etc. Although it can be effectively argued that the likes of Delphi can easily be used (and I can cite many successful projects) in much larger corporate development projects, the acceptance for this is simply no longer there (shame on Borland).

While I am quite sure that you have your own list, and that you hold strong considerations that may differ from some of my comments, as a Development Manager in charge of a development team that creates corporate applications, the above is the way that I look at the world of languages. I'd love to hear of your experiences and thoughts.

4 comments:

  1. What should be considered is response times required and general architecture. J2EE (and .Net) is strongly frowned on in many large environments here in South Africa and I imagine in many places outside of Europe/USA. That's why Delphi has such a solid following outside USA/Europe.

    ReplyDelete
  2. AnonymousJuly 29, 2008

    Depends on your situation, if you are looking for a reasonable decent corprate level application, J2EE is your best choice.There is nothing better than it in the enterprised field.

    ReplyDelete
  3. I have this dilema.

    We are a Delphi shop by tradition but it gets harder to sell this as a solution building tool to clients, especially those with SQL server shaped stars in their eyes - for them .net and SQL Server go together automatically which was the plan all along.

    Having said that I am very fond of C# for a number of reasons and would love to see a proper Win32 development option for the language, or indeed the same for Java itself. MS had it with Visual J++ but Sun didn't like the Win32 extensions.

    We have multi-tier apps to write and I do this with Delphi but feel that .net and VS have more built in tools to do it. I considered mixing the technologies but feel that would be a debugging nightmare with loads of finger pointing.

    Eventually we will move to either D2007 (which is actually OK with some strange behaviour) or .net for our core apps.

    At the same time when we discuss a "server" based solution - i.e. not win32/Delphi we remember our competitors are all coming unstuck making the switch...

    As for web dev, asp.net is pretty good but unlike PHP, LAMP and Ruby on Rails (which is also very good) it costs oodles of money in licenses.

    ReplyDelete
  4. Chris (Again)August 05, 2008

    Nggaaa - the rest of my comment went - so here goes again. Pilot error my end I think (EeePC small sreen...)

    Although your blog post is titled "Programming Languages" really what you are asking about is "Platforms". Whatever you want to implement the solution's platform really dictates the language.

    .NET - C# really, VB is just as good but C# is sexier without being really better.

    - LAMP - PHP, Ruby definitely.

    - J2EE - Do you have a choice ? I've never bought into the Java cross platform stuff really and I'm still waiting for the killer app that justifies it for the man in the street.

    - Oracle - Same as J2EE really.

    - Cross platform ? Well thats kind of C/C++ (GCC ?) with some kind of library - GTK etc ?

    - Cross Platform 2 - Maybe Mono on windows or Linux/Mac with .NET. There are some apps out there developed using this which work well.

    Cross Platform 3 - Delphi for cross platform - aka Lazarus. In my limited experience this has been a reliable and stable tool for my own projects (vs my Work projects) and works well in Linux and Windows with some compiler switches.

    But the overall cross platform question is - do you want to support all of those differing Linux installations / versions.

    - End user - Windows really, maybe some people using Mac but are those in your target market ? There are a few other tools including some V Basic style tools or some older languages like Visual FoxPro or some of the older libraries like Clipper etc. which link with GCC or Mingw C++.

    The choice is never easy, making it future proof is the hardest issue - will .net get dropped by MS in favour of something else like VB was (really, it was - VB.NET is a veneer over .net IL with some COM wrapping).

    Having spouted off a lot though, I'd be interested to read what was chosen though. Although I suspect I know (I read this blog because of the content..., I came here for the title ;-)

    ReplyDelete

Note: only a member of this blog may post a comment.