Top 10 Dead (or Dying) Computer Skills

Lucas123 writes "Computerworld reporter Mary Brandel spoke with academics and head hunters to compile this list of computer skills that are dying but may not yet have taken their last gasp. The article's message: Obsolescence is a relative — not absolute — term in the world of technology. 'In the early 1990s, it was all the rage to become a Certified NetWare Engineer, especially with Novell Inc. enjoying 90% market share for PC-based servers. "It seems like it happened overnight. Everyone had Novell, and within a two-year period, they'd all switched to NT," says David Hayes, president of HireMinds LLC in Cambridge, Mass.'"

Comments

c ? really?

[stoolpigeon]

doesn't really match up with my experience. and putting it next to powerbuilder? that's just not right.

Re:c ? really?

[WrongSizeGlass]

'C' will never die. Period. It has so many uses from PC's & 'big iron' to embedded systems.

Re:c ? really?

[fyngyrz]

No, C isn't in any way going out. C produces fast, tight code that so far, C++ and C# can't even begin to match. C++ is just C with a lot of baggage, a great deal of which you can implement in C in a completely controllable, transparent and maintainable manner. We use the most important of those regularly in C code, specifically objects and objects with methods. We obtain better performance, smaller executables, and smaller memory footprints than any company that makes similar software using C++ or Objective C's add-on paradigms. C, and the C sub-domain of C++ and so on, is no more "going away" than C++ itself is. C occupies a unique niche between the metal of assembly and the (so far) considerably less efficient higher level languages — I'm talking about results here, not code. I'm all about recognizing that a few lines of C++ are very convenient, but the cost of those lines is still too high to even think about abandoning C code for performance applications. For many, the object isn't finding the absolute easiest way to write code, but instead trying to find a balance between portability, reasonable code effort and high performance. C sits exactly in that niche. C++ is easier to write, almost as portable, but produces applications with large footprints, inherited, unfixable problems inside non-transparent objects (like Microsoft's treeview, to name one), and a considerable loss of speed as compared to a coder who has a good sense of just what the C compiler actually does (which usually means a C coder that has assembly experience, intimate knowledge of stacks and registers and heaps and so on.)

Speaking as the guy who does the hiring around here, If your resume shows C and assembler experience, you've made a great start. Even just assembler. C or C++ only, and your odds have dropped considerably. C, assembler and either a great math background or specifically signal processing, and now we're talking. C++ doesn't hurt your chances, but you won't get to use it around here. :)

Re:c ? really?

[tha_mink]

'C' will never die. Period. It has so many uses from PC's & 'big iron' to embedded systems. What is 'C'? Is that a language? Like latin?

I'm kidding, but only partially. I was a COBOL developer for lots of years, and I thought that COBOL would never die either. I would say "Too many companies are too invested ..." blah blah blah. I think that I actually even used the 'big iron' quote too when telling my friend how secure COBOL was. Um...I was wrong. I found that out with plenty of time to learn other stuff like Java and so forth but of course it's going to die. Just like C++ will die, just like Java will die, et al. If you've been in our business long enough, you should know better. Everything dies, it's just a matter of time. And if you think you're going to get 30 years out of the technologies that are new now, then you're wrong there too. That's the double edge sword that is the IT business. Keep learning, keep growing or start flipping burgers.

Re:c ? really?

[Chainsaw]

C produces fast, tight code that so far, C++ and C# can't even begin to match. C++ is just C with a lot of baggage, a great deal of which you can implement in C in a completely controllable, transparent and maintainable manner.

Wow. You must have had some really shitty software engineers. It's very likely that you can create C++ code that is as fast or faster than C. Yes, I said it. Implementing virtual inheritance and method overloading in plain C is doable, but it will be very complex. Templates? Don't even want to think about it.

