Slashdot Mirror


The Problem Of Developing

A reader writes "ZDNet News is running an editorial about the choice of programming languages for developers today. The author suggests that developers have been left with little choice because all of the current programming languages are essentially the same."

30 of 438 comments (clear)

  1. C# by October_30th · · Score: 4, Funny
    C# is not the same! Neither is .NET.

    They both are brilliant innovations by Microsoft that will carry us all into the wonderful future on the information superhighway!

    --
    The owls are not what they seem
    1. Re:C# by jovlinger · · Score: 4, Insightful

      When you choose a language it shouldn't be for the operational properties of a language. How many people do you think need the speed benefits of C enough to pay the price for using it? About one in a gazzilion.

      The wise programmer chooses a language for it's denotational properties. Such as: how straight forward is it to solve my problem in this language? Does the language provide me with early predicitions as to where the problems with my code are going to be? Does the language have constructs that directly capture the ideas you want to work with?

      So you see, having several languages implemented for one back end, so that I can write my lexing routines in PERL, write my AST construction routines in Java, and my compiler in Scheme, ammounts basically to choosing the right tool for the job.

      How isn't this appealing?

  2. What is he smoking by rootmonkey · · Score: 5, Interesting

    The author obviously is not in the right industry if he thinks developers only will program in VB.NET, C# or Java. I suppose I shouldn't show up to work on monday for the job I got programming C, because once the word gets out I'm *sure* that C will only be found in a museum.

    --

    Yes but every time I try to see it your way, I get a headache.
    1. Re:What is he smoking by Milican · · Score: 5, Insightful

      I know you weren't dogging C/C++, but I would like to take this opportunity to point out that for embedded development on a microcontroller, or development on any non-PC platform C is a God send. Programming for PCs is only a small fraction of the whole pie.. by small I mean out of "100 million or so PCs shipped each year; (there are) 6 billion processors that go into embedded systems " - Jack Ganssle Just check your Palm, cellphone, microwave, car, sound card, video card, stereo, fridge, ac unit, gas pump, coke machine, etc.. if you don't believe me ;)

      The embedded market is enormous and C/C++ aren't going away anytime soon.

      JOhn

    2. Re:What is he smoking by joib · · Score: 4, Funny

      [oldest programming language pissing match]
      You program in C for a living? Well, I recently landed a job involving fortran programming. :)
      [/]
      Conclusion: ZDNet author is a dimwit if he believes every programmer in the world does nothing but shopping carts.
      Or should I do shopping carts with "fortran.NET"? Bwahahaha...

    3. Re:What is he smoking by vanguard · · Score: 4, Interesting

      I've given this a fair amount of thought and this is what I came up with:

      When it's possible (right staff, right project, etc.) IT departments try to avoid C/C++.

      Does that mean C is going away? No. It's also unfair to compare it to COBOL. When performance is important C/C++ is the only choice. However, if you have a chance, interpreted languages really do help with code quality and development time.

      If you're coding for an IT department and you are doing it in C it's *probably* because they have no other choice.

      --
      That which does not kill me only makes me whinier
  3. All developers aren't web developers by Jbrecken · · Score: 5, Insightful

    There may be only two choices for making internet apps, but a lot of development is still going on that uses neither .Net nor J2EE, and will continue to do so for the forseeable future.

    He needed to make it clear that his scope was only web-based development.

    1. Re:All developers aren't web developers by twocents · · Score: 5, Insightful

      and if he was talking about only web based development, then does that not include all of the web scripting languages, such as PHP, Python, Perl, etc, etc, etc.

      Oh why even bother commenting...these stupid little rimshots from ZD are nothing more than attempts to capture the glory days of pitting WP against Word against Ami Pro.

  4. Truth of article depends on who you know by syzxys · · Score: 5, Insightful

    I think this article is basically ZDNet trolling again. After all, the more "controversial" the article, the more hits they get = more ad revenue.

    So today's developers will use one of three languages: Java, C# or VB.Net.

    Strange, a lot of projects I'm familiar with don't use any one of those languages. I think it depends who you talk to.

    I think the author believes in two common fallacies:

    1. C++ has some plus signs after it, so it must be a replacement for C
    2. All problems in systems programming are trivial and have already been solved, and will never need solved again, so there's no need for really low-level languages.

    I'm sure the argument is a lot more valid for big corporations, but they've always been bastions of VB and "4GL's" (even when 4GL was just a marketing term). Basically, /. has been trolled again.

    ---
    Windows 2000/XP stable? safe? secure? 5 lines of simple C code say otherwise!
    1. Re:Truth of article depends on who you know by euphline · · Score: 4, Insightful
      Strange, a lot [apache.org] of projects [kernel.org] I'm [tigris.org] familiar [freebsd.org] with [sourceforge.net] don't use any one of those languages. I think it depends who you talk to.

      Exactly!

      The author is sensationalizing... and forgetting the multitude of languages out there being used for applications. I think if people [people != geeks, people == lusers like this guy] were to really know what the apps they use were made from, they'd *freak*. I'm thinking of the apps I deal with on a daily basis... and the number of languages is tremendous!

      The diversity in languages, runtimes, and platforms is a good thing. It allows us to use the best tool for the job (and there usually is one) and to accomplish our tasks quickly and painlessly.

      -jbn
      (Former VB addict. Now healed and addicted to perl.)

  5. Interesting... but far too short and simple by msuzio · · Score: 5, Insightful

    The short editorial is good in that it points out what I suspect most developers already knew (but the marketers would never admit) -- there basically are very few choices offered in terms of "how to do it". As a matter of fact, I know in my part of the country, 95% of Internet application work being advertised is one of two things: ASP/DCOM apps, or J2EE apps (using IBM Websphere, sometimes WebLogic).
    That's it. No Web job I looked at in my two months of searching for a job recently specified anything else. No Perl. No C++ unless the job also specified ASP and DCOM. Certainly no Zope, Tcl, etc.
    Is this because no one uses any other technologies? No, of course not... but those other approachs lack a strong marketing organization behind them... Programming is as prone to the influence of hype as anything else.

    That is what I think is important to assert; that other choices do exist, and it should be our job as supposed experts to investigate all the options. Diversity is a healthy attribute to have... Let's hope the "hyped" languages never succeed in marginalizing all other approaches.

  6. Funny by ergo98 · · Score: 4, Insightful
    It's funny how C++ (and the subset C) is constantly glossed over as some archaic remnant of the past, yet the overwhelming majority of commercial appliations continue to be developed in C++, and likely will continue to for some time. It's an interesting scenario of Fire and Motion. It always makes me wonder if all of the .NET and Visual Basic fanatics every stop and think "Gosh, how many Microsoft products are built with .NET or Visual Basic?" (they'd be surprized that the number is very close to 0, and will likely remain so). Silver bullet languages give short term bursts of productivity, followed by the reality that the nuances of languages become trivial in the long term of a real project.

    Just intriguing to see. J2EE, .NET, etc., all definitely have a place, but it is interesting seeing how many people hop on the bandwagon without requiring the developing company to prove that they eat their own dogfood.

  7. Fairly Microsoft Centric by scotch · · Score: 5, Insightful
    This is a fairly Microsoft oriented editorial, and a little light on meat at that. Examples: assumptions that C#, .NET, and VB.net do or will by years end account for the bulk of programming langauges, with an "also-ran" entry for Java.

    As far as I know (not far?) C++ and C are still widely used in industry. The editor speaks of C++ significance as something of the past: 5-years ago.

    GUI skins are discussed as a pretty weak analogy of language interfaces to common runtime libraries. Then of course, the editors example of a GUI skin is Windows XP.

    Where I work, C++ is the prime langauge. But then, we're worried about cross-platform development. Maybe that's a thing of the past, too.

    Don't waste too many brain cells on this one.

    --
    XML causes global warming.
  8. Languages by bentini · · Score: 5, Interesting

    Hmm... I'm no expert, but neither, apparently, is this guy.
    A) All languages share a common runtime: Assembly. Just because I can run LISP and C on the same computer/runtime doesn't mean that they're similar. CS is all about abstraction. Of course you can have the same underlying structure, you can have different underlying structures too. That's the beauty of abstraction!
    B) Java and C# are not the logical successors to C/C++. They're more like a smalltalk with a C-syntax and some trade-offs for efficiency. In terms of providing system calls and API's that are cross-platform... Well, even more like smalltalk!!
    C) Remember, C++ started out as a preprocessor for C. Any "C++" code just became C code that was uglier to look at. The difference between procedural and object-oriented isn't that big a deal, other than it's often easier to think in OO and easier to implement a language that's procedural.
    For a more interesting observation about the same problem that comes from Rob Pike (big UNIX guy at Bell Labs, co-wrote the UNIX Programming Environment) go here: Systems Software Research Is Irrelevant. It makes many good points about how cs is more the same than different now as compare to 10, 15 even 20 years ago!

  9. I Disagree by puppetman · · Score: 4, Insightful

    There are still millions of lines of COBOL, FORTRAN. And you can still develop in ADA, LISP, Scheme, etc. Compilers exist.

    Sure - Java, Pythol, C# are pretty similar. But what about Lua? PERL? Or CURL?

    Sounds like a case of the "good ol' days".

  10. He is a jounalist, not a programmer... by rufusdufus · · Score: 5, Insightful

    This guy is saying that programmers only have 3 choices; Java, C# or VB. He backs this up by stating Java is what you learn in school these days.

    Do not buy into his "reasoning". When I was in school, they were teaching Scheme and Lisp--make no mistake, what they teach is school is not what will build the future! The programmers who only learned what the professor told them became tech support and helpdesk. In those days, to be a 'real programmer' you had to know assembler and 'C'. They made the big bucks, and all major operating systems and applications were written in them.

    Today, things haven't really changed that much. Professors are teaching goofy stuff, programmers get a degree but never learned pointers, and the major software is still written in C. The major difference is the success of C++. Yes, there are lots of Java programmers out there, but really fairly few *major* Java programs. The major OS's and applications are still written in C and C++,rather than assembly.

    Of course, in the end, if you learn 'right', what language you use is simply a choice, like a carpenter might use a metal hammer for nails, and a rubber hammer for wooden pegs. The right tool for the job. Today, the jury is out on C# being the right tool for anything, and even Java is still a new fangled gadget that hasn't fully proven itself in the toolbox.

  11. bunch of crap by mrpotato · · Score: 5, Informative
    The article doesn't say anything, and is really aimed at manager-type people.

    Example:
    Look at some of the other languages that have been ported to the CLR. In every case, those languages have had to lose something important that made them different to fit the common dominator offered by the CLR. Microsoft has brought the notion of skins to programming indeed.
    (emphasis mine)

    What a gratuitous (and feeble) claim. The author obviously think that about 3 languages exists: C(and friends), Java and VB.

    Some functionnal languages have been successfully ported to the CLR, and they didn't need to be amputated for that.

    For example, Standard ML and Mercury. Both have been succesfully ported to the CLR without violence to those languages.

    So, in conclusion, I agree that when you know only 3 procedural/OO languages you might be under the impression that all languages look alike.

    Move along, nothing to see here.

    --

    cheers
  12. Question by The+Cat · · Score: 5, Funny

    What's .NET written in?

    oh...

    hmmmm....

    GOODNIGHT EVERYBODY!!!!!!!

    1. Re:Question by sharkey · · Score: 4, Funny

      What's .NET written in?

      Orwellian

      --

      --
      "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
  13. Guess it's all where you work by pongo000 · · Score: 4, Interesting

    That's funny...I've been developing for many years, for a number of very large companies, and I've seen no indication of a mass exodus towards J2EE and .NET. With a large base of C/C++ legacy apps already in place, there's not a chance in hell J2EE and .NET will "rule the world" anytime soon (if at all). I've seen too many "large-scale enterprise solutions" become waterlogged by voluminous requirements birthed from the loins of the J2EE standard, or slowed to a crawl by megadollar application servers that simply can't scale worth a damn.

    Sounds like this guy's just trying to make a name for himself. To me, it simply appears to be a load of FUD, with no basis in fact (like most FUD).

  14. Comment removed by account_deleted · · Score: 5, Interesting

    Comment removed based on user account deletion

  15. Morons. by Hagmonk · · Score: 5, Insightful
    By the end of the year, two platforms--J2EE and .Net--will essentially control the programming languages market.

    Oh my god. Moses handing down tablets from on high? A sweeping statement supported by no figures, no examples. Why will they be dominant? Why will they supplant C/C++?

    I would assume that basically all of the Unix market will remain on C/C++/fortran/cobol. Why? Because J2EE and .Net are buzzwords and Unix people have an uncanny nose for sniffing out this kind of crap. And the Unix market is big enough to ensure that your virtual-machine-of-the-month based language "controlling the programming languages market" is always going to be a dream.

    So today's developers will use one of three languages: Java, C# or VB.Net.

    And everyone will shop online, and bookstores will go out of business. I'm sorry Matt, haven't you heard of MY object orientated virtual machine based runtime enterprise kidney beans based language? It's called Bollocks# and I think you will be finding it dominating the programming language market this year.

    Developers switching from C++ to Java concluded that Java was the natural evolution of C++.

    Java is the natural place that people flee to when they can't cope with memory management and pointers. Java is a beautiful language, and the class library is exceptional. But the layers of indirection added through the JVM will always make it slower, and never a language that will replace C++. Just as C++ will never replace C (in the forseeable future), because C++ has its own levels of indirection and safety which slow it down (RTTI, virtual tables, etc). Different tools for different jobs matey, not "one language to rule them all".

    if one were to look at computer science departments across the country, you'd see that Java has replaced C++.

    Java is easier to learn. Hence you can push out more graduates from Compsci courses with it. Unfortunately, you can't apply those guys to say, kernel programming or embedded systems work because they are clueless w.r.t memory management and the guts of the machine. And when speed is paramount, what is a Java programmer going to do? Turn the hotspot flag on and hope for the best? What if it needs to be *reallly* fast, like "we want operation X under Y instructions on the CPU". You're out of luck. Wrong tool for the wrong job.

    Fuck I'm sick of reading this. Another pundit just jabbering off his ideas with only a market analysis background (a poor one at that), not a technical one. I'm sure heaps of IT managers will be reading his column around the world, nodding their heads sagely.

    I haven't even had a coffee yet.

    --
    Ash OS durbatulk, ash OS gimbatul, ash OS thrakatulk, agh burzum-ishi krimpatul! Uzg-MS-ishi amal fauthut burgulli.
  16. building the future by brlewis · · Score: 5, Insightful

    Given that Perl imitates Lisp and Scheme more closely with each release, that GC made it into the mainstream with Java, and that Python eventually got lexical scoping, maybe you should revisit your idea about whether what they teach in school is what will build the future.

  17. Re:What are YOU smoking by Havokmon · · Score: 5, Insightful
    The author obviously is not in the right industry if he thinks developers only will program in VB.NET, C# or Java.

    Interesting perspective..

    What I got out of the article was:
    Because of CLR, most languages for a common runtime will end up having the same abilities, just different syntaxes.
    So, if you know VB.Net, you'll be as 'powerful' a developer as someone who knows C#. But then your C# is probably watered down also.

    I think he's saying CLR has it's advantages, BUT keep in mind you may be sacraficing a better tool for the current job.

    Kinda like Java.. choose interpreted platform interoperability over compiled speed.

    I saw/remember nothing about "All other languages will die.." What would I do with my REXX knowledge? :)

    --
    "I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
  18. Re:LISP, Scheme, Prolog? by brer_rabbit · · Score: 4, Funny
    Author seemed to not consider

    while you've got excellent pointts, your post should of ended there. The author simply didn't consider much of anything. His boss must of asked him to write an article about that newfound TV/typewriter combo thang.

  19. Turing Completeness and Virtual Machines by Baldrson · · Score: 4, Insightful
    People forget that a machine/language that is Turing Complete can emulate any other machine/language that is Turing Complete.

    The most widely deployed Turing Complete machine/language is a close race beteween Javascript and the Wintel machine code, with Java a distant 3rd. Since there is a problem with reliance on machine code for dynamic installation of software over the network, that leaves Javascript the most obvious candidate in which to write other languages. Most people never thought of Javascript as anything but an afterthought to HTML so they might have their eyes opened a bit to the power of Turing Completeness by seeing the TIBET virtual machine written in about a 100K Javascript embeded in a web site's (gzipped) HTML. It gets away with this by dynamically patching (Perl-config style) Javascript incompatibilities and building out from the set of features thereby supported cross-browser.

    As I've written elsewhere, this isn't the ultimate language by any means -- but it is a critically needed repair to the foundation of the web that can be followed by more advanced VM's later on.

  20. Diversity by gnovos · · Score: 5, Funny

    Replacing a position because some guy back in '83 decided to use the odd-ball programming language : $120k

    Maintaining 17 different operating system at once : $225k

    Answering calls from 200 end users with slightly different desktops : $57k

    Having your entire network, the networks of all your end users, and your entire array of backup systems turned into incomprehensible mush overnight due to an advanced virus that could easily target and replicate in your undiversified computer systems : Priceless

    --
    "Your superior intellect is no match for our puny weapons!"
  21. Re:Programming in the US Military by Amazing+Quantum+Man · · Score: 5, Funny

    Oh, I agree. Ada95 is much better than Ada83.

    --
    Fascism starts when the efficiency of the government becomes more important than the rights of the people.
  22. What about K? by Jayson · · Score: 4, Interesting
    I agree that most language are the same C derived POS. C was different and inventive when it was created. Lisp, APL, Prolog, and Smalltalk were all different when they were created. It seems like as time went on we started narrowing our field of vision and implementing the same languages: C to C++ to Java, what kind of intereting steps are those? At least Smalltalk to Self was a very interesting pushing of the boundries. Today, almost nobody pushes anything, except how similar their langauge is to C and why that it good. Even Python and Perl don't attempt to explore any new concepts, they are happy being a Frankenstein of older languages that people seemed to have forgetten about; name three new features of either language, just try to name one!

    My sole exception to this is a language called K. Yes, it has its roots in APL and has added to the APL model from languages such as Lisp and Scheme, but it has some very interesting new features of its own.

    K is very very very fast to write and the run. It blazes in both categories. There is a full relational database that is written in K, called KDB. It crushed Oracle on the TPC-B and TPC-D benchmarks in both speed and storage size, requiring only a few percent above the dataset size in overhead. It has native clustering and replication that allowed it to run on a 50 cpu Linux cluster loaded with 2.5 billion stock trades and quotes and have simple table scans (such as, select max price from trade) take under a second and multi-dimensional aggregations (such as, 100 first desc select sum size*price by sym from trade) take only 10 seconds. Starting the database cluster took a tenth of a second. It is SQL92 compliant, has an extended ultra-powerful query language called KSQL that makes writing queries very simple, and the stored procedure languages are K and C.

    In bwk's language benchmarks, even though this is not the K strong point, the sum of the execution times were: K at 32 seconds, Perl at 95, Java at 300, and TCL above 1400. The lines of code to implement were: K at 9 lines, awk at 95, Perl at 96, TCL at 105, Scheme at 170, VB at 200, and Java at 350.

    Yes, K can look like line noise, but unlike Perl, you get alot from this. First you get extreme code density and see the entire problem on the screen at once. I came from a Scheme background and Perl hurt my eyes, so I was very skeptical, but after my roommate persuaded me to look at K harder, I realized that this high code density made it very easy debug and write code. It is rumored that KDB is written in 26 files of code, each file consisting of a single screen of code, labeled a to z. Try doing that in any other language. The language is exceptionally regular. It is so logical and consistent that it takes a little getting used to. You never have to remember any baroque language rules. Anything that makes sense, you can do. Also, even though it looks difficult, it is extremely easy to learn because K is directly translatable to English, in fact there is a K program that will do this automatically. For example to split a line by tabs you could write:
    cut:{1_'(&x=*x)_ x:"\t",x}
    And this is read:
    cut gets function, 1 drop each, where x equals first x quantity, cut x. When X gets tab join x.
    It may take a little getting used to, but with a month of K, my roommate and I were able to converse this way when describing K and you could see the picture developing in your head. It was amazing.

    A unique feature of K is what is called the K tree. Unification is a very strong idea in K, so it unifies the idea of object, variables, attributes, namespaces, and dictionaries. A dictionary is a native K type. Each variable lives in a dictionary (somwhat like Python). These dictionaries are joined hierarchically and can be removed and added dynamically. All variables are on the K tree, too, so a new namespace is really just a dictionary on the K tree! This means that you can rearrange the K tree and change what functions get called. This is the most reflective language that I have ever seen (Python, Scheme, and CLisp come in a very close behind). All variables have attributes. All attributes are is a special dictionary attached to the variables (the language is so regular that this is really a namespace with a blank name so to refer to the attributes of a variable you say ns.var..attrib). And, of course, each attribute is just a variable so each of those can have attributes, too.

    This interesting K tree leads to a very elegant GUI. Each variable can have an attribute named c (for class), and this can have certain values like `table, `check, `radio, `button, and others (the backtick ` is how you make a symbol). Lets take radio for an example. Then you would have another attribute o (for option) with possible values:
    r..o:`zero`one`two`three`four
    r:r..o[1]
    r..c:`radio
    `show$`r
    These four lines would create a radio box with five choices, zero through four, and everytime you evaluated r whatever the radio was set to, r would evaluate to. Basically, each variable has a direct on-screen representation (they default to `data) and is directly manipulable.

    K also has the ideas of dependencies and triggers in the language, so if a..d:"1+b" then refering to a will dynamically calculate 1+b, but only when necessary (if you refer to a multiple times but b does not change between those references, a will only be calculated once and stored; K figures out the dependency graph for you). There are also triggers. If b..t:"a:b-1" then whenever b is assigned or modified then a will get the appropriate value. This trigger can be anything, such as a network operation or a gui command.

    The language has some other unique features like an interesting callback oriented interprocess communication system and an on-the-fly optimizing vm.

    Of course since it inherits some background from APL it has bulk operators, called adverbs, that modify functions in every conceivable way (much more powerful than APL or Perl). One of the signs of a good K programmer is one who knows how to do this and doesn't use any loops (KDB, the relational database, is written without any loops).

    From functional languages K inherits higher-level functions and projections. Both which are very standard practices especially when combined with the bulk operators. b f[a;;c;]'d takes the four argument function f, fixes the first and third arguments projecting a function of two arguments, then applies it to each down the list of argument in b and d.

    When you use K you truly are standing on the shoulders of giants. The person who wrote it, Arthur Whitney, has this amazing ability to identify the important pieces of a problem and simplify away the rest. The performance in K and KDB is incredibly; the simplicity and power of the language and the database is incredibly.

    K runs on various flavors of Unix and NT, so people should take an open mind (I didn't have one at first and was very skeptical) and really try the language and try a new style of programming. Your code and thoughts on developing will never be the same.

    -j
  23. The groupthink here is amazing. by Stu+Charlton · · Score: 5, Insightful

    Won't anyone stop and possibly think: maybe this isn't a ZDNet-FUD story, or a clueless journalist, but maybe a practitioner with a point?

    There seems to be a tremendously insular mindset here on Slashdot... Java and .NET have little relevance here, whereas C and C++ maintain their positions as the "true" languages.

    The majority of software developers and software development work gets performed today in large corporations in industries like financial, insurance, manufacturing, utilties, pharmaceuticals, defense, real estate, retail, etc. 90% of this work is effectively about writing something that talks to a database somewhere for operational or decision support (reporting) purposes.

    The culture of these companies is tremendously insular with regards to technological change. Here's a quick'n'dirty view of what tools are used generally out there, all IMHO:

    up until 1998:
    C++ (MFC, COM, UNIX), pick a 4GL (VB, Powerbuilder, Delphi), some Perl, tinkerings with Java, some niche technologies (WebObjects, Smalltalk, Lisp), and mainframe legacy (COBOL, fortran, etc.)

    past 1998:
    more Java, C++/COM going well, C++ UNIX going legacy, VB holding steady, Perl growing, other 4GLs going legacy, niche technologies being replaced with prior mentioned technologies, mainframe legacy being retrofitted for Y2K

    2002:
    Lots of Java, steady amounts of Perl & PHP, VB is legacy, C++ is legacy (COM and UNIX), some niche technologies remain but are targetted to be 'sunsetted', mainframe legacy systems in place but some are looking to be replaced with Java systems. Growing interest in .NET -- lots of training gigs, but very few consulting pilots yet.

    ANSI-C doesn't really enter into the picture. The #1 one criteria for choosing a technology in these businesses (usually) is how easy/quick can it talk to a relational database. Java's past performance problems are largely irrelevant today -- this language is running billions of dollars of transactions a day through thousands of companies. It works, and it's fast enough for most purposes.

    You may not agree with this picture, but it has been my experience as a senior consultant to many different companies throughout the world, and working for a company that is a Microsoft .NET national trainer. I don't think I'm alone in looking at these figures. Let me be very clear: The greatness of open source development is that none of this really matters. If you love a language, use it. The marketshare of a language really has no effect on whether you can use it to write good software, it really only speaks of the probability of getting a job or contract using a particular programming language and working as a custom software developer.

    Remember: my assumption is that the custom software marketplace is very conservative in the technologies it chooses because of the maintainance costs involved. So you see less diversity in using niche technologies unless a group with complex needs (i.e. an OODBMS in Smalltalk, or an expert system in LISP) shells out the extra $$ to get it done. Most systems just aren't written that way. If I'm wrong on this, if Goldman Sachs or Johnson & Johnson or Royal Dutch/Shell are really building most of their next projects spread over hundreds, if not thousands of developers -- all with ANSI-C, then I sit corrected.

    The author of this article is making an important point, though he didn't qualify it properly enough... language diversity is drying up in the custom software development market..

    This year, if you look at "growth", i.e. what languages are being used for new projects, there are only three major players: Java (mainly JSP/Servlet based), VB, and Perl (for backoffice automation), with other scripting languages like PHP and Python and Ruby in Japan doing smaller projects.

    In 2003, there will be more .NET in that equation. The author's prediction of a 50/50 .NET/J2EE split is silly. More realistically, by late 2003, mid-2004 I would suggest:

    50% J2EE
    30% VB, C++, Perl, Python, etc.
    20% .NET.

    Eventually .NET may grow to overtake the other languages, but I wouldn't bet on it until 2004 at best, no matter what the hype. It's a conservative industry, and not even Java, the current adoption rate record holder, was adopted as fast as some think .NET will be.

    The problem that Java introduced, and one that will be compounded is that if .NET catches on, there is a problem that the JVM or the CLR does not have a design that allows for true language innovation. We're stuck at extracting and sharing "design patterns" to patch all the shitholes we find in our languages instead of inventing new langauges to fix these problems.

    Sure, many people in this forum will point to implementations of ML, Haskell, LISP and Smalltalk on .NET. They won't point you to the absolutely horrendous performance problems of porting languages to .NET if they don't walk & talk like C#. This is where the "skinnable language" concept comes from... the CLR shipped with Windows is optimized for statically typed object oriented imperative ALGOL-like languages, C# and VB.NET in particular. You're not going to run Lisp, ML, Haskell, Self, Smalltalk on them with reasonable performance without a) bastardizing the language and b) using the .NET base class libraries & foregoing the libraries that ship with your language (a major hinderence for Common Lisp and Smalltalk, I'd say).

    I have a great interest in programming language innovations.... life isn't getting any simpler, and our programming languages are going to have to start looking more like Ruby, Python, Smalltalk or eventually even Lisp if we're going to be handling the burgeoning complexity that's out there. I get frustrated when BigCo's set the agenda with their marketing pushes and the industry sits still for yet another 5 years... until the next hype wave rolls through. We're going to have more failed projects, more long hours, and more stressed-out/cynical developers because language design isn't keeping pace with the rising complexity of problems we're trying to solve.

    While Java did a lot to bring some innovations like garbage collection to the mainstream in 1996... we should me moving beyond this... unfortunately and .NET is sealing us into another 5 years of the status quo.

    disclaimer: my opinions, not my employer's. take with grain of salt.

    --
    -Stu