Slashdot Mirror


The Working Dead: Which IT Jobs Are Bound For Extinction? (infoworld.com)

Slashdot reader snydeq shares an InfoWorld article identifying "The Working Dead: IT Jobs Bound For Extinction." Here's some of its predictions.
  • The president of one job leadership consultancy argues C and C++ coders will soon be as obsolete as Cobol programmers. "The entire world has gone to Java or .Net. You still find C++ coders in financial companies because their systems are built on that, but they're disappearing."
  • A data scientist at Stack Overflow "says demand for PHP, WordPress, and LAMP skills are seeing a steady decline, while newer frameworks and languages like React, Angular, and Scala are on the rise."
  • The CEO and co-founder of an anonymous virtual private network service says "The rise of Azure and the Linux takeover has put most Windows admins out of work. Many of my old colleagues have had to retrain for Linux or go into something else entirely."
  • In addition, "Thanks to the massive migration to the cloud, listings for jobs that involve maintaining IT infrastructure, like network engineer or system administrator, are trending downward, notes Terence Chiu, vice president of careers site Indeed Prime."
  • The CTO of the job site Ladders adds that Smalltalk, Flex, and Pascal "quickly went from being popular to being only useful for maintaining older systems. Engineers and programmers need to continually learn new languages, or they'll find themselves maintaining systems instead of creating new products."
  • The president of Dice.com says "Right now, Java and Python are really hot. In five years they may not be... jobs are changing all the time, and that's a real pain point for tech professionals."

But the regional dean of Northeastern University-Silicon Valley has the glummest prediction of all. "If I were to look at a crystal ball, I don't think the world's going to need as many coders after 2020. Ninety percent of coding is taking some business specs and translating them into computer logic. That's really ripe for machine learning and low-end AI."


5 of 581 comments (clear)

  1. What a load of BS by jonwil · · Score: 4, Informative

    C and C++ aren't going anywhere. Everything from operating system kernels to operating theater robots are programmed in C and/or C++.

    I count at least a dozen devices in my apartment that contain some sort of microprocessor and I would bet money that all of them are using C and/or C++ in some form as part of their software.

    Anyone who thinks C or C++ is going away anytime soon is either a clueless idiot or has some vested interest in pushing Java and .NET.

  2. Re:COBOL by scsirob · · Score: 4, Informative

    "You still find COBOL coders in financial companies because their systems are built on that"
    Fixed that for you. And those guys make a pretty bunch, for being obsolete.

    --
    To Terminate, or not to Terminate, that's the question - SCSIROB
  3. Re: Not dead just clueless writer by Anonymous Coward · · Score: 2, Informative

    Yes - the original Oak was meant for resource limited devices.
    But by the time it ended up as Java it no longer fit that requirement and was repositioned as Enterprise software building environment - and it's fairly successful as that. But the JVM and base libraries are now totally unfit for most cheap embedded devices. Which explains why it's not used for that.

  4. They also never look at embedded software by Sycraft-fu · · Score: 5, Informative

    These days, everything is a computer. Your stove, your car, your cable modem, your TV, all are computers. They all have microcontrollers or microprocessors in them to handle various functions. It is cheaper and easier than doing discrete dedicated logic, even for simple things. Well, those need software of course and it turns out C/C++ are the thing that gets used a lot because you have little memory and power to work with. Pennies count in mass production and the smaller a CU, RAM, flash, etc you can get away with the better, but that means the code needs to be small. You aren't loading up Windows and running .NET on a microwave, you are getting a little PIC24 or something and putting on some highly efficient, directed code.

    Because of all these embedded devices, there's a lot of market for this kind of thing, it just isn't the trendy shit you see on hip "Web 3.0" sites. It gets done by people with engineering backgrounds at big companies.

    Also, speaking of small embedded computers, regular computers themselves have tons of computers in them. Crack open a desktop and you find a lot of chips in there, many of them computers in their own right. Your NIC is a computer. A simple one to be sure, but it is a processor that runs code, it is not all hard wired. Your SSD is a computer, it has a little chip (ARM usually) that runs the code it needs to do its job. Again, someone is writing the code for all that and that code is not being written in Java.

    Even when you have a platform that at a high level runs Java/.NET/whatever it had a bunch of lower level code on it.

  5. Re:C and C++ aren't going away by Ambassador+Kosh · · Score: 3, Informative

    I am not talking about regular programs. I am talking about the types of high performance computing software that is usually run on large clusters or supercomputers.

    For the simplest possible case lets say you have to add up an array of tens of millions of doubles. On an x64 arch cache lines are normally 64 bytes which allows you to store 8 doubles at 8 bytes each. You can also use vectorization in a modern CPU and haswell and above can do do vector operations per cycle. If you break up the work to something small like 128 threads you need to break the whole thing up into very large chunks memory such that each chip gets a large contiguous memory region and such that each core in that chip also has a large contiguous memory region. You also need to allocate the memory to hold each cores temporary result such that none of them are on the same cache line or you will cause invalidations on every summation operation and have a large impact on performance.

    If you do all of this completely correctly then you are doing linear memory with unit 1 stride and that will allow the memory controller to optimally load in data while you are processing. You also use every entry in the cache line and a cache line never has to be fetched again. At the very last step you would need to read from 128 memory locations on different cache lines to do a final add but you did eliminate all false sharing.

    This is of course a trivial example meant to illustrate a point. Even just adding up lots of numbers can be quite complicated to make high performance. Sure a java program can do this but it won't be anywhere in the same ballpark speed wise. In a more realistic example you have to do this kind of optimization work but the problem is not so simple. Just designing a data structure that correctly works across all the different usage and ordering cases can take weeks of work and profiling.

    More commonly you have parallel processing that happens in phases where you have large parallel areas followed by sequential areas and then followed by parallel areas again that operate on the same pieces of data. If you are VERY careful you can keep the information you last used in the cache still and so long as you assign all the work to the same cores as they where assigned the first time all the memory access will be local. If you screw it up performance is often 10x to 100x worse on a ccNUMA system with 128 cores.

    This type of programming is programming is HARD but it is an area where C/C++ and Fortran completely dominate with no competitors around. Everything from molecular dynamics simulations, quantum simulations to chemical simulations and machine learning. This is an area where Java does not play in and Oracle is not even trying to push it in this area. When Oracle does high performance they do it with C/C++ usually and OpenMP. They have given some very interesting talks on OpenMP optimization.

    --
    Computer modeling for biotech drug manufacturing is HARD! :)