C++ is easier to write, almost as portable, but produces applications with large footprints, inherited, unfixable problems inside non-transparent objects (like Microsoft's treeview, to name one), and a considerable loss of speed as compared to a coder who has a good sense of just what the C compiler actually does (which usually means a C coder that has assembly experience, intimate knowledge of stacks and registers and heaps and so on.)

I have no idea what the MS Treeview problem is, but once again - the programmers that you have worked with must have sucked balls. I'm an old C coder, with some solid x86 assembler knowledge. As you say, it's possible to get very high performing applications using C. However, why would I do that, when I can create code that is just as fast and much more readable by using C++? Yes - even for embedded development, which is my dayjob.

Re:c ? really?

[Penguinshit]

Or do what I did and move into management...

Re:c ? really?

[iamacat]

a great deal of which you can implement in C in a completely controllable, transparent and maintainable manner

So, when you have a small object with 10 methods, do you actually waste 40 bytes on 10 function pointers? Do you define your own virtual table structure, use var->vtable.move(var, x, y) kind of notation and require users to call non-virtual methods as ClassName_MethodName(obj, arg, ...)? What kind of C++ overhead are you avoiding here? How did you like the experience of incorporating a library whose developers implemented similar paradigms but different details and naming conventions into your code base?

Re:c ? really?

[WrongSizeGlass]

And if you think you're going to get 30 years out of the technologies that are new now, then you're wrong there too. I've been coding in 'C' for 24 years, and unless OS's, drivers, embedded systems, et al, stop caring about performance I think 'C' will out last me in this industry (and probably out live me, too).

That's the double edge sword that is the IT business. Keep learning, keep growing or start flipping burgers. I've coded in over 20 languages in my career, from assembly languages to proprietary 4GL's and everything in between, on more platforms than I have fingers. My library has programming texts older than most coders today. Keep learning? Great advice. Give up on 'C'? That's another story entirely ...

Re:c ? really?

[Rakshasa Taisab]

We've already gotten 35 years out of C, and it is still going strong. Not as much used at it used to be, but not insignificant.

In addition to that, you could say that the C we have today is an old 'stable' fork of that language, which is now moving ahead in the form of C++.

Re:c ? really?

[grumbel]

### C produces fast, tight code that so far,

So can other languages, I don't think that is the main selling point of C. I think the main selling point of C is that it is by far the most "compatible" language of all. Python, Perl, Ruby and friends are all based on C, if you want to extend the languages, you do so by writing a module using their C API. If you want to simply call C functions, you can do so from many other languages as well be it Lisp, Ada or whatever. If you want to talk to the kernel you do so in C. No matter what language you use, sooner or later you come to a point where you have to fall back and either write C or interface with C code, since C is the 'real thing', while everything else is just an ugly wrapper around C code, trying to hide it, but often failing at doing so properly.

As long as a ton of stuff is based on C code it isn't going away, especially not in the OpenSource world where basically everything is based on C.

Maybe one day some Java or .net based OS will take over, but I don't see that happening for many years or decade(s?) to come.

Re:c ? really?

[Anonymous Coward]

C's use at PC application level programming is over.

C as a vehicle for embedded programming is very much alive. I work as an embedded programming for devices ranging from 8 bit PIC's to DSP's and most things in between.

How would you like to code a TCP/IP stack in asm? It's not entertaining and while low power low cost embedded devices are more and more having ethernet MAC and PHY layers embedded in them C programming for these devices becomes more and more important. At the point where a $1.50 micro can give you 10+ mips, asm programming is more in danger of dieing than C.

If you have an embedded monitoring app i challenge you to find a more cost effective solution than using a PIC from the pic18f97j60 family, and you had between be comfortable with ANSI spec C to do anything really useful with it. At $5 a chip there is no easier way to add TCP/IP support to a low bandwidth application (the chip can sustain something around 5-6 MBit a sec while running useful code)

I think the REAL point that this article should make is that if you are only capable of programming in one language or API...your days are numbers no matter what, to exist in the engineering world of today you need to understand COMPUTING at a hardware level. At this point the language or API you use is trivial.

If you can't pick up a language or API after a week working with it you are simply in the wrong field.

-xian

Re:c ? really?

[jesuscyborg]

I'm kidding, but only partially. I was a COBOL developer for lots of years, and I thought that COBOL would never die either. I would say "Too many companies are too invested ..." blah blah blah. I think that I actually even used the 'big iron' quote too when telling my friend how secure COBOL was. Um...I was wrong. I found that out with plenty of time to learn other stuff like Java and so forth but of course it's going to die.

But you're forgetting the reason COBOL is dying is because the tech industry is moving away from the machines and operating systems that make use of COBOL. C will not die in the next half century because the tech industry is moving closer towards technologies that are built on C like GNU/Linux. If anything, C will become more prevalent.

In the next fifty years I imagine C's role more or less becoming that of the "mother language". 90% of the time everyone will be using higher level languages like Perl, Ruby, and Haskell on their Linux computers, all of which are programmed in C. Programmers will only need C when they need to change their lower level system tools, or to write new ones that perform very efficiently.

The only way I can see C dying is if a kernel comes along with a Linux compatible system interface that's written in a language suited better to the massively parallelized CPUs of the future. And once the kernel moves away from C, applications are bound to follow.

Re:c ? really?

[91degrees]

Nope. I know a C programmer. He developed code tht was launched on an Arianne 5 a couple of months ago. As long as you're good, there's a C programming job. You'll probably need to know a little assembly as well but I don't know many C programmers without at least some idea of the code their copmplier produces.

I could do that sort of thing but felt it was worth my while learning C++.

Re:c ? really?

[Plutonite]

You are definitely right, and it's not just because what happend over the last 24 years of your engineering history is likely to carry over..it's also the nature of the language itself. There is a reason C (and C++) are so damn popular, and the reason is that they embody most, if not all, of what can be done with a general purpose language. Things like Java and Python will stay for quite a while too, because the design there is more conforming to object-orientation while keeping most of the general-pupose flexibility, but C and the various assembly languages will never die. It would require a re-write of the entire architectural basis of computing to throw them out, and the theoretical part of computation theory does not need features that are unavailable here (yet). Anything that can be done in any language can be done (albeit less elegantly) with the aforesaid.

No one shall expel us from the Paradise that Richie has created (Apologies to David Hilbert)

Re:c ? really?

[Javagator]

I thought that COBOL would never die

Wait until Y3K. Then everyone will come crawling back, offering COBOL programmers big bucks.

Re:c ? really?

[multipartmixed]

So, Haskell only runs on one architecture? Or they write a different Haskell compiler for every architecture they support?

Damn, that's hard core. Not even GCC is that close to the metal! (except for a very, VERY tiny piece...)

Re:c ? really?

[nwbvt]

Well, yeah, every language will eventually fade out. But C is still going on strong, as its still the language of choice for many low level applications. I just searched Monster.com and found over 2500 jobs referencing C (its possible that some of the results are because the term "C" is too generic, but most of the titles indicate that C programming is actually part of the job), while Python gets 419, Ruby gets 168, PHP gets 612, and JavaScript gets 1736. How the hell can C be considered dead if its one of the most popular languages around, and probably still the best available choice for a huge class of applications (just not web applications)?

And in fact even the "dead and buried" Cobol is still alive, with 174 jobs. Now, its not as much as the more popular languages, but its still more than Ruby, which is supposed to be the next big thing.

Anyways, from TFA:

As the Web takes over, C languages are also becoming less relevant, according to Padveen. "C++ and C Sharp are still alive and kicking, but try to find a basic C-only programmer today, and you'll likely find a guy that's unemployed and/or training for a new skill," he says.

Despite what this guy thinks, web programming hasn't "taken over", and never will. Yes, it has a large niche, but there are many systems out there that are not, nor never will be web applications. Unfortunately some people (like this guy, he owns some dumb .com company that no one has ever heard of, how does that make him an expert on the subject) have tunnel vision and think that since they work on web applications, everyone else must as well.

Re:c ? really?

[gmack]

C is still a moving target.. slowly but still moving. Every Decade or so they release a new standard (C89, C99 etc). Some tasks are still more suited to C than C++ just like some tasks still need ASM.

Re:c ? really?

[Anonymous Coward]

Several times I've been told "nobody does assembler anymore", and yet I still keep needing to use it. I'm not writing whole applications in assembler of course. But the same reasons I keep having to do assembler are some of the same reasons that C is used. C and assembler may be less commonly used than in the past, but unlike COBOL, modern computer systems are still very heavily dependent upon them. Until we get a radically new form of computer architecture, which doesn't seem likely anytime soon, demand will remain for people who can write and maintain the guts of what happens underneath the applications. And you can't do that in Java or C# or Ruby.

Computerworld Magazine, being an IT rag, is concerned about IT, not computer science or engineering. Thus it worries about product names, not categories. So the point out skills in SNA or Novell Netware that aren't needed so much anymore, even though computer networking skills are even more popular and vital today than in the past. COBOL may be virtually dead, but dry and dusty applications for business purposes are alive and well and written by people who still wear ties.

Re:c ? really?

[gfody]

hi Peter

Re:c ? really?

[Max Littlemore]

I found that out with plenty of time to learn other stuff like Java and so forth

WTF? I mean, I can understand learning Java to update your skills, but forth? And how does learning java lead to learning forth anyway?

Must be one of those ancient COBOL codgers who's lost his marbles. ;-P

Re:c ? really?

[Critical Facilities]

Nicely done, although it should have been...

"Hey, Peter. Whaaat's happening?"

Re:c ? really?

[644bd346996]

Sure, some things still need to be done in assembly, but they are always wrapped in a C api. And that is why C will not die until computer architectures change drastically. C is close enough to the hardware that you really know what is going on, and you can control it directly. Languages like Java, which eschew pointers and mandate that all code be in a class, can never replace C.

In fact, no language that isn't pretty much C can replace C. If it doesn't give you the control over pointers and memory allocation that you have with C, it won't work as a replacement. If it does have those thing, it is not going to replace C unless it is a backwards compatible extension like C++ or Obj-C.

Re:c ? really?

[fishbowl]

>I'm surprised that Fortran didn't make the list.

I would have been, but working in scientific research I've discovered a couple of things that are surprising:

1. People actually do calculus on the whiteboard for reasons other than taking a math class.

2. Lots of people actually use FORTRAN. Even people whose Java, C, C++, Perl, Ruby, etc. skills are such that I look up to them -- and they have solid arguments for using FORTRAN, at least for certain kinds of numerical computing.

But here's the thing: There are separate worlds. In one world, the idea of using calculus on a daily basis is simply never a consideration. You learn enough to finish college, and that's the end of it. Likewise, there's a world where numerical computing and arbitrary precision and optimized complex arithmetic are actually primary considerations and not just hypothetical things.

I never understood this until I found myself in that world. And I wouldn't have believed you if you told me that people who know other languages, choose FORTRAN even when given a choice.

But what I take from it, is that there are requirements that are met by FORTRAN which are not met by languages that offer more comfortable grammars.

People (myself included) will argue that, for instance, C can do anything that FORTRAN can do, in a much happier grammar (opinion, mine, widely shared), but the thing is... while that's strictly true, a lot of the things that seem tangential or irrelevant, turn out to be *crucial*, where seriously optimized math support is the core of the application. FORTRAN makes guarantees on the kinds of things that are implementation dependent in C.

Anyway, there's no shortage of FORTRAN programmers. It's quite easy for a skilled programmer to learn FORTRAN, once you get past the 'WTF' factor and can accept that it's relevant in todays world, at least when your problem space is a good fit for the language.

COBOL or PL/1 and the like, make another story entirely. My experience has been that the role of COBOL has been replaced by the combination of transitions to modern RDBMS, decentralized business processes as a side-effect of the whole ubiquitous "PC" adoption, and the adoption of, for example, Enterprise Java. That covers one end of the spectrum, and the other end (the big corporate end) is covered by the evolution of vertical systems providers (e.g., Peoplesoft, SAP, SAIC).

Back on topic: If there's a university CS program that gives degrees without courses in Operating System and Compiler design taught in C, I'd love to hear about it. No way are C programmers in decreasing supply. If nothing else, the million or so open source projects have created a whole generation of self-taught folks who know C.

Re:c ? really?

[iamacat]

Umm... Thanks for insight into image filtering, but how are you avoiding the overhead of an equivalent C++ code? If you wrote your filters as C++ classes with virtual methods, you would be limited to 4/8 byte overhead (with single inheritance) no matter how many methods you have. You would have a consistent syntax for virtual and non-virtual methods. You would be able to more easily handle clean up with stack-based destructors and auto pointers. And your code would be still as small and fast as now. Perhaps even a bit faster, because you would be able to inline small functions and the compiler would optimize away some virtual calls to non-virtual.

All C++ compilers in the market have ability to turn off exceptions, which is the only feature that inherently generates larger/slower code (but not slower than "if (e 0) goto cleanup" after every function call) even when not used. It would be trivial to institute a coding convention of making all constructors explicit and add -Doperator=foobar -Dtemplate=foobar to your Makefiles to avoid generating unwanted code.

Re:c ? really?

[SadGeekHermit]

I think they're confused, anyway -- they're writers, not programmers. I bet I can even guess how they did their research: they called up all the recruiters they could find and asked each one to list the languages he/she thought were dead or dying. Then they compared notes on all the responses they got, and built their final list.

I think the list should be called "top 10 languages recruiters don't want to hear about" because that would be more accurate.

Realistically, as far as C goes I think the following factors should be considered before declaring it a dead language:

1. Most of the more popular object oriented languages (Java, C#, C++) use C syntax. C++ is a superset of C.

2. Java can use compiled C modules as an analog to C's old "escape to assembler" technique. In other words, you can call C code from Java when you have something you want to get "close to the metal" on. Thus, a "Java Programmer" may very well ALSO be a C programmer, even if technically that isn't on his resume or job description. I can do this; I imagine most other Java programmers can as well. What's funny is that, once you're calling C code, you can turn around and use the C code to call assembler, Fortran, or whatever else you like! What a weird world this is!

(Links for the skeptical):
http://www.csharp.com/javacfort.html (Ironic that it's on a CSharp site, no?)
http://www.mactech.com/articles/mactech/Vol.13/13. 09/CallingCCodefromJava/index.html
http://java.sun.com/developer/onlineTraining/Progr amming/JDCBook/jniexamp.html

3. Linux is still written in C, I believe. As are its drivers, KDE-related programs, Gnome-related programs, and whatnot.

4. C is the modern version of assembler, isn't it?

ANYway, I don't think C's going anywhere. You might not be able to get PAID for doing it, as your main speciality will probably be something more buzzword-heavy, but you'll probably be doing some of it as a part of whatever other weird and mysterious things you do in the ITU.

Poor journalists... One suspects they're rather easily confused these days.

Re:c ? really?

[atomicstrawberry]

When you say 'based on C', do you mean that the compiler / interpreter is written in C, or that the language itself is derived from C? Because technically Ruby is based off Perl and Smalltalk, not C. The Perl side of things can be traced back to C, but Smalltalk's origins are in Lisp.

However they are all implemented in C, as is PHP. In fact, I'm reasonably confident you'll find all of the web languages that the article declares are taking over are implemented using C. As is Apache, which is the backbone of the majority of internet servers. In fact, pretty much everything that provides important infrastructure is written in C.

There may be demand right now for programmers that know the latest fad high-level language, but the demand for competent C programmers has hardly disappeared. The only reason that C would die is if another fast, portable, general-purpose language like it came along that offered significant benefits over C. I can't personally see that happening any time soon.

Re:c ? really?

[mcmonkey]

If web apps will replace C then why is the hottest web company of all looking for C programmers?

Read
Ye olde tyme C programmer: What's this? A bona fide, genuine, certified job ad! Yes sir, a job ad.

Think
Mouse: What's this? Cheese? And served up on this little platform. Must be my lucky day, squeak.

*snap*

;)

Re:c ? really?

[Khashishi]

Any programmer worth his salt can pick up a new language in a couple hours. Hell, most languages today are just ALGOL with some syntactical refinements, and you know one, you know them all. I'm not worried if Java or C or Matlab dies out. What separates programmers is ability, not language experience.

Re:c ? really?

[nwbvt]

Sorry, but system programming itself is a huge category. Also many embedded applications use C, and believe it or not but many "run of the mill GUI apps" out there are developed in C, regardless of whether or not you personally feel they are too expensive to maintain.

Re:c ? really?

[Steavis]

If there's a university CS program that gives degrees without courses in Operating System and Compiler design taught in C, I'd love to hear about it.

Mine did. If I had chosen to, I could have made it through the entire curriculum primarily using Java.

My Operating Systems course had an assignment writing multi-threaded applications using semaphores and a simulated scheduler. You could write it in C or in Java. The option was there because about half the students never took C as part of their 100-level and 200-level core (you could take either Java or C). Compiler design was covered in one class, but it was entirely theoretical book work with no implementation IIRC (been a few years).

Some courses required using C or C++, but if you wanted to you could avoid them. Sure you get "exposure" to C/C++ in 200-level Intro to Programming Languages, but it was cursory at best unless you were self-directed. Even 3D graphics allowed the java openGL wrapper. Yuck.

My point is, you could have made it through with maybe one semester worth of very basic C. But like any educational experience, what you get out of it is what you put into it. I know I got a lot more out of it then many of my peers who took CS because "computer stuff pays well." I'm not so sure it's paying them well now, unless they took jobs managing geeks like me instead of being a geek themselves.

Hey, wait a minute....

Re:c ? really?

[Kjella]

Any programmer worth his salt can pick up a new language in a couple hours.

If you mean whether it's curly braces or brackets or none at all and the syntax of basic control flow, then yes. If you mean being familiar with the standard library, the development tools and all the specific bits (Java generics, C++ templates, take your pick)? No.

Re:c ? really?

[shutdown -p now]

Any programmer worth his salt can pick up a new language in a couple hours. Hell, most languages today are just ALGOL with some syntactical refinements, and you know one, you know them all.

Surely you meant to write, "all ALGOL-family languages"? Which includes most mainstream ones: C/C++, Java, C#, Python, Perl, BASIC etc. But you can't easily jump from C++ to Lisp, Erlang, Prolog or FORTH (just to name a few) easily, because they are different. Then there are people having troubles moving from class-based OOP (Java) to prototype-based (JavaScript). Etc... there is a lot out there, and it does differ.

Re:c ? really?

[Sir Toby]

I think you will only need to wait till 2100

Or 2050, when all of the following logic begins to fall to pieces:

if ( x > 50 )
      return 1900 + x;
else
      return 2000 + x;

Re:c ? really?

[jimicus]

Less than that, even. I bet there's a lot of Unix user-land software out there which assumes that "number of seconds since the epoch" is a 32-bit unsigned int, which IIRC runs out in 2038.

Re:c ? really?

[polar red]

C is a niche language. that's an 'H' too much.

Re:c ? really?

[Chris Mattern]

3. Linux is still written in C, I believe. As are its drivers, KDE-related programs, Gnome-related programs, and whatnot.

Yes, the Linux kernel is written mostly in C (with a few modules in assembler). KDE, however, is C++. The basic GUI widgets are written as C++ classes. Gnome's widgets are written in C, but API bindings for C++, Java, Perl and Python are part of the project.

Chris Mattern

Re:c ? really?

[Junta]

Hard core? It's only a compiler. Besides, there are only two architectures that matter, any more: x86 and x86-64. Yes, because the 17 billion dollar a year industry in Sparc/Power based systems doesn't exist.

Re:c ? really?

[MojoRilla]

According to this, Haskell generates HC files (which are stylized C files) when it compiles GHC (the Haskell compiler). You then get the HC running with GCC, and you have a working Haskell compiler.

Re:c ? really?

[spirit of reason]

C is used all over in systems-level programming and in applications where speed is critical (but not so much to merit the much-lengthened development time of using assembly). There's more to the computer than your silly "web 2.0" applications; it's just one layer of the abstraction.

Re:c ? really?

[TheRaven64]

Multicore CPUs are likely to kill C. C is a great language for writing high-performance code on an architecture that is semantically similar to a (fast) PDP-11. The more chips become unlike a PDP-11, the less useful C is. You can do a lot of optimisations in a language that has single-assignment variables and immutable data types that you can't do with C (and you can't adapt C to support them without making it a completely different language). These aren't so important in a single thread, but they are when you introduce parallelism. You can't get this kind of thing in C without dropping into assembly, which is what C was meant to avoid. On the subject of assembly, I find that I don't write pure C anymore. Anything that can afford a slight performance hit is done in Objective-C, which is a lot easier. Everything else needs to take advantage of CPU-specific features, and so ends up having macros or inline functions that wrap snippets of inline assembly scattered throughout it.

