Slashdot Mirror


Unpopular Programming Languages That Are Still Lucrative

Nerval's Lobster writes In theory, learning less-popular programming languages could end up paying off big—provided the programmers who pursue them play their proverbial cards right. And as with any good card game, there's a considerable element of chance involved: In order to land a great job, you need to become an expert in a language, which involves a considerable amount of work with no guarantee of a payoff. With that in mind, do you think it's worth learning R, Scala, Haskell, Clojure, or even COBOL (the lattermost is still in use among companies with decades-old infrastructure, and they reportedly have trouble filling jobs that rely on it)? Or is it better to devote your precious hours and memory to popular, much-used languages that have a lot of use out there?

274 of 387 comments (clear)

  1. COBOL by NotDrWho · · Score: 2

    My college still teaches COBOL, requiring two semesters of it. But I'm not sure if this is because they illegitimately believe it's still useful or just because of old habit (and to keep the guy teaching it employed).

    --
    SJW's don't eliminate discrimination. They just expropriate it for themselves.
    1. Re:COBOL by HornWumpus · · Score: 4, Interesting

      When I asked why they still taught the CS students COBOL 20+ years ago the explanation was 'it's a weed out, you have to really love computers to put up with COBOL'.

      They didn't make EEs/CompEs take it. Thank dog. I had taken a semester at a Jr College at 15, thinking it might get me respect and a job from the big iron idiots of the day.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    2. Re:COBOL by attemptedgoalie · · Score: 5, Interesting

      For what it's worth:

      I work in the power industry. We are upgrading to the very latest version of the application we need to operate our power plants.

      It is COBOL throughout.

      The vendor is taking away access to the source code soon, as the version that replaces this one will be Java. By Java, they mean all the COBOL code wrapped in Java.

      So, a major application for use in the power industry will be COBOL until at least 2030.

      Our COBOL devs make nearly six figures. And after our salary review is done, will get some serious raises.

      They're all in their late 40s-50s. We have no COBOL people in the pipeline.

      --
      My mom says I'm cool.
    3. Re:COBOL by Anonymous Coward · · Score: 2, Interesting

      Right, but would they hire someone who didn't know what a COBOL was 4 years ago?

      It seems to me that the people looking for COBOL programmers are looking for experience. This image of taking a COBOL class or two then going out to make a fortune has been fed to me since I was in school, but I've yet to see it actually happen. I do hear plenty of stories of people who stayed with COBOL and are now doing very well, but no success stories of people jumping into it at this late point in the game.

    4. Re:COBOL by Noah+Haders · · Score: 2

      I learned the one, what's it called? it has the little turtle that moves around in straight lines? Is that one still in use?

    5. Re:COBOL by HornWumpus · · Score: 1

      Operations? In COBOL?

      Are you sure you aren't talking about a bean counting function? A database backend?

      Operations? COBOL? Doesn't make sense.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    6. Re:COBOL by Anonymous Coward · · Score: 1

      Was LOGO ever used outside education?

    7. Re:COBOL by Jeremi · · Score: 5, Funny

      I learned the one, what's it called? it has the little turtle that moves around in straight lines? Is that one still in use?

      Ah, you're thinking of LOGO. It isn't widely used anymore, except as a niche language for cruise missile guidance systems.

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
    8. Re:COBOL by gstoddart · · Score: 2

      I don't think LOGO was ever actually used for anything but teaching programming.

      I think I learned it when I was around 10 or so (yes, that was back in dickety doo) ... it was good for teaching concepts, but I would be surprised if there's anything doing any real work at companies using it (or if there ever was).

      Though, I'm sure someone will tell me how utterly wrong I am, and that something like the air traffic systems still runs on it. ;-)

      I haven't thought of that language in years. Thanks for that. :-P

      --
      Lost at C:>. Found at C.
    9. Re:COBOL by HornWumpus · · Score: 1

      All four year CS degrees are 'MIS degrees' so to speak. Just as with all the sciences, a four year degree qualifies you to be a tech, not a 'scientist'.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    10. Re:COBOL by jythie · · Score: 3, Insightful

      Often languages are chosen because of who they have on hand rather then what is ideal, so if you have a bunch of COBOL programmers from another project you use COBOL, if you have a bunch of Java programmers you use Java. Sense is usually irrelevant.

    11. Re:COBOL by johnlcallaway · · Score: 2

      I did COBOL for 15 years. It's not difficult to learn if someone already knows another language. It only takes about 6 months to become proficient in it, maybe a year or two to become an expert for someone who is good.. Many shops are maintaining old code for the most part, so no one has to design something new. Even if they do, there are probably tons of examples.

      We still use COBOL at the company I work at on the IBM systems. Who would I pick given the choice between a COBOL programmer with 20 years experience and a Java programmer that just learned it?? It would depend on what I wanted them to do, what the work split was, and what the salary requirements were. I might be more interested in their experience working on code other people wrote than their programming skills in a specific language ... I don't think I would want somebody who has only worked on new projects to suddenly jump in and work on a 20 year old system, no matter what their experience level.

      Given the choice between a Java programmer and a Java programmer with COBOL knowledge, I would choose the COBOL guy, all things being equal. He will be more flexible and deserve a larger paycheck.

      Our COBOL programmer works remotely and rarely has to come into the office.

      However ... anyone that does this needs to keep current. It's very easy to fall into the rut of doing your job and then losing other skills. I know plenty of COBOL programmers who felt their jobs were safe and never made the transition out of the mainframe world, and are now not programmers anymore. Anyone who doesn't know two or three languages and can't work in a couple of different OSs is a fool.

      --
      I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
    12. Re:COBOL by lasermike026 · · Score: 3, Insightful

      COBOL is great and prolific programming language. COBOL programms will be running long after we are dead. I almost wish I saw more COBOL on Linux. Designed by Grace Hopper she made it so average people with limited CS knowledge could get work done. It's about a sexy as Mom's minivan but it brings the groceries home.

    13. Re:COBOL by Bigby · · Score: 1

      I am CS and no languages were required. CS is about theory which goes into types of languages. Schools that teach CS by teaching a language are teaching tech, not science. But not all CS are tech.

    14. Re:COBOL by jittles · · Score: 1

      For what it's worth:

      I work in the power industry. We are upgrading to the very latest version of the application we need to operate our power plants.

      It is COBOL throughout.

      The vendor is taking away access to the source code soon, as the version that replaces this one will be Java. By Java, they mean all the COBOL code wrapped in Java.

      So, a major application for use in the power industry will be COBOL until at least 2030.

      Our COBOL devs make nearly six figures. And after our salary review is done, will get some serious raises.

      They're all in their late 40s-50s. We have no COBOL people in the pipeline.

      Nearly six figures, or nearly seven? I know a place in my current locale that pays about $300,000 to experienced COBOL guys, with a history in the financial market. And let me tell you, you can live like a king around here for even $100,000.

    15. Re:COBOL by geekoid · · Score: 2

      I wonder why they didn't just move to COBOL.net.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    16. Re:COBOL by NJRoadfan · · Score: 1

      LOGO is a dialect of LISP, something that is (was?) widely used.

    17. Re:COBOL by rubycodez · · Score: 3, Interesting

      I've worked at a three places that did MicroFocus COBOL on Linux, huge in insurance world

      if you just want to play, 'sudo apt-get open-cobol' on your debian or ubuntu or mint box http://sourceforge.net/project...

    18. Re:COBOL by HornWumpus · · Score: 2

      So what? Chemistry students don't take 'lab technique' classes. Yet with a BS all they are qualified for is lab technician. Just like a BS is CS qualifies you to be an entry level programmer or computer tech.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    19. Re:COBOL by HornWumpus · · Score: 1

      Right. And power companies are full of FORTRAN programmers on the engineering side and COBOL programmers on the bean counter side.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    20. Re:COBOL by nctritech · · Score: 1

      It's useless to learn COBOL or any other old language for job purposes because you have to have YEARS OF EXPERIENCE to get the jobs in the first place, plus experience with other non-COBOL things. Here's an excerpt from a current dice.com COBOL job:

      Essential Skills:
      - 6+ years COBOL, JCL, CICS, DB2, and SQL experience
      - 6+ years Syncsort experience
      - Excellent communication skills

      Let me know when COBOL classes start teaching JCL, CICS, and DB2.

    21. Re:COBOL by ranton · · Score: 1

      To be fair, the parent poster could be working in rural Arkansas or somewhere similar where $90k/yr is considered a high salary for experienced developers.

      --
      -- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
    22. Re:COBOL by gbjbaanb · · Score: 3, Insightful

      That is what I love about COBOL - that the people who do it are doing it as a job, rather than a hobby where they get to play with new toys.

      If you want to see what the future of programming looks like, as a professional industry, COBOL shops are the leader. I bet none of your guys has thrown a tantrum because he was asked to put some comments in his code, or had week-long arguments about implementing unit tests for every component.

    23. Re:COBOL by gbjbaanb · · Score: 1

      Somewhere near you, usually funded by IBM.

      See the computerworld article.

      But some colleges are still providing Cobol training -- with help from IBM. The mainframe vendor has developed curricula in association with more than 80 colleges and universities ranging from Brigham Young to Texas A&M.

      "We donate hardware and software, help with the curriculum, and they graduate hundreds of people every year," says Kevin Stoodley, an IBM fellow and CTO.

      and this:

      "They take kids from disadvantaged neighborhoods and provide them as consultants,"

      "I is like your consultant, innit".

    24. Re:COBOL by HornWumpus · · Score: 1

      Depends on where you go to school.

      Many/most CS programs aren't anywhere close to engineering in rigor.

      There are three grades of CS, depending on which school it is taught out of.

      Best is CS taught out of engineering.

      Middle is CS taught out of A&S/math (or spun off from it). (This is the most sciency/least practical version).

      Worst is CS taught out of the business school (spit).

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    25. Re:COBOL by __aaclcg7560 · · Score: 1

      Besides Big Trak in the early 1980's, not really.

    26. Re:COBOL by Critical+Facilities · · Score: 2

      Hang on a second. You're telling me that your Building Automation System or SCADA system is written in COBOL? I've been working in Critical Facilities Management for about 14 years, and I haven't come across that yet, and I find it fascinating. Would you be kind enough to share which system(s) you're using? I'd be interested to learn, as some of my facilities are definitely older, and while I am not aware of any of the code bases being written in COBOL, it is something I'd love to find out more about.

      Now, with that said, even the bigger, more well-known BAS's are generally still proprietary (Siemens, Honeywell, Liebert, Eaton, etc), so there is usually still a dependence on a dedicated team or vendor to update and maintain the systems, so I don't know that your system being written in COBOL (and thus needing dedicated people to maintain it) actually puts you at any sort of disadvantage when you think about it. Plus, there are some very serious banking and insurance actuary applications that are running on COBOL code form the 70's that's still going strong, so it's not absolutely crazy that it might be in place in your facility because it just "works".

    27. Re:COBOL by plopez · · Score: 1

      TO expand on johnlcallaway's post, it takes longer to learn the problem domain for COBOL than it does to learn the language. My experience with COBOL was a few months for the language, a few more months for the IDMS database system and mainframe OS, and a year or more for the problem domain. This was sue to the code having years of business information embedded in it. You essentially have to understand all the nuances of the business to understand what the code does and why.

      --
      putting the 'B' in LGBTQ+
    28. Re:COBOL by angel'o'sphere · · Score: 1

      LOGO has mothing to do with Lisp.
      It is a structured imperative programming language, a little bit like Pascal and a few bits of SmallTalk included:

      to spiral :size
            if :size > 30 [stop] ; a condition stop
            fd :size rt 15 ; many lines of action
            spiral :size *1.02 ; the tailend recursive call
      end

      A piece of code from wikipedia that draws a spiral, unfortunately they use fd and rt instead of the more legible 'forward' and 'turn right' commands.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    29. Re:COBOL by angel'o'sphere · · Score: 1

      Care to explain, why it does not make sense?

      COBOL is a general purpose programming language, like C or any other.

      In 1999 I helped migrating all old COBOL code, reimplementing it actually for one of the biggest steal companies in the world to Java. They used decade old mainframes and midrange computers to control steal plants and send messages about production progress. The 'organization' software is now in Java, communications is now done in Java, on top of the i2 supply chain management solution and Oracle as a database.

      The plants are still controlled with the 50 years old COBOL software. And why change a running team?

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    30. Re:COBOL by angel'o'sphere · · Score: 1

      Because COBOL.NET (does it actually exist?) does not run on an IBM mainframe, or Amdahl supercomputer or a Tamdem Computer.

      So the question behind your question is: why don't they upgrade to modern hardware?

      No idea ...

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    31. Re:COBOL by Dragonslicer · · Score: 4, Funny

      Reminds me of a good joke:

      In 2010, a COBOL programmer developed a rare fatal disease for which there was no known cure. The programmer was cryogenically frozen, to be revived when a cure had been found.

      In the year 9999, the programmer is revived. When he wakes up, he asks the doctors what year it is, and when they tell him, he asks if they finally found a cure for his disease. They answered, "We're sorry, but no, we still haven't found a cure. But it's almost the year 10,000, you see, and you know COBOL..."

    32. Re:COBOL by Darinbob · · Score: 1

      Cs is more than just theory, it is a very broad based curriculum covering computing. Yes there are a broad set of theories that overlap with mathematics and science and engineering fields. But just as CS is not only programing languages, neither is it only one type of theory (most people think the theory is just algorithms and computability). Electrical engineering and chip design are very much a part of CS, as are programming languages, compilation, operating system, networks (and theory of), set theory, algorithms, yada yada.

    33. Re:COBOL by Darinbob · · Score: 1

      Hmm, when I was in school, in the 80s, it was associated with math and engineering departments (part of EE originally but with professors from math), and required calculus and physics and one EE class, even for the BA in CS deg. More requirements for the BS in CS degree.

      The problem is that CS is not just engineering and not just math. It is a cross disciplinary curriculum. Which is why it's hard to pigeonhole it like the corporate employers want to do.

    34. Re:COBOL by HornWumpus · · Score: 1

      It's a cross disciplinary curriculum, just like all forms of Engineering. Granting it's a really, really immature Engineering discipline.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    35. Re:COBOL by HornWumpus · · Score: 1

      COBOL is optimized to do string processing and fixed point math. Early business applications.

      I've been all over the world, working on power dispatch floors. Never seen a bit of COBOL on the operations side of things (SCADA, AGC etc). Perhaps there was a little lurking in the data center. The costs of PLCs are low enough that replacing direct mainframe links at the generator have been no-brainers literally for decades.

      There are _very_ few 50 year old power plants still running. Basically hydro. Even there the automation isn't 50 years old and the handle and head have both been replaced multiple times, so to speak.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    36. Re:COBOL by fahrbot-bot · · Score: 1

      My college still teaches COBOL, requiring two semesters of it. But I'm not sure if this is because they illegitimately believe it's still useful or just because of old habit (and to keep the guy teaching it employed).

      It's probably because your college still uses COBOL and wants to ensure they can still hire inexpensive grads to support them :-)

      --
      It must have been something you assimilated. . . .
    37. Re:COBOL by khellendros1984 · · Score: 1

      That salary sounds low, depending on living expenses for your area. For that level of experience and that specialization of knowledge, I'd expect the number to be well into 6 figures, if they were working here.

      --
      It is pitch black. You are likely to be eaten by a grue.
    38. Re:COBOL by Joe_NoOne · · Score: 1

      Even more modern applications like Banner which is a Higher Ed. ERP system use COBOL...

    39. Re:COBOL by wiredlogic · · Score: 1

      Ask them to implement a DSP algorithm in COBOL. I'm sure you'll get some tantrums from that.

      --
      I am becoming gerund, destroyer of verbs.
    40. Re:COBOL by CaffeinieBaby · · Score: 1

      I am the proud recipient of an F in Cobol. I was taking assembler, graphics, and physics, and just couldn’t feature wasting my time on that (required) class. At that time made you use punchcards for your first assignment, ostensibly to show you how lucky you were that we now had terminals. Two years later when I *really* needed to graduate, I spent a total of about 8 hours re-taking it (+ sleeping through the lectures); no punchcards required. Got an A, and haven't touched it since.

    41. Re:COBOL by bws111 · · Score: 1

      Are you seriously trying to claim an IBM mainframe is not a 'modern computer'? What possible definition of 'modern' are you using?

    42. Re:COBOL by mjvvjm · · Score: 1

      First sentence of the second paragraph of the Wikipedia Article at
      LOGO

      "Logo is a multi-paradigm adaptation and dialect of Lisp, ..."

    43. Re:COBOL by angel'o'sphere · · Score: 1

      Racks of x86s ofc ...
      That is the only thing modern developers know about ;)

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    44. Re:COBOL by angel'o'sphere · · Score: 2

      I don't care what the first sentence in wikipedia is.
      It is wrong.

      Would be a no brainer if you looked at a small piece of Logo and a small piece of Lisp. Check the german Logo page on Wikipedia e.g they have a Logo and Lisp example side by side. You clearly see both langugaes have nothing at all in common.

      See here: headline Logo&Lisp
      http://de.wikipedia.org/wiki/L...

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    45. Re:COBOL by snkline · · Score: 1

      My uncle worked for a business (can't remember what it was) that used Logo, that was his job, to write Logo programs for the company.

    46. Re:COBOL by Half-pint+HAL · · Score: 5, Funny

      Ah, you're thinking of LOGO. It isn't widely used anymore, except as a niche language for cruise missile guidance systems.

      [Image of panicking missile controllers attempting to abort an erroneous launch by frantically typing PEN UP repeatedly.]

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
    47. Re:COBOL by LoRdTAW · · Score: 1
    48. Re:COBOL by baegucb · · Score: 1

      COBOL is easy imho. Assembler on mainframes or PCs is fun. But I have an easy job, close to retirement, so I really don't care if there's a shortage. Funny enough to watch organizations spending hundreds of millions to replace existing systems, rather than training in-house for skills lacking. Really, know how to program in a few languages? Picking up a new, well, old an one, is easy.

    49. Re:COBOL by wallner · · Score: 1

      Well, the paragraph under your cited wikipedia headline explains that Logo is influenced by Lisp and puts the two pieces of code side by side to illustrate that influence.

    50. Re:COBOL by frank_adrian314159 · · Score: 1

      I guess I'm not much of a modern programmer. Although PL\I, FORTRAN, and BAL were the languages I used. And JCL... don't forget that... I also wrote a couple of RPG programs, but that was on an AS/400. Fun times.

      --
      That is all.
    51. Re:COBOL by Smallpond · · Score: 1

      Every language is influenced by Lisp.

    52. Re:COBOL by Kalium70 · · Score: 1

      But techs are exactly what companies are looking for. The main reason that they even look for people with computer science degrees is that there aren't many schools that have a degree titled "computer programming."

    53. Re:COBOL by gbjbaanb · · Score: 1

      I doubt it, you'll get told that it isn't the right tool for that job and that they need a library to call.

      Not much difference is using Ruby on Rails or similar language.

    54. Re:COBOL by Alioth · · Score: 1

      The first two are easy... but the last one? Yikes!

    55. Re:COBOL by Fallso · · Score: 1

      For what it's worth:

      I work in the power industry. We are upgrading to the very latest version of the application we need to operate our power plants.

      It is COBOL throughout.

      The vendor is taking away access to the source code soon, as the version that replaces this one will be Java. By Java, they mean all the COBOL code wrapped in Java.

      So, a major application for use in the power industry will be COBOL until at least 2030.

      Our COBOL devs make nearly six figures. And after our salary review is done, will get some serious raises.

      They're all in their late 40s-50s. We have no COBOL people in the pipeline.

      Nearly six figures, or nearly seven? I know a place in my current locale that pays about $300,000 to experienced COBOL guys, with a history in the financial market. And let me tell you, you can live like a king around here for even $100,000.

      You're assuming he's talking in dollars, whereas in GBP or EUR that's a very decent salary.

    56. Re:COBOL by angel'o'sphere · · Score: 1

      Yes and no, manipulation of Lists is influenced by LISP.

      And you clearly see: the Lisp code on the left side has nothing in common with the Logo code on the right side, except names of variables.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    57. Re:COBOL by angel'o'sphere · · Score: 1

      What has your link about financial crisis to do with steal companies using COBOL for running plants?

      What point do you want to make?

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    58. Re:COBOL by david_thornley · · Score: 1

      Requiring two semesters of it for which degree? If it's MIS, fine. If it's Computer Science, you've been ripped off. There's very little you'll learn with COBOL that you won't learn much faster with more modern languages. If they're looking for a weeder, Scheme does pretty well, and learning Scheme is actually useful in introducing a different programming paradigm.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    59. Re:COBOL by david_thornley · · Score: 1

      Lots of things have been influenced by Lisp. Through the Twentieth Century, improvements in language design were largely a matter of applying Lisp features to languages with actual syntax.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    60. Re:COBOL by david_thornley · · Score: 1

      There's a big difference between being MIS and CS, even at the four-year degree level. (Like most fields, the Ph.D. is the scientific degree.) Or, at least, there should be.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    61. Re:COBOL by david_thornley · · Score: 1

      I think the big problem with COBOL is that it tends to be IBM, which means they want several other ancient technologies along with it. I can get a free COBOL compiler (were I to allow such in my house - I told my son that if I found porn, illegal drugs, and a COBOL manual under his bed he was in trouble for the COBOL), but CICS etc. aren't something you can pick up at home.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    62. Re:COBOL by PCM2 · · Score: 1

      one of the biggest steal companies in the world

      Do tell. Enron, maybe?

      --
      Breakfast served all day!
    63. Re:COBOL by angel'o'sphere · · Score: 1

      When you _used_ JCL successful you can _master_ any language :D

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    64. Re:COBOL by angel'o'sphere · · Score: 1

      Enron what? do they control plants with COBOL? Or not?
      Care to make a full comprehensible sentence?
      What is Enron?
      All I know about Enron is they are a scandal company in energy business, never heard they have steel plants or do COBOL for controlling plants. Or don't use COBOL ... sorry what is your point of your and your parents silly "one sentence posts"?

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    65. Re:COBOL by RespekMyAthorati · · Score: 1

      You repeatedly misspelled "steel" as "steal".

    66. Re:COBOL by angel'o'sphere · · Score: 1

      That explains the wikipedia link about banks :)
      Sorry, I don't see spelling mistakes that are not red underlined ... and both words are legit english words, so the spelling correction does not complain anyway. (And the iPad spelling correction often remains silent, it seems it has trouble to follow keyboard language switches)

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    67. Re:COBOL by zwarte+piet · · Score: 1

      Microsoft used it to code Windows 95

  2. In Theory by Anonymous Coward · · Score: 5, Interesting

    Key words "in theory".

    The type of businesses who need an actual expert in COBOL and not just a programmer who can pick up what they need to know need just that: an expert. You can't really become an expert without actual experience. When a company wants a COBOL expert, they want someone with 20 years experience to sort out the problems the programmers with a c++ or java background can't figure out.

    I've been hearing since I was in school that the "smart" thing to do is learn COBOL and go make a billion dollars maintaining someones mainframe, but I've never heard of anyone actually doing it. Not saying it doesn't happen, just not in my chunk of visible world.

    On the other hand, a friend of mine started working with Foxpro back when it was popular, and unlike everyone else, stuck with it. She makes egregious amounts of money maintaining the small number of things still using it. In her words: "keep laughing, it paid for my house".

    TLDR: if you were lucky enough to have started in some old tool/language that's still used and have kept your skills up to date, there is big money. Good luck jumping into it now though.

    1. Re:In Theory by HornWumpus · · Score: 2, Insightful

      It's not COBOL that gets the jobs. It's CICS. The COBOL 'database layer'.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    2. Re:In Theory by leonardluen · · Score: 1

      I used to do Foxpro, it at least paid for my education. i would still pick it over MS Access on most days. we long ago converted everything out of foxpro and had never allowed anything that uses Access.

      my favorite little side project that i had worked on in my free time was a sort of foxpro VM written in foxpro...yeah everyone thought i was crazy.

    3. Re:In Theory by bws111 · · Score: 5, Informative

      CICS is not a database layer, it is a transaction manager. The database layer is IMS or DB2. And CICS is callable from languages other than COBOL.

    4. Re:In Theory by jythie · · Score: 2

      Though I would not be surprised if companies are often willing to consider people who are experts in the field or in another language and know the basics of COBOL too. Still not an opportunity for someone fresh out of school, but I have found that often those '20 years experience' jobs care less about which specific languages you have worked in and more what types of problems you have been working on.

    5. Re:In Theory by Matheus · · Score: 2

      I'm currently *reading a LOT of COBOL (JCL, etc) We're doing a migration project away from the existing 370 mainframe to 'modern' tech. The requirements gathering was spotty at best so every time I get a new chunk to replace I'm reading lots of COBOL to grep for what I need my new code to do.

      I'm very thankful I'm not writing any 'new' COBOL but I can read it fairly smoothly. I can say for certain that skill will never be on my resume.

      On the topic as a whole: This article (or at least the summary) seem to imply you need to put all your eggs in one basket which is completely false. I've learned a new language for almost every job I've had. I am fairly fluent in Java which tends to shape the jobs I go after but every single one has required proficiency in some other language for some other reason. (Small example I wrote a library for a large international project in Java for my own purposes. It was useful enough that the rest of the project started using it so it bumped up against contractual requirements that everything "delivered" had to be in Java and C# SO I taught myself C# and ported the library to it. C# is *very similar to Java so this was pretty easy but a great example of learning a language on the fly.)

      Learn em all I say! Sort it out later...

    6. Re:In Theory by jafac · · Score: 1

      Yeah, but on the other hand, I don't know of many Rexx ninjas who are still out there. Back in the 1990's, Rexx was THE shit for banks. Now it's basically evaporated.

      --

      These are my friends, See how they glisten. See this one shine, how he smiles in the light.
    7. Re:In Theory by DoofusOfDeath · · Score: 1

      She makes egregious amounts of money maintaining the small number of things still using it. In her words: "keep laughing, it paid for my house".

      Can you be more specific about how much it pays? I can currently pull in about $140k/year in a major U.S. metro area. I'm curious if Foxpro is more lucrative than that, or just more lucrative than we'd expect.

    8. Re:In Theory by rubycodez · · Score: 1

      nonsense, plenty of places do database or VSAM without the CICS stack. I did COBOL at a couple places that did healthcare insurance and related financials, never had to touch CICS

    9. Re:In Theory by NJRoadfan · · Score: 2

      Learn em all I say! Sort it out later...

      Anyone who is proficient in programming shouldn't have a problem picking up a book (or website) and learning a new langauge, API, etc. in a weekend or two.

    10. Re:In Theory by Anrego · · Score: 1

      Exactly.

      There were plenty of tools that we all ran screaming from when better stuff came along, and most of them are now dust. It's only a handful that stuck around for various reasons, and the people who stuck with them are lucky bastards.

    11. Re:In Theory by DahGhostfacedFiddlah · · Score: 4, Insightful

      Anyone who is proficient in programming shouldn't have a problem picking up a book (or website) and learning a new langauge, API, etc. in a weekend or two.

      This is true as long as you're hacking something together. If you're expected to work with other developers and create something maintainable, you've got to learn a million little standards, conventions, quirks, tricks, and optional 3rd-party libraries.

      Picking up the basics is easy, but in my experience it takes a couple of years before one can truly be comfortable with a new language.

    12. Re:In Theory by CRCulver · · Score: 2

      Anyone who is proficient in programming shouldn't have a problem picking up a book (or website) and learning a new langauge, API, etc. in a weekend or two.

      This claim gets thrown around on Slashdot a lot, but it's simply not true. In a weekend one might learn enough of a language to bootstrap oneself to learning more through reading real-world code, and you might even be able to fix a bug in an open source program that has been annoying you, but you can forget about working professionally with that language right off.

      Just look at the standard references for various languages to see authors admit this. Python is a nice, clear language, right? "executable pseudocode". And yet in O'Reilly's Learning Python Mark Lutz, who has many years of experience teaching skilled programmers, say that it will take readers months to get a complete view of just the core language, let alone the standard library and important third-party libraries.

    13. Re:In Theory by Anonymous Coward · · Score: 1

      BS.

      Sure, you can pick up the syntax of a new language, but you aren't going to pick up the idioms.

      You'll just write code that looks like languages you already know in the new language.

    14. Re:In Theory by hoggoth · · Score: 1

      So what did you convert everything TO? I needed a program to manage my business and whipped it together in Access in one day. It handles customer lists, project lists, billable hours, todos (customer requests) and auto generates all of my end of month invoices from the billable hours.

      Thing is I *hate* Access. Every time I have to touch it I cringe because the way it works hurts my brain. But what else would let me make a system that does all this in just a few hours? Foxpro-ish tools would take weeks to code the loading editing and saving data from the database to the on-screen grids and forms. I looked at Lazarus, Rebol, DABO and LiveCode (RunRev), but they all look like they require hand coding the interface to some extent.

      --
      - For the complete works of Shakespeare: cat /dev/random (may take some time)
    15. Re:In Theory by david_thornley · · Score: 1

      Okay, assume you're very proficient in C#. Now sit down with a book and try writing good Haskell or Lisp or Prolog after a weekend. Java you should be able to do, but Haskell and Lisp and Prolog are different ways to program that you probably haven't learned yet. Learning a new language that works like the ones you know is pretty easy. Learning a new paradigm takes a lot longer.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    16. Re:In Theory by uninformedLuddite · · Score: 1

      RPL, Filetab

      --
      The new right fascists are bilingual. They speak English and Bullshit.
    17. Re:In Theory by leonardluen · · Score: 1

      I don't know.

      many Access project start like yours but then the business outgrows it, but then by the time you realize that you are then stuck with Access and have nowhere to go as it is doing all of your business logic and has turned into a monster.

        we originally moved everything to PHP and MYSQL, but have since converted most things to Java and MSSQL, with a little bit of C# here or there.

      Our path probably isn't too helpful to you. i work for a university primarily developing internal applications. The majority of our decisions on what platforms to use are made based on what our slave labor (students workers) are capable of doing, so this is probably not necessarily what would work best for most businesses. The students may be cheap but they have extremely high turnover, as we can't keep them after they graduate. To be fair we do pay them and this is one of the highest paid student jobs available on campus. we have a short time to train them and get them productive before they leave, we have to work around their class schedules during the school year so we only get them part time, and considering they are still taking their CS classes they often know little to nothing when we get them. considering those limitations, i think we do quite well and the students that work for us get some valuable work experience that has helped them start their career after graduation.

  3. Lucrative isn't all it's cracked up to be by Russ1642 · · Score: 5, Insightful

    Many jobs are lucrative, but so what? Try to do work you enjoy. If you go off trying to learn something just because it's lucrative you'll probably end up in a job where you're maintaining some obsolete system that's held together with duct tape. Not fun. Probably not worth the money for the amount of anguish it'll cost you.

    1. Re:Lucrative isn't all it's cracked up to be by Anrego · · Score: 3, Insightful

      Indeed.

      It's all a package. Geographic location, work culture, personal interest, and money all play a part in various proportions. I have an interest in money, but I have no interest in maintaining some old accounting system that's been bandaged for decades any more than I have an interest in moving to where that kind of work exists.

    2. Re:Lucrative isn't all it's cracked up to be by Anonymous Coward · · Score: 1

      If I had to work with objectively terrible languages like Java, Javascript, Python and Ruby I'd change careers.

      If the Slashdot trolls from 10 years ago saw this pathetic attempt they would laugh you off the planet.

    3. Re:Lucrative isn't all it's cracked up to be by rubycodez · · Score: 2

      mainframe and midrange financial system apps are tested and rolled out over very long time periods, usually not 'held together with duct tape". That phrase describes popular script based web stack apps.

    4. Re:Lucrative isn't all it's cracked up to be by SethJohnson · · Score: 1

      Fully agreed. Additionally, if it's lucrative, that means the organization perceives it as a cost-center. At some point, management will finally tire of the burden of this inflated paycheck and under-performing technology and will dump it out along with you.

      I find that the more reliably lucrative jobs are the ones that provide efficiency and cost-savings to organizations.

    5. Re:Lucrative isn't all it's cracked up to be by gstoddart · · Score: 4, Insightful

      If you go off trying to learn something just because it's lucrative you'll probably end up in a job where you're maintaining some obsolete system that's held together with duct tape.

      The problem becomes when you have an application which has been worked on for 30+ years, and which is tightly integrated with everything at the company.

      I've seen several attempts to replace those type things which have failed utterly, because it was impossible for a new vendor to write the same functionality, as well as the tight integration with every other system at the company.

      There's a reason mainframes are still sold and supported, because many organizations have learned it's easier, cheaper, and less disruptive to keep using the stuff that works, instead of trying to build it from scratch.

      And, as I've said elsewhere, I've known people who were retired and getting 4-5x their previous salary to maintain those systems.

      Throw enough zeroes on the pay, and obsolete systems paying super well can be an attractive option.

      Of course, the problem has always been with these system that going out and learning the environment doesn't give you the equivalent of the years of experience people have with these systems ... if you don't already have a lot of experience, these systems aren't really going to be made available to you to learn on. Because the people who have them, really really need them and rely on them.

      --
      Lost at C:>. Found at C.
    6. Re:Lucrative isn't all it's cracked up to be by geekoid · · Score: 1

      I enjoy taking care of my family, therefore Money.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    7. Re:Lucrative isn't all it's cracked up to be by boristdog · · Score: 4, Interesting

      Exactly.

      I started writing a replacement for our company's 20+ year-old file-based data system 7 years ago. I didn't tell anyone about it until a few years later when I had a prototype ready and started producing better and faster reports for management than the old system. But they still wouldn't okay me to go ahead and start designing a full replacement for our old system. Then the old system coughed up some blood for a couple weeks and nearly caused us a to lose a couple million in sales.

      After everyone stopped running aroud with their hair on fire they asked me what it would take to get my new system up and running as a replacement. I did it and now I am the one who controls all company data. At least a half-dozen people now work supporting the system and writing new code for it, but no one else has 7 years experience thinking about and designing this system, so a lot of the details escape them. HA! Try to get rid of me now.

      Proactive programming will get you far.

    8. Re:Lucrative isn't all it's cracked up to be by gstoddart · · Score: 2

      Sadly, not all systems can be replaced by one guy over a 7 year period.

      Now take a mainframe system, which has a database which feeds dozens of other applications, all of which are integral to the business of the company, and which implement the business process and logic for many aspects of the business -- either you fully solve the integration across ALL of those at once, or the system is essentially useless.

      I'm certainly not saying all pieces of legacy software can't be replaced, but some of the scarier/huger ones don't always lend themselves to it.

      I once worked on a project where 4 of us were working full time to replace a system like that for four years ... at which time, we'd barely scratched the surface, and were learning the more we knew the more everything they'd told us about the system at the beginning was such an oversimplification as to have been an outright lie.

      And, then the usual cancelling of the project and acrimony follows.

      There are certain kinds of legacy migrations I do not want to get anywhere near. There's also been a couple which are relatively straight forward and made perfect sense.

      Because, there is no one size fits all solution for all problems.

      --
      Lost at C:>. Found at C.
    9. Re:Lucrative isn't all it's cracked up to be by HornWumpus · · Score: 3, Insightful

      Congratulations. You are now UN-promotable.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    10. Re:Lucrative isn't all it's cracked up to be by Rigel47 · · Score: 1

      You write the truth. If you want to be rich there's one sure-fire way.. become a dentist. The problem is you'll spend your life working with people who really don't want to see you, with whom you never build a relationship. To say nothing of poking around in someone's smelly orifice all day.

      There's a reason doctors and lawyers have high rates of substance abuse and suicide. It's a shitty job a lot of the time.

    11. Re:Lucrative isn't all it's cracked up to be by micahraleigh · · Score: 1

      There's no such thing as "objectively terrible".

      If you say AIDS is "objectively terrible", well, what about the case where the AIDS virus is used to deliver life-saving genetic modifications?

      Value is in the eye of the beholder.

      Better to own your opinion than take the mantle of objectivity.

    12. Re:Lucrative isn't all it's cracked up to be by whoever57 · · Score: 2

      HA! Try to get rid of me now.

      It only takes one PHB who thinks that programmers are a fungible commodity.

      --
      The real "Libtards" are the Libertarians!
    13. Re:Lucrative isn't all it's cracked up to be by Anonymous Coward · · Score: 1

      Proactive "might" get you far - not "will".
      I was a proactive programmer, on a 6 figure contract, happy as a pig in shit.
      Then I proactively discovered discrepancies between internal records and what suppliers were charging us for.
      I wrote a "proactive" comparison algorithm, saved an international bank several hundreds of thousands per year, and promptly had my contract cancelled because some bean-counter got hauled over the coals for allowing the wasteage for so long. As revenge, he got my contract cut short. Cute.
      They finally brought in an outsourced team to replace me, and they're still failing miserably years later to maintain the custom code.

      Watch your back - if you do bad, sometimes you're out.
      If you do good, you make the passengers look slack, and you're out for sure. They outnumber you and outpower you, and you're a threat to their existence.

    14. Re:Lucrative isn't all it's cracked up to be by david_thornley · · Score: 1

      Moreover, if you specialize in something because it's a niche and you can make lots of money, you can find yourself out of a job without real marketable skills at any time. If I left where I work, I could find another job pretty fast. If I were writing PL/I for someplace or another, and had to find another job, it would be difficult at best.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    15. Re:Lucrative isn't all it's cracked up to be by david_thornley · · Score: 1

      I had a friend who worked for a company in the student loan business. Things went well with the old mainframe and COBOL system, until the new director decided he wanted a COBOL to Java conversion line on his resume. I got a ringside account. He saw the layoffs coming up, and was fortunate enough to be laid off early when they were still giving good layoff packages.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  4. COBOL & Scala & HTML5 by globaljustin · · Score: 2

    The TFA author has an interesting perspective.

    I dove into TFA because the description lists *Scala* with languages like COBOL as both being "unpopular"...not sure if Scala is "unpopular" in the way COBOL is that...

    While reading TFA, I discovered his link to his other article of *5 Programming Languages to Learn*

    in it, he lists HTML5/CSS3/PHP as *2* of the 5! haha! i hope this doesn't cause another round of "HTML5 isnt a language" arguments...Erlang gets a shout out

    good articles...i'd stay away from anything M$ proprietary so that #F language or w/e I don't agree with...but i like his analysis in both articles and learned alot...

    --
    Thank you Dave Raggett
    1. Re:COBOL & Scala & HTML5 by bugs2squash · · Score: 1

      I have to say that I enjoy learning to write at least a basic application in lanuages that I will probably never use for production code; like erlang, forth etc. I find they help me think about things differently, in ways that I can sometimes apply to applications written in my go-to languages.

      --
      Nullius in verba
    2. Re:COBOL & Scala & HTML5 by lpevey · · Score: 3, Insightful

      I think R is similar. R is not as well known as many other languages, but it serves a very important purpose and is getting more and more popular every day. I know some people who as adults are "learning to code" for the first time right now for their jobs. Why? We are starting to get into territory where every business person worth their salt needs to have some familiarity with data science.

    3. Re:COBOL & Scala & HTML5 by boristdog · · Score: 2

      Yep, I try to do a few basic programs in nearly every language I hear about, just to see what works well in which situation.

    4. Re:COBOL & Scala & HTML5 by Em+Adespoton · · Score: 1

      This. I found the article question a bit odd, as it seems to imply you should only learn languages that have, or will become in high demand and land you a job with a good paying salary.

      The other thing that playing around with esoteric languages will do is let you review other people's code with a fresh perspective, no matter the language. If you wrap your head around the mindset behind enough languages, it'll be easy to spot where someone has written code in a certain mindset and blinkered themselves to certain issues they my hit in the language they're using.

      Oh, and I'm surprised nobody mentioned LISP. Let's all learn to think recursively.

  5. R still in heavy use by Anonymous Coward · · Score: 2, Informative

    MATLAB/R/SAS are still used a lot in life sciences and probably other businesses. I don't use them directly but have users who do.

    In the olden days I got a lot of programming and database experience iwth MUMPS (or M as it's sometimes called). Think hierarchical rather than relational databases which makes things like patient data a lot easier to sort through.

    1. Re:R still in heavy use by TyFoN · · Score: 4, Insightful

      R is on the upswing so I wouldn't call it "still used" really :)

      That said, you can make money knowing R. I am doing it, but you really need some database experience and possibly some python, c++ and the like.

      SAS won't die in a _long_ time either, in the banks I've been too except for this last one have been using SAS almost exclusively.

      The problem with SAS/R code is that neither is usually written by a programmer but a statistician that want something to work there and then.
      It can be a nightmare if you inherit too much legacy code.

      Also, you actually need to know statistics to be effective :)

    2. Re:R still in heavy use by HeckRuler · · Score: 1

      Also, you actually need to know statistics to be effective :)

      Yeah, no shit. I tried to pick up R when I was putzing about with the rules of Risk. Wanted to find out how to balances this abstracted army-combat thing for a D&D game. Turns out even if you know the syntax and coding paradigms for the language, that doesn't magically teach you a damn thing about statistics.

  6. Perl, anyone? by ashshy · · Score: 1

    I'm still getting paid for some Perl 5 work. Learned some when it was still hot, built something with passing value, and now I'm pulling a small but significant monthly fee for supporting it.

    It's still what I do best, thanks to all this regular practice. Coding is otherwise more of a hobby than a job for me. Can't say that I see a lot of demand for Perl code monkeys out there, though.

    --
    #o#
    O Moo.
    1. Re:Perl, anyone? by bzipitidoo · · Score: 1

      Last coding job I had used Perl 5. We recreated an app for a database. The original app had been discontinued in favor of a 4GL language.

      Then the client decided they wanted that app coded in the 4GL language, and hired me to do it. Wow, what a lot of 80s thinking and cruft I saw. Managed to produce what they wanted, but they had to compromised a little. The input methods were typical of the era. Tried to do it all so the programmer didn't have to bother with tedious details. But if you wanted to change some of those details, you couldn't, not without a lot of extra work.

      --
      Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
  7. COBOL and FORTRAN by Frosty+Piss · · Score: 4, Insightful

    The story implies that COBOL is an ancient outdated language. But this is not true. COBOL serves a specific niche and does so quite well, and indeed like C and FORTRAN has been enhanced through the ages. Sure, you can't really code a bleeding edge website with COBOL (and FORTRAN), but that's not what they are for.

    --
    If you want news from today, you have to come back tomorrow.
    1. Re:COBOL and FORTRAN by Anrego · · Score: 1

      Is it ever chosen for new projects though? Would there ever be a reason to?

      I get that for the type of programs originally written in COBOL it makes no sense to do a complete re-write. Things like accounting and payroll and inventory management are pretty static, and once you've got a working system, why change it.

      But does COBOL offer any reason to start a new system with it?

    2. Re:COBOL and FORTRAN by bhcompy · · Score: 1

      Sometimes you're creating that new software in an old environment. When I worked for ADP we were constantly creating new software written in DataBASIC, simply because the environment we were working in was a PICK environment.

    3. Re:COBOL and FORTRAN by gstoddart · · Score: 2

      The story implies that COBOL is an ancient outdated language. But this is not true.

      Well, let's face it ... it is an ancient and outdated language. It was when I was in university 20+ years ago.

      But ... it's still entrenched in a lot of places and isn't going to go away any time soon, simply because there are legacy systems out there which can't readily be replaced.

      Years ago I was working with a client, and one of their people was retired from the company after something like 35-40 years. He was getting his pension, but he was also getting paid something like 4-5x his previous salary as a consultant to maintain the systems he used to simply because there wasn't anybody else on the planet who knew it.

      So, sometimes, you accept that you're working with ancient technology, because nobody else knows it well enough, and because you'd just as soon make buckets full of money.

      Because, really, would you rather work for a shorter number of years for much more than you'd make normally if you had the chance and your skillset was sufficiently arcane that you could get paid boatloads of money?

      --
      Lost at C:>. Found at C.
    4. Re:COBOL and FORTRAN by Errol+backfiring · · Score: 1

      , but he was also getting paid something like 4-5x his previous salary as a consultant to maintain the systems he used to simply because there wasn't anybody else on the planet who knew it.

      Wow, that is an extremely expensive mistake. He's bound to take his final breath at the least convenient moment. In fact, the later the less convenient. If you rely on tools that much and have no control over it, you have a very dangerous business.

      --
      Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
    5. Re:COBOL and FORTRAN by gstoddart · · Score: 4, Interesting

      Wow, that is an extremely expensive mistake.

      It's not so much that it was a mistake, as it was actual reality of the situation the company found themselves in.

      We're talking about systems with 40-50 years of data, for highly complex machines with incredibly long service lives that generate billions in revenue, which are tightly integrated into everything in the company, and which would likely cost 10's of millions of dollars (if not 100's) and several years to replace -- with the risk that you'd spend the money and still not end up with a viable replacement.

      The reality is, in long-established businesses in highly regulated industries with systems which are literally decades old and not easily replaced ... many many organizations find that it would be impossible to replace/retire these systems, and that it's cheaper to keep paying the people who have familiarity with these systems. And if they die, you find someone else with a lot of years on a similar system.

      Saying "oh, just replace it with something new" is something which I hear from naive, inexperienced people who have never encountered these kinds of systems. Sure, it sounds great, but it doesn't match up with actual reality.

      I've encountered several of these systems, and been on projects to try to replace a couple -- and almost universally when you try to do it, you realize that the scope of the problem, and the way in which it will break everything else you have, corporations decide it's not possible or cost effective.

      Say what you will about the old school mainframe applications, but they did exactly what they were supposed to, for very long periods of time, with thousands of pieces of institutional and business process embedded in them ... and they do it without crashing, breaking, or otherwise being unavailable. EVER!

      Systems which have been running robustly since decades before Microsoft was even founded are about as non-trivial to replace as you can possibly imagine.

      Precisely because they are so big, so important, so complex, and so tightly integrated into every one of your business processes.

      So, you'll excuse me if I question if you've actually encountered any of these systems, or been part of trying to replace one.

      Because anybody who has usually looks at the project and says "no way am I getting dragged into that".

      --
      Lost at C:>. Found at C.
    6. Re:COBOL and FORTRAN by tlhIngan · · Score: 1

      by Anrego (830717) * Alter Relationship on Tuesday September 09, 2014 @08:27AM (#47862303)

      Is it ever chosen for new projects though? Would there ever be a reason to?

      I get that for the type of programs originally written in COBOL it makes no sense to do a complete re-write. Things like accounting and payroll and inventory management are pretty static, and once you've got a working system, why change it.

      But does COBOL offer any reason to start a new system with it?

      Surprisingly, few new projects do it. But then they implement a whole programming layer on top of whatever the application is written in to do similar things.

      So many crappy languages have been created over the years that really are meant to implement business logic without having to recompile the source code or have managers etc. learn C or Java or whatever because they want to implement a 10% discount on card members.

      So you see lots of abstraction layers built up and maintained. And it's funny, since COBOL was designed for this - it's designed for managers and all those kind of people to understand. Accountants and the like love it (which is why the financial industry runs off of COBOL) because they can read it and comprehend what it does without being a programmer.

    7. Re:COBOL and FORTRAN by geekoid · · Score: 1

      Please explain why it's ancient and why ancient is bad.
      Llease explain why it's outdated.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    8. Re:COBOL and FORTRAN by oh_my_080980980 · · Score: 1

      Agreed. Many companies got dragged into the mainframes are bad client/servers good debate only to find out that servers did not have the up-time that mainframes have. Just because it's shiny and new does not make it better. That's the sorry state of IT. IT does not want to support they just want to replace.

    9. Re:COBOL and FORTRAN by gstoddart · · Score: 1

      I'm not saying ancient is bad. I'm saying ancient is ancient.

      The language itself is ... I believe purposefully verbose is a nice way to say it. I also know the language has had extensions over the years (don't ask me what they are, I haven't kept track). But I'm betting there's no "COBOL on RAILS" (or if there is, that's hilarious).

      But, really, when I was in university 20+ years ago, I had profs who had used COBOL 20+ years before. Which means there's software out there which is old enough to be grandparents. ;-)

      The wheel is ancient, but not bad.

      Except for places where it's entrenched ... do you really think people are choosing it for new work? There's a lot of open source projects using COBOL nobody is aware of, are there? If it's largely legacy systems using it, it's outdated.

      However, I've also know people who have been using the same old farm tractor to power something for several decades, and they work just fine.

      But, if you were starting from scratch, you might use something else.

      (Though, admittedly, I'm not sure you can do better than some of those old farm tractors which have been running machinery for decades.)

      --
      Lost at C:>. Found at C.
    10. Re:COBOL and FORTRAN by marcello_dl · · Score: 1

      > But I'm betting there's no "COBOL on RAILS" (or if there is, that's hilarious).

      You got it, there is.
      Well, kinda :)

      --
      ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
    11. Re:COBOL and FORTRAN by gstoddart · · Score: 1

      LOL ... suddenly I'm nostalgic for old fashioned green on black monitors.

      They even implemented screen burn in, that's awesome!!!

      Cheers, and thanks for the good laugh. The guy who did that site is a genius.

      --
      Lost at C:>. Found at C.
    12. Re:COBOL and FORTRAN by angel'o'sphere · · Score: 1

      My terminal on my mac is green on black, but I set the background to translucent, so I see what is going on behind in youtube while typing (actually it is not youtube, but a random window, but it sounded funny at the first glance ;) )

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    13. Re:COBOL and FORTRAN by jstott · · Score: 1

      Is it ever chosen for new projects though? Would there ever be a reason to?

      I can't speak for COBOL, but Fortran (with the 1990/95 language standard, not the ancient 1966/77 versions) is still being used in astronomy for new projects - the MESA stellar evolution project, for example, is completely written in Fortran (it launched in 2007, so isn't exactly a legacy project either). There's also a lot of supercomputer code still written in Fortran for the same reason: the language makes it easier to do the things I need to do.

      I wouldn't do a webpage with it, but when you're doing heavy-duty mathematical calculation, Fortran is breeze to work in compared to lower-level languages like C.

      --
      Vanity of vanities, all is vanity...
    14. Re:COBOL and FORTRAN by michael_cain · · Score: 1

      The reality is, in long-established businesses in highly regulated industries with systems which are literally decades old and not easily replaced...

      Too often true in state governments as well. The executive branch struggles with COBOL on a mainframe because the price tag for the replacement system is $50M and the legislature won't pop for that. Often for political reasons -- different parties in control and we'll be damned if we'll cooperate with this Governor. Price tags for government software tend to be quite high because of the large number of obscure add-on requirements that have to be satisfied. For example, the system touches information that is classified by the law as "medical records" at some point -- HIPAA as applied to government agencies rears its ugly head. Incredible amounts of cruft have accumulated over the decades.

      Thank goodness I wasn't ever in the position of having to write software under those conditions. But for three years as a legislative staffer I did get to sit in on post-mortem analyses for failed software projects.

    15. Re:COBOL and FORTRAN by Errol+backfiring · · Score: 1

      I would not replace it with something new, but migrate it to something maintainable.

      you know the mantra:

      • If it ain't broke, maintain it
      • If it's broke, either repair it or discard it
      • If it's beyond maintenance, it's definitely broke

      The fact that it is a core business system does not provide an excuse, it makes it even worse.

      --
      Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
    16. Re:COBOL and FORTRAN by david_thornley · · Score: 1

      How do you migrate an old COBOL system?

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    17. Re:COBOL and FORTRAN by Errol+backfiring · · Score: 1

      In pieces. The database or whatever storage is used could be a good starting point to abstract. See How to Ride a Dinosaur.

      --
      Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
  8. Bullcrap by Anonymous Coward · · Score: 5, Funny

    Haskell code never has any bugs. But that's just because it's never used in production.

  9. Mainframe Programmers by __aaclcg7560 · · Score: 1

    I still see job advertisements for mainframe programmers from time to time. How does one break into this line of work without access to a mainframe system?

    1. Re:Mainframe Programmers by LWATCDR · · Score: 1

      Simple, steal one.
      Or get one of the free emulators. The problem is finding the OS. You can only run zOS legally on real IBM hardware.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    2. Re:Mainframe Programmers by bws111 · · Score: 1

      If you are really serious about it, buy the IBM zPDT (Personal Development Tool). Let's you run z/OS, z/VM, and z/VSE on a PC (legally). A little pricey (about $5K for the tool, and $900/yr subscription for the software), but comes with a whole bunch of mainframe environments and tools.

    3. Re:Mainframe Programmers by khb · · Score: 2

      "...access to a mainframe system"....

      Well, there is more than one kind of mainframe, and they aren't much alike. But let's assume you really mean IBM zSeries. You have several options:

      1) Take a course. Many schools have IBM sponsored classes with access provided.
      2) Find a copy of the "Hercules" emulate http://www.hercules-390.org/
      3) Sign up for ANY university class to become a "student" and apply to IBM http://www-03.ibm.com/systems/...

      Also note the growing popularity of Linux on zSeries systems, so your Linux skills can be directly applied.

    4. Re:Mainframe Programmers by Eunuchswear · · Score: 1

      So use some other manufacturers mainframe.

      I can point you towards a pretty good emulator for the ICL 1900 series, running George 3.

      There is rumoured to be still one running George 3 site in Russia, so you might be able to get a job.

      --
      Watch this Heartland Institute video
    5. Re:Mainframe Programmers by rubycodez · · Score: 1

      1. pick one of the three very common mainframe OS that is interesting to you: Z/VM, Z/OS, Z/VSE
      2. you violate IBM's license agreements and get a torrent or whatever of the disk images of installation set up for Hercules emulator
      3. enjoy your illegal virtual mainframe

    6. Re:Mainframe Programmers by laejoh · · Score: 1

      Hit caps lock on your keyboard and you're halfway there!

  10. Trendy != popular by Viol8 · · Score: 1

    It might be fashionable in academia and certain CS circles but I've never once seen it used commercially in 20 years of working in IT. Now maybe I've not worked in the right sort of companies but I've worked for some pretty big blue chip ones and small houses so I reckon I've got a good spread of experience there.

    1. Re:Trendy != popular by jythie · · Score: 1

      That is the trouble with trying to talk about 'popular' languages, one has to specify 'within what domain?'. If one does not care what they are working on as long as it is 'programming' then pure numbers are all that matter, but anything more targeted and you have to look at what languages are in demand there.

    2. Re:Trendy != popular by gbjbaanb · · Score: 1

      you mean you hated it so much you gave up on programming and became a project manager instead? That is a way to make much more money.

    3. Re:Trendy != popular by lgw · · Score: 1

      I was going to post that RabbitMQ was written in Haskell, but fortunately I checked first: nope, Erlang. Haskell? I got nothing.

      Languages don't really matter much. Pick a problem domain that's in demand, and not much in supply. The language is just a tool. (But avoid COBOL if at all possible.)

      --
      Socialism: a lie told by totalitarians and believed by fools.
    4. Re:Trendy != popular by WillAdams · · Score: 5, Interesting

      Three words:

      High frequency trading

      Most of the code driving that is written in Haskell, which is just criminal, since it's some very bright people writing that code, and they're not contributing in any meaningful way to humanity, just fiddling bits to determine who has how much of what money at the end of each trade.

      http://adtmag.com/articles/201...

      --
      Sphinx of black quartz, judge my vow.
    5. Re:Trendy != popular by mfwitten · · Score: 2

      Allocating capital profitably is extremely beneficial to humanity.

    6. Re:Trendy != popular by Whibla · · Score: 1

      In any ecosystem there has to be a bottom feeder. If they only feed from the bits that no-one else cares about at that time why shouldn't we be happy with that bargain we made? What is contributing? How do we measure contribution?

    7. Re:Trendy != popular by ultranova · · Score: 2

      Allocating capital profitably is extremely beneficial to humanity.

      High frequency trading is not about allocating capital, it's about bleeding the people who are seeking to reallocate it.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    8. Re:Trendy != popular by WillAdams · · Score: 1

      ``Almost no one'' != none, therefore, some people are using Haskell in HFT by your own admission.

      I cited a source which noted Haskell is used for such --- do you have a citation for that number / proportion being very low?

      Looking through the first page of Google search results for ``high frequency trading programming languages'' Haskell is noted as being advantageous for its ability to prove correctness of a program.

      --
      Sphinx of black quartz, judge my vow.
    9. Re:Trendy != popular by HornWumpus · · Score: 1

      If you're in investor, you shrug your shoulders. Happy with the low commision modern markets give you.

      If you're a speculator, the HF traders can be a problem. Being better speculators and chiseling a penny out of every (velocity/heat map/day trader method) trade is what they do.

      Fuck the speculators, right in the dick eye, with a high speed data cable bundle.

      I have a problem in that they (GS) have previously been allowed to back out trades caused by bugs. Fuck em. Trades a trade. If that breaks them, so be it. Obviously that 'can't be allowed to happen'.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    10. Re:Trendy != popular by PCM2 · · Score: 1

      High frequency trading

      Most of the code driving that is written in Haskell

      That's weird. The very article you link says most of it is written in C/C++, with a bunch of other stuff thrown in here and there. One guy said he used Visual Basic.

      --
      Breakfast served all day!
    11. Re: Trendy != popular by smithmc · · Score: 1

      Indeed. In fact, a lot of the guts of HFT systems are implemented in hardware - TCP/IP stacks implemented in FPGAs and such.

      --
      Downmodding is the refuge of the weak. Don't downmod, make a better argument!
  11. Yo got time to lean, you got time to clean by nosajholt · · Score: 3, Insightful

    As always with these sorts of questions, the answer is "it depends". If you are employed and working with Java or C++ or something else, then by all means be the expert in these languages. Once you get to the expert stage - might take a year or two or three - by all means expand and be a generalist in many languages, but continue being an expert in your favorite language. I can tell you that those COBOL/RPG programmers in this great land are within ten to fifteen years from retirement, and there is a-whole-lotta code out there that still needs love. Since Y2K, I don't know anyone under the age of 40ish who is writing COBOL/RPG, so there is an opportunity there, if you are so inclined. If you are unemployed, then do one or two projects in your favorite language and one or two projects in a language that is used on your prospect list. For example, you want to work for Twitter? Learn Scala. Regardless, as the old adage goes, if you got time to lean, you got time to clean, or in this case, code. Good luck, and good question.

  12. The problem is not what to learn by hcs_$reboot · · Score: 1

    Languages are not equally accessible. The most popular languages , like PHP, allow many people - almost everybody - to program, whatever their background is, and whatever the outcome (performance, maintenance, ...) of the application may be. Among this many people is diluted a rather low percentage made of some good developers who could easily adapt and program in something else, like R or Haskell (they don't do it because they don't need to).

    In other words, hire R developers to make better PHP programs.

    --
    Slashdot, fix the reply notifications... You won't get away with it...
  13. think about what it says about the company by silfen · · Score: 2, Interesting

    You should think of what the choice of language says about a company. Any company that built its business on Clojure, Scala, or Haskell has a management problem in my opinion: while those languages may be more productive than, say, plain Java, hiring and tool support has always much more difficult. COBOL is indicative of lots of legacy code and a company that has been in business for a long time. That has some advantages, but also means a work environment that's likely very different from others in the industry. R is something used by statisticians and scientists; if you get hired solely as a programmer (rather than a scientist/analyst) to do R programming, your job is likely to clean up other people's messy R code. Can you make money with any of those languages? Sure, but the job may not be quite what you expect or what you are used to.

    1. Re:think about what it says about the company by rnturn · · Score: 1

      ``R is something used by statisticians and scientists; if you get hired solely as a programmer (rather than a scientist/analyst) to do R programming, your job is likely to clean up other people's messy R code. Can you make money with any of those languages? Sure, but the job may not be quite what you expect or what you are used to.''

      While I've found R to be useful for analyzing/plotting/etc. system performance data I haven't seen any actual job listings in the past couple of years that required `R' experience that were not actually looking for someone with a background in biostatistics. I.e., they weren't programming jobs but for folks with backgrounds in medical/genetic research who would be using R at those jobs. I can see where R would be useful for working with financial data . Wonder if Wall Street might be a good place for someone with R experience to find work?

      --
      CUR ALLOC 20195.....5804M
  14. Why limit yourself? by zelbinion · · Score: 4, Insightful

    Why limit yourself? Learn both a popular language and a less-popular one. I had the fortune of picking up both Java and COBOL in a previous job, which helped me land my next job, which involved (guess what?) both Java and COBOL (and Perl, and SQL, and XML, and C#, and PHP, and....). Never have I encountered a job where you only need to know one language. All those big banks and manufacturing companies running COBOL? They probably need to make those systems talk to something written in a more modern language like Java, or C#, or PHP, or even Ruby or Python. They are probably even trying to move some of their old legacy systems off on to newer systems, so having an engineer who knows both the legacy technology as well as newer technologies is just what they need. Knowing more than one language and more than one technology also means you don't get stuck when the company re-orgs or you finally decommission the old system or they hit a rough patch and downsize.

    What makes a valuable employee isn't someone who is an expert in one thing. A valuable employee is flexible, can teach themselves new things without having to take a class or being asked. A good programmer is good at programing regardless of language. The more you learn, the more valuable you are, and the more options you have finding a job. Once you have experience solving problems with software, picking up a new language isn't really that hard. Yes, you could specialize in something like mainframe COBOL and there will be niche jobs for you in the financial industry for a long time to come, and you might be able to command a hefty salary as well, but do you really want to write COBOL for the foreseeable future?

    1. Re: Why limit yourself? by Dishwasha · · Score: 1

      I'm surprised it took this many posts to see Ruby. Ruby developers often make above national average and higher than big tech companies like Google.

  15. Python is eating Perls lunch by Viol8 · · Score: 4, Insightful

    Perl was used because it was a powerful scripting language despite a god awful syntax that took the worst parts of unix shell and awk and made them even more painfully contorted. When an equally (some would say more) powerful scripting language called Python came along with a sane syntax, a shallower learning curve and a properly interactive interpreter its no surprise huge numbers of people jumped ship.

    I for one won't miss Perl - it had its day but its day is pretty much done apart from legacy code and the few dyed in the wool web sites still using CGI.

    1. Re:Python is eating Perls lunch by rjmx · · Score: 3, Insightful

      Uh-huh. And when the Python people learn something about backward compatibility and make up their minds (so we all don't have to keep half-a-dozen different versions of it lying around), then it might actually get somewhere. Until then, it's just the new shiny-shiny.

    2. Re:Python is eating Perls lunch by Eunuchswear · · Score: 1, Insightful

      Can Python do unicode right yet?

      --
      Watch this Heartland Institute video
    3. Re:Python is eating Perls lunch by rubycodez · · Score: 2

      which python are you talking about? 3.x, 2.5...2.7???? yes those different languages used for things....

    4. Re:Python is eating Perls lunch by marcosdumay · · Score: 1

      Can any language do unicode right yet?

      You can throw away any language that uses UTF-16 right from the start. What's left is C/C++, if you are careful enough.

    5. Re:Python is eating Perls lunch by Eunuchswear · · Score: 1

      Perl does a pretty good job.


      #! /usr/bin/perl

      $x = "\N{WHITE SMILING FACE}";

      binmode STDOUT, ":encoding(utf8)";

      print "Have a nice day: $x\n";

      --
      Watch this Heartland Institute video
    6. Re:Python is eating Perls lunch by plcurechax · · Score: 1

      Can any language do unicode right yet?

      You can throw away any language that uses UTF-16 right from the start. What's left is C/C++, if you are careful enough.

      In fact C (C89/90 to C11) is character-set neutral, and continues to maintain support for EBCDIC for those still stranded without 7-bit ASCII (which is technically superseded by ISO/IEC 646) by providing trigraph (5.2.1.1) and digraph (6.4.6.3) support.

      See Section 1 Scope: 2. "This International Standard does not specify / the mechanism by which C programs are transformed for use by a data-processing system" and the definition of 3.6 Byte which is an "addressable unit of data storage large enough to hold any member of the basic character set of the execution environment". So yes Cray, you can even have 12-bit bytes (CDC Cyber).

      Kids these days.

    7. Re:Python is eating Perls lunch by plcurechax · · Score: 1

      Or to paraphrase whimsically: "C: it's been ignoring Unicode since before you were born."

    8. Re:Python is eating Perls lunch by rnturn · · Score: 1

      ``so we all don't have to keep half-a-dozen different versions of it lying around''

      Sounds like my experience having to keep 4-5 Java runtime environments on UNIX systems to support older code that nobody had the time to rewrite to be compatible with the runtime du jour. Figuring out how to keep those old runtimes up to date every time some bozos (*cough* politicians *cough*) decided to monkey around with daylight savings time was, oh, so much fun.

      --
      CUR ALLOC 20195.....5804M
    9. Re:Python is eating Perls lunch by ultranova · · Score: 1

      Sounds like my experience having to keep 4-5 Java runtime environments on UNIX systems to support older code that nobody had the time to rewrite to be compatible with the runtime du jour.

      That's an important lesson for any future language designers: if you have requirements (don't pass references to the object being constructed away from the constructor or start new threads there), you also have to enforce them, otherwise programmers will ignore your rules and write code that only works with particular runtime (or particular garbage collector options, in some cases).

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    10. Re:Python is eating Perls lunch by marcosdumay · · Score: 1

      Python have some problems with I/O being allowed only in ASCII or Unicode on some circunstances, depending on your version. It also has some problems with composing codepoints, lengths, encode translations, and other of that stuff that nobody does right.

      Yet, Python has the most comprehensive support for Unicode of any language that I looked out, outside of C/C++. (Beats Perl 5 in any day. I don't know about 6.) It's just that no language has complete support (except for C/C++, that properly ignores the entire issue).

    11. Re:Python is eating Perls lunch by rjmx · · Score: 1

      > Python 3 is the first break in backward compatibility this century!

      Yep. And why is that not backward compatible too? Why don't they aim to get it right the first time? And if they don't get it right, why change it when that breaks previous uses?
      I'd also remind you that we're not very far into this century yet. If that was supposed to be sarcasm, it fell short.

      > Python 2.x up to 2.9 is and will be backwardly compatible with python 1.6

      Then how come my Debian system needed 2.6, 2.7 _and_ 2.8 all installed at one point? Why do Pythin apps and libraries keep breaking because somebody introduced a subtle change somewhere?

      Whatever Python is, it's not very robust.

      I still say it's the new shiny-shiny. Nothing more.

    12. Re:Python is eating Perls lunch by Ogi_UnixNut · · Score: 1

      Sounds a bit like my experience maintaing perl infrastructure. We had to have like, 4 different versions of perl5, with their own module set, because each one had subtle changes that would break some library, or some other piece of code, or not run as expected. What a PITA.

      Maintaining two (or even three) versions of Python is bliss in comparison. We only had to maintain two versions: 2.7, and 3.

      So yeah, neither Python nor perl are really robust, although IMO Python is more robust than perl.

      I don't know, if you want rock solid single standard languagel, I really can't; think of one. COBOL perhaps, along with Forth and LISP come to mind. C suffers from lots of "undefined" behaviour which is compiler dependent, but at least the standard syntax doesn't really change often.

  16. How much money are we talking about? by MalleusEBHC · · Score: 2

    I'm a software engineer who works mainly in C++. There are tons of jobs available to me, and they generally pay a metric fuckload of money. How much more could these jobs for unpopular languages pay? Having the choice of many employers is a big benefit of being strong in C++, and that allows me to choose a company that will treat me well both in terms of compensation and work/life balance. There would have to be an extremely very large premium for me to focus on an unpopular language and limit my choice of employers.

    1. Re:How much money are we talking about? by Glock27 · · Score: 2

      Actually I think you're more representative of someone who's making a lot of money working with an unpopular language.

      C++ has fallen way down the charts, and I'd be willing to bet fewer than 10% of those writing software today are writing C++, especially using recent/advanced features. You're making good money because you're using one of the more difficult and painful languages out there. :-)

      Sooner or later a superior language that fills the C++ niche will come along, then it will go to a truly legacy status...finally.

      --
      Galileo: "The Earth revolves around the Sun!"
      Score: -1 100% Flamebait
    2. Re:How much money are we talking about? by Anonymous Coward · · Score: 1, Insightful

      Well, that, and also the general perception that C++ programmers are generally way smarter than any other programmers out there. I've noticed that algorithmic skills are generally higher in C++ programmers---they generally know how linked lists work, how to implement array based queues, how sorting actually works, where the bottlenecks are, etc., stupid little things that most average C# or Python developers wouldn't be able to think through.

      So yes, even if you're not hiring a developer to do C++, having a C++ developer generally increases the programming skill level on your project. In other words, hire smart folks, and you'll do well.

    3. Re:How much money are we talking about? by Errol+backfiring · · Score: 1

      a metric fuckload of money

      Is that more than an imperial fuckload?

      --
      Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
    4. Re:How much money are we talking about? by captjc · · Score: 1

      90% of all the jobs I have seen listed were either Java, SQL, or C#, with the occasional reference to iPhone programming.

      C++ is not even remotely close to being a popular language unless you are looking for jobs that require a masters / Ph.D in electrical engineering.

      --
      Slow Down Cowboy! It's been 1 hour, 47 minutes since you last successfully posted a comment
    5. Re:How much money are we talking about? by MalleusEBHC · · Score: 1

      This is the complement to the other comments about C++ not being popular, although I disagree with them on the degree of popularity. The knowledge you mention about data structures and algorithms is transferable to any language. I often see jobs for Java, Python, etc. that say C++ experience is an acceptable substitute, but I'm also able to drop down into C.

      C++ programmers are generally way smarter

      Well, I did my best to disprove this by writing "extremely very large" in my OP. Note to self: when upgrading very to extremely, remove the original very.

    6. Re:How much money are we talking about? by Dishwasha · · Score: 1

      Let me put it this way. With such languages you can break in to the 36% Obama 2013 MFJ proposed tax bracket and you don't even have to be living in the greater Seattle, Washington area.

      I think once you're at a certain level, you must be multi-disciplinarian in languages, libraries, and frameworks. You're also primarily getting paid well because you're a good software engineer and even better at solving the business's problems elegantly and with the least amount of effort.

      Working in a smaller pool can be good because scarcity drives demand. If you're in the larger talent pool you have a lot more competition which actually drives down wages, especially when you're getting edged out by dirt cheap H-1Bs.

    7. Re:How much money are we talking about? by david_thornley · · Score: 1

      C++ is normally in the top 10 on the Tiobe charts, and everything else I've seen. I'd call that popular. It isn't the most popular language, but lots of places use it.

      There's also an $EXPLETIVE GERUND lot of C++ code out there. It's not going away any time soon.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    8. Re:How much money are we talking about? by david_thornley · · Score: 1

      A C++ programmer with both feet still on is smarter than most other programmers out there.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  17. Learn Coldfusion by Anonymous Coward · · Score: 1

    It's right on the verge of being a lucrative language almost no one uses.

    1. Re:Learn Coldfusion by Anrego · · Score: 1

      Sure, but how many systems were written with it that you expect to be around in 10 years.

      COBOL is still around because complicated yet relatively static systems were written in it, and those systems are still needed, still do what they need to, and are big enough that re-writing them would be a massive risk.

      Web apps come and go, old school payroll systems are forever.

    2. Re:Learn Coldfusion by edremy · · Score: 2

      Heh- a large chunk of our timesheet system where I work as well as departmental budgets is all done within a custom portal written in.... ColdFusion. We're slowly moving away from bits of it (The helpdesk ticketing/inventory control parts are gone now) but I can't see it dying completely within the next decade.

      --
      "Seven Deadly Sins? I thought it was a to-do list!"
  18. Just get really good at something by blueshift_1 · · Score: 1

    There is always jobs out there. Really it's better to figure out what style of programming/development you want to do, then go out there and get damn good at those most relevant languages. It's certainly good to tinker in different ones that might fall outside just for excercise and just a new experience. However, focus on you want, build your core and there will always be positions to suit you skills in my opinion.

  19. How to make money by sjbe · · Score: 1

    You can make good money two ways. 1) Be able to do something not many others can do for which there is a need OR 2) Be able to do something not many others want to do for which there is a need. You can make a lot of money if the activity fills both requirements and is under served. If you enjoy or at least can tolerate working with unpopular technology for which there is a need you can make a nice little living for yourself so long as the need remains and is not over served.

  20. Lisp, Forth, APL, J, Prolog, PostScript by Kazoo+the+Clown · · Score: 1

    And of course x86 or RISC Assembler...

    old languages never die, the programmers just start charging a prohibitive amount of money to code in them. Forth is only justifiable doing embedded programming when you don't have an OS. APL and J are only justifiable if you don't have a popular OS, AND you're stuck with a low speed printing terminal.

    1. Re:Lisp, Forth, APL, J, Prolog, PostScript by khb · · Score: 1

      APL and J are useful for doing the sort of ad hoc big data analysis that R is also popular for.

      The speed (or lack thereof) of your terminal isn't really the issue, its being able to think in matrix/vector transformations. A skill which is actually more important today than 40 years ago.

    2. Re:Lisp, Forth, APL, J, Prolog, PostScript by Kazoo+the+Clown · · Score: 1

      That's no excuse for their lack of readability. The only excuse for that is a low baud rate. Or perhaps, hunt & peck typing ability.

  21. Re:Ugh by rossdee · · Score: 3, Funny

    The actual cards would be those 80 column things that the ancient languages were stored (and inpuy) on.

  22. Re:Ada? by HornWumpus · · Score: 1

    No. I remember when Ada was required by the DOD.

    I've also heard it referred to as 'writing code in triplicate'.

    --
    John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
  23. Re:Bullcrap by rubycodez · · Score: 1

    please list the huge companies using it

  24. LotusScript by Dr.+Evil · · Score: 1

    Not holding my breath for My LotusScript skills to come back into style.

  25. Re:Ada? by uncle+slacky · · Score: 1

    It's still being taught as an introductory language at my daughter's university - Ada 2005 no less! Just installed GNAT & GPS on her laptop. Me, I'm an old Fortran jockey (VMS, mostly). There still seem to be a few jobs in it, but nobody interested in me (yet).

    --
    Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it.
  26. Re:Ada? by ajdlinux · · Score: 1

    I'm currently studying for my bachelor's in CS, and I've taken two courses taught in Ada. Quite an alright language, IMHO. I'm also aware of at least two private-sector companies in my relatively-small city who are starting new projects in Ada (in addition to all the established defence contractors around here). So it's not completely dead! Mostly, but not completely!

  27. Old coder here by clickclickdrone · · Score: 1

    Been programming since the late 70's in one form or another. Probably 98% of the stuff I have worked on is C, C#, VB or Java. The only reason it's not 100% is because to begin with it was all stuff like Dbase III, FoxPro, Access, DataEase and some assembler. I've not been asked to tackle anything other than the C/Java/VB variants since about 1990. Where exactly are all these other (non web related) languages used?

    --
    I want a list of atrocities done in your name - Recoil
    1. Re:Old coder here by CycleFreak · · Score: 1

      Anywhere/everywhere there's a system that does not need to run on the web. Like say, an ERP system.

      Now, I'm sure you think, "but order entry is part of an ERP system and you must be able to take orders on the web!" True, but the front end that receives those orders is usually just that - a front end. The "grunt work" is done by the back-end systems and is most likely not written in a language like C/Java/VB.

      These are the systems that rely on middleware and/or messaging services of some kind to get data in/out. There's still a TON of coding to be done on the back end.

      Become an expert is some BI system (yes, not truly a "language", but still). Execs are constantly fooled into thinking that buying a BI system will instantly give them magical reporting and analytical powers over their burgeoning "big" data. Except they don't - all the dashboards, automated reports, etc. need to be developed, configured, rolled out and maintained and are invariably uniquely tied to the company in which they are being used.

      I've been using Progress 4GL (now given the num-du-jour ABL) for 25 years. It's a niche. As is the eponymous RDBMS, at which I am also an expert. Progress does not own a significant portion of the DB or application market. But where it is used, folks like me are in high demand. The exact opposite of you, I have not programmed in C/C++/Java/VB since early 90's. And I don't miss it.

  28. Re:Ada? by Anrego · · Score: 1

    Interestingly there is a small but strong Ada community with Apple levels of fanboyism going on.

  29. Highschool girl logic by hibiki_r · · Score: 5, Insightful

    It's interesting how many programmers make decisions while ignoring the wisdom of the high school girl. When in doubt, you pick something that is popular. When you are really good at it, you pick something that is going to become popular, and by choosing it, you make it more popular.

    Seriously though, it really depends on where you are, market wise, and where you want to be. There are a lot jobs around here for Java programmers that understand Spring and Hibernate. However, the people hiring for those jobs are looking for competence, and little else. You won't be able to ask for a great salary in those conditions, because while good performers aren't that easy to find, the hiring pool is also pretty large.

    Instead, imagine that you have 15 years of experience, and you want to remain technical. At that point, having a decade of experience on the exact same thing won't really help you. Your selling point has to be that you've seen everything, and that you are up to date with the latest and greatest. So you don't look for yet another generic job with popular tools: You have to learn shiny new things, and sell that your know-how with many tools means you'll make a lot less architectural mistakes than a youngster. At the same time, this gives you a chance of getting into a technology early, when finding experienced people is harder. You ride the top of the wave, get paid well, and can keep in the tech switching train.

    Soyou need both serious knowledge of a couple of popular languages, and then to try to spend your time working on the less popular ones, that are still growing, because that's where real opportunity is.

    1. Re:Highschool girl logic by HeckRuler · · Score: 3, Interesting

      At that point, having a decade of experience on the exact same thing won't really help you

      ... unless you specialized in something that's still used, and the company you're at still uses it or some other company out there needs it.

      I mean, if the "thing" you did for those 15 years was streamlining TCP traffic in assembly, then you could go make $500,000/year as a quant dev on wallstreet. If it was abstract computer generated graphics in turboPascal... then not so much.

      So yeah, it depends on where you are market-wise. Sometimes specializing is a good idea. Sometimes it pays to be a generalist.

      Personally? I went with embedded C and every now and then dip into general business applications just so I'm not super-specialized. But so far, low-level C has been a stable bedrock for a career. And I don't think I'm being too optimistic when I say it's probably going to stay that way.

  30. I use cobol, you insensitive clod! by nimbius · · Score: 5, Funny

    I work for a financial institution that rhymes with race, and im paid handsomly for nothing short of necromancy and time travel. my cobol applications interface with 50 year old cobol applications, which in turn interface with java, which runs in a godless vortex of jboss and tomcat. the accounts division I write for is beginning to suspect im some kind of evil witch that lives on the 5th floor and creates their reports over a fuming cauldron. I have in the past transferred money in my checking account using the original cobol-85 nested subprograms written to handle some of the first ATM's ever invented. Security has, on two separate occasions, mistaken me for a hobo trying to steal a laptop.

    --
    Good people go to bed earlier.
    1. Re:I use cobol, you insensitive clod! by GlobalEcho · · Score: 1

      If you have not yet read Charles Stross' Laundry novels, now is the time.

  31. Job vs interview by ColonelPanic · · Score: 1

    You may not get to use much Haskell on the job at Google, but I guarantee you that really knowing Haskell is one of the best ways to *get* the job.

    --
    "Skill shows through where genius wears thin." -Wittgenstein || Religion: uniting aviation and architecture.
  32. Theory vs Practice by corporate+zombie · · Score: 1

    It's not being an expert at some particular language that ends up paying. It's being an expert. You will always have to play your cards right but there are high paying jobs in any of the languages. Figure out the style you like, become an expert in one of its mainline languages, play your cards right, profit.

  33. Lucrative for whom? by Dcnjoe60 · · Score: 1

    Lucrative is relative. Yes, COBOL programmers are in demand right now, because most of them have retired. Does that mean somebody just starting out should expend the resources and time to learn COBOL? Probably not, because the return on their personal investment would be less than if they spent it on more current/in-demand technologies. OTOH, a programmer that already has COBOL experience, can still find employment.

    It's like buggy whips. As the buggy was replaced by the automobile, the demand for buggy whips declined. However, until horse buggies were completely gone, there was still a demand, albeit smaller than in its heyday, for buggy whips. If you were an experienced buggy whip maker, you could still find employment making buggy whips. However, it would not have been a field for a new apprentice to enter.

    Likewise with COBOL and the other languages mentioned. There is still demand for programmers with that knowledge, but it isn't a growing field. At some point the cost to maintain the code will become higher than converting the code because the cost of COBOL programmers will be too great given the supply and demand curve. For those who currently are COBOL programmers, that bodes well, but not for somebody just entering software development.

    BTW, I use COBOL in the above languages, but the statements apply to most long lasting programming languages, not just COBOL.

    1. Re:Lucrative for whom? by oh_my_080980980 · · Score: 1

      LMOL yeah they've been saying that for decades and yet COBOL is still here. I don't think you understand how much it would cost to re-write those COBOL application. You are not converting code. There's no magical button that will transform COBOL into the flavor of the month language. You are starting from scratch and oh you need to bring in the existing data. GOOD LUCK!

      It's far more lucrative to learn COBOL than the latest flavor of the month where it's easier to outsource you to some guy in India. It's far easier to fill positions that use popular languages. It also means your pay will be lower because of the competition.

      It comes down to what you want to do and what industry you want to work. COBOL could be a very good learning experience even if you don't plan on being their for the rest of your career.

  34. Re: Bullcrap by thetoadwarrior · · Score: 1

    Since it's about making money obviously they're not talking about what academics use to make themselves feel special.

  35. Supply vs demand not popularity which matters by abies · · Score: 2

    I would probably avoid looking into Clojure or Scala to make money based on popularity. Problem is that these languages are 'cool' which means that there is considerable amount of good programmers playing with them in free time and willing to take a job where they could code in that. Let's say that there are
    - 2 million java programmers
    - 2.1 million java jobs
    Doesn't look good? But if you compare it to (completely random numbers)
    - 50k Clojure programmers
    - 1k Clojure jobs
    Then the fact that there is 40 times less Clojure that java programmers is not going to help you much.

    If you are trying to game the popularity, you need to find languages platform which are in some demand, skillset is rare and they are horrible to work with. With that, you may get into job which you will hate, but you will be paid a good money and have job security.

    Look what is happening with game development. So many people want to work there that you work very long hours and pay is very low. I knew some people who were willing to get pay cut to switch from Java to Scala. They weren't learning Scala to earn more, but to have fun again.

    From my experience, domain you work in has a lot bigger factor in salary than platform. Investment banking people will earn same money, regardless if they code C#, java, C++ or python, but might get considerably different packages based on domain knowledge and actual skill. Game developers will be paid badly regardless if they do Flash, Android (talking about salaries, not indie games) or C++.

    Switching language in same industry can give you maybe 20-30% salary increase? Switching industries can double or triple it.

    Examples:
    C# developer with 5 years experience in banking
    http://jobview.monster.co.uk/C...
    600-700 GBP per day (which gives 130-150k yearly)
    plus plenty of other 500-600 GBP per day jobs.

    Web C# jobs outside banking (same city)
    30-50k GBP yearly
    and no offer for daily contracts.

    Learning Scala just to move from 30k to 35k job is not worth it. If you want money, go for proper industry. Learn languages/platforms if you want to have fun in work - but then base it on what you want, not what is best paid.

    1. Re:Supply vs demand not popularity which matters by angel'o'sphere · · Score: 1

      ROFL, learn to read.
      The 600 - 700 GBP job is not a C# job, besides it requires development in C#. It is a 'financial trader' job ... you have to develop in an trading environment at financial institutions. That is the core requirement. If you have no background in trading and finances you never get that job ... regardless of your C# skills.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    2. Re:Supply vs demand not popularity which matters by abies · · Score: 1

      I can read. It is C# job for programmer, not for trader. It is C# frontend development, most probably to display UI for risk metrics for daily trading. Yes, you need to have experience with working in investment banking, same way as you won't get accepted into certain jobs without knowing browser quirks, physics or whatever is needed in given environment. As for getting accepted without finance background for similar jobs - indeed it might be hard, but everybody starts somewhere, people are not born with that knowledge. There are offers which accept good programmers even without background in that area (not contracts, but still good money) and in few years you already will get the experience.
      You might be confused with some job offers which call for quants - these are indeed quite different profile, where programming is secondary requirement (but it will be mostly C++, not java/C# and it will mention quantitive finance somewhere in requirements). Plus they pay better.

      In any case, it is what I'm talking about. Experience in proper domains will earn you a lot more money than experience proper languages. I know about investment banking and game companes, so I gave these examples, but similar discrepancies might exists in other industries. You just need to get out of the mindset of "I'm programmer so I can code in A whatever you throw at me with no knowledge of domain" to "I'm expert in domain XYZ and can code that in any language you ask me for (with preference for A and B)"
      And no, HTML or J2EE is not a 'domain' in my understanding. Investment banking, 3d games, biotechnology, nuclear simulation, GIS etc is what I mean.

    3. Re:Supply vs demand not popularity which matters by angel'o'sphere · · Score: 1

      You are mistaken, the job you linked explicitely wants an expert intrading algorithms and implementation of wishes of the trsders. C#/WPF just happens to be the language/technology used for developing it.

      o Pricing and risk systems development is a prerequsitie
      o Rates or credit business knowledge is highly desirable
      o Degree educated or higher from a leading academic institution

      And more importantly:

      As a C# developer you will be responsible for full lifecycle software development, working with traders and business users in order to define and analyse requirements for the pricing and risk system, developing client side solutions for intraday risk and pricing, for the high volume swap and government bond trading desks.

      Should I underline "working with traders and business users" or "analyse requirements for the pricing and risk system" or "solutions for intraday risk and pricing" or "for the high volume swap and government bond trading desks".
      I rarely use C# but I bet I would come into the last three for that Job with my Java knowledge and my financial trading background on Calypso and Endur platforms.
      No one pays 600-700GBP (a day) for a mere C# developer, you are bigly mistaken.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    4. Re:Supply vs demand not popularity which matters by abies · · Score: 1

      I'm not saying anything of that. I was saying that:
      - it is a job for a programmer, not for trader
      - that is is possible to get neccessary experience in just few years to qualify for such job (if you are good)
      - that key part here is that you know the domain (investment banking), rather than C# itself
      I think that we agree on all that? And this is point I want to make - instead of learning C+-%&^!, train into well paying industry and utilize whatever skills you already have.

      Said that, few more points:
      - it is a lot easier to get into such positions starting from good IT background and then learning finance on the job rather than having financial background and learning how to program
      - there are positions where they will accept good people without financial background for money which is still considerably bigger (2x?) than anything in web-programming
      - there are positions where they will accept very good people without financial background for exactly same money (I was hiring for one few months ago, where we were looking for soft/hard-realtime programmers, paying normal investment banking daily rates)
      - it is not just 8-5 job in many cases, but it is not as scary as stories about game development crunches (unless you get into small hedge funds, but then you are asking for that...)

      From my experience, biggest issue to overcome for people from 'outside' is not lack of financial knowledge, but rather mindset. A lot of programmers enjoy living in walled garden, with requirements coming in controlled agile fashion, well defined sprints, not caring about final deliveries after unit/integration tests have run, not having to face end users pointing your mistakes to you and abstracting away clients to be far away evil. But that is separate story.

  36. Key skills by biodata · · Score: 1

    The knowledge that consistently pays best is how to bring a project in on time, to budget, working and accessible by users, and how to communicate well with other people.

    --
    Korma: Good
  37. Drake's equation for getting the job? by istartedi · · Score: 1

    E*D*M*T*P*J*

    Where E=documented experience, D=degree or other credential, M=motivation, T=talent, P=practice, and J= the number of jobs available.

    If you have a really high E for COBOL, maybe it will overcome the low J. Same deal with a lot of these other unpopular languages. That's not to say "life" won't develop on some unlikely "planet", but it's not the best place to look.

    Standard disclaimer: I'm leaving out some factors, and any ridiculous inference you've just made is not what I meant to imply.

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
  38. False dilemma? by Art3x · · Score: 1

    A programmer should be able to pick up another language in a matter of weeks and master it within a year. Do your best in whatever language you like or need now. While it's fun to talk about the pros and cons of different languages, the idea of being stuck in a language is silly.

    DISCLAIMER: You may have to network socially to bypass those who rely too much on words in resumes. You may have to do a couple hobby projects. You may have to take a pay cut while an employer waits for you to get up to speed.

    1. Re:False dilemma? by angel'o'sphere · · Score: 1

      Well, the usual mantra is "in a matter of days".
      But COBOL certainly is beyond days and even weeks. I would plan in a three month period if I would like to learn it thoroughly.
      (And I did more than a year Y2K reengineering in/on COBOL based systems ... actually, you don't need many COBOL skills to do Y2K reengineering, but it showed me: it is a fascinating language)

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  39. Avoid pigeonholing and this can work. by ErichTheRed · · Score: 4, Insightful

    I'm a systems architect with a company that does IT services for the airline industry. Airlines are the third oldest users of computers, next to banks and the military. There has been an amazing amount of legacy technology that has been built around for the last 60+ years. Systems that are running modern languages and OSes today need to interface with systems via IATA protocols that were invented decades ago. Even though those legacy systems may run on new mainframes, they're still speaking the exact same language they were when they were rolled out. All that whizzy new stuff passengers see (cell phone boarding passes, full function booking websites, etc.) is riding on top of an ancient core that fewer and fewer people know everything about.

    Anyway, my point is this -- we do have some people on staff who know about all these systems, and have built or worked on parts of them. They're paid very well, but I guarantee they would have a very difficult time finding work if they were suddenly not needed. The main reason for this is that they're solely dedicated to supporting these older systems. People sometimes allow themselves to be pigenholed into a single task or set of tasks. In my side of the house (systems engineering,) admin tasks are becoming like this through things like ITIL. ITIL is solely designed to remove any sort of judgement from an administration job so that you can plug an interchangeable human into any process, give them a runbook and tell them to execute only these steps when prompted. It's a huge problem, because the next generation of admins is having difficulty graduating to systems engineer and systems architect roles, simply because they don't have a big-picture view of everything.

    I've been with the same company for quite a while, but have taken this approach to managing my career -- never do the exact same thing for more than a few years. I get to work in the same field and do _similar_ projects, but I also don't stagnate into a single role. This is very difficult to do because it requires you to be very flexible and constantly learning new things. You need to push your way into new projects because managers will want to hang on to the skills you've developed. Because of this, you need to be willing to document your work and train a replacement when the time comes. Also, you need to actually have some depth in the technology you're working with. There must be 20 or 30 new web frameworks that come out every year, on top of everything else that exists out there. You could try to learn everything but you'd never get good enough at any of it to be useful. At the same time, specializing in ancient languages and systems may be lucrative but you need to be prepared to jump as soon as your skills aren't needed anymore.

    If you do it right, you can make a lot of money by being able to jump into a position that no one else knows anything about. But if you can't jump right back out, you will end up doing the same thing forever.

    1. Re:Avoid pigeonholing and this can work. by Anonymous Coward · · Score: 1

      Problem with specializing in niche: Economy of scale kills you. Management outsources their mainframe stuff. Outsourcers do more work with fewer people who get paid less (that's how they lowball management and do the work for less than you get paid). A lot of out of work people are competing for fewer, lower-paying jobs. There's a glut of people with your skills all of the sudden (that's why no one cares about training right now - this glut will persist another decade or so). Now you're screwed.

      You might think management cares about having people who know your code base. No, they see programmers as fungible, disposable commodities. The outsourcers are identical to you but cheaper, the way management thinks. Managers outsource now, and give themselves bonuses. They are gone to another job before anything goes wrong.

  40. Exactly: it's not about R, it's about statistics by golodh · · Score: 2
    As far as I can see around me, there are not many openings for mere "coders" who just happen to have picked up some training in R.

    Most R code does things like model fitting, parameter estimation, data visualisation, data analysis etc.. The code mostly is just a way to capture and operationalise an idea in statistics or data processing. If you can recognise, grasp, and follow through that idea then the code usually starts to make sense pretty quickly.

    On the other hand, if you can't, then you'll be hard put to understand the code on its own terms and you really shouldn't try to modify it because you won't know what to look out for.

    As I see it, the openings in "R" are for people who are "numerate", know about statistics, data analysis, a little database knowledge and who also happen to know R.

    People like that are also likely to be able to work effectively with SAS, SPSS, SQL, Matlab and other high-level programming languages.

  41. Easy answer by Yakasha · · Score: 1

    What are you looking for?

    If you're looking for a steady paycheck, or you're a talentless hack that can't compete with a flooded market, or you're a self-starter that can master a weird language quickly without any instruction (are there even COBOL books out there anymore? ;), mastering COBOL is a worthy route. As the work is out there, and the employees aren't, you'll be nice and safe demanding a reasonably good salary. Just know that the company you're working for will be largish, established, and not giving out any high-flying stock options. You'll be able to retire in 20 years... probably with something old people like to call a "pension".

    If you're looking for a lottery payout in the form of an IPO, or you're interested in cutting edge technology, or you're not sure what you want to do, or if you have no life and actually enjoy working 80 hours / week, or you want to do mobile phone development... then go for the more popular languages.

  42. It aint about the language by Neumann · · Score: 1

    it is about the codebase. Learning the language takes a week if you are going by a book and a day or 2 if you have actual working code to learn from. However, learning a codebase takes months/years.

  43. Devote your time to logic by chubs · · Score: 2

    It's better to devote your time to improving your logic, design and architecture skills. If your career is tied to the continued usefulness of a given language, you're almost guaranteed to eventually find yourself unemployed or forever locked into a maintenance job that doesn't allow you to create anything new or interesting. Hardly what I'd call a "great job", which you seem to believe you must paint yourself into a corner to obtain.
    Stop focusing on being a coder and start focusing on being a software developer. Learn about algorithm analysis and optimization. Learn about design patterns. Learn about software architecture. Apply those to whatever language the "great job" employer wants you to use.

  44. pfff, pick a truly "less popular" language by cellocgw · · Score: 1

    Go learn brainfuck and whitespace, and see how many jobs you can get with *those two* under your belt.

    (and LolCode, too!)

    --
    https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
  45. The Rolling Stones by holophrastic · · Score: 1

    The Rolling Stones make a lot of money, that doesn't mean that you should start a band. There are countless garage bands that make no money.

    Sure COBOL can net you big bucks, and a really great set of very stable clients; but how many of those do you think there are? and how many near you? that you can approach? and have the "other" industry qualifications that they require?

    Look, if you are passionate about old industrial equipment, then sure, you may be the guy for the job.

  46. Poorly worded mess ... by janoc · · Score: 1

    If someone puts together R, Haskell, Cobol and Fortran and declares them unpopular my bullshit detector goes off-scale. That person obviously has no clue.

    What exactly does make a language "unpopular"? That it isn't used to build whiz-bang websites or smartphone apps? Do they realize that languages like Cobol, Fortran and R are fairly specialized tools (data processing, math and statistics) and thus they will always live inside their little (or big) niche. Comparing these with something like C#, JavaScript, PHP, Swift is just retarded, it isn't even apples to oranges comparison. It is like declaring Matlab "unpopular", because there are no apps in Apple's AppStore written in it. About as relevant as yesterday news :(

    I don't really get what is the point of this type of article. Good programmer must learn to adapt, if someone thinks that they will learn *THE LANGUAGE* and then live off it until retirement, they are either being delusional or extremely stupid. Learn the underpinnings of the field instead - logic, theory of computation, language theory, data structures and algorithms, structured/object oriented, functional and declarative programming (to at least know that there are other approaches than just the usual imperative code!). Those things are going to be way more useful for any programmer than learning one or two programming languages. That is something that you will typically do in a few days/weeks when you will actually need it - if you know the basics and have some programming experience under your belt already, picking up a new language (not becoming an expert!) is easy.

  47. Re:Delphi still nets me an extra 50k or so a year. by HornWumpus · · Score: 1

    Repeat after me: 'Languages are easy. Libraries are hard.'

    Once you've got a dozen languages under you belt they are _all_ easy.

    That said a C++ builder should be able to pick up Delphi pretty quick.

    --
    John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
  48. Delphi 5 and 6 vs DelphXE## by Latent+Heat · · Score: 1
    Is there a divide between the community using Borland Delphi (say, Delphi through Version 7) and the current Embarcadero Delphi offerings?

    I kinda quit upgrading my Delphi install after Version 7 having switched to Java for the work I am doing going forward. I needed a 64-bit capable Delphi for something so I downloaded the Embarcadero Trial of one of the current Delphi versions.

    Besides New Delphi being a complete pig on resources, there is no comparison of its machine "footprint" to Visual Studio let along Classic Delphi (of which Delphi 7 is the "standard" because that is where Classic Delphi development stopped). I didn't do much with the trial install because I couldn't figure out the settings and modes on the compiler and I consider myself an old Delphi-hand. Attempting to compile a legacy Delphi 7 app with it resulted in a barrage of compiler errors.

    When I need to "do something 64-bit" (also cross-platform) in Delphi, I have switched to Lazarus/Free Pascal, which I understand is targeting Delphi 7 for clonage -- kinda like Linux distros targeting something somewhat but not completely unlike XP for the GUI experience with Microsoft having gone off into the ozone UI-wise with Windows 8.

    So, is it just me, or do others view Delphi 5-6-7 as the Windows 2000/XP of that world and the new Embarcadero offerings as being a whole 'nother language culture?

    1. Re:Delphi 5 and 6 vs DelphXE## by Mr.+Somey · · Score: 1

      It's not just you. Delphi 7 won't even install under post-XP Windows versions, though the applications compiled by it will still work.

      Still, I wouldn't call it a "dead" or even "unpopular" language at all, personally. They've made lots changes since 2002, most of them good, that would have resulted all the compiler errors you encountered - the switch to Unicode was probably the biggest one, starting with Delphi 2009. And for years, every new VCL was incompatible with the previous one, so if you didn't have the source code to your controls, you'd either have to dump them or wait for the controls' authors to update them (assume they were still in the business). More recent upgrades have been a lot less painful compatibility-wise, though as you say, they don't seem to have to have put much of a priority on footprint-reduction.

      Also, I should probably move to Atlanta.

  49. Comparative advantage by Stuntmonkey · · Score: 4, Insightful

    I have yet to see a young person say, "I'm going to learn COBOL so I can spend my career nursing 40-year old code." You want to be building new things instead, and for that you choose the best tools for the job right this moment. Those are also usually the skills that will make you most marketable to companies that are building new things.

    Conversely it's rare to see an IT person keep up with the latest technologies throughout their careers. At a certain point in life you get other things that need attention, such as raising kids, taking care of parents, mowing the lawn, or whatever. And you start to get more risk averse because people depend on you. Although you are very good at your job, truthfully your confidence starts to wane a bit when you see all the really good young people coming up, who can absorb the new skills with relative ease.

    The result is what economists refer to as comparative advantage: The younger people who are more adaptable focus on the latest and greatest technologies, and the older people focus on problems that benefit from their experience and judgment.

    1. Re:Comparative advantage by SecurityGuy · · Score: 1

      You also see enough new things to realize the latest and greatest is sometimes simply the latest. Now and again you see someone re-engineer something that works, and make it into a god-awful monstrosity that may fit the way its creator wants to work very well, but doesn't solve the underlying problem any better than the original. Build toolchains, for example, have had tools come and go, and more times than I want to remember the new and improved versions have simply become one more thing I have to troubleshoot when it doesn't work.

      I'm more than happy to learn something new, I just want some reason to believe it's better, not just new.

  50. Things never change... by Anonymous Coward · · Score: 1

    Patroclus: You told me never to change sword hands...
    Achilles: Yes. When you know how to use it, you won't be taking my orders.

    If you were ready to dabble in different programming paradigms or specialized languages... you wouldn't be asking us for permission.

  51. Does the OP know what they're talking about? by whitroth · · Score: 1

    Let's talk about R. Do they know what it is? I don't use it... I'm a sysadmin. But a number of my users do, heavily.

    How 'bout if I describe it this way it's free, and so it's a *lot* less expensive than the alternative: MatLab. That *is* what it's used for, guys. So, maybe it's "less popular" becuase the audience that uses it doesn't write, say, games or websites in it?

                      mark

  52. PHP? by wonkey_monkey · · Score: 1

    Unpopular Programming Languages That Are Still Lucrative

    PHP? Judging by past comments on here it's massively unpopular.

    Or did you mean "lesser-used"?

    --
    systemd is Roko's Basilisk.
  53. Re:Ada? by Drethon · · Score: 2

    And still required for some DOD development. I like Ada, if you can get it to compile it may still have a crap ton of bugs but it rarely if ever crashes...

  54. I've been programming as an employed Java web app developer for a few years. If hypothetically, there is another company looking to hire for a Scala developer position, would it be a good idea to take it? Assume no previous Scala experience is required and the company is willing to fully train on said language. Assume its also a great company

  55. My take on COBOL.... by erp_consultant · · Score: 1

    In large scale, enterprise class systems COBOL is still used extensively. For operations like Payroll that move huge amounts of data around, COBOL is the gold standard. Why? Other than the fact that much of the code was written a long time ago and just works, there are very few languages that can process large quantities of SQL as efficiently and as quickly as COBOL. That's what it was designed for.

    Now, you might argue that some of the modern languages can process just as quickly but many businesses are reluctant to change because:

    1) The COBOL code they have now has stood the test of time. It has been battle tested. It's rock solid.
    2) Many of the processes that COBOL handles are considered to be "mission critical" applications. If something goes wrong it will cause big headaches.
    3) The investment required, in time and resources, does not justify the return.

    So COBOL will probably continue to be around for a long time. What's it like to program in COBOL? It's wordy, procedural and in short not very sexy. But it's a good skill to have.

    To be successful at COBOL it's not enough to just know the syntax. To be valuable to an employer you also need to know the business processes and rules that need to be implemented in the code. If you are going to program COBOL for a Payroll system you better know Payroll inside and out. If you can get to that level then you can have a very successful career.

    1. Re:My take on COBOL.... by Alioth · · Score: 1

      SQL didn't exist until long after COBOL was a major thing. What COBOL is good at is dealing with fixed width record format flat files, which was a common way of storing stuff when COBOL was first invented. When you have a large complex system that's been going for decades, is fully debugged, and just works there is a huge cost in rewriting it that may just not be worth it.

    2. Re:My take on COBOL.... by erp_consultant · · Score: 1

      Interesting comment on the fixed width record format. I didn't know that. My friends on the DBA side of things told me about the SQL processing. Evidently, COBOL is extremely efficient at processing SQL. Perhaps not by design but in practice.

      But I think we both touched upon the real reason - it just works. A few places have tried to replace their COBOL code with mixed results. If it were me I'd just leave it as is.

  56. Re:Bullcrap by bzipitidoo · · Score: 4, Insightful

    The entire premise of the article is bull. Are companies ever going to get off this fixation on specific programming languages? There used to be such a thing as training. Companies once did that.

    Now it sounds like everyone has accepted that you should train on your own time. Worse, you have to do speculative training. Learn the specifics of some platform, and you might get a job doing it.

    --
    Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
  57. Why not? by plopez · · Score: 1

    1) Good for the resume. You never know where your next job might come from. Or your manager pops his/her head into your cube saying "We need to support client X and they only use language Y".
    2) Most of the popular languages are imperative, I am not sure why. Perhaps because that is all that is taught or that Joe Average Programmer cannot wrap their heads around functional languages. Get proficient at at least one functional language. It will challenge how you think.
    3) It's fun.

    --
    putting the 'B' in LGBTQ+
  58. MUMPS by fhic · · Score: 1

    Or M as it's known these days. It's a horrific mess of a language, but there's still a LOT of legacy code out there and it's nearly impossible to refactor M databases into anything more modern. No matter how much I try to move away from it, I keep getting pulled back in. But hey, it pays the mortgage!

  59. FoxPro and xBase (Re:In Theory) by Tablizer · · Score: 3, Interesting

    I wish there were an open-source version of FoxPro. There is the Harbour project for xBase, but it's not interpretive, and lacked many of the interactive features the last time I checked.

    FoxPro and xBase are great for hobby CRUD-centric or smaller data-centric projects: Lots of functionality with very little code because the imperative code could be tightly bound to the database rather than requiring application-code-to/from-SQL translation layers like the current stuff. One learned to "think in tables", and thus become a Tablizer. It's sort of like APL re-shaped by practical concerns.

    There's something magical about it in that it can dance nimbly between high table abstraction and nitty-gritty imperative fiddling code. Some try to compare it to LINQ, but LINQ feels like an add-on to the regular clunky way, and not part of a bigger united experience.

    The xBase approach may not work well for "big team" programming, but for certain projects it could scream.

    Ah, the good 'ol days. You Ruby-ites get off my lawn!

  60. Learn You A Haskell for Great Good by srobert · · Score: 1

    I'm not a programmer. Lately I started reading through http://learnyouahaskell.com/. I haven't gotten very far yet. My only purpose was to get a handle on the syntax in my xmonad configuration file. I had no idea it could be used to make money.

  61. Supply and demand by Theovon · · Score: 1

    In general, having a niche skill pays more if you can find a job in that niche. Companies that need that skill know it's a niche skill and one way or another end up realizing they have to offer higher salaries to attract the right talent. On the other hand, if you are an expert in COBOL and go to work doing web programming, they're not going to care, and your COBOL knowledge will have no impact on your income.

    That all being said, I don't understand the general fear people have of learning new languages. Sure, it takes time and effort, but it should be considered part of the craft. At Ohio State, the CSE department used to teach a language called Resolve for its beginning courses. It was DESIGNED to make things like data structures and algorithms easier to code, avoiding a lot of the cruft of other languages that is unrelated to the code that matters. But students complaned and complained about learning a language they'd never use again. My thinking is that if they're going to be successful, engineers need to be willing and able to learn new languages on their own time.

    At OSU, they eventually caved to student pressure and switched to Java. Why they chose Java is beyond me. Where I teach now, they use Python, and that makes a hell of a lot more sense to me. If you're entirely new to programming, there is a lot of boilerplate (from the perspective of the uninitiated) Java code you have to write just to do simple things that is unnecessary when writing Python.

  62. R is less popular? by neurovish · · Score: 1

    What is R less popular than? That's the only language I've ever really heard of stats and math-types seriously using.

    1. Re:R is less popular? by rnturn · · Score: 1

      I, too, found it curious to call R ``unpopular''.

      If it means anything, a couple of years ago, doing a search on the internet for "R" was almost useless. Now entering just ``R'' into a Google search brings back , as a suggested search string, ``r programming language''. And as the first entry in that list. Seems to me that means it's not exactly ``unpopular'' when Google is suggesting it in the list of suggested searches. Of course, it could be that this article is the reason for ``r programming language'' percolating up in the list of suggestions.

      --
      CUR ALLOC 20195.....5804M
  63. Modula 3? by BenSchuarmer · · Score: 1

    Anybody?

  64. Re:Bullcrap by gnupun · · Score: 1

    Is Facebook huge enough? See haxl

  65. COBOL - it's all about the data by Animats · · Score: 1

    Nothing ever came along to replace COBOL which took data storage as seriously as COBOL did. COBOL has DATA DIVISION syntax for talking about file formats and databases. No other language has syntax for talking about the external representation of data. This is a lack.

    Look at how much code goes into taking data out of an SQL database and into an object in Java or Python. And what a pain it is to change the code when the table format changes. It really is a lack that modern languages don't deal with external data well.

    This is a special case of the marshalling problem. Programs are always packing data into some specified form for transport or storage. It's an operation which often needs to go fast, and is a clear win if done in hard-compiled code. Yet there's little language support for this. There are precompilers which compile Google protocol buffer definitions into C++ or Go. There are interpreters for Python which understand a SOAP protocol spec and decode, slowly, the XML accordingly. Those are add-ons. Language support for marshalling is very rare, if not nonexistent.

    1. Re:COBOL - it's all about the data by Alioth · · Score: 1

      COBOL is just as disadvantaged in dealing with an SQL database. All that DATA DIVISION syntax is about reading and writing flat files, not interacting with a database engine in a separate executable. (It's a while since I've done any COBOL so perhaps matters have changed now, but COBOL was always about fixed width record flat files).

      My Java code needs no changes if table formats changed (things like added columns) because I try to use the supplied classes and the JDBC properly (and also take the time to make sure the database is designed right - such as using views, so the underlying data format can be changed without requiring all the things that depend on it to change).

  66. Re:Bullcrap by khellendros1984 · · Score: 1

    Are companies ever going to get off this fixation on specific programming languages?

    About the same time that they get over the fixation on specific college degrees. I was hired as a C++ developer, but I've touched code in half a dozen languages besides that, and I didn't know a few of those before I had to use them.

    --
    It is pitch black. You are likely to be eaten by a grue.
  67. SNOBOL by Joe_NoOne · · Score: 1

    Anyone remember SNOBOL (StriNg Oriented and symBOlic Language)? My Dad was a systems analyst and worked a lot with COBOL and SNOBOL. I used to go in to work with him on the weekends when he'd pickup the output from his batch jobs (no real-time processing back then) and often I'd just play with the card-punch machine. We'd take the "chads" from the machine's bin and put it in a bag and take it home to use as hamster shavings...

    1. Re:SNOBOL by david_thornley · · Score: 1

      I had to do a project in it for a class. The string handling was absolutely marvelous, but the control structures made me want to scream.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  68. Re:Bullcrap by plover · · Score: 3, Insightful

    The entire premise of the article is bull. Are companies ever going to get off this fixation on specific programming languages?

    No. Companies (at least the executives running them) look at their code base differently than technologists. They see the cost of maintenance as X$, and if it's written in ten languages, the cost of hiring ten people to do maintenance is 10X. If you say "one person can know ten languages" they assume such people are expensive and very hard to find.

    They want a simple way to manage the cost of maintenance. Cutting the number of languages in use accomplishes that goal, in their minds. Therefore, this practice will continue at companies that don't have unlimited IT budgets.

    --
    John
  69. Re:Bullcrap by ultranova · · Score: 2

    There used to be such a thing as training. Companies once did that.

    And they still do. They just want to pretend new recruits are up to speed right away. That looks better on the balance sheet, I guess.

    It's all about the appearance of efficiency, rather than actual efficiency. You get the former by measuring and micro-managing everything, and the latter by ensuring your employees want you to succeed and then cooperating with them. Yet companies insist on re-enacting Soviet Union in their own structures and practices, with predictable results. So I gues it's true that enemies will always end up resembling each other...

    --

    Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

  70. PDP-11 assembly!! by mwlphelps · · Score: 1
  71. Re:Ada? by micahraleigh · · Score: 1

    That's some broad strokes there!

  72. Re:Ada? by mekkab · · Score: 1

    hunh? it's the same language, but now there's tagged types (aka polymorphic, inheritable objects). String manipulation is still as much a nightmare as it's always been.

    --
    In the future, I would want to not be isolated from my friends in the Space Station.
  73. missing the point - cobol is not unpopular by smylingsam · · Score: 2

    Here is a list of truly unpopular (almost hated) languages that I know folks make over us$150,000 using:

    - Delphi / pascal (automotive, process control, chemical )
    - Forth (embedded)
    - Basic (a large array of strange niches from chemical processing , manufacturing assembly lines, scientific etc )
    - visual basic 6 ( chemical and scientific )
    - Lisp (autocad scripting , embeded and graphics processing/simulation creation )
    - Q&A database aka Sesame database (seriously I have no idea who uses this but I keep coming across jobs for this)

    none of the languages are seen on open forums like monster or dice but rather are direct hire, strange recruiter spam and consultant gigs from the niche language mailing lists.

    1. Re:missing the point - cobol is not unpopular by Wootery · · Score: 1

      FORTH go conquer and

      How people get their heads around that paradigm I don't think I'll ever know.

  74. Re:Delphi still nets me an extra 50k or so a year. by Anrego · · Score: 1

    Repeat after me: 'Languages are easy. Libraries are hard.'

    So much this!

    And not just the libraries, but the entire tool stack. Sure a c++ guy can pick up java the language fairly quickly, but there are a shit tonne of widely used libraries and tools that require anywhere from weeks to months of solid experience to really become proficient in, and some that are complex enough that you can build a whole career on them.

    Sure the principles carry over mostly, but there's still plenty of stuff in the details bin that doesn't.

  75. Re:Exactly: it's not about R, it's about statistic by Kagato · · Score: 1

    Indeed. It helps that R is the learning language many stats programs use in college these days. Often the college kids no more than the experienced Matlab/SAS folks. It also helps that many "big data" databases will natively run R code. HP Vertica in fact will split and optimize R between all the nodes in the cluster.

    R is definitely a language on the rise for big data applications.

  76. No love for D? by Wootery · · Score: 1

    D's a pretty good language, if you're looking for something a little higher-level than C++ and without the C++ warts, and if you can forgive a little language instability. It's not that obscure.

    (Was TIOBE always such a JavaScript-only mess?)

  77. More tools by Walter+White · · Score: 1

    The more tools you have in your box (that you are actually skillful with), the more valuable you will be to any given employer/client. I got my foot in the door at a particular trading shop because I could program in C/C++ on OS/2. Later on I did another job for them because no one there wanted to deal with SNA networking. Skills like that earned me a *lot* of money over the years.

  78. ALGOL by Kittenman · · Score: 1

    Paid my rent for many a year. I dabble in it less now (some work in Powershell to do) but still my first love.

    --
    "The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
  79. HTML5 is a language. by rjh · · Score: 1

    HTML5 is, indeed, a programming language -- at least when paired with CSS3. You can implement Rule 110 in nothing but HTML5 + CSS3, and Rule 110 is known to be Turing-complete. Ergo, HTML5 + CSS3 is capable of any computable process, and is a full programming language.

    It's a horrible programming language, but hey, when has that gotten in the way of widespread acceptance?

    1. Re:HTML5 is a language. by globaljustin · · Score: 1

      i agree!

      IMHO the Turing test is a solipsism...i use a conceptual definition of code: for me personally any system of alpha/numberic that programs machine behavior is "code" and the act of using that code to return specific behavior is "programing"

      i just think the whole Turing thing is irrelevant, and the computability function kind of goes along with it...it's all an unnecessary abrstraction describing machines and their function

      i mentioned the 'HTML5 is not a language' controversy because i've seen alot of trolls on /. saying it is not (and they are therefore somehow superior) and TFA clearly is written by a programmer and he included them as languages

      --
      Thank you Dave Raggett
  80. Re:Bullcrap by MikeBabcock · · Score: 1

    Why would a company train you to learn a language you should be able to pick up on the job if you can program well enough in similar languages?
    That's like expecting GM to teach you how to use a wrench.

    --
    - Michael T. Babcock (Yes, I blog)
  81. Re:Bullcrap by kmoser · · Score: 1

    The entire premise of the article is bull. Are companies ever going to get off this fixation on specific programming languages?

    No. Companies (at least the executives running them) look at their code base differently than technologists. They see the cost of maintenance as X$, and if it's written in ten languages, the cost of hiring ten people to do maintenance is 10X. If you say "one person can know ten languages" they assume such people are expensive and very hard to find.

    They want a simple way to manage the cost of maintenance. Cutting the number of languages in use accomplishes that goal, in their minds. Therefore, this practice will continue at companies that don't have unlimited IT budgets.

    Generally speaking, the more languages a programmer knows, the higher a salary they can command. What's unintuitive about that?

  82. Old hat thoughts... by servant · · Score: 1
    If you know COBOL and FORTRAN already, sell your efforts to the highest bidder. Those of us that remember the days when COBOL and FORTRAN were king have put up with learning 'popular languages', OO, Agile programming, etc. Every change is hard, and getting harder as we age.

    For younger folks, if you want to learn and do some projects in COBOL and/or FORTRAN, even assembler, it will give you a different perspective on computing. It will possibly give you another tool to generate an income stream, but I would not do it for the money, it must, IMHO, be for the passion of learning and understanding of the history of this industry. A side benefit is the new skill set and opportunity for income that may or may not pay off.

    In the day, there were other 'special purpose' languages. Forth, Easytreve, Snobol, EasyOut, RPG, APL, etc. These were all great languages for their purpose, some uber small and simple, some mathematically fantastic, some had optimized I/O, some just obtuse for no other reason.

    A number of the languages you mentioned, R, Scala, Haskell, Clojure, go on this list. Most are for general use, most are good for learning, not necessarily designed for commercial use.

    COBOL and to a lesser extent FORTRAN, only gained acceptance because the industry was forced into acceptance by the 900# gorilla in the room, the DOD. Like the Interstate highway system, what was done for military purpose this time became a boon to the industry. The DOD tried again with ADA, but that one failed to illicit such a great commercial response. (I am not defending COBOL or FORTRAN as great computing platforms, but as a necessity for the times.)

    Right now, C and even C++ are getting a bit long in the tooth. Java too, but more from a language architecture and implementation than the base language itself. I think we do need some new or new implementation of a 'killer language' or so to consolidate education and industry. We should possibly break into a handful of 'great' languages. Bean counting, graphics, hard-real-time, 'super-cluster/mesh' computing, possibly even for portable devices, small and large control systems, even networking, and even with built in inherent security. What form will it take? That part of my crystal ball is very fuzzy. But I do see it needs to be done.

    --
    ... "When you pry the source from my cold dead hands."
    1. Re:Old hat thoughts... by david_thornley · · Score: 1

      COBOL and FORTRAN also thrived because there really wasn't that much competition. IBM tried to replace them with PL/I, which tried to combine the best features of COBOL, FORTRAN, and ALGOL with some nearly incomprehensible rules on number formats.

      C is not a good general-purpose language, because there's a whole lot of better ones for just writing a program. Most of these languages aren't as close to the metal as C (C++ and Objective-C can do just as well there, of course), and there's a definite need for a close-to-the-metal language.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  83. Well, that's lame! by Latent+Heat · · Score: 1
    So an otherwise correct Delphi 7 program that uses strings won't compile? They couldn't bring themselves to keeping the legacy string types and introducing a "Ustring" or some such new type?

    The 32-bit to 64-bit change is a big jump, but int (32-bit) and long (64-bit) have the same meaning in Java whether 32 or 64 bit, and the "integer models" of C and C++ are OS dependent, but they made some effort to ease the transition. Here, you are telling me that Delphi 2009+ is a totally different and incompatible language from Delphi 7, that they didn't even make an attempt at a smooth migration path?

    That gets back to my original question/observation. It does seem that there is a "Lost World" of Delphi programmers and application users still living in the era of Delphi 7, either out of sloth, inertia, legacy systems, or that Embarcadero has gone off into the ozone layer of the stratosphere with their product offerings, and this Lost World is cut off from the Embarcadero World.

    Oh, don't move to Atlanta because you are experienced in Delphi. The traffic alone in the Atlanta Metro area will make the 6-figure pay not worth it.

    1. Re:Well, that's lame! by Mr.+Somey · · Score: 1

      It wasn't (isn't?) that bad. What would sometimes happen was, if you had a program in Delphi 7 that depended on a third-party component, and you upgraded to Delphi 2009 or later, and got a new version of that component that had been converted to Unicode support, your code might not compile unless you changed your string declarations. But if you only used stock VCL components, you'd almost never have a problem, or if you did it would be fairly trivial to fix.

      Unfortunately, third-party VCL components were always one of the main attractions of Delphi, and a lot of third-party database components (including many of the ones available for xBase, which was still big back then) were converted to Unicode that way because (I assume) it was just impractical to try to have it access data files both ways. Another problem was components making Windows API calls. Delphi 1.0 Object Pascal strings were 256-byte arrays, and starting with Delphi 2, dynamically-allocated 32-bit arrays - but Windows API calls have always required null-terminated pointer strings (PChars). So if one of your older components made a WinAPI call, you'd sometimes get compiler errors/warnings about type incompatibility after an upgrade.

      It was a PITA in some cases, but generally speaking you only had to fix it once. No fun, but as long as you had the source code for your VCL components, it wasn't so bad - I still thought it was better than Visual Studio, at the time at least. That was back in the COM days, and COM components had their own set of compatibility problems. (Still do, actually!)

  84. Re:Bullcrap by rubycodez · · Score: 1

    No, the Facebook stack is not built using Haskell.

  85. Re:Bullcrap by rubycodez · · Score: 1

    but the point is that it's fringe language, not very popular at all and no job openings for it.

  86. The reason by cwsumner · · Score: 1

    The reason that the old programs must be maintained, is that the people that wrote them were smarter than you and knew more about what the company needed.
    If you throw it away and try to re-write the programs in a new system, they will lose functionality and much of the remaining functionality will be wrong.
    The existing specifications are always incomplete, so the only complete record of what is running is the source code for the old programs.
    Just because you find learning other peoples programs to be very frustrating, does not mean you can avoid learning it.
    The second step, in learning anything new, is frustration. If you avoid frustration, you will never learn anything new.

    By the way, I'm using the Clarion development system. http://www.softvelocity.com/

  87. COBOL by smithmc · · Score: 1

    Yeesh. My school taught COBOL and FORTRAN, but only for non-CS majors. ME students had to take FORTRAN IIRC, but CS majors couldn't receive credit for either course. CS majors started with Pascal and went from there into C, C++ and assembly (Java wasn't a thing yet).

    --
    Downmodding is the refuge of the weak. Don't downmod, make a better argument!