back to article Platform clouds: The hot battle for developers' hearts and minds

It has been a decade since Microsoft announced its .NET framework and the Common Language Runtime - where C# and other languages do their frolicking on Windows systems. And thanks to the proliferation of open source programming languages and frameworks, which are the foundations of emerging platform clouds, this could very well …


This topic is closed for new posts.
  1. This post has been deleted by its author

  2. Anonymous Coward
    Anonymous Coward

    Development Tools for the next quarter century...?

    Glanced at the headline and thought *groan* yet another cloudy sales pitch. However, the article was thought provoking. I've been using MS tools forever and made a useful living, but I'm now unclear where to invest time next... I lost interest in .Net. It rarely had appeal. Instead I got stuck coding legacy VBA-Macro-front-ends and C / VB back-ends for years. In short, the time / cost benefit for updating apps to C# / VB.Net wasn't clear to me or the traders I worked for, and Java meantime had let people down with its sluggish UI & lengthy development times. C++ was pure gold for the quant libraries, but it wasn't the right tool for rapid prototyping. Any takers on what's a good learning investment for the next decade...?

    1. Destroy All Monsters Silver badge

      Re: Development Tools for the next quarter century...?

      Scala. And LISP or Scheme or Clojure. LISP is always good.

    2. Anonymous Coward
      Anonymous Coward

      Re: Development Tools for the next quarter century...?


    3. HmmmYes

      Re: Development Tools for the next quarter century...?

      Horses for courses. There is no easy decision for a target platform esp. when you are dealing with a very unusual environment - the city is one of the places that is willing to throw money at short-lived, proprietary software. MS is no longer the 'easy-money bet'

      I've taken the safe option: standard (not MS), C++11 + python to get the mix of slow to develop, fast to run (C++) with fast to develop, slow to run (python). And Boost C++.

      GUI-wise its less clear cut. I'm targeting a mix of HTML/webserver (for forms and client/server) and QT4 for singing + dancing, point-click graphics stuff.

    4. Anonymous Coward
      Anonymous Coward

      Re: Development Tools for the next quarter century...?

      Thanks for sharing your thoughts.

  3. amarsys

    Open source lock-in

    I am struggling to see how open source somehow prevents lock-in as the article tries to imply. If your core business application is developed with, say, PHP and MySQL, and you have built it up over the last 5 years, you are locked in, just as surely as if you had used .Net and MSSQL.

    I've used .Net since it came out. I got into it because PHP did not have any XML/XSL support at the time. My only concern over the years has been the ridiculous cost of MSSQL licences - I keep reading the MySQL migration guide in the hope that it will have caught up and I can switch over. The point is, it is about the functionality and productivity, not whether a tool or application is open source.

    1. 1Rafayal

      Re: Open source lock-in

      If you are locked in just because your design is so complex it makes moving to something new, you are in a whole world of hurt. Moving from one DB provider to another is not a trivial matter, but at the same time it shouldnt be impossible to move from one provider to another.

      I have been in situations where the architecture of a product or service was overly complex, making any sort of migration tricky. The idea is to design your software so that the relevant sections can be vertically migrated with as little fuss as possible, however in saying that, it is never that easy.

      This means that you might need to complete a load of work prior to getting into the point where you can migrate, which is better off for you in the long run, provided you can allocate that much resource to start with.

      Oh, please treat the above as a generic "you", I am not implying that your software is in this state. Its just that I have seen situations like this before and this is how I worked the knot out for myself.

      Agree with you on the MSSQL licensing model, it is ridiculous and makes it hard for anyone without the relevant clout in the company wallet to move and expand. The Oracle licensing model is better imho, well perhaps more easier to work with than better.

      1. Anonymous Coward
        Anonymous Coward

        Re: Open source lock-in

        Respectfully disagree

        "f you are locked in just because your design is so complex it makes moving to something new,"

        In my experience, given a complex enough application, you'll end up inevitably locked in to some product, platform or technology. Simply because at some point it becomes advantageous to use whatever features are implemented in your product or platform of choice rather than roll yourself your own. Emulating these to avoid lock in means introducing another abstraction layer, creating by yourself something that is already there.

        "This means that you might need to complete a load of work prior to getting into the point where you can migrate, which is better off for you in the long run, provided you can allocate that much resource to start with."

        Exactly, related to the point above, management does not want to spend a lot of money on something just to prevent some kind of uncertain future lock in that does not provide any immediate benefits. This is why COBOL/RPG/FORTRAN .... will never die. It makes sense to keep using the old platform and pay the lock in tax as long as it is less than the cost of that lot of work. Which almost always is.

        "Agree with you on the MSSQL licensing model, it is ridiculous and makes it hard for anyone without the relevant clout in the company wallet to move and expand. The Oracle licensing model is better imho, well perhaps more easier to work with than better."

        Care to explain? I have had the privilege of looking at both brands and both of them are equally difficult to understand and apply.

        The point of using open source is not avoiding lock in. Using open source merely shifts the lock in from a closed product to an open source one. The key difference is that with the closed product you're at the mercy of the product manufacturer: their product roadmap, lifecycle and even financial troubles become yours, and none of that has to do anything with how well the product works for you. With the open source product you have at least a choice of when and how to move forward, because having the source gives you:

        - Ability to maintain the product yourself, or find an expert in the matter that can do it for you.

        - The opportunity to fork and change the product to suit your needs, assuming of course that you are willing to keep the fork up to date.

        Lock in is unavoidable. Using FOSS gives you more choices than using a closed product. This is purely a pragmatic view, of course arguments about freedom, sharing, etc, are not going to get very far in a business context, even if they are quite real and perhaps a good enough reason to use open source.

        1. 1Rafayal

          Re: Open source lock-in

          Ah, can explain the license bit for Oracle and MS, I spent the last week going over the licensing terms for Oracle.... So you can pretty much ignore me on that one.

          I kind of agree with you about the freedom that an open source product gives you over a propriety one, having the source available does indeed present you with the opportunity to get out of a dead end, something that an MS product will probably never do. But, this assumes your company has the desire and/or appetite to go down that route.

          Take Puppet, for instance. Its a fantastic open source tool, one that I use on a daily basis where I am now and in previous places. However, if it were not for Puppet Enterprise, my company would never have chosen to use this software. Why? Because they wanted to pay money to get them in and set up our POC, dev, test and production systems. My company is pretty big (global), but they didnt want to go and contract a bunch of Puppet consultants in when they could buy in everything they need from the get go. Now, we are beholden to Puppet Enterprise - which is no way a bad thing.

          Thats just one example from me with my current place of work. We have no intention of ever ploughing the knowledge we have gained back into Puppet. The tools and processes we have developed will stay with us as our own property. We have come up with (not me) a number of cool things that could help out a number of other Enterprises but this will never get beyond our NDA.

          So, I completely agree that open source software is good, and yes it does have a load of positives that put it above closed source apps - but does open source really benefit at the end of the day?

          I guess the point I am labouring is this, the open source community is excellent, it should never be disregarded and is an essential source of software and tools for IT in general. But is it fair that the development carried out internally by private enterprise is never shared with anyone else? Puppet has an Apache license, which means that it is defined as "Free Software", I think this means that if I choose to make changes to the source, I dont need to distribute it to anyone if I dont want to.

          I suppose the flipside is also true.

          This is just my opinion, I am not a staunch advocate for either side, instead I am someone who appreciates what is on offer etc. But I can completely agree why big business may choose not to use open source software, they simply dont relish the thought of having to make any changes they have developed themselves available to the public.

          I think you can take away the "Open Source" from the "Lock In", that would be a far more valid statement?

          1. Anonymous Coward
            Anonymous Coward

            Re: Open source lock-in

            The obligation to make changes available to the public depend on the license you use, not all open source licenses are equal. If I understand correctly, the GPL only requires you to do that when/if these changes are part of something you distribute outside your organization.

            I think that the main problem here is the different customer perception of closed vs. open source vendors.

            While closed source vendors see source code as an asset that is being sold, for the open source vendor source code is the underlying foundation of their service business. True, big closed source vendors (MS, Oracle, etc) want also a slice of the "services" pie that comes when they sell their closed source code, which is often bigger than the revenue from licensing the product.

            But from the business (customer) point of view, going with a closed source vendor provides the illusion that they are going to get a better end result than with the open source variant, simply because they are paying separately for the product itself, the support fees and the implementation fees. With an open source offering, they are paying only the cost of deploying and customizing the product. I think that this is what drives them to the closed source option, rather than the fear of having to go public with their changes.

            My use of "lock in" was not meant to be pejorative. Lock in is something that happens when your system depends on some features of a product not available anywhere else. It can be because you're using proprietary SQL extensions, JVM optimizations or whatever else that cannot be replaced without extensive rewrites of the remaining code. It can also be because the vendor deliberately hides APIs or does not document file formats with the sole intention of making their products harder to replace. So there is good lock in (when it is your choice) and bad lock in (when it is someone else)

            1. amarsys

              Re: Open source lock-in

              It makes no difference if you have spent 5 years building a mission-critical system using open source tools such as PHP, or closed source tools such as .Net. You are still locked-in to that platform, and it will be a major cost to migrate to another platform (regardless of whether it is open source or closed source).

              Similarly if you need an ecommerce package you could purchase an open source or closed source package, but after you have spent time and money on training your staff, adding your products, and processing orders - you will be locked-in.

              The converse of this is of course that there is no particular advantage to open source vs closed source - open source is simply a good marketing term. The only decision that matters is choosing the platform or package that provides the best fit and best value for your requirements.

  4. 1Rafayal
    Thumb Up

    +1 from me

  5. Anonymous Coward
    Thumb Up

    +1 All

    A very nice adjunct to the article by all. Thank you.

  6. Michael Wojcik Silver badge

    New languages and frameworks?

    New languages such as Ruby, Node.js, and Scala were created with specific frameworks, but programmers do not code in only one language

    Node.js is not a "new language". It's ECMAScript (also incorrectly but commonly called "JavaScript" or "Javascript"[1]), packaged with an engine and a server-side framework.

    Scala is a "new" language, in the sense used by the article, but it compiles to JVM bytecode or CIL, and so uses the Java or .NET framework. Scala is completely interoperable with all of the many languages that also compile to one of those two intermediate languages.

    [1] The ECMAScript family lineage begins with Eich's LiveScript, a language in the Self family of prototype-inheritance OO languages. Netscape renamed it JavaScript to jump on the Java bandwagon, thus causing great and lasting confusion among those who didn't understand the difference, and irritation among those who did. That eventually evolved into an ECMA-standardized language named ECMAScript. JavaScript remains the name of's implementation of ECMAScript. Node.js uses a Google implementation, and thus is not JavaScript.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2022