The only reason C is still alive today in the application space is that UNIX didn't define a cross-language ABI. Microsoft had COM, which let any languages with C++ like semantics share objects (now they have .NET which does the same thing for languages with C#-compatible semantics). VMS had something similar for sharing functions across procedural languages. UNIX just expects people to expose C functions and write a wrapper for their own language.

Re:Number 1

[stinerman]

And the ability to use spell checkers...

Some of the list looks good

[Sycraft-fu]

But C? Really? I guess that the fact that nearly every game, every OS, almost every high performance computation tool and so on are written in it (or C++ which I keep under the same heading) doesn't count. While it certainly isn't the be-all, end-all, it is still widely used. Even games that make extensive use of scripting languages, such as Civilization 4, are still C/C++ for the core functions.

Until there's enough spare processor cycles that it really doesn't matter how much CPU time you use, or a managed language gets as good at optimizing as a good C compiler/programmer combo (unlikely) I don't think C is going anywhere.

Re:Some of the list looks good

[LWATCDR]

C++ is still alive and well.
I think they are wrong since C is still used on a lot of embedded systems where C++ is too heavy.
BTW a good number of HPC tools and applications are still written in FORTRAN.

Re:Some of the list looks good

[Chibi Merrow]

And a modern C program is quite incomprehensible except to the guy who wrote it. :)

Re:Some of the list looks good

[abigor]

The point of the article is that there are a tiny fraction of developers actively writing C compared to those writing, say, Java (practically every enterprise app) or C++ (practically every desktop app). They are judging the "life" of a technology by the number of its practitioners.

And before someone jumps in to say, "Oh, but all the open source developers, blah blah," there honestly isn't that many compared even to C# developers. Honestly. And I say this as someone who has contributed his share of open source C.

So, there is a lot of legacy C around, and there is still lots being written in niche fields (embedded). But for active, mainstream, ground-up development, there isn't too much happening. No big deal, really, that's the nature of technology.

Re:Some of the list looks good

[xenocide2]

Ironically, most of Google's code has been rewritten to MapReduce style. Interestingly, the core functionality is written in C++. I guess it helps make the function oriented system a bit simpler to implement. The end result is that most of their programmers don't focus on savoring every cycle. Today's computers can run something like a million instructions in the time it takes to serve a single disk read; making code that can be run on 1800 nodes is far more important than how many fewer cycles your uniprocessor code can accommodate. Fewer instructions is better, but there's far more performance gains to be had from better locality -- process the data on the node that holds it.

