Slashdot Mirror


Goodbye, World? 5 Languages That Might Not Be Long For This World

Nerval's Lobster writes As developers embrace new programming languages, older languages can go one of two ways: stay in use, despite fading popularity, or die out completely. So which programming languages are slated for history's dustbin of dead tech? Perl is an excellent candidate, especially considering how work on Perl6, framed as a complete revamp of the language, began work in 2000 and is still inching along in development. Ruby, Visual Basic.NET, and Object Pascal also top this list, despite their onetime popularity. Whether the result of development snafus or the industry simply veering in a direction that makes a particular language increasingly obsolete, time comes for all platforms at one point or another. Which programming languages do you think will do the way of the dinosaurs in coming years? With COBOL still around, it's hard to take too seriously the claim that Perl or Ruby is about to die. A prediction market for this kind of thing might yield a far different list.

29 of 547 comments (clear)

  1. If you wanted us to believe your Op-Ed... by Bill_the_Engineer · · Score: 5, Insightful

    You shouldn't have made Perl and Ruby #1 and #2 respectively. Of course being on dice.com should have been enough.

    On the plus side, I didn't waste much time reading the rest of the BS.

    --
    These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    1. Re:If you wanted us to believe your Op-Ed... by i+kan+reed · · Score: 5, Interesting

      lol
      "Syntax that every programmer uses to make their program readable is unreasonable as a semantically meaningful syntax"

      Come on, python's got its problems, but forcing you to lay out your program in a naturally readable way to compile isn't one of them.

      For example, duck-typing might be one of the worst ideas in the universe, because it's doing the exact opposite of the whitespace thing. It's decoupling easy-to-make mistakes with the output of compiling of your code.

      But this whining about whitespace just comes off as having never actually tried it.

    2. Re:If you wanted us to believe your Op-Ed... by CastrTroy · · Score: 4, Insightful

      Whitespace is great, I use it all the time. I use the IDE to automatically fix the indenting of my code. That doesn't mean the compiler should attach any specific meaning to how things are indented. For one thing, once you let the level of indentation govern the execute, you lose the ability to auto-format your code. You can't autoindent the code based on where the blocks start and end, because the level of indentation defines where the blocks start and end. If you messed up the indentation at some spot, there is little to no indication that something went wrong. It's the same reason I don't like languages that don't require that you define that variables exist. Letting you define variables just by using them leaves you open to spelling mistakes and all the bugs it causes just so you can save a couple lines of code.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    3. Re:If you wanted us to believe your Op-Ed... by Bill_the_Engineer · · Score: 4, Insightful

      I don't like languages that don't require that you define that variables exist.

      If only Python and Ruby offered something similar to Perl's "use strict".

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    4. Re:If you wanted us to believe your Op-Ed... by Anonymous Coward · · Score: 5, Insightful

      It wouldn't be an object-oriented language without duck-typing.

      lol no. An object-oriented language is language in which you can easily write object-oriented code. Object-oriented code does not imply dynamic typing.

      broken code should break immediately and with regularity, rather than hobble along until specific conditions are met.

      Broken code that can break in the compiler should break in the compiler.

    5. Re:If you wanted us to believe your Op-Ed... by phantomfive · · Score: 4, Insightful

      Duck-typing is fundamental to program polymorphism. It wouldn't be an object-oriented language without duck-typing.

      Duck typing becomes a problem when your program becomes big and lots of people are working on it, because it removes compile-time checks. Unless everyone on their project is extremely careful to write readable code, then random bugs will start popping up because it's not checked at compile time. Although I'm sure you personally write excellent, readable code so that's not a problem.

      Also, come on, duck-typing is not necessary for polymorphism, inheritance and defined interfaces work just as well.

      --
      "First they came for the slanderers and i said nothing."
    6. Re:If you wanted us to believe your Op-Ed... by PRMan · · Score: 4, Funny

      Oh PROGRAMMING languages! I was in here looking for German.

      --
      Peter predicted that you would "deliberately forget" creation 2000 years ago...
    7. Re:If you wanted us to believe your Op-Ed... by gstoddart · · Score: 5, Insightful

      Come on, python's got its problems, but forcing you to lay out your program in a naturally readable way to compile isn't one of them.

      So, here's my problem with whitespace being syntactically significant ... everybody likes to see code with different levels of indent. There isn't one "naturally readable" way which everybody agrees on. And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".

      Years ago I had a co-worker. He liked emacs, and I liked vi. OK, whatever, that's not a big deal, I can overlook that.

      The problem was his electric mode in emacs was thinking itself oh-so-clever, and instead of storing the *actual* number of tab indents or whitespace, it just stripped them in favor of a single tab that emacs would then know how to render later.

      Unfortunately, not all editors rendered the same way his beloved emacs did. So after he edited a document, every line showed as a diff, and every file he edited now rendered as gibberish in every other editor, because there was only a single whitespace character.

      He was one of a team, but wouldn't listen when we said his editor was fscking up the code, and making it impossible for us to work on it.

      So, where he wanted to see two character indents, and I wanted to see 8, and a co-worker wanted to see 4 ... once he'd edited it, in anything not using this electric mode didn't work.

      Finally the solution was to lock him out of CVS, and tell him in no uncertain terms it was his problem to make his editor work with our coding standards, and that we didn't give a damn about his pretty little electric mode.

      It took a lot of howling and gnashing of teeth for him to realize that he needed to fix it.

      But this whining about whitespace just comes off as having never actually tried it.

      No, it's a concept which had been ridiculed when COBOL used to insist you put things in specific columns. And as far as I'm aware, even COBOL stopped doing it, because we don't use punch cards any more.

      For any of us who have taken compiler classes, a context free grammar specifically ignores whitespace. That's how compilers have worked for a very long time, if the grammar productions for your language involve counting whitespace ... well, my compilers prof would have failed me. Instead of having a visible thing to define a block, oh, well, just indent a few more chars.

      You can't see what character whitespace actually is ... is that 8 spaces or a tab? Which means when your program suddenly won't compile, or is doing strange things, you have to spend extra effort to figure out WTF specific piece of invisible whitespace is the problem.

      I've thought syntactically significant whitespace was dumb since I first saw it. Specifically because it creates many many places where it can go wrong, and no easy way to find them.

      I've seen someone debug a python program, and even though things were in the same column in the editor, some were tabs and some were spaces, which had the very bizarre effect of making it semantically different than it looked. Because the block wasn't explicit, it was implicit based purely on indenting.

      If you can break a program by changing the tab indent of your editor, the problem lies in the syntax of your language.

      Making whitespace affect your syntax means "I'm too damned lazy to make my blocks explicit, so I'll rely on this cheap hack".

      I've also worked with blind programmers who used code readers (yes, blind, and they were damned fine programmers). You know what whitespace being part of your syntax does to them? Renders them almost unusable.

      --
      Lost at C:>. Found at C.
    8. Re:If you wanted us to believe your Op-Ed... by ShanghaiBill · · Score: 4, Insightful

      If only Python and Ruby offered something similar to Perl's "use strict".

      If only programmers always used code they wrote themselves.

      I put "use strict" at the top of every perl file, javascript file, etc. I also compile C/C++ with "-Wall -Wextra". But that doesn't protect me from libraries and headers written by incompetent slobs.

    9. Re:If you wanted us to believe your Op-Ed... by wrook · · Score: 4, Funny

      OMG! A rant about Emacs vs VI with a sub-rant about indenting with spaces vs tabs!!! And you even throw in a story about locking someone out of CVS (although in my day we used RCS and we were damn happy to have it).

      You know how to make an old man feel young again.

  2. Who cares? by PhilHibbs · · Score: 5, Insightful

    Some people like to make a big deal over languages dying, particularly if the language is one that they never really liked. I say, why make a fuss? Sure, some languages will decrease in popularity, but they're still there to use if you want, and there will always be a die-hard community of fans that keep it alive. Why hold a big whoop-de-doo circus to celebrate the ebb and flow of language popularity?

  3. Adoption by large organizations limits extinction by Terry+Pearson · · Score: 5, Insightful

    Once a language is adopted by a large organization, it is almost impossible for it to go extinct. Just the way that larger companies tend to work, means that the language will exist in some form for decades. If I were to predict a language to go extinct, I would say that it has to be one that has not been widely adopted already, has not made its way to mainstream organizations, and basically reproduces what is already done by another, more popular, language.

  4. Ruby? by Chris+Mattern · · Score: 5, Insightful

    His main complaints about Ruby seem to be that C programmers find it hard to use (because C is at the forefront of innovative computer languages, you know), and that Twitter has stopped using it (oh noes!).

  5. Perl and VBA will live for a long while yet by Beetle+B. · · Score: 4, Informative

    I work in an engineering firm. There's so much legacy Perl out there that there'll be a need for it for at least another decade.

    As for VB, it'll remain as long as Microsoft Office is used in companies. It's way too handy and there's no alternative.

    --
    Beetle B.
    1. Re:Perl and VBA will live for a long while yet by jmac_the_man · · Score: 4, Interesting

      The VB that Office does is VBA, which is essentially VB6. The language that they're predicting will die out is VB.Net, which has a very different syntax.

  6. Perl? by just_another_sean · · Score: 5, Insightful

    Perl 6 might be languishing in academia but in the meantime Perl 5 is chugging along nicely with bug fixes released regularly and CPAN content growing week over week. Not to mention Debian and BSD's heavy use of Perl in the base system.

    They can have my Pathologically Eclectic Rubbish Lister when they pry it from my cold, dead hands!

    --
    Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
  7. Maybe Perl is just "complete," not dying. by Arakageeta · · Score: 4, Informative

    "Perl is an excellent candidate, especially considering how work on Perl6, framed as a complete revamp of the language, began work in 2000 and is still inching along in development."

    This does not imply that Perl is on its way out. I don't use the language myself (I despise it, personally), but I know many who use it on a daily basis. It is still a go-to language for many programmers (albeit, who may no longer be in their 20s) who need to quickly hack together a test harness for a larger system. It could merely be that Perl is "complete" for applications where it is useful. Further revision is no longer necessary.

    Also, I'd hardly say that C++ is on it's way out, even though C++11 took so long to be ratified.

  8. Thinking back to my undergraduate days (late 70's) by 14erCleaner · · Score: 5, Interesting

    Fortran: will live forever
    Cobol: ditto
    PL/1: probably a goner
    Pascal: is that still around?
    LISP: was already for hipsters only by the 80's

    --
    Have you read my blog lately?
  9. Not going to happen by Carewolf · · Score: 4, Insightful

    That is not dead which can eternal lie, in unmaintained hardware burried deep in your organization.

  10. That's not how languages die by gurps_npc · · Score: 4, Insightful
    Languages die when people stop using them, not when they cease to be 'hot'.

    Look at human languages. They die when the last person speaking them dies. What makes anyone think computer languages are different?

    --
    excitingthingstodo.blogspot.com
    1. Re:That's not how languages die by T.E.D. · · Score: 4, Informative
      Well, there are actually multiple levels of human language death.
      1. Extinct - No living speakers.
      2. Dead - Perhaps still known, but no longer used in general conversation
      3. Pseudoextinct - No living speakers, but there are speakers of a child language
      4. Moribund - Speakers are shifting to other languages. Nobody new is learning it.

      IMHO, most supposed "dead" computer languages are in actuality barely even moribund by the above definitions. There are some pseudoextinct languages though. K&R C would probably be a good example.

  11. Let me save you some time by Somebody+Is+Using+My · · Score: 4, Informative

    Here are the dead and dying languages

    1) Perl - because it's a "piecemeal" language with features pile atop one another
    2) Ruby - because its difficult to learn if you know C
    3) Visual Basic.Net - because C#
    4) Adobe Flash & AIR - because iPhone
    5) Delphi Object Pascal - because it isn't well-supported

    Now you don't need to read the article

    1. Re:Let me save you some time by TechyImmigrant · · Score: 4, Informative

      That article was written by a youngster.

      Pilot, PIC, mathchat, hypercard, IPL, SIMULA, etc.

      These are the dying or dead languages.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  12. Re:"Microsoft's long love of BASIC...." by tadas · · Score: 4, Informative

    I'd say that MS's love of BASIC goes back at least a decade before that; they wrote the ROM BASIC for the TRS-80 (as I found when doing a PEEK scan through it).

    Umm.. try 1975, when Harvard dropout Bill Gates and his friend Paul Allen wrote a BASIC interpreter for the Altair, the first microcomputer. http://en.wikipedia.org/wiki/Altair_BASIC/

    --
    This page accidentally left blank
  13. Perl in Latin by Anonymous Coward · · Score: 4, Interesting

    Lingua::Romana::Perligata -- Perl for the XXI-imum Century

    http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html
    Abstract
    This paper describes a Perl module -- Lingua::Romana::Perligata -- that makes it possible to write Perl programs in Latin. A plausible rationale for wanting to do such a thing is provided, along with a comprehensive overview of the syntax and semantics of Latinized Perl. The paper also explains the special source filtering and parsing techniques required to efficiently interpret a programming language in which the syntax is (largely) non-positional.

  14. Re:Adoption by large organizations limits extincti by cant_get_a_good_nick · · Score: 5, Interesting

    I agree to this.

    We have millions of dollars riding on perl scripts. Yeah, we want to move to python, but while we're on perl we're on perl. There's a lot you can do with maintenance and upgrading to better perl with better constructs.

    A language is not like a cellphone. We don't toss perl because the new iPhone is out next week. Perl doesn't fade. There's not a battery that will slowly begin not charging as deeply as time goes on. Perl remains perl. The problem domain doesn't radically shift month by month where we need a new language every month. What we have works.

  15. Re:Thinking back to my undergraduate days (late 70 by Halo1 · · Score: 4, Interesting

    Pascal was/is a much better language than Fortran or Cobol.
    I would be shocked if it completely died out.

    Me too. Especially since I've been contributing for 17 years to the Free Pascal Compiler, and it supports more platforms than ever. I also don't see any particular declines in our download statistics or the bug reporting rate. Whether Borland-Inprise-CodeGear-Embarcadero Delphi will survive, that's another question. If they'd disappear, that would however be unfortunate for us too though, since many of our users use both products (Delphi for its polish and commercial support, ours for the multi-platform support).

    --
    Donate free food here
  16. The article is on dice.com. by QuietLagoon · · Score: 5, Insightful
    The purpose of the article is to make dice.com (/.'s owner) appear to be a place where people can go to read articles about job skills and such.

    .
    The purpose of the article is not to convey any manner of knowledge on the subject.

    It's chewing gum for the job seeker, no more, no less.

  17. Re:Scripting language du jour by steveha · · Score: 5, Insightful

    ...I don't waste my time with Python. There will always be a latest and greatest scripting language to come along and replace the previous one.

    Maybe so, but Python is getting more popular and widely-used rather than dying out.

    IMHO Python hits the sweet spot: it's powerful and expressive, yet the code is readable and maintainable. The worst thing about Python is that it's pretty slow, but it has a vast library of extensions (written in C or even FORTRAN) and the extensions aren't slow. (Like, if you wrote your own FFT in Python it would be glacially slow, but you don't need to write your own FFT because fast ones are available... and if your program is mostly doing FFTs it will be nearly as fast as a C program, because the slow Python glue code isn't where the program spends most of its time.)

    In the world of science, everyone is converging on Python because of SciPy (which rocks). As people get fed up with legacy systems, they adopt Python as the replacement. I attended a keynote lecture at the SciPy conference a few years back, and a senior guy from the Hubble Space Telescope project talked about how they were leaving a language called IDL and switching to Python, and how much happier they were with Python.

    I have heard that the Ruby guys had a project to make a "SciRuby" but (a) progress was slow and (b) the science guys are already using SciPy and won't switch unless some really compelling advantage appears.

    Python is a clean, well-designed language that can have anything you need put in as an extension. So you can replace Matlab with Python and it's mostly a win. You can replace R with Python (and I think it's probably mostly a win, but I'm biased toward Python and have never seriously used R so feel free to ignore my opinion).

    Python can be used by sysadmins, web site developers, cloud app developers, scientific researchers... really almost everyone can do their work in Python, and they can talk to each other about it if they are all using the same language. That's not a trivial benefit.

    So, IMHO you would not be "wasting your time" to try actually using Python.

    --
    lf(1): it's like ls(1) but sorts filenames by extension, tersely