The rest of the things you've mentioned all outdate C++, let alone newer languages. And most don't use assembly at at all (apache doesn't, I doubt BIND or sendmail does). The UNIX kernels don't use assembly because it's faster (though it helps), but because there are things that must be done that are platform specific, and C's provided way of handling those cases is assembly. But generally, x86 computers are changing too rapidly to make any optimizations worthwhile. Just make clear code and let the compiler handle the dirty work. If you don't think it's good enough, improve the compiler. But usually the people who claim to "write their inner loops in ASM" have troubles making solid contributions to compiler technology.

ColdFusion Dead?

[AKAImBatman]

I can only hope. Terrible, terrible language. Of course, these days it's actually a template engine for a J2EE server. So it's not nearly as bad as it once was. Unfortunately, most of the ColdFusion projects are massive, sprawling directories from the CF4/CF5 days. You're not likely to see a nicely package JAR here. :-/

Also, what's with "PC Network Administrators"? TFA must be referring to a rather specialized form of administrator, because last I checked we still needed someone to keep the desktops configured, the networks running, the file severs sharing, the login servers logging people in, and the IIS servers serving.

Re:ColdFusion Dead?

[funkdancer]

I beg to differ. Whilst I agree that there's some shocking solutions out there, I develop applications using the http://mach-ii.com/ framework and it makes for a great development platform; since version 6 (MX) it has supported components that allows for using object oriented development principles.

If one was to use crappy solutions as an argument, how come anyone is still using php, asp, etc? I think ColdFusion has copped it more than any due to its low threshold of entry, but just because one _can_ make a shit solution using a platform doesn't mean the platform is shit.

Have been using ColdFusion for 11 years now and it keeps getting better. It's a great second language to know in addition to .net or Java. Unfortunately & ironically, the low availability of developers pushes the case for enterprises to phase the solutions out, as it is too hard to get people who are good at it - even though it is a perfect fit for a lot of the work.

Re:ColdFusion Dead?

[Tablizer]

I can only hope. Terrible, terrible language.

In what way? I find it fairly nice for the following reasons:

1. Makes it easy to integrate HTML with app code if you go that way (The "separation" argument is usually oversold in my opinion. The cost/benefit analysis often doesn't favor it if you do the probability estimation math. And one can still separate if you really want.)

2. Very scriptish feel for rapid development. You don't have the verbose formality of some web languages and Java. (OO fans will not like it, I would note. I don't put much stock in OO. It is based on flawed assumptions about change patterns and developer psychology.)

3. Pretty good database integration, almost plug-and-play.

4. Graphing widget, editable grid widget, and tree widget are fairly good. It is hard to find decent edit-grid widgets without spending a fortune. (Its grid is far from perfect, but it is hard to find better web grids without spending a fortune.)

5. Natural for web designers who know HTML to work with variable-embedded templates.

I would recommend PHP over it because PHP probably has more staying power, but CF isn't bad for small and medium apps. It is how you program, not the language that makes the biggest difference.

Re:ColdFusion Dead?

[Tablizer]

sprawling directories from the CF4/CF5 days.

I forgot to mention in my reply that CF4 and CF5 lacked full-blown user-defined functions. This often resulted in file proliferation. When full-blown functions were added in later versions, it became a lot easier to organize stuff and create reusable libraries. Thus, your criticism is correct for those versions, but is no longer applicable. However, the file sprawl did give it a bad name. (I don't need Fusebox anymore since functions.)

Re:ColdFusion Dead?

[nebrtoad]

(Disclaimer: I work mostly in ColdFusion)

I completely agree with your point about processing moving to the client's side. I want to point out that ColdFusion is embracing that shift in paradigm, especially in the upcoming release, ColdFusion 8, that is slated to have a lot of nice and easy AJAX integration. CF 8 is more than just pretty stuff though; it's got a lot of fine-grain feature improvements in there as well.

I think you would be hard pressed to find a platform that has been as adaptive as ColdFusion has been. It's come a lot further than the CFQUERY tag (not to diminish that though). Consider for a minute its move from CF 5, written in C++, to CF 6 written in Java. Let's see Ruby switch off of Rails to something like "roads" or "orbits".

ColdFusion has been proven in rapid application development (even before that was a buzz-term), but still has the power and extensibility to accomplish some pretty intense things. If you can't figure out how to do something with the proper ease or efficiency you need in ColdFusion, go write something in Java, C++, or even .NET and you can hook it into your ColdFusion application. This interoperability is a huge benefit in multi-lingual workplaces; anyway ever had trouble calling a .NET web service with Java and Axis?

Maybe ColdFusion guys are a dying bread; but one possible reason is because they are picking up other languages along the way to marry with the ColdFusion skills. Once you know Java, it seems to be more chic to call yourself a "Java Developer" than a "ColdFusion Developer". That fact itself may invalidate Mr. Foote's (see TFA) data collection methods; I can't really comment decidedly due to the lack of information about the data.

ColdFusion's reputation has always been plagued by several problems: its uniqueness, not lending itself to any particular design patterns, cost, total lack of presence in the education field, etc. All of those issues have not stopped it from becoming a viable technology that is used in real-word applications. It's been around for over a decade now, and I don't see any new threat to its existence on the horizon and in the absence of such a threat, I can hardly describe it as "dying".

Wait, there IT people who specialize this much?

[Rakishi]

I mean, this is IT where things change quickly and at times unexpectedly. If you don't have at least a number of diverse skills then I can't say I feel sorry for you when your job gets axed. I may not be a guru in any one language but at least I won't be unemployed when that language dies out.

Re:Wait, there IT people who specialize this much?

[Jimmy King]

Not that simple. Companies want *paid* experience above all else. If you don't have paid experience, it often doesn't matter much if you memorized the book (unless you get lucky or find a backdoor).

This is all too true. I had to fight with this problem for about 6 months awhile back. I got hired as a tier 2-3ish support guy who would also do some shell (primarily Korn and sh) and Tcl coding (along with some Javascript and had I stayed longer, possibly some C and some VB eventually). I was very lucky and they picked me for it due to my hobby perl and bash experience. A year and a half later I was lucky and was hired away (that last one was contract and going to end sometime) into a full time Perl dev position due to my hobby Perl experience and professional Tcl experience. Then there was the great layoff of '06.

I went home, saw there was fuck all demand locally for Perl, Tcl, or C (unless you had 3-5 years experience with embedded C apps in robotics, which I only had some fairly basic hobby experience in C). There was quite the demand for C# and ASP.Net stuff, though. I thought to myself "Cool, I'll learn me some of that newfangled C# stuff. I'd been wanting to for fun anyway and now I've got both a reason and time to do it". No one cared. All of my C# was hobby programming. It didn't matter that I had code examples and a couple years professional experience developing in other languages, I didn't have professional experience in C#. No, that wasn't an assumption I made due to not getting jobs, that's what I was directly told by multiple recruiters, in case that's what anyone here was thinking.

I spent the next 6 months honing my Perl, C, C#, and PHP skills while getting turned down left and right for everything that wasn't Perl due to lack of professional experience and seeing very little in the way of Perl unless I was willing to relocate halfway across the country for a 3 month contract. Fortunately, I was picked up again by the place that had laid me off in a more senior level Perl dev position.

Now I'm trying to solve the problem of how to get my employer to pay me to improve my skills in or pick up another language so that if I have to look for work again I have something more than Perl and Tcl to bring to the table as languages I've got professional experience with.

C? You must be kidding

[Ckwop]

As the Web takes over, C languages are also becoming less relevant, according to Padveen. "C++ and C Sharp are still alive and kicking, but try to find a basic C-only programmer today, and you'll likely find a guy that's unemployed and/or training for a new skill," he says.

What the web can now allocate memory and talk to my hardware? Even if you're not a kernel programmer, the web has sucked and still sucks for application development. It will continue to suck for years, due to Internet Explorer. It's misleading to claim AJAX will solve all these problems because it won't. In fact, it might even cause a few problems of its own. For example, do you really think all that AJAX is secure? In short, I think the web is taking over what naturally comes to that medium. It is wrong to say its displaced C.

Does this guy forget that all of the GNU/Linux Kernel base system is written in C? You know, the operating system that powers most web-servers? I'll tell you one thing, C will still be here in twenty years time when Ruby on Rails is talked about much in the same was Blitz Basic is today. C is here to stay; it's immortal.

Simon

Re:C? You must be kidding

[anvilmark]

This SO reminds me of a comment one of our business users made to my boss a couple years back:

"We don't need sockets anymore, everything is going to Web now..."

LaTeX

[Anonymous Cowpat]

with MS equation editor becoming passable, journals that will mark your work up for you and quasi-wysiwyg TeX editors, people who 'do' LaTeX are hard to come by. (Afaik, I was the only person out of ~60 in my year (of physicists) who typed their project report up in LaTeX as plain LaTeX markup. About 4 other people used an editor. Everyone else used word.) Or maybe it's just that the students in my department are lazy and take little pride in the presentation of their work.

Re:LaTeX

[serviscope_minor]

You're the lazy one. You know, avoiding all that tracking of cross references, mindless reformatting, applying styles, and doing battle with the (still) inadequate equation editor. Slacker.

Re:LaTeX

[radarsat1]

Or Lyx! I've been using it to write my thesis and it's fantastic. A tad hard to customize, but usually I find if you have to customize you're probably doing something wrong. In cases where you do need custom output formatting it's probably not the right tool for the job. But for paper/thesis and letter writing, nothing beats it.

Re:LaTeX

[siwelwerd]

LaTeX isn't going anywhere. It is the standard among mathematical journals for good reason.

True story...

[KingSkippus]

When I started working at the huge multinational company I work at now, there were three things that I had very little experience with that everyone swore would last at the company for decades to come: Token Ring, Netware, and Lotus Notes. I insisted that within the next few years, these technologies would be dead and the company would have to change, and I was constantly reminded of the millions of dollars invested in them.

It's eight years later. We have no Token Ring network. We have no Netware servers. I'm doing my damned best to convince people of how bad Lotus Notes sucks, and most everyone agrees, but we have a Notes support team that really likes their jobs and somehow manages to convince upper level management that it would cost billions of dollars to change to a real e-mail and collaboration solution. But I'm still holding out hope.

Godwilling, Lotus Notes will soon be on this list as well.

If only...

[26199]

...writing unreliable, poorly-documented, just-about-does-the-job-and-only-if-you-get-lucky code would go out of fashion.

Sadly it seems to be here to stay. In fact with the better availability/quality of scripting languages it is, if anything, becoming more popular...

10 more dying computer skills

[Anonymous Coward]

1. secure software coding
  2. data management theory
  3. data modeling
  4. usability
  5. interface design
  6. use of testing, version control, refactoring, and other best practices
  7. space or time efficient algorithms
  8. general communications skills
  9. basic business concepts like ROI
10. business ethics

Re:10 more dying computer skills

[Duhavid]

You are supposed to start with 10, and increment by 10.

They said something else.

[khasim]

"C++ and C Sharp are still alive and kicking, but try to find a basic C-only programmer today, and you'll likely find a guy that's unemployed and/or training for a new skill," he says.

Now I know some people who've learned on C#, but I'm sure that will change in the near future.

Anyone who originally learned C, and is still writing code, has probably picked up a few other languages over the years.

Re:They said something else.

[rs79]

"Anyone who originally learned C, and is still writing code, has probably picked up a few other languages over the years.

I learend Assembly first and have programmed nearly every cpu except a vax. I learned C second (in 1976) and still use it every day.

I also know: apl, forth, snobol, fortran, rpg, cobol, lisp, smalltalk, pascal, algol and probably more I can't remember. I've never done much in them except for a tiny bit of forth. I know postscript pretty well and used it quite a bit. But I do C, day in day out and do not think very much of C++ or (worse) C#. The oddball languages have their place but for most it's a pretty narrow niche. I'd rather invert a matrix in Fortran than C though, I'll admit.

Andrea Frankel said it best on usenet in the 80s: "If you need to hire a programmer ones with assembly are better than ones without".

It worries me that people today don't actually know how computers work inside any more.

Re:They said something else.

[Opportunist]

To quote my Guru: "When you learned C, and you mastered it, you have learned every (procedural) language there is, for it is easier to take a step down rather than up."

It's pretty much true. Look at the other languages you "should" learn today. Perl, PHP, Python, C#, Java... When you know your C well, learning them is fairly easy.

Re:They said something else.

[fishbowl]

How do you get out of university without taking an architecture course that gives some assembly language, at least for a hypothetical machine?

If you claim to have a BS in CS at the interview table, but didn't suffer through, e.g., a computer organization course (like Hennessy and Patterson style, which is common these days), didn't have a course where you developed an operating system, didn't design a language starting from BNF and build a compiler for it, didn't take 2 years of a lab science, didn't at least come close to a math minor, didn't have at least 4 courses at various levels of discrete math, automata, algorithm analyis, and didn't have a course that, as a final project, you deliver a significant user app in a high level language (on the order of an original multiplayer game, let's say)... I'd say your school has some explaining to do.

Seriously, what school can you go to and somehow avoid having a significant background in several languages and paradigms, including but certainly not limited to asm, C, and either C++ or Java, if not both? I don't expect everyone to take an elective where they compare Lisp, Scheme, Ruby, Haskell, and Icon. And I realize that there's often a variety of senior-year choices, and some people don't take Databases choosing HighPerf/Parallel/Distributed computing, say, or 3D Graphics. But there are some basic things that you'd better have done, or else, despite having the piece of paper hanging on your office wall, you're not done with school!

Re:They said something else.

[rs79]

"You got a big gray beard, too?"

No, I'm clean shaven and have all of my long blond hair. I like long walks on the beach and pina coladas. I'm good with kids and dogs.

You better be a chick, bitch.

dovetail

[Anonymous Coward]

No better place to dovetail than first post.

Here's a link to the print version for those who dislike clicking 18 times to read a news piece.

And for those not wanting to feed the gossiping trolls altogether, here's the (pointless) "Top 10" list in short form.

1. Cobol
2. Nonrelational DBMS
3. Non-IP networks
4. cc:Mail
5. ColdFusion
6. C programming
7. PowerBuilder
8. Certified NetWare Engineers
9. PC network administrators
10. OS/2

You may now return to the /. index in search of better things to quibble over.

Re:dovetail

[MightyMartian]

I don't think you can justify C and Cobol. There are millions upon millions of lines of code in these two languages, and despite all the sexy new ones that have come along, these two still reign supreme; C is incredibly prevalent on dedicated systems and within a lot of operating systems, and mainframe Cobol code can still be found throughout the business world (though often cleverly disguised these days). I doubt a skilled Cobol programmer will be at risk of starving any time in the near future.

Re:dovetail

[StarvingSE]

I've said it before, and I'll say it again... lists like this are ridiculously stupid and not thought out. Its like "hey this is old it must be obsolete."

The first two items on the list made me not want to take the author seriously. The financial business is run on COBOL and flat files, and will continue for some time. The language is not pretty, but it was made for a specific purpose and it does it well. In fact, demand for COBOL programmers has risen dramatically as people retire, and it is 7 years after Y2K. I know people who were asked to come out of retirement to work on COBOL again, for very high salaries, because it is not taught to us youngens anymore.

Re:dovetail

[MightyMartian]

Talk to me again in thirty years. I never said Cobol wasn't being phased out, but the sheer mass of code written in it means that Cobol programmers have probably got it very safe for a few decades to come.

Re:dovetail

[Chibi Merrow]

I'll give you a dollar if you can find me ONE SINGLE deployment of mainframe COBOL that is being used for business that is not in the process of being phased out and redeveloped. Also, find me one person that knows and writes COBOL that doesn't hate his/her job. Worst language EVER. (Hollerith cards aside)

You owe me a dollar. The IT department I used to work at runs most of the organization-wide stuff on an IBM OS/390 monolith, written in legacy COBOL code. Any of the programmers that worked there that did hate their job didn't hate it because of COBOL, believe me. Instead of "phasing out" the system, they got a nice new flashy IBM server to run a virtualized version of the mainframe seamlessly. Will the code be phased out one day? Probably. Not because of the language, but because the size of the organization has scaled so much and the increase in communication capacity available to them has grown exponentially, so problems like this can be approached from new directions. Plus, COBOL coders are getting harder to find. But any COBOL gurus could probably eat very well for the next 10 years there, since that's probably the earliest that system will be "phased out".

And calling it the worst language EVAR is a bit disingenuous... It's very very good at what it does: business logic. I wouldn't want to write an operating system or a thermonuclear explosion simulation in it, but I wouldn't want to write check printing routines in C, either. :)

Re:dovetail

[Stormwatch]

10 PRINT "What, no BASIC?"
20 GOTO 10

Re:dovetail

[rujholla]

I am a contractor and occasionally I get contracts doing Cobol work. I can think of at least two of the companies that I have worked that still actively use Cobol with no plans to move off it. Plus another of the companies that I worked for wanted to get rid of their Cobol application to escape the oppressive mainframe license fees, but after supporting a project to rewrite that application for 3 years and several million dollars they came to the conclusion that it was easier to get a mainframe emulator and host the Cobol app on a Unix box, and there it continues to run 3 yrs later.

I think until it becomes so difficult to find people to program Cobol application that it costs more to hire people than it does to rewrite the Cobol application those applications will remain. There are so many years of business processes built into the systems that rewriting them becomes more of a process of changing the business processes to match a new enterprise application than a program rewrite. And it is much more difficult to change the business process than it is to rewrite the application.

BTW -- I don't hate my job when working with Cobol. It's just another language. Sure its a lot easier to program the same thing in a more modern language, but working with Cobol applications is almost never writing from scratch.

Re:dovetail

[Watts Martin]

I think you (and many others) are somewhat missing the point of the article, although the somewhat histrionic headline encourages a "miss the forest for the trees" reading.

I don't think anyone is expecting C or even COBOL to vanish with the speed of PowerBuilder or NetWare; the issue is whether those are actually "growth markets" any more. The article is asserting they're not, and particularly in COBOL's case I'm pretty sure that's correct. COBOL will probably live on for quite some time, but you don't hear much about people deploying new COBOL projects -- you hear about them supporting existing ones that haven't been replaced.

As for "but the OSes are written in C!" as a battle cry: well, yes, they are. But 25 years ago, they sure weren't: C was just too damn big and slow to write an operating system in. What's happened since then? Computers have gotten orders of magnitude faster, RAM and disk space have gotten orders of magnitude bigger, and of course compiler technology has also just gotten better. Couple that with the fact that operating systems and the computers they run on are just a lot more complicated -- having a higher-level language to deal with that, even at the system level, is a real advantage. There's nothing that prevents you from writing an operating system in assembly language now, but under most circumstances you probably wouldn't want to.

The thing is, unless you want to assert that computers twenty years from now will not be much faster and have much more storage and be much more complicated, you can't assert that moving to a higher-level language than C will never be either practical or beneficial even at a system level. I don't expect C to go away or even be relegated to "has-been" status, but I suspect in the long term it isn't a growth skill. It's going to move more deeply into embedded systems and other arenas where small is not merely beautiful but necessary.

The comparison with COBOL may be overstated, but it may not be completely inapt: the fact that there are still COBOL jobs out there and they may actually be fairly high-paying ones doesn't mean that going to school, in 2007, in preparation for a career as a COBOL developer is a bright idea. The same isn't as true for C, but I'm not convinced that's going to stay true for that much longer, let alone indefinitely.

Re:dovetail

[fishbowl]

>I just started working in the actuarial department of an insurance company. Almost all of our code is in Fortran.

Ah, you work in the OTHER place where people routinely do calculus on the whiteboard and people who have a choice and know lots of languages, program in FORTRAN.

Surprised the hell out of me too.

For number-theoretic approaches to certain classes of problems, FORTRAN gives some guarantees, offers optimizations, has the widest range of libraries available, and scales in ways that aren't even a consideration in other idioms.

I hate FORTRAN as a grammar, but I certainly now have an appreciation of why it's used by the people who use it. Know what it took to make me realize this? I needed to be told by someone whose skills in other languages meets or exceeds my own. Then I understood; it's not that you have a golden hammer, know only one thing, and stick to it (that's what I thought FORTRAN was!). It's something else, and it has to do with the fact that we are easily deluded into thinking that a modern grammar equals an object better suited to task. It turns out to be true in some cases, but life-and-death-NOT-TRUE in others.

It would be scary to have someone naively think he could duplicate a math-intensive FORTRAN module with C or Java. How certain are you of the behavior of your language's exponentiation operator between quadruple precision floating point and an integer? Willing to bet your life on it? What does your language have built in for arbitrary precision? Willing to bet your life on that too?

What? C?

[Aoreias]

C is just the next highest step above assembly if you don't use standard libaries. C is still the de facto standard for embedded systems, drivers, and kernel modules. The only thing likely to replace C is a similarly low-level language with more useful features.

Delphi

[CrazyTalk]

Anyone out there still use Delphi? Does it even exist anymore? I'm a bit nostalgic for it - that was my first professional programming gig.

Re:Delphi

[Anonymous Coward]

I'm nostalgic too. Delphi still is one of the best development systems for Windows out there. Too bad Borland/Inprise/Borland jumped on the .NET bandwagon and destroyed it. But if you get an old copy of D6 (or D7? cannot remember which one was the last non .NET-polluted version) you can write great software with it.

Also, take a look at Lazarus. It's a multiplatform and open source Delphi clone that brought the beauty of Delphi to Linux.
Note that it's 100% native on all platforms and produces 100% native code: no Wine, no emulations. Young but already powerful, and damn funny to use!

Web Design

[happyfrogcow]

Judging by their web page, all design jobs are dead too. We should all just write web pages to serve ads, because C is dead.

This article is trash, even if it does have some technologies that are irrelevant. It has very little value to the reader. I'd rather read a 10 top list for reasons Paris Hilton should be locked up for life.

C and PC network administrators?

[baggins2001]

I don't see where either of these are going away.

There just aren't that many people that know networking outside of IT and there are still a lot of people that get confused about what is going on. I have seen where many people have cluged together a network at their office, but then they find out it sucks after awhile, so they have to call somebody in to look at it.
C programming is going away. I'm always seeing algorithms with some part of C in them. Partly because these guys with VB skills say hey there is no reason to learn all that hard stuff. We'll just get more/bigger hardware. So far they have spent $300K on hardware and 5 man years of programming. They've got a lot of code but nothing to show for it. Runs fast and cranks through a lot of data, but nobody can figure out what it's good for.

Re:They are nuts on the C front.

[Dionysus]

a C programmer can move to C++ without a problem but the reverse is not true I find the opposite to be true. A C++ programmer is able to move to C without much problems, but the oppose it just not true.

Re:You have to admit

[ivanmarsh]

Yep... after all everyone knows that C# is the best language with which to progarm an embeded micro-controller.

Technology reporting is certainly dying.

It's not C. It's the C only programmer.

[khasim]

They phrased it very badly. C isn't going anywhere. But if all you know is C, then you are very rare.

Most programmers who know C also know at least one other language.

In any event, putting that on the list was just stupid.

Re:It's not C. It's the C only programmer.

[multipartmixed]

> Think of how you would react if some Perl/Python programer said
> "Sure, I don't know LISP or C ... but I could probably get to
> moderate proficiency in two weeks".

I would consider this individual a dedicated, professional programmer.

Note that there is a HUGE difference between "moderate proficiency" and "very proficient". I figure it took me about 3,000 hours of C programming to get to the "very proficient" tier (it was also my first professional gig).

Moderate proficiency is what half the OSS C code out there is. (I'm not counting the sendmails and apaches of the OSS world either). It works, it's obvious-bug free, it's not elegant and it's probably nowhere near optimal -- and desperately needs peer review from an expert to point out where improvements can be made.

But it should be functional, not reinvent core elements of the language, perform the task correctly in the language's native paradigm, and be legible to a skilled programmer.

Note, also, that I differentiate strongly between "core language" and common libraries available for use. Java does not imply J2EE, struts, and whatnot. JavaScript does not imply W3C DOM (but it does imply Math and Date). Perl does not imply CPAN. That said, C++ *does* imply stdlib, and C [to me] implies unistd, stdlib, stdio, strings, etc, but not xpg4, sockets, iconv, blah de blah.

PC network admins?

[Volante3192]

With the accelerating move to consolidate Windows servers, some see substantially less demand for PC network administrators.

Apparently this guy's never dealt with users. If there's a way to screw up a system, even a dumb terminal, they WILL find a way.

Re:COBOL as number one?

[Danga]

COBOL may be dying, but it's lingering on...

You are 100% correct and like the article mentioned COBOL is still not only used at many companies but also taught in some universities Computer Science programs including the one I graduated from being Northern Illinois University in DeKalb. Here are two examples:

http://www.cs.niu.edu/undergrad/coursecat.html#250
http://www.cs.niu.edu/undergrad/coursecat.html#465

There are A LOT of companies that still use COBOL out there (I saw many of them at every job fair I went to) and the langauge is far from dead. Thankfully I didn't have to go the route of being a COBOL programmer and found a job I love doing C/C++ development but at least I have the option and I definitely did learn a lot about the langauge as well as mainframe programming from taking the COBOL classes.

Another great class they teach at NIU is Assembler on an IBM System 390. That class was HARD but I love the experience and knowledge it gave me regarding how a computer works at the lower levels and I wouldn't trade that experience for anything. Here is more info on the assembler class:

http://www.cs.niu.edu/undergrad/coursecat.html#360

While I am not exactly happy that COBOL is still around it still is a fact that it is going nowhere anytime soon.

Re:C, dead or dying!?!?! OUTRAGEOUS!!!

[JustNiz]

Well they are agents. if there's one group of people I've come across that don't understand technology its technical staffing agencies.

I disagree with some of the list.

[jd]

Cobol has died back as much as it's going to, same as Fortran. It won't reduce in scale any further, because of maintenance requirements, so it is meaningless to say it is "dying". It's a stagnant segment, but it's a perfectly stable segment.

Non-IP networks are dying? Must tell that to makers of Infiniband cards, who are carving out a very nice LAN niche and are set on moving into the WAN market. Also need to tell that to xDSL providers, who invariably use ATM, not IP. And if you consider IP to mean IPv4, then the US Government should be informed forthwith that its migration to IPv6 is "dead". Oh, and for satellite communication, they've only just got IP to even work. Since they weren't using string and tin cans before, I can only assume most in use are controlled via non-IP protocols and that this will be true for a very long time. More down-to-earth, PCI's latest specs allows for multiple hosts and is becoming a LAN protocol. USB, FireWire and Bluetooth are all networks of a sort - Bluetooth has a range of a mile, if you connect the devices via rifle.

C programming. Well, yes, the web is making pure C less useful for some applications, but I somehow don't think pure C developers will be begging in the streets any time soon. Device driver writers are in heavy demand, and you don't get far with those if you're working in Java. There are also an awful lot of patches/additions to Linux (a pure C environment), given this alleged death of C. I'd love to see someone code a hard realtime application (again, something in heavy demand) in AJAX. What about those relational databases mentioned earlier in the story? Those written in DHTML? Or do I C an indication of other languages at work?

Netware - well, given the talk about non-IP dying, this is redundant and just a filler. It's probably right, but it has no business being there with the other claim. One should go.

What should be there? Well, Formal Methods is dying, replaced by Extreme Programming. BSD is dying, but only according to Netcraft. Web programming is dying - people no longer write stuff, they use pre-built components. Pure parallel programming is dying -- it's far more efficient to have the OS divide up the work and rely on multi-CPU, multi-core, hyperthreaded systems to take care of all the tracking than it is to mess with very advanced programming techniques, message-passing libraries and the inevitable deadlock issues. Asynchronous hardware is essentially dead. Object-Oriented Databases seem to be pretty much dead. 3D outside of games seems to be dead. Memory-efficient and CPU-efficient programming methods are certainly dead. I guess that would be my list.

Yet more netware bashing...

[damn_registrars]

I guess this shouldn't surprise me. Even though Netware was pulling "five nines" (of reliability, for those not familiar with the term) long before anyone considered running any flavor of windows on a server, we see another article bashing Netware.

Sure, its sales have declined drastically, but I wouldn't say that its relevance has. I'd be willing to bet that if we were to actually survey what file servers are still running out there, we'll see a much larger representation of NetWare. Just because people aren't buying the latest version doesn't necessarily mean that they aren't using the old ones.

For two years, I managed the computer network of a daily newspaper - including through the election debacle of 2000 and the 9/11 events. We ran that network primarily off of four netware 4.11 (later netware 5.0) servers. One of those servers had been running for over 400 days continuously when I left, and it served files and print jobs. That kind of reliability is hard to match.

Then Pay the Market Wage

[Anonymous Coward]

If you pay the market (equilibrium) wage, then you will find plenty of workers. However, most companies, just like your company, refuse to pay the market salary. They then cry, "There is a shortage of workers!"

F77/F90/F95 aren't on the list.

[i_like_spam]

Yeah! Does that mean that my FORTRAN programming skills are still marketable?

"What will the language of the year 2000 look like? Nobody knows, but it will be called FORTRAN." John W. Backus

Memory Tuning

[bobdehnhardt]

Back in the days of DOS, when everything had to fit in 640KB RAM (give or take), the ability to load device drivers into UMBs and High Memory. Now there were tools you could use, like QEMM or memmaker in MS-DOS 6, but Real Admins did it by hand.

I carried a specially tuned DOS disk around with me, and would whip it out whenever anyone complained that a certain program wouldn't load. Boot off the floppy (with around 630KB conventional memory available after all drivers loaded), run the program with no problem, deliver the classic "It works for me" tech support line, slip the boot disk back into my pocket, and leave the user convinced they're doing something wrong.

Ah, good times, good times....

Re:Memory Tuning

[camperdave]

I remember being able to squeeze 704K of conventional memory out of some systems (shadow RAM at $A0000, and a video card that sat at $B0000), then have certain programs complain that there was insufficient memory... because their counters wrapped at 640. Good times indeed.

ColdFusion

[Goyuix]

Wow. I didn't actually expect this to be on the list but I am not at all surprised. We use it at my work as the primary web platform and I can assure you of two things regarding the language: 1) it is very hard to find someone with development skills using it and 2) the ones who do have the skills are VERY expensive. That seems to go along nicely with the theme of the article that it is in fact a dying skill. While I personally have never developed much of a taste for it (I do post on /. after all - it would be like heresy / blasphemy) there are a few long-time-developers here that have an unholy allegiance to it, almost completely unwilling to even look at alternate environments or frameworks. I would guess that is probably similar for many of the languages/skills on this list and their long time supporters.

Typing

[radarsat1]

I was just copying down a quote from an article I was reading, and I realized that my typing skills haven't really been up to scratch, even though I spend hours and hours on the computer every day. For programming and general writing, I spend a lot more time thinking than actually writing, plenty of time to fix typing mistakes. Rarely do I ever just copy something directly, but this time I happened to be putting a long block quote into my document.

It got me thinking.. secretaries used to be hired just based on their typing skills. Speed & accuracy. I remember when I took a typing class in high school the teacher made us cover the keyboard so we couldn't look at it while we were typing, and we especially weren't allowed to use the delete key so she could mark us on how many errors we made.

But it's funny, that's so backward, of course. Since typewriters are no longer used, your typing speed _includes_ the time it takes to hit the delete key and fix what you did wrong. You time further increases if you have to look at the screen and then find your place in the text. So typing speed is now the only thing that counts...

Now add into that the fact that the days of the boss dictating memos to the secretary are mostly gone, and typing is really a skill that no longer matters. It certainly helps in day-to-day computer tasks, but it's no longer a make or break skill for IT and office people.

Re:Typing

[swordgeek]

Funny, that's the first thing that I thought of too.

When I was in elementary school (before most of /. was born), I taught myself to touch-type, to impress a girl. When I was in high-school, I could easily type 70+WPM without mistakes.

Now I type less than that with typos, and MUCH less than that if I have to do it without typos. I know I could get my speed and accuracy back up to snuff with some work (and once a year or so I force myself to work on accuracy again), but as a sysadmin who types for 8+ hours/day, neither fast or accruage typing is a requirement any longer.

Re:Typing

[radarsat1]

I taught myself to touch-type, to impress a girl.

Interesting technique you have.

neither fast or accruage typing is a requirement any longer.

Case in point. ;-)

experience

[DrYak]

In similar way :
Non relationnal DBMS
Yes, maybe they don't play such an important role as before at big irons. But actually they are encountered painfully often in science, where usually database grow slowly out of small projects that subsequently undergo numerous hacks.
I'm studying bioinformatics and proteomics, non relationnal DBMS are part of the standard cursus (and often encountered in the wild).

C programmingy
Yes. Just try to tell it to the OSS community. Almost any cool piece of technology (most libraries) are coded in C. Not only but it is an option that almost any student in science can ask.

NetWare
Once again a big-iron vs. universities. There's still a lot of NetWare legacy in smll business and universities, even if bigger corporation have moved to some unix-based solutions or (the gods forbid) MS based Active-something.NET solutions.
Novell is still offering training for it. Even if Novell would like to concentrate more on their Linux solutions.
It'll end going the way of the dodo. But just not yet. ...the soso category...
Non IP network
This guy has never heard about something called bluetooth. But on the other hand, courses, as far as I know, seem to be mostly TCP/IP oriented. ...the agree category...
ColdFusion, PowerBuiilder : they're dead and deserved it.
OS/2: cue in "all 2 of them" jokes from Bastard Operator From Hell.

Re:experience

[loganrapp]

Isn't Myspace ColdFusion?

Granted, that may explain everything, but that's an awfully big part of Internet usage being declared dead.

Re:What is NT?

[damn_registrars]

I believe it to be
Neanderthal Technology

Re:Raising the bar

[AuMatar]

You don't master pointers til you learn assembly. Until then, you just don't truely understand addressing and memory use.

There's one *very* important place where C is used

[unixpro]

If you work in the kernel, you work in C.

Comment removed

[account_deleted]

Comment removed based on user account deletion

30 year technologies

[Colin Smith]

Off the top of my head:

Unix, shell scripting, C. There must be more.

Just a thought, but it makes sense to invest skills in technologies with proven survivability.

The curse of good presentation skills...

[Anonymous Brave Guy]

The curse of good presentation skills is that no-one ever notices that you've used them, because you're good at presentation. :-)

I'm currently having a similar debate at the office. We're working on a new tool, effectively a web front end for a simple database with a few handy UI gimmicks. In the grand scheme of things, it's a pretty simple tool, but it's part of a routine business process and literally thousands of people are going to be using it for a few hours each month.

At a progress meeting yesterday, one of our (cross-discipline but manager-dominated) team suggested that we should skip the next couple of weeks of detailed design work and just go with something OK, because it will save a few days of our time and so be available faster. It doesn't seem to occur to them that all that time is the equivalent of mere minutes for each person who will be using the tool. If we identify a simple usability improvement that saves every user ten seconds the first time they use the tool just because they find something a little quicker, then that's saved the equivalent of about two solid weeks of one person's time to design and implement that improvement.

So it goes with typography and graphic design in documents. Poor choice of fonts or use of whitespace = hard to read on-screen = wasted staff time. Awkward page layout = people can't follow the text = wasted staff time. Poorly drawn diagram = distracted reader = wasted staff time. Poorly typeset equation = delayed understanding while the reader figures out what it says = wasted staff time. And so on...

Unfortunately, presentation skills are one of those things where people don't really notice the subtleties. If something is poorly presented then the viewer will still read something more slowly, or misunderstand what it says, or not remember it as well later, but they probably won't realise what they're missing.

Re:They are nuts on the C front.

[Neo Quietus]

At least in my case I also find this to be true. I first learned C++ way back in high-school, and just recently for my CS degree I took the "C/UNIX" class. I've barely opened the C book, because (although I realize that C++ came from C), C is just like C++, except that the useful classes and exceptions have been removed. Oh, and I have to define my indexing variable outside of my "for" loop.

10 undead computer skills

[QuantumG]

Everyone says they are dead, but they just won't go away!

1. functional programming
2. formal methods
3. prolog
4. LISP
5. Scheme
6. Smalltalk
7. Pascal
8. Tcl/Tk
9. LALR parsing
10. pre-bash shell scripting.

and that's the real message here.. nothing is thrown away in computer science.. we're just too damn young a field to honestly say we've hit a dead end on any particular technology. Anything you can name, people have done work on it in the last 10 years.

I'm more concerned with dead USER skills

[sootman]

1) knowing what extensions are
- Both the fact that that they exist in the first place AND what the different ones mean--"ooh, should I click on hotsex.jpg.doc.exe.scr.pif?"

2) looking at the URL in the status bar before clicking on a link
- Apple: I love you, but you SUCK for having the status bar off by default in Safari.

3) knowing where downloaded files go
- Every phone-based support call I've ever made:
a) Painfully (see #4) navigate to a URL.
b) Painfully (see #5) instruct user to download a file.
c) Spend 5 minutes telling them where that file is on their computer

4) the difference between \ and /
- these people saw a backslash ONCE in their lives while using DOS about twenty years ago, and now every time I tell them an address, it's "Is that forward slash or backslash?" (Despite the fact that I've told them a million times that they'll pretty much NEVER see a \ in a URL.) This is usually followed by the question "Which one is slash?" God damn you, Paul Allen.

5) the difference between click, right-click, and double-click
"OK, right click on My Computer... no, close that window. Now, see the mouse? Press the RIGHT BUTTON..."

6) the concept of paths, root directories, etc.
- I why do I have to explain fifty times a day how to get from example.com/foo to example.com?

Admins can get whatever skills they want--they picked the career, thy can accept the fact that things change. The backends are usually handled by people with some know-how. It's the end-users that cause all the problems. It'd be like driving in a world where people didn't know how to use turn signals, didn't check their blind spots, didn't know they shouldn't talk on the phone while making complicated maneuvers--oh, wait, bad example.

I dare to disagree

[Opportunist]

Cobol had one huge disadvantage over C: It was no "system" language. It was an application language. Whether it was good at that is up for debate, it certainly was better than most alternatives there were, but it was dependent on the applications it was used for.

When the applications died, the language followed. I dare say, ABAP is going to suffer the same fate as soon as SAP wanes and The Next Big Thing comes along. 'til then, it is a get-rich-quick scheme in IT if there ever was one, granted.

C, in its "pure" form, is certainly not going to last forever either. But C-derivates will be driving the systems for the forseeable future. C (and C++) offers a good balance between closeness to hardware, so you can actually write low level programs in it, and readability, while still maintaining some basic inter-platform compatibility (unless you want to get really, really close to the system). Even if you can't port a program seamlessly, you can at the very least apply your skills to the compiler on a different platform, something that's not a given with languages that get closer to the core.

C is probably not going to last. But its successors, C++ and C#, will. Well, C++ will, for sure. Whether C# is just another fad that gets a lot of hype now and gets dumped soon, time will tell.

Re:Raising the bar

[Opportunist]

Well, not necessarily so. It does help to see the "wiring under the board", granted, and to see the difference between static and dynamic allocation, especially in subroutines (given the amount of buffer overflow exploits, I guess quite a few people at MS still don't know it), but to understand pointers, or why they can come very handy, you should rather learn some theory about trees, lists and so on. It will not "show" you where your memory is allocated, but it will certainly give you an idea just why and how pointers are very useful.

I highly disagree with number 9!

[Opportunist]

A good network admin is sought after. And he will never be out of a job.

Notice the "good" in the above statement, please!

Unfortunately, network admins have already suffered for years from what we (programmers) are facing now: Clueless wannabes flooding the market. Sounds harsh, is harsh, but it's sadly true. Everyone who can spell TCP/IP and doesn't think it's the Chinese secret service calls himself a net admin. And since human resources usually can't tell a network cable from a phone cable, they hire the ones with the cutest looking tie. Or the one with the most unrelated certificates.

Quite frankly, I have met so many people who claim to be net admins who know even LESS about networks than me. And I can barely cable my home net, and I can't solve the retransmission issues with my game machine that clog it. I do expect a lot from a net admin, granted, but for crying out loud, it's their JOB to know more about networks than I do, or I could do it myself!

What you get today as a "network administrator" is some guy who can somehow, with a bit of luck, good fortune, a graphical interface and a step-by-step guide from the 'net, get the DHCP server on a Win2003 Server up and running. Don't bother trying to get a static IP or even a working DNS server from him. Not to mention that he'll look blankly at you when you ask him about splitting the 'net into smaller chunks. Anything in a netmask other than 00 or 0xFF (sorry: 0 and 255) is alien to him.

That's not what I call a network administrator. That's what I call a clickmonkey.

True network administrators who got more than an evening school degree are still rare. And they will have a job, with companies that know what to look for in a net admin.

But the plague spreads. Recently we hired a "programmer" who doesn't know the difference between heap and stack. Or why inserting an inline assembler line of INT3 could do some good for his debugging problem.

And we wonder about buffer overflow issues and other security problems in code? I stopped wondering.

Re:I highly disagree with number 9!

[swordgeek]

I had the same thought about 'network admin' being on the list, but I'm curious about precisely what they mean by 'PC network admin.'

A good network admin (hell, even a bad one) has enough equipment and required comprehension these days that they can't be too worried about the intricacies of some OS's non-standard quirks. In that sense, the PC network admin is going the way of the Appletalk admin.

On the other hand, true network admins are absolutely crucial to most companies, and I've been lucky enough to work with a good number who understand their roles very well. Sounds like you haven't, which is a pity. Rest assured, they're out there.

a few hundred million in marketing gets customers

[Locutus]

That's right, after Microsoft shipped Windows 95, they dumped hundreds of millions on pushing Windows NT at the server markets. It was a full blown marketing attack on UNIX, Netware, and Lan Manager/OS/2 and we know it is marketing which won the day and admins who lost. How many UNIX servers turned into a dozen WinTel PCs after they found out one WinTel PC couldn't a few server processes and had to be split into one service/PC. Then they had to pull in replication to get anything close to the 99.9999% uptime of the UNIX systems.

Yup, it's interesting how snake oil still gets sold year after year but only under a different name. IMO.

Oh, and virtualization, that's all about moving all those single tasking servers back into one box where one crash won't take out the others. That's innovation for ya. Go Microsoft! :-/

LoB

Re:IT is More Than Software

[gmack]

Phone systems are meant to just work and often the idea is that if it's still working it should be left that way. I contract for an ISP that has it's own adsl equipment and have an access card that gets me into several Bell Canada Buildings in Montreal and one in Toronto.

The telephone world is a weird mix of the state of the art and old.

I regularly see software that comes on 9 track reels and other ancient equipment.. My biggest shock was seeing in downtown Toronto equipment that still uses vacuum tubes.

Re:Ha! C != performance

[v01d]

You sounds trollish, but I'll bite anyway.

I've coded some fairly complicated high performance multi-threaded applications in C. It's not easy, but it's not easy in C# or Java either. There have been many minor improvements to the required syntax, but that has never been the hard part of multi-threaded development. Parallelizing (sp, I know) the problem is a conceptual problem unrelated to language.

Re:Amateur's make me laugh.

[mikaelhg]

> Name one other system that does everything that Notes does. And I mean everything.

Matt's a flaming asshole who manages to make everyone miserable and lose us business, but we can't fire him.

Name one other person who can kind of deliver the mail, kind of answer the phones, do some of the bookkeeping, unclog the toilet, and kind of drive a 18-wheeler?

Of course, a reasonable manager who understood some of these things would conclude that since these days it's possible to hire well trained, specialized and pleasant professionals to do all of these things, some of which are business critical, it makes sense to break up this arbitrary collection of tasks which have no real synergy, fire Matt, and hire modern, well adjusted professionals to run the business.

Other dead skills

[Orion Blastar]

Turbo Pascal, phased out with Delphi and Free Pascal/Lazarus replacing it. I still know people who know Turbo Pascal and I learned Turbo Pascal in 1985.

LANTastic, I recall some people were experts with this network. I can recall when Windows for Workgroups came out and had built in networking that LANTastic went on decline.

DBase and Clipper, I can recall porting databases and code written in them to MS-Access in 1996-1997.

Wordperfect 5.0/6.0 macro writing. I know some small law firms that still have document templates automated with Wordperfect 5.0 for DOS or Windows. Hardly anyone else uses Wordperfect and has moved to MS-Word and used VBA for Macros.

AmigaDOS/AmigaOS it used to be the bee's knees for video and multi-media in the late 1980's, I am one of the few left that still has Amiga skills on my resume. AmigaOS reached 4.0 quite some time ago, but hardly anyone uses it anymore except in Europe for various niche markets.

ProDOS, AppleDOS, I think the Apple // series is long since dead and buried, but still alive in some poor school districts that couldn't afford to replace them.

Mac OS9 and earlier, I think Mac OSX is the top dog now. The Classic MacOS is no longer in demand, and 68K Macs are only used in school districts that couldn't afford to replace them.

BeOS, despite trying to bring it back from the dead it using open source, BeOS used to be popular in the late 1990's and used to run on PowerPC Macs and Intel PCs. I can recall some of my friends used to develop software for BeOS, but not anymore.

Wang, some people I know still list Wang skills on their resume. It used to be in high demand, but once Windows NT 4.0 and Windows 2000 Server came out, there was a mass migration from Wang, after Wang got shrunk and almost went out of business. They did have some Visual BASIC graphic tool called Wang ImageBasic, but I think Internet Explorer 4.0 or 5.0 broke it and so did Visual BASIC 6.0 break it. I think Leadtools replaced it.

8 Bit Computers, nobody really uses them anymore. Big Businesses only used the Apple // or CP/M systems and the Atari, Commodore, Sinclair/Timex, etc were used in the home mostly.

The Apple Newton, the Palm Pilot and Windows CE devices replaced it.

Arcnet and Starnet cards, Ethernet replaced them. Token Ring is almost dead, but some die-hard IBM Fans still use it at their companies. Anyone remember making twisted pair and coaxial cable network wires for Arcnet and Starnet networks? I do.

MS-DOS 6.X and Windows 3.X and earlier, like OS/2 they deserve to be mentioned. I think some older charities non-profit organizations still use them on old 286/386 systems that cannot run even Windows 95, and they use a Netware 3.X server to share files with them.

MS-Foxpro, does anyone still use it? After MS-Access got upgraded, and MS-SQL Server had more features added to it, MS-Foxpro became redundant.

Assembly Language, Machine Language, remember writing native code for the 8088, 68000, 6502, 6809, IBM Mainframes, etc? Hardly any company wants us to write in Assembly or Machine language anymore. It seems like only hackers use these to do exploits and write malware.

FORTRAN, I think BASIC and C sort of replaced it, and then C++ and Java replaced them. FORTRAN got NASA to the moon, but NASA uses Java or Python now.

Re:Other dead skills

[saitoh]

> FORTRAN got NASA to the moon, but NASA uses Java or Python now.

That clarifies many, many things about NASA. Thank you.

Re:IT is More Than Software

[DerekLyons]

In the cities, on the cutting edge, stuff drops out of use almost before it can be considered a mature product. But not every IT project is about the cutting edge. A lot of things, particularly in infrastructure and even more particularly in remote rural areas, were built to last because no one knew when they'd be able to afford a proper upgrade.

Even in the cities stuff was built to last - because until very recently upgrade cycles were measured in years, if not decades. Certainly not the annual or quarterly cycles so common today, even in infrastructure.
 
I own a Bell System familiarization manual from the early 80's - and about the only type of switching system not covered in it was the local manually operated local plugboard. The only type of switching system specifically mentioned as being phased out was the manually operated (actually semi automatic as the operator punched buttons rather than patched cables) switchboards for connecting to and cross connecting between long distance trunks. The tacit assumption (even for the remaining mechanical systems where were already obsolescent by then) was "this stuff is out there, and it's going to be for a while yet - so you'd better know about it".

COBOL is not a skill

[glwtta]

Neither are C, ColdFusion, or NetWare certification - programming and software design are skills, as is network administration; what they list are called tools.

Re:They are nuts on the C front.

[fishbowl]

> I find the opposite to be true. A C++ programmer is able to move to C without much problems, but the oppose it just not true.

There are some very idiomatic elements to C++ that are not of obvious utility from a C programmer's point of view. This can even escape people who *Teach* C++. Some differences between C and C++ look tiny, but have enormous implications.

Consider a couple; const correctness, and the function-style casts.

There is a short list of specific things where C++ differs from C. So a programmer can basically write C in a C++ environment and get away with it. He can even make use of the type/class/object system, heap based memory allocation, etc. But these are really still superficial differences. The real differences don't present themselves so much as syntactic distinctions, and it is quite obvious when a C programmer writes "C in C++".

Likewise there are some big hurdles that a Java programmer has to get over before being a really effective C++ programmer, although in these cases, the whole OO-design idea has usually taken root; sometimes even more than is typically idiomatic for C++ -- you can tell when someone is thinking Java and writing C++ too.

Like I said, the differences can be subtle, but fundamental, and it really jumps off the screen when an experienced C++ programmer sees the work of another experienced C++ programmer, as opposed to the C++ of a java or C programmer. Hard to explain, but I suspect you know what I'm saying if you are one.

my experiment

[wellingj]

I went to dice.com and started a blank search.
The number of jobs(posted in the last 30 days) that was listed if I picked C as a skill?
Answer: 17139 jobs

Java?
Answer: 15760 jobs

So.....Myth-busted?

not my experience

[Trepidity]

I've never met a single serious mathematician who used anything but hand-coded LaTeX, and few (no?) mathematics journals even accept MS Word submissions. It's also still the dominant way of writing CS articles, with the exception of some of the more social-sciencey branches of CS (e.g. HCI), which prefer MS Word.

Re:I agree totally.... BUT

[adamjaskie]

I don't understand this whole "computers are faster; why bother making things run fast?" thing. Why can't we keep writing efficient code, run it on the faster modern machines, and have things actually GO FASTER? It seems that as computers get faster, application programmers get lazier, and everything runs at the same pace. What used to take 20 cycles now takes 4000 cycles, but those 4000 cycles happen in the same time as the 20 cycles. Is that an improvement? Not in my book.

Re:I agree totally.... BUT

[Money for Nothin']

Why can't we keep writing efficient code, run it on the faster modern machines, and have things actually GO FASTER?

Simple economics: developer time is expensive, and the cost of it keeps rising with inflation, if not beating it, making the cost of developer time ever more expensive in real terms.

Meanwhile, hardware continues to drop in price in both nominal (not inflation-adjusted) and real (inflation-adjusted) terms.

It's cheaper to implement for a 16 core, 8GByte RAM box than it is to pay a developer to optimize the code so it can run on a single 486DX2/66...

Re:Amateur's make me laugh.

[KingSkippus]

Wow, to the poster above, thank you, that's a fantastic analogy!

I've been beaten over the head with the "it does a LOT of things!" stick so many times it makes me sick. The problem is that it really sucks at all of them!

It's really comical. Here's a typical me/Notes goober conversation:

Me: The Notes client truly sucks as an e-mail client. It doesn't adhere to any OS's standard conventions, and it crashes a lot.
Them: Well, Notes does kind of suck on the client side, but the servers are where it counts, and it's really stable.
Me: Okay, well explain to me why we have at least one or two servers crash every week, and we have to schedule a reboot once a week then. Oh, and what happened to my e-mail? It's all gone!
Them: Oh, sometimes databases just eat themselves. Don't worry, I'll restore everything up through last night from backup. But the rest of the time, it's stable! And besides, it's more than just an e-mail system. It's also a database!
Me: Oh! Well, in that case, I have these two related tables that I need to store in an--
Them: It's not a relational database, just a database.
Me: Come again?
Them: You can't actually relate the information from one table in another. They're just flat tables. No relations.
Me: So, for most practical purposes, it's just a storage bucket that can't do what even Microsoft Access can then?
Them: Oh, it can do rapid application development too, though. Yeah, it's a development environment, that's the ticket!
Me: Oh! In that case, I'd like to create some kind of form where I can enter this information and store it. Then when I click that button, send an e-mail to those people with the information in it.
Them: No problema.
Me: Okay, that's a title, so it needs to be bold text--
Them: Oh, that's a rich text field.
Me: Yeah, so how do I code up a rich text field?
Them: Well, that's kind of a beast. You can't really code it up directly, you have to create another object to store the information in and... Well... I don't really understand rich text fields myself. It's best just to avoid them. Even professional Notes developers know that.
Me: So, it sucks as an e-mail system, it sucks as a database system, I can't even send out a frickin' formatted e-mail... Is there anything Notes does do well? Anything at all?
Them: Oh, yes! Replication and security!
Me: Fuck you. I'm using Gmail account.

As a technical professional with a strong background in systems architecture and server administration, I would highly advice any serious businessperson to avoid Lotus Notes like the plague. Ignore me at you and your career's peril.

skills we want to kill

[neonsignal]

How about a top 10 list of computer skills we'd like to see die?

1. Mass marketing (also known by the fuzzy name 'spam').
2. Ability to piss someone off with an email that was meant to be friendly.
3. Documenting with the text "someone needs to fill this bit out".
4. Finding the Caps-Lock; wasted brainspace for a useless key.
5. Coding of Flash advertising.
6. Writing bubblesorts... and inline.
7. Industrial design that puts the reset button near one's knee.
8. Being able to press the Ctrl-Alt-Key without thinking.
9. Internal cable engineering that enables leads to be plugged in reverse.
10. COBOL; because it is the vampire that needs a stake through the heart.

Flip, why stop there. Lets go for the top 100.

Re:I agree totally.... BUT

[mcvos]

Why can't we keep writing efficient code?

Economics. Computers are cheaper than programmers, so efficiently writing code is more important than writing efficient code.

Actually, Java is hardly slower than C++ these days, so for most purposes, you can write pretty efficient code in higher level languages. C/C++ will remain for the really low-level stuff that you simply can't do in Java, and for the high-performance libraries where even the slightest speed gain will pay off in the end.

Re:it's the perception of its importance that died

[Old Wolf]

Don't get me wrong, I love C, but there is absolutely no reason to _still_ be using C in the _21st century_ when you could be using Embedded C++

Embedded C++ is the worst of both worlds, IMO. It is more like C with some syntactic sugar. It removes all of the good features of C++ such as namespaces and templates.

to get rid of the stupid "typedef struct" type declarations,

You don't have to write "typedef struct" in C. Simply 'struct X { ...... };' works just fine.

and other C idioms such as implicit int, no proper bool support, limited variable declarations, etc.

Those things were all corrected by ISO/IEC 9899:1999, which came out just a few months after the C++ standard (and long before EC++).

Depending on your real-time nature constraints, you'll want to turn off RTTI, Exceptions, Virtual Funcs, and Multiple Inheritance and use C++ as a better C to _at least _ get some better compile time type safety.

People often say that, but I've yet to see any code example of how C++ has better compile-time type safety (assuming you are not talking about the use of templates for generic programming). The only thing that comes to mind is that in C++ you can not implicitly convert from (void *) to some other pointer type, but in C++ you would almost never use a (void *) anyway so it seems rather moot.

Re:I agree totally.... BUT

[swilver]

Actually, I think it's not as bad as you think -- you assume that a 10 times faster CPU actually performs 10 times faster in every way, unfortunately it usually means that the CPU wastes 10 times more cycles waiting on stuff. Yes, there are lots of things that used to take 20 cycles that now take 4000 cycles, but mostly those things are not time-critical anyway (like user interaction, anything that has to access the network or harddisk -- webservers spring to mind). For example, does it really matter if my GUI code runs in 20 cycles vs 4000 cycles? No, it won't make any difference at all -- the bottle neck here is how fast a user can click (and how fast the graphic card can render all those "special" effects users seem to love these days). Optimizing that code to run in 20 cycles won't give any performance increase at all -- optimizing it would not only be a waste of time, but would be like fixing something that already works -- the best case you can hope for is to get a faster piece of code with as much bugs as the original.. usually however it will introduce new bugs.

Now let's take this a bit further -- how much of a performance hit do you take when you access memory that is not in the CPU's cache (or 2nd level cache)? The CPU will have to wait for the memory to be available... optimizing code that frequently accesses memory outside the cache would be useless (and would just mean the CPU has to wait a bit longer). Let's take quicksort, the algorithm isn't particularly hard but accesses memory a lot. Would it matter if one iteration takes 20 cycles or 40 cycles on a modern CPU (let's assume that's the difference between C and Java)? It will make little difference, the CPU has to wait for data anyway. In the end, even in such a low level algorithm, it will make little difference whether we used a very efficient piece of code, or a slightly less efficient one -- the bottleneck is the memory. In other words, as long as the algorithm you use is the same, both pieces of code should be about as efficient.

The only time optimizing is still worth it is when you are doing stuff in tight loops that isn't randomly accessing memory for all kinds of reasons (and which of course is used to do a lot of bulk processing, like video encoding) -- it's hard to even think of a good example, but I suppose it might be worth using more efficient code in signal processing, compression/decompression and rendering applications. Even in those cases however a lot of stuff is handled in optimized libraries for higher level languages.. I mean, it won't make any difference if I use Bash (horribly inefficient!) to call my favourite Unzip program to unzip a multi-megabyte file, or whether I wrote a C program to do the same. It would still take as long.

BAH - 10 already-dead skills...

[bscott]

0. Tweaking IRQs on PC clones to let soundcards work with any other card
1. Knowing how to drop certain types of home comupter to re-seat the chips
2. Inserting 64k RAM chips with your bare hands to expand memory
3. Cutting a notch in 5-1/4" floppies to use the other side
4. Adjusting graphics by hand to NTSC-legal colors for decent video output
5. Editing config.sys to push drivers into HIMEM in order to free up memory
6. Crimping your own RJ45 connectors to save money
7. PEEK and POKE locations to do cool stuff on the Commodore 64
8. Manually configuring a SLIP connection to connect to the Internet (in pre-Winsock days)
9. Removing adjectives and punctuation from code comments to fit into 1k of RAM

Re:IT is More Than Software

[Yer Mom]

I regularly see software that comes on 9 track reels and other ancient equipment.. My biggest shock was seeing in downtown Toronto equipment that still uses vacuum tubes.

I bet it has a lovely rich, warm sound, though...

Re:I agree totally.... BUT

[Alioth]

No it's not cheaper to implement for a 16 core space heater. The majority of computers sold today are not the mini tower room heater that you may have beside you, but embedded devices. ARM cores outsell x86 by a large margin. Atmel and Microchip sell billions of 8 bit devices every year. Zilog still manufactures the Z80, as well as microcontroller style Z80 chips. For every space heater PC, there are ten other devices that use a small processor (washing machines, microwaves, phones, cars, televisions etc.)

You _have_ to write efficient code for those. The laws of physics say that these small processors will *not* get substantially faster, because they need to be very low power and have very small die sizes, so you can't just throw MHz and extra transistors at them to compensate for software bloat. Anybody working with embedded computers still has to write efficient code, and get as close to the metal as they can. This means assembly language or C.

The cost of developer time in an embedded device that will ship millions of units is trivial compared to having to use a more powerful microcontroller to compensate for bloated code. In the PC world, of course, the opposite holds true - since the software developer is only shipping a software device, they can just rely on the customer to buy beefier hardware at no cost to the software developer. Embedded developers cannot push the cost of bloat onto their customers without losing out to their competitors.

Re:I agree totally.... BUT

[ShannaraFan]

I wish I could shake your hand... In my company, we have monthly production outages during which system maintenance is performed and new code is deployed. During the last one, we also upgraded the production database server to a new 16-core 128GB RAM SAN-attached IBM server running SQL Server 2005. Big ol' nasty machine, new database engine, updated DB statistics. Sunday morning, as systems were brought back online and the "world" was beginning to reconnect to the database, Perfmon began to show high CPU utilization. This continued until all 16 cores were pegged at 98-99%. We're all tired, crabby, disappointed, and now management level folks are waking up and beginning to panic.

The problem turned out to be a new table/stored procedure combo that was part of the new code deployment. The table was missing a critical index. A simple 40-second CREATE INDEX statement produced a near-vertical drop of the CPU metric in PerfMon, from 98% to less than 10%, where it has remained most of the week. Faster hardware is not always the answer!!!!

Re:I agree totally.... BUT

[nametaken]

Excellent point.

It also broadens the pool of available programmers. I work for a small business. I know I'm not a great (or good, probably) programmer, but I write all kinds of applications for the company I work at. I certainly try, but I know there are probably a 1,000 ways to do what I do, better.

So why does the company allow me to write our stuff? Because we're a small company and we could never justify hiring those great programmers for every little thing we'd like to have. It's either me, the guy who probably doesn't always know the best way, or not having it at all. In the meantime, like you said, a workstation costs what a workstation costs... it's not like we're dumping extra money into hardware because of my code.

And the people who use my software? They love it. It gets the job done well (because it was designed the way they want it) and it all works fast enough. Geocoding software, log parsing and reporting, trivia engines w/ web services for multiple locations, automated RFP systems that integrate with SalesForce, mailing apps, shopping carts, document libraries, etc... all things they've gotten in the last 11 months that they probably wouldn't have purchased or hired someone to develop, but I can knock out for them in no time while still fulfilling my actual job duties. That makes me pretty damn affordable, considering I'm already worth my salary for my regular job there.

BTW, you can all blame VisualStudio and the .Net framework for making situations like this commonplace... I've seen it all over. It's really TOO easy to write software nowadays! Oh, and nobody panic, I know my code isn't good enough for the public... you won't be dealing with any of my bugs anytime in the near future. :)

My predicition:

[Ihlosi]

C will still be dying when most languages that are alive and kicking right now are already buried.