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?

[Anonymous Coward]

Same for COBOL. Loads of people are still being hired to build and maintain (large) COBOL applications. While there aren't many new systems being made in that language, there's a considerable amount of them that need maintaining and would simply be too expensive to rebuild in a different language. Think of large human resource applications, mostly.

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?

[Anonymous Coward]

Speaking as a Linux developer at a major US corporation, we have HUGE demand for C skills, but have trouble finding people that know it. C++ and C#, by comparison, have next to no demand in our company.

Re:c ? really?

[jcgf]

damn rights dude. Plain old ansi C was the first language I learned in college (only ever touched Qbasic in HS) and it's by far my favorite language ever.

"C++: an octopus made by nailing extra legs to a dog." - Steve Taylor

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?

[sim82]

Why do I have the feeling that c and c-derived languages like c++, c# and java (maybe not really c-derived, but generally real 'non scripting' languages that somehow look and work similarily to c (but that would have been too long)) will still be around after "the Web" is long dead and gone?

The web has gone through immense changes in the last 10 years, while the basic technologies that keep the web running have stayed remarkably stable. Windows has had some gui changes, UNIX is now called Linux, those fancy new web-servers even run scripts to generate HTML code. But still it is the same old c-ish technology. I don't see how this will become irrelevant even when "the Web" takes over even more ...

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?

[Anonymous Coward]

The best sign of of a good programmer is the number of languages known. C sucks as far as productivity but is necessary. Smalltalk RULES (but is truly dead).

An Old Fart

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?

[geekoid]

"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."

You, like many may people, do not understand C++. It is not, nor has ever been, a replacement for C or to be used in very low systems.

The indirection alone should tell you that.

Re:c ? really?

[geezer nerd]

After more than 40 years, Fortran still keeps chugging. Fortran will never die! But seriously, programming languages are not only what this is all about. Surely every programmer of a few years experience has used many different languages to develop programs.

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?

[polar red]

it's going to die. Sure, They were saying that since I started in IT in the early 90's.

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?

[rrohbeck]

That's probably in the Microserf world.
Linux, embedded anyone? I use C++ only sometimes and have yet to see any use for C#. No, I'm not a Windows app coder.

Re:c ? really?

[Mieckowski]

I agree with your point, but I don't think Haskell is written in C (at least its main implementation, GHC). I bet there's some glue code somewhere but I think it's written in Haskell and compiled directly to machine code.

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?

[jesuscyborg]

The bulk of GHC is written in Haskell and requires GCC to compile a large portion of C code required to bootstrap the compile process. Also if memory serves me correctly GHC compiles binaries by translating your Haskell code to C, and then compiling the C code.

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?

[quanticle]

C isn't the only language that you can implement a compiler in. Haskell might use another language, such as ML for its compiler.

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?

[Anonymous Coward]

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

Re:c ? really?

[mehtars]

Wait until Y3K

I think you will only need to wait till 2100

Re:c ? really?

[fyngyrz]

So, when you have a small object with 10 methods, do you actually waste 40 bytes on 10 function pointers?

We would use - not waste - 4 or 8 per method (I see you're not thinking 64 bit yet...) if we create an object that will specifically benefit from methods, which mostly they don't; standard coding approaches work fine. Constructs often don't need to be objects because they aren't handled by multiple clients that would benefit from that kind of paradigm.

I'll give you an example of an object with methods; an effect, or filter, that can be animated or used atomically. Methods include setup, update, RGBA execute, geometric execute, cleanup, open dialog, set dialog, update dialog, draw, close dialog and so forth. Hundreds of effects or filters share these methods; all the methods are used under one condition or another, hence there is no waste. Likewise, these carry lists of variables that can be modified by the animation system, which are themselves objects and which are processed by another section of the software. It isn't wasteful in the least, it isn't difficult, and it doesn't bring along any baggage unless you specifically intend it to be there (which makes it not baggage.) It allows uniform handling of parameters, the ability to process them using various mechanisms such as splined, linear, table-driven - no matter what operator we're talking about. It also allows filters plugins to be both extremely simple, and still take advantage of the dialog system, the animation and so on. We use a similar approach for objects and textures in the ray tracer.

For example, in the image processor, a fully functional tint plugin that implements all filter capabilities breaks down to an ID function with 4 short lines of code, an initialize function with 1 short line of code, an execute function with 21 short lines of code, a setup function with 6 very short lines of code, and a dialog processing function with 7 short lines of code. That gets the plugin an about dialog as well as the function dialog, area-aware effect processing, user abort, unlimited undo, developer ID, progress bars (2 - 1 per op, 1 per stream), variable range limiting and wrapping, and error checking. Nothing else of ours gets linked into this, so it is extremely lightweight. Anything else is OS related (DLL paradigms, etc) and isn't overhead attributable to our code (and doesn't amount to much either.) Looking into the effects plugin folder of a competitor I have installed, the smallest plugin in the folder is 96k. Looking at a directory of our plugins, the smallest one in there is about 10k — and our plugins do a lot more and are considerably more flexible.

This size pattern (approximately 10:1) holds over the main executable, our own libraries as compared to libraries that come with competing products, and plug-ins. Speed doesn't see that kind of gain, but we do see a 2x to 3x speed advantage for most things, and for the couple that come to mind that we don't show such an advantage, I know the method we're using isn't even remotely similar to the competitor's method; we probably have failed to come to nearly as efficient a solution to the problem - it isn't a language issue so much as it is someone being more clever about that specific type of image processing than we have been. One big exception to this is application load time; there we are way faster than any of our competitors. Our apps are ready to use, including having registered a folder heavily loaded with plugins, before you can get your finger off your mouse using a machine that is several years old. Modern machines are even faster, but there isn't any way to really perceive it - once you get to the human perception of "immediate", there isn't anywhere else to really go.

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,

Re:c ? really?

[Anonymous Coward]

"My library has programming texts older than most coders today."

Oh, yeah? Well, I have "The Computer Survival Handbook (how to talk back to your computer)" by Susan Wooldridge & Keith London, © 1973, hardcover. So neener neener neer!

Re:c ? really?

[Critical Facilities]

Nicely done, although it should have been...

"Hey, Peter. Whaaat's happening?"

Re:c ? really?

[msuarezalvarez]

You can also skip the C step. Or compile targetting bytecode VMs.

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?

[Anonymous Coward]

Don't worry, nobody in their right mind (who has written a line of code in this century) will come asking you for a job, after reading your comment.

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?

[gmack]

That example was amusing for me considering the job ad I had in my inbox a couple of months ago from Google. If web apps will replace C then why is the hottest web company of all looking for C programmers?

Re:c ? really?

[fyngyrz]

[c++] is not, nor has ever been, a replacement for C or to be used in very low systems.

By all means, elaborate. What is c++ "to be used" for?

Also, just FYI, the systems I'm talking about are very amenable to c++; image processing, animation, ray tracing, particle systems, and so on. They're "low level" in the sense that they have a lot to accomplish, but they are high level in the sense of accomplishing many kinds of very sophisticated tasks.

You, like many may people, do not understand C++

Quite possibly. Being able to use all of its mechanisms doesn't mean that I fully grasp the gestalt they create as a whole. But I do understand c. More critically, I am also well versed in the value of speed, efficiency, and conservation of the user's limited resources to the user. I consider pursuit of these things an obligation that trumps the convenience offered to us as coders by going more HLL than c; that's not to say that you have to perceive such an obligation. Our competitors don't, and that alone creates a significant market niche for us.

Re:c ? really?

[sparetiredesire]

Ever heard of this thing called an Operating System? Ever heard of linux? While C is not the best tool for most application development, it is indispensible for OS programming.

I'm sure C is dying as the hot language of choice for writing Hello World, but for applications where performance is key, or those that need explicit memory management (OS, drivers, embedded systems, network stacks), C is the top language by a huge margin. If there were a suitable replacement for C, I could see its popularity waning, but there really isn't a language which compares. C++ is more trouble than its worth in many applications (try to commit a C++ patch to the linux or freebsd kernels for a good time).

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?

[bl8n8r]

There seems to be a large mass of people that *wish* C would go away, that I agree with. If you want it gone, you may as well take databases and operating systems with it.

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?

[fyngyrz]

...how are you avoiding the overhead of an equivalent C++ code?

I think you may have answered your own question. There are no constructors, no destructors, no garbage collection, no inherited anything, the vast majority of temporary variables go away with one LEA (or architecture-specific equivalent) instruction on the way out of a function... there is only code you wrote, running exactly as you meant it to run, and built just like you intended it to be built. You have complete control, nothing is hidden or obscured, intentionally or inadvertently.

You would be able to more easily handle clean up with stack-based destructors and auto pointers.

Local cleanup in a c function happens when the function returns, typically in one instruction cycle; the stack pointer is modified to pop up past the reserved variables, regardless of how many there are, and that's it, they're gone. No muss, no fuss, and no programming - the close brace on the function is the closest to "programming" you have to do to accomplish this. Here's pseudo ASM code for typical function entry and exit:

// calling code: reserve space for non-register variables
LEAS -20,S
STORE copies of parameters into that area
CALL function
// function entry
LEAS -80,S // reserve space for locals
...init variables if called for using S + offsets as base memory pointer
...function does whatever it does
LEAS 80,S // dump all locals
RETURN // to caller
// or sometimes the above two instructions are one, LEAS 80,S + load PC from S++, meaning, also RETURN
// calling level
LEAS 20,S // dump copies of called variables
...continue normally

As you can see, memory "management" for locals is two machine instructions, which isn't anything to be concerned about in most situations.

For non-local elements, we have our own pool and atomic memory allocation mechanism. If we even miss one memory deallocation (or make one of a number of other types of memory management errors), it screams bloody murder at us, tells us where and when and what happened in build configuration; consequently, we don't often ship memory leaks and we don't have to ship that portion of the memory management system, either, which makes things lighter and faster for the end user.

The bottom line is we don't have speed or code issues with clean-up; mostly, it's invisible, and when it isn't, it's trivial, though certainly critical. C++ doesn't offer anything to us in this area as far as I am aware. Though I would certainly be interested in hearing if you think otherwise.

Re:c ? really?

[Anonymous Coward]

C will flat out never go away unless the computer architecture changes. It's for the exact reasons you mention, C is the real deal. C is the ABI that practically everything uses at some level.

It has been said millions of times: C is portable assembly. It maps to the current architecture of most computers and is in the sweet spot of performance and portability. This absolutely will not change unless the architecture changes significantly. It won't change because there is no reason to change it. More stuff will be built on top of it but at some level there is and will almost always be C.

Re:c ? really?

[RightSaidFred99]

C is a niche language. Cobol is still around, and will be for a long time too - doesn't make it particularly relevent to most people. It's useful in a few specialized fields, but if you're Joe Average C developer from 10 years ago you've probably had to move on.

Re:c ? really?

[RightSaidFred99]

Best available choice for... OS, compilers, and a few specialized applications? I wouldn't call that a huge class. I think you'd be insane to write your run of the mill Windows or even Linux GUI app in C. C isn't dead, but it's certainly declining in usefulness. It's too expensive to maintain and develop large systems in C.

Re:c ? really?

[magarity]

Several times I've been told "nobody does assembler anymore"
 
By people who think there aren't going to some day be new processors and chipsets wanting BIOSes written?

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?

[Anonymous Coward]

Keep learning, keep growing or start flipping burgers.

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

...at Burger King.

Re:c ? really?

[mcpkaaos]

C is a niche language.

It just takes longer to get the hang of it.

Re:c ? really?

[Lord Kano]

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.

I still have to perform bugfixes on and add new features to programs written in Fortran, specifically DEC Fortran derived from Fortran 77.

That's right, 20 year old code written in a 30 year old language. C is very much like Fortran. It's so ubiquitous that we're likely going to have to deal with it for quite a long time. It'll be supplemented by Java, C# and all sorts of other technologies, but C will be around for a while.

LK

Re:c ? really?

[lcreech]

Now Pascal I would believe, but not C.

Re:c ? really?

[tknd]

I'd say the main selling point of C is that you can jump into assembly code and start toying with the layer below. That's pretty useful when you want to exploit something about the hardware to boost performance or whatever you may need to do because your compiler doesn't/can't do it for you. Very few other and newer languages allow that.

Re:c ? really?

[MostAwesomeDude]

Heh, that's sorta funny. See, at my day job, building embedded point-of-sale systems, we only use C, since so much of our legacy code (not to mention the GNU, Linux, and Debian tools we use for distribution and bootstrapping) is written in C. C++ is possible, but never seriously considered due to the fact that nobody really needs it.

My hobby is even more C-centric. I help with iPodLinux. We are on ARM7s, and with only 32MB of slow RAM on a 16-bit bus, trying to load the C++ standard library in conjunction with the kernel, libc, and GUI is just ridiculous. So, although we provide a libstdc++ for userspace authors, the GUI and modules are all written in C. There's simply nothing faster.

While C++ is better for massively object-oriented applications, a lot of embedded systems are simple, single-purpose tools, and procedural C is simply a better, lighter, and more optimized choice.

Re:c ? really?

[Jay Carlson]

Yes, and this 23-year veteran of C now has exactly one goal when writing applications:

Get the hell out of C.

I'm sorry, I used to not care about checking error results or the sizes of allocated strings. But now I do. And it is just soul-killing to write one line of code and write five more to cope with the consequences of a function call failing. Not to mention the time sitting around worrying about whether I'm correct in my analysis of memory ownership in any function that allocates or frees memory and passes it to another.

So I dutifully write enough C code that is legitimately low level and has to care about stuff like system calls and memory allocation in a cold sweat, and then write the rest of my application in a scripting language like Lua, Python, or Tcl.

From then on, I can write code that I know will not bring down the runtime. Strings are no longer objects to be feared. The worst thing that can happen to me is a traceback.

Of course, I can still do stupid crap like evaluate strings coming from the network, but then again those kinds of risks don't show up every single time I touch a string.

Re:c ? really?

[RockoTDF]

How are those TPS reports coming?

Re:c ? really?

[kbro]

C is becoming relegated to the implementation language for language VMs, OSes, and device drivers. That is a very important function, but a small niche incapable of keeping that many people employed.

C is not a programming language that I would think of using when writing an application -- on any platform (think C#/Java). If you are writing apps in C, you should be worried. If you using C to peek/poke values in physical memory addresses, then you are pretty safe.

Re:c ? really?

[Hoi Polloi]

I didn't see "putting useful comments in the code" on that dying skills list. ;)

I used to see Powerbuilder and Coldfusion in job ads in the 90s all the time. Surprised it died off so fast.

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?

[danlock4]

When I took a programming class in ANSI C in 1994, we used ANSI C for that very reason: because it embodied more purely the general purpose programming skills that C++, et. al, had added upon. Oh, and the professor was kind of a purist...

Re:c ? really?

[Anonymous Coward]

My library has programming texts older than most coders today. Even worse, I have some programming texts which have dust on them older than most coders today.

Re:c ? really?

[Nicolay77]

Do you know you don't have to write classes or use templates in C++?

Just because they are there doesn't mean you have to use them.

There are some advantages of C++ over C like inline functions (that's a way C++ is faster than C) and a boolean type.
My favorite advantage is that you don't have to declare variables at the beginning of a block but just before you need them.

And if you only use GCC as you post seems to imply, then C++ is as compatible as C (mmm not so sure about this one).

However, the fact that the rest of the code is already written in C is a huge reason to keep using only C.

Re:c ? really?

[butlerdi]

But I wonder how accurate it really is. Cobol, while an old language, was estimated last year to employ approx 3 : 2 ratio compared to Java. I know that there is still an awful lot of that code still out there as I see it regularly at large client sites.C is still very much out there and for many embedded devices there is little choice besides ASM of sorts where every device requires a different codebase. I can not see this happening for a long time. As was said above development in a particular language may go out of fashion, but after 30 years in the biz I could have started in Cobol and stayed there for 30 years with little change, same as Fortran, APL, RPG, Lisp ... the list goes on ..

Re:c ? really?

[WhoBeDaPlaya]

Thank C properly. Without it, we'd have BASI, PASAL and OBOL ;)

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?

[Anonymous Coward]

Do you know you don't have to write classes or use templates in C++?

So, use C++ but don't use the C++ features...why again? So you have more work to try to trim fat from your binaries without gaining any actual advantage in writing your code?

There are some advantages of C++ over C like inline functions (that's a way C++ is faster than C) and a boolean type.
My favorite advantage is that you don't have to declare variables at the beginning of a block but just before you need them.

Um, both of those features are available under C99, along with a lot of other C++-isms. And since most embedded development work seems to be either under gcc (which supports C99) or some proprietary compiler (for which you probably don't have much choice on the language), the only thing to stop you from using those C99 features is incompatability with existing code. But, then, it's unlikely that code will be C++ compatable either. Or, in short, you're back to choosing C++ or C on language features for which C++ is notoriously for producing larger binaries if you exploit heavily.

Re:c ? really?

[arivanov]

Yep. Total BS.

1. C is still the language of embedded systems and OS internals and will be for the foreseable future. 10+ years at least. Whoever wrote that go go shoot himself in the foot with a bazooka while looking at its exhaust.

2. Non-relational DBMs. Embedded DMBMs which you include in your applications are often non-relational. So are many "standalone" persistence frameworks.

In addition to that a combination of good software development skills and RDBMs design and optimisation is quite rare, because most RDMBMs vendors, textbooks and courses do not teach the subject from an application design and development perspective. They look at it purely from data integrity perspective instead and applications are mostly referred within the scope of various pre-baked vendor frameworks. As a result the only people who are good in both RDBMs and modern software design and development are career switchers. These are hard to find, atrociously expensive and tend to disagree with both the software development and database camps which makes them "known troublemakers". This also makes many software developers constantly call for "let's give up on this SQL thing and switch to something simpler or more suitable". As a result many projects started on an SQL backend later switch to non-relational DBMs, persistence frameworks (not all of which are relational), etc.

Whoever wrote that article needs a cluebat. A heavy one.

Re:c ? really?

[Anonymous Coward]

> C++ doesn't hurt your chances, but you won't get to use it around here. :)

Not surprising coming from someone who thinks that "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". So you go and re-implement "a lot of baggage" from C++ in a subset of C++ and that proves that C++ is not worth using around there, isn't that a bit contradictory? If it's a lot of baggage you just leave it behind for good, if you actually need the features then reimplementing them in C instead of learning to effectively use C++ (which, of course, is far more demanding than learning to rant incoherently about C++) is simply asinine.
Nope, the key of C++ is not objects and objects with methods, you can use anything from Visual Basic to Java if that's all you need (and no, no matter what you do in C there is simply no substitute for public, protected and private; by lacking language support for information hiding, a.k.a. encapsulation, C really can't implement full OO semantics regardless of how much you want to stretch the syntax). You might be a little closer to the truth if you at least mentioned destructors, one of the true OO features that place C++ above most of its competitors in the OO space, but if you missed the point about encapsulation I think you will also miss the importance of destructors (as do, e.g., most Java programmers). Finally, you can't truly appreciate C++ unless you are experienced to the point of fluency in templates: C++ is the only commonly used language that effectively supports generic programming, Java's feeble attempt notwithstanding ("type erasure"? More like type collapse!)
My feelings of appreciation and reverence for C are as deep as those of any true geek, it has served me (and supported me and my family) for years and will hopefully continue to do so for many years more. But the "reductio ad ignorantia" so common among C++ detractors irks me beyond what I can endure without throwing a few exceptions (hopefully you at least managed to fake those in C using non local jumps nicely hidden behind an interface, if you didn't understand why that's important or didn't manage to properly implement it you really should be forcefully asked to STFU!)

Re:c ? really?

[bucket_brigade]

Good languages don't die take lisp for instance - it's alive for more then 40 years already and lot's of smart people swear by it. COBOL was a bad language (like everything else businesses - not programmers invent for themselves) so it died, c is a good language so it will exist for a very long time. But obviously everything comes to an end, when he says will not die he probably means in 20 or so years.

Re:c ? really?

[Anonymous Coward]

Um, maybe I'm incorrect, but doesn't a decent compiler eliminate your argument?

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?

[r_newman]

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

That's the difference between a programmer and a coder. I learned C a few years ago back when I had a bit of free time and I was looking for something constructive to do with it. I never learned programming theory specifically though and now I think I could have better spent my time on it. AH well, some day I'll have the time.

Re:c ? really?

[jjinco33]

Motorola, VISA, MasterCard, AMEX and US most emergency service dispatch stations (Public Safety Answering Points)- including the US Military still use COBOL. Granted they use Tandems (HP NonStop now)which hardly anyone I meet has even heard of, but they are frequently looking for people who can maintain and fix their COBOL programs.
Motorola actually needs people who can write new programs to replace the old ones that were semi-replaced by a failed changeover to .Net for their emergency services Computer Assisted Dispatch (CAD), of which the military uses a modified version supported by Motorola. They bought a company that was called PrinTrak (sp?) in Boulder, CO that they got all of this from.
Most of the work is done by Chinese and Indian nationals living in Canada, which then must be reviewed line by line in the US as only US citizens are allowed to write the software for both civilian and military emergency services dispatching. The bottom line there is that a lot of fucked up code comes in and needs to be fixed by US citizens.

Re:c ? really?

[LizardKing]

That example was amusing for me considering the job ad I had in my inbox a couple of months ago from Google. If web apps will replace C then why is the hottest web company of all looking for C programmers?

Was this an unsolicited email from Google offering you an interview? If so, then I had a similar one. At first I assumed it was some sort of spam, but there were no links in the email, just a request to reply to the senders google.com (not gmail) email address. The sender mentioned various postings I'd made to mailing lists such as the NetBSD ones as the reason I'd been contacted. As with you, they were interested in my C programming ability, as well as any knowledge I have of NetBSD (I've heard they use it for several systems alongside the Linux stuff). I deleted the message as I've worked at Yahoo! which was enough to put me off working for a big dot-com, but was left wondering how genuine the interview offer was.

Re:c ? really?

[lambini]

You got to be kidding me, how can you assume that C will ever die? It is still the basic language people learn to continue into other programming languages. How many of the now current programming languages aren't similar too C? Each of them differ amongst themselves, but once you know C you easily can move into another language with those basic skills.

Re:c ? really?

[Anonymous Coward]

Hard core? It's only a compiler. Besides, there are only two architectures that matter, any more: x86 and x86-64.

As a hobbyist user of Common Lisp I've been often frustrated by the slowness of more mainstream high-level languages like Python. Dammit, we've used natively compiled interactive Lisp systems for decades, why can't the Python community get rid of the glacially slow interpreter?

Re:c ? really?

[asc99c]

The COBOL language died because it's entire family of languages dropped out of mainstream programming. C is in a distinctly different position. C++, C# and Java are all based very closely on C-syntax. Actually learning C isn't really required. C syntax is by far the dominant style.

My education taught me Java and only Java (in terms of real large-scale programming languages). At Uni, I wrote my dissertation in C++ because I needed to make use of various intel DLLs so C++ was just the easiest option. That was hardly a difficult transition to make. For my work, I program in C, and again it's an easy transition to make. System design is a bit different but I can easily switch C to Java and often even copy paste code from one language to the other (many semi-standalone parts of our systems are now Java based). PHP is a bit more different but the overall syntax of pure PHP is also similar.

Pascal and COBOL on the other hand have significantly different syntaxes and it's not so easy to pass a C-style programmer a Pascal program and just let them get on with it (although thats what happened to me!)

Actually I'm surprised Pascal wasn't on the list. Various features of the language made it naturally easier to write more reliable systems with Pascal vs C - notably a more resilient string representation, stronger typing and stronger handling of case statements (missing a case value crashes the program). Therefore it is used for a lot of older mission-critical applications. Getting Pascal programmers to support these is hard work since there are so few around.

Re:c ? really?

[Aliriza]

I don't think that it will be c , cause it develops by time as system changes (visual etc) And an important part missing is most of the Certified NetWare Engineer's are managers generally cause they were in the market before everyone and this brings them an advantage.

Re:c ? really?

[Anonymous Coward]

Keep learning? Great advice. Give up on 'C'? That's another story entirely ...

Which is exactly what TFA actually says: there are almost no programmers left who only program in C, they pretty much all have other skills (at least C++).

Re:c ? really?

[Alioth]

C won't die like COBOL, but it has become niche.

You'll always find C programmers - doing low level system programming, or writing code for microcontrollers. This is where C's strength lies in 2007 - doing low level stuff that you don't really want to do in assembler, but you still need performance as close to as possible as hand-written assembler. So operating system kernels, embedded programming - anything that needs a low powered CPU (i.e. something that uses very little electricity, and as a consequence has a relatively low clock speed and transistor count) will need C if you don't want to hand-write assembly language.

COBOL on the other hand can be allowed to die - in COBOL's sphere, there are now better tools. But C is still the best tool for the job in low level programming.

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?

[Eudial]

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

They'll have to pry C from my cold, dead hands.

Re:c ? really?

[Archtech]

Reports of almost everything's "death" are greatly exaggerated. What journalists mean when they write that something is "dead" is that they don't feel like writing about it any more. Generally, that means it's about ready for serious use. Remember the definition of a "legacy" application? One that works.

In about 1990 some analyst (Gartner, I think) reported that there were about 100 billion lines of COBOL in use. Since 2000, I have seen that figure revised to about 200 billion lines. Now, while I doubt if the amount of COBOL has actually doubled in the last 15-20 years, I strongly suspect it has substantially increased. Moreover, COBOL applications drive a surprising proportion of the world's really important transactions. If you doubt this, ask IBM.

Same goes for C. Sure, commentators on the PC apps market may be seeing less of it these days, what with C#, Java, PHP, Ruby, Perl, etc. That's partly because people are using more structured and OO languages, but also because many developers work at a higher level of abstraction. That means they need scripting languages, not low-level 3GLs like C. Nevertheless, C is still the classic system programming language. If those pundits even realised there is an embedded systems market, they might get a clue.

AFAICS, one of the industry's biggest problems today is that it is getting assimilated to the fashion/entertainment industry. COBOL has been around for over 50 years; C for nearly 50. We've had Java for 12 years or so. But now new languages, frameworks, etc. are popping up and flashing by in weeks or months. No one really has time to learn how best to use them.

Re:c ? really?

[Archtech]

'COBOL has been around for over 50 years; C for nearly 50.'

Uh-oh. Before everyone else piles on, apologies for those gross inaccuracies. COBOL has been around for 48 years, and C for 35. It just seems longer.

Re:c ? really?

[maxm]

So what you are saying is that you should be flipping burgers but went into management instead?

Sounds about on par with my experience with managers ;-)

Re:c ? really?

[jrumney]

The key there was C-only programmers are finding it difficult to get work. Personally I would never hire anyone that claimed they could only program in one language, whatever that language was.

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?

[Ateocinico]

I have not seen ANY language for dealing with the bare iron like C in the las 20 years. With Java an C++ you can do what cobol does, but how do you manage the first stacks, heaps and threads? What do you use for writing the first garbage collector ,free memory manager or task switcher, or attend interrupts? C is blooming in the embedded market, a far bigger market for computers than business.

Re:c ? really?

[polar red]

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

Re:c ? really?

[Anonymous Coward]

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.

NOW GET OFF MY LAWN!!!!

Re:c ? really?

[Engine]

"My library has programming texts older than most coders today."

Oh, yeah? Well, I have "The Computer Survival Handbook (how to talk back to your computer)" by Susan Wooldridge & Keith London, © 1973, hardcover. So neener neener neer! I beat that with James Martins's "Programming Real-Time Computer Systems" from 1965.

Re:c ? really?

[Anonymous Coward]

If anyone tells you that "nobody does assembler anymore" use that as a Static Value that that person knows almost nothing about programming. Almost ALL tiny embedded systems use a mixture of Assembler and C. you know that stuff that does far more and more important work than some silly Windows application.

I am certain that patriot missile guidance is not written in C# or Java. I immediately dismiss anyone that claims that a core low level language is not used. It's just proves they are either uneducated, mis-educated, or simply full of feces.

Re:c ? really?

[eam]

> Computerworld Magazine, being an IT rag, is concerned about IT,
> not computer science or engineering. Thus it worries about product names,
> not categories.

That's an interesting point. When I opened the article, I expected it to talk about actual skills. However, as you pointed out, the article wasn't about skills disappearing. It was about products disappearing.

Products change, but if you actually have some kind of skill, you should still be useful.

I can think of some skills that *may* be dying out. However, they were dying out a long time ago.

1) The ability to write complete and correct code *without* running it through a compiler.

2) The ability to write code that is as efficient as possible.

Both of these skills seem to be fading, primarily because the hardware has rendered them less valuable.

The penalty for using the compiler to debug your code isn't as clear as it once was. If you could only use The Computer for one hour every week, you couldn't waste that time finding typos. I'm not sure how much this matters, but my thinking is that people don't look at their code enough. When they were reviewing to find typos, they could also be more likely to find other kinds of errors.

While efficiency may still be valued, improvements in hardware has made it possible for less skilled programmers to get away with ignoring efficiency. "Fast enough" has replaced "as fast as possible". "Small enough" has replaced "as small as possible". How much this matters depends on your point of view. In some areas it is still extremely important, and people working in those areas focus on efficiency. If you weigh the consequences and make a decision to disregard efficiency for some chunk of code, that's no big deal. However, it seems that a large number of programmers just don't understand the system well enough to be able to make an informed choice. They're doing the best they can, because they don't know it could be better. They don't learn, because it is good enough.

However, I'm not nearly old enough to spend this much time talking about the good old days.

Re:c ? really?

[Locklin]

> 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.

That probably won't happen untill CPU's have many, many cores, and threading in C has become too awkward. However, I have a feeling in this case, C's replacement will look as close to C as possible.

Re:c ? really?

[Dogtanian]

I am certain that patriot missile guidance is not written in C# or Java. No, they're written in Ada :-)

Re:c ? really?

[MBGMorden]

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. I went to Clemson, albeit a few years ago (2003 graduate) so things may have changed, but in my compiler design class we were allowed to write in anything that the University system had a compiler/interpreter for (our CompSci lab computers were all running Solaris and seemed to be able to run/compile ANYTHING). All you had to do was provide a working Makefile with your projects (if a compiled language) and then tell them the syntax they could use to test against their sample data (the professor was particularly good for throwing completely off the wall stuff at the programs in the sample data just to see how they'd handle it).

We actually did the class with virtually no code discussion in class, except that of our language to be compiled (LISP). For the most part the class was theory and basics, with the student left to figure out the "make this work" part on their own. Despite being a rather difficult class, I throughly enjoyed that part of my education.

Re:c ? really?

[Anonymous Coward]

It's not the language that's the issue, it's the libraries. Sure, it's not that big of a deal to learn Haskell (for example), but learning Parsec, Quickcheck, and all the other things you use to get the job done takes a long time. Especially to learn them to the level where you don't need to consult the reference docs every 2 minutes.

Re:c ? really?

[rastos1]

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.

You don't need to go that far. C/Java might be similar to Delphi, but it entirely different thing than Lisp or Prolog or ObjectStar.

Re:c ? really?

[Gotebe]

C produces fast, tight code that so far, C++ and C# can't even begin to match.

(Not speaking about C#) C and C++ are the same. If needed, you can always drop down from C++ to C and, in a C++ source, do stuff the way you'd do in C and get same fast, tight code. This statement has no merit.

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.

I gather you don't really profile your code. If you did, chances are, you'd find that bottlenecks are in some spots and that all C in the world doesn't matter compared to the cost there.

(like Microsoft's treeview, to name one)

What this has to do with anything? The tree view, that is a part of win32 shell common controls, is a C API (like the rest of Win32). WTF!?

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?

[Tatarize]

A computer programmer had just finished his project updating the COBOL code at his company, he was crossing the street and was hit by a bus.

Suddenly he found himself in a cryochamber with somebody standing in front of him saying "are you okay?"

"Why am I here?" the programmer asked.

"Well," the man replied... "The year in 9999, and we are preparing for the Y10K bug, and we heard you know COBOL."

Re:c ? really?

[jedidiah]

Big deal. You probably could have said the same thing 10 or 15 years ago.

C programmers are not the sort to stand still. They will get into just about anything, except perhaps cobol.

Re:c ? really?

[Dogtanian]

NOW GET OFF MY LAWN!!!! "Get off my LAN", surely?

Lameness filter encountered. Post aborted! Reason: Don't use so many caps. It's like YELLING. Yes, lameness filter, I believe that was the original poster's intent. (Ironic that padding a rejected message with the filter's original complaint stops it complaining again).

Re:c ? really?

[shutdown -p now]

A classic example where C++ can be faster than C is generic sort function. C's qsort takes a function pointer, and it has to do an indirect call for every comparison. C++'s std::sort is a template function taking a functor, and the call to said functor is usually inlined within the sort loop when the template is instantiated. The only way to get the same effect in C is to manually write sort functions for all type & comparison op pairs (or use macros to do the same) - effectively manually instantiating the equivalent of the C++ std::sort.

Re:c ? really?

[shutdown -p now]

Local cleanup in a c function happens when the function returns, typically in one instruction cycle; the stack pointer is modified to pop up past the reserved variables, regardless of how many there are, and that's it, they're gone.

That's not exactly local cleanup. That's stack cleanup, but there are still resources you have to free if you had allocated any inside. The only difference between C and C++ in that regard is that, in C, you have to clean up yourself on every exit point, or define a bunch of labels for various stages of cleanup, and goto those as needed, depending on how much you've allocated. The latter is precisely what a C++ compiler will do with destructors, except that the C++ code is 2x shorter as a result, and you cannot accidentially forget to cleanup.

The nice thing about C++ is that it doesn't make you pay for features you don't use, and the cost is usually clear. For example, inheritance does not cost you anything over plain composition if you have no virtual functions (but the syntax and type compatibility are more convenient); non-virtual method calls are the same as plain old function calls; etc.

Re:c ? really?

[shutdown -p now]

What he means is that plain C calling convention, on any platform, is the universal cross-language interop protocol. You cannot use a C++ template class from Java, and you cannot call a Python multimethod from Ruby, but all these can call an extern "C" function exported from a shared library, no matter how it is implemented, and most compiled languages provide the means to write such functions as well.

Re:c ? really?

[Anonymous Coward]

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

hi Peter

Nicely done, although it should have been...

"Hey, Peter. Whaaat's happening?"

Ahem. I think he's implying that Peter's last name is Principle. The guy is so famous that there's even an article about Peter on Wikipedia.

Re:c ? really?

[mnmn]

Indeed C is the lowest level structured language and simplistic enough to survive for a long time. It's what sits on top of assembly and I can imagine neither disappearing except if all chips took java bytecode.

C might be changed or enhanced to match changing hardware, but neither objective C nor C++ killed C because C cannot be replaced.

It might become relatively unpopular over time however and be limited only to the layer between assembly, operating system and other langauges...

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?

[Crazy Taco]

C still has many uses in low-level coding, operating system development, embedded system design, etc., because as a language it is about one step above assembly. You still find it very commonly taught in good engineering schools. In fact, about half my classes in my computer engineering program were in C (all the ones that focused on the before mentioned topics).

I think what they mean is that C is dying as a general purpose language that your average programmer would use to do day to day programming. It used to be used for absolutely everything, including writing GUI programs on early versions of Windows using the Windows API. Now, though, C is no longer used for everything, and is having to settle for the niche of lower level coding. Nevertheless, I think once C gets in that niche, it is going to stay there for quite a while without usage falling further. When you really need to intimately work with the hardware and write small footprint, efficient code, I have yet to see anything better suited to the task than C.

Re:c ? really?

[LizardKing]

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.

Virtual methods add extra code which introduces indirection - the result is larger and slower code. Exceptions are slower than a conditional and goto (which are four or five assembler instructions), as they have to walk up the stack looking for a handler. Yup, it may be possible to optimise them at compile time, but I'd be surprised if any compiler does as by their very nature they're expected to be *exceptional* occurences - rare indications of a problem. Well written C code will always outperform C++, although other considerations may still sway your decision to use C++ over C (quality of libraries, developer familiarity, etc).

Re:c ? really?

[Doctor Faustus]

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.
My operating systems class wasn't really a practical class. We basically just talked about all the things operating systems do and how they affect your programs and whatever else is going on in the computer. I think that's normally how it's done unless you use Tannenbaum's book and study Minix.

We have a compilers class (Programming Language Implementation), but it's an elective, and while I'd like to take it, I'm graduating in December and it's not offered before then and hasn't been for at least a couple of years.

My school

Re:c ? really?

[644bd346996]

Compiler written in what language? Assembly? No, because that's not portable and too low-level to implement a complex language anyways. Compilers are generally written in C or a C compatible language.

Re:c ? really?

[Goaway]

True. C's niche, however, is the niche of making everything actually work for the rest of the people.

Re:c ? really?

[J.R. Random]

Nobody ever wrote a kernel in Cobol. C will be dead when Linux and BSD are dead.

Re:c ? really?

[Goaway]

I'm pretty sure he just glossed over most of those languages because nobody actually does anything useful with them.

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:c ? really?

[Goaway]

On the other hand, nobody does anything useful with those languages, so it doesn't really matter.

Re:c ? really?

[TheRaven64]

Lisp certainly still has it's place. After all, it's about the easiest language to write a Smalltalk runtime in...[1]

[1] Or, as a Lisp programmer once told me 'Smalltalk still has it's place; it's about the easiest language to write a Lisp runtime in.'

Re:c ? really?

[Richard Steiner]

You're not alone. The F77 code I play with now is newer (maybe 12 years old at the oldest), but some of the F66 code I played with at a previous job dated from the mid-1960's and is still running in production.

We have a lot of Fortran *and* C code here. :-)

Re:c ? really?

[TheRaven64]

There are some advantages of C++ over C like inline functions (that's a way C++ is faster than C) Most C compilers have supported inline functions for well over a decade. They became an official part of the spec eight years ago. Oh, and the SGI compiler can do inlining between separate compilation units, which can make some things hugely faster.

Re:c ? really?

[SoulRider]

And how does learning java lead to learning forth anyway?

Its a gateway language.

Re:c ? really?

[iamacat]

The point of exceptions is that they are faster than if statements when not thrown. Theoretically, they could have zero overhead by maintaining a subset of debug information. What I saw in practice is incrementing a hidden local variable a number of times in a method to know which destructors to call and which try blocks are in effect.

Re:c ? really?

[iamacat]

There are no constructors, no destructors, no garbage collection, no inherited anything, the vast majority of temporary variables go away with one LEA

While your choices in this particular product may be justified, you might want to review both C++ and x86 assembler (WinImage) for the sake of both your employees and your slashdot friends.

Re:c ? really?

[Tabernaque86]

I don't know about other universities, but at mine you have to take a C programming course in first-year engineering(regardless of discipline), and pass it in order to go into second-year studies. I found it interesting, and actually looked forward to writing the assignments/exam.

Re:c ? really?

[shutdown -p now]

I listed those merely as particularly representative of their respective fields. Even so, I wouldn't dare say "nobody actually does anything useful" with Prolog or FORTH, for example. But if you want a more mainstream language, try XSLT. A very common way to deal with XML these days. I've found that my colleagues, mostly with C/C++ background, find it hard to grasp the idea of a language where variables are immutable - they simply cannot understand how to go around the most basic tasks. Yet it is something that anyone even with the basic knowledge of functional programming will find obvious. JavaScript, another immensely popular industry language, has a very different approach to OOP compared to the rest of the family (C++/Java/C#), and I've seen people struggling with the transition.

Re:c ? really?

[LizardKing]

I can think of a number of ways of optimising exception handling, such that there's less code to execute when an exception isn't thrown, however they all involve storing a fairly hefty amount of data. Even so, I can see that it's possible to make code that predominantly uses exceptions for error handling perform a little better than C code that checks a return value almost every function call. However, you'd need to apply some forethought to ensure you don't end up with too many fine grained exception and try ... catch blocks.

Re:c ? really?

[Anonymous Coward]

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.

Congratulations, you have identified the biggest problem with java and (to a lesser extent) C++ - the enormous freighterloads of crap they carry around with them, which contributes to a large degree why modern applications are so slow, resource intensive, bug-ridden, and difficult to deploy and maintain.

Re:c ? really?

[Anonymous Coward]

That's not exactly the case. In order to write the first C compiler it would have had to been written in assembly or some other pre-existing language. Of course that first app was probably a compiler compiler. E.g. assembly was used to write a compiler for language B which was a sub language of C with enough functionality to be able to generate a compiler for C... B was then used to compile the C compiler which is then used to compile future C programs.

Then only the intermediate compiler in B needs to be transitioned to other architectures. The final uncompiled C compiler is then machine independent and can be compiled by B for each target hardware. This is basic compiler 101. Take a look at other compiled languages and you will often find they are "self compiled", this is the technique referred to.

Re:c ? really?

[be951]

And how does learning java lead to learning forth anyway?
Its a gateway language.
Gateway? Do they even make those anymore? Maybe they were bought by Dell or HP or someone...?

Re:c ? really?

[be951]

COBOL was a bad language ... so it died

Perhaps you missed this COBOL has been around nearly 50 years and still has a very strong user base, as indicated in the linked post. Moreso than LISP, I would say (a quick search on Monster turns up over 1000 hits for "COBOL" and 55 for "LISP"). COBOL has its place despite 20 years or so of people claiming that it is dead.

Re:c ? really?

[SadGeekHermit]

That's cool... But, still, C++ is a superset of C, right? So C's still "in there", kind of, even if the techniques are different (references instead of pointers, etc). I guess the point I was trying to make was that you might say something like "C is dead" but if you don't look really closely, you won't notice that it's all around you and its death was greatly exaggerated. :)

Re:c ? really?

[Tablizer]

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.

Except for Lisp, whose secret is to never become popular to begin with :-)

Re:c ? really?

[fyngyrz]

That's not exactly local cleanup. That's stack cleanup, but there are still resources you have to free if you had allocated any inside. The only difference between C and C++ in that regard is that, in C, you have to clean up yourself on every exit point, or define a bunch of labels for various stages of cleanup, and goto those as needed, depending on how much you've allocated. The latter is precisely what a C++ compiler will do with destructors, except that the C++ code is 2x shorter as a result, and you cannot accidentially forget to cleanup.

OK, it's not "local cleanup", it is cleanup of locals. For any reasonably sized element, you would allocate it that way. For large elements, you'd use an allocation. However, as I stated above, we have written a complete memory manager which includes pools. Works like this (typically - there are other modes of operation, and I've expanded some things into explicit code rather than parameterized defines so it'll be clearer... just keep in mind this exact functionality actually requires considerably less than the text shown... for instance, the entire getpoolid() line collapses to GPID("functionname") similarly to several other uses here):

// at beginning of source file:
#define THISFILE "filename"

// on function entry:
unsigned int pool = getpoolid("functionname", THISFILE);

// within function

if (ptr1 = getpoolmem(size1, "p_name1", pool))
{
if (ptr2 = getpoolmem(size2, "p_name2", pool))
{
if (ptr3 = getpoolmem(size3, "p_name3", pool))
{

// we're in here because all resources we require have been allocated, so do some things

freepoolmem(ptr2); // toss ptr2, we're done with it earlier than the others

// do more things

}
}
}
discardmempool(pool); // ptr1 and ptr3 get tossed here

// exit function

...this mechanism ensures that no memory from the local pool is left hanging around, and just takes two calls other than those you'd have to make anyway to use. what I do is have them as a macro, press a key for a function body that has them already stuck in there. In this way, the convenience and security of large local items that aren't stack-based is easily put in place, without going outside the bounds of c. Of course, there are other ways to use this mechanism, and a lot of other features ( emptypool(), getpoolmemindirect(), reportpoolstate(), discardallpools(), preallocatepool(), reallocpoolmem(), and so on. )

You'll note that of your proposed costs: A bunch of labels or gotos? None. Figuring out what to clean up? Not required or even helpful - if anything fails, the pool will cleanup regardless. No payment for a feature you're not using (plus, you have control over the features you do use.) If you want error tracking other than the allocation problems (the pool manager tracks those for you, live, right down to the file, function and specific pointer that had problems), putting elses on the ifs will do the job perfectly. Execution doesn't begin until the block where all resources are available, so no worries about that, either. And you can't forget to cleanup such that you ship a leak, because it'll flag you every time you run the feature if you do (and you won't if you build your function with a macro that puts the boilerplate in for you, which is the sensible and time-saving thing to do anyway.) The pool manager also "firewalls" the memory so that you can catch memory over-runs and under-runs, which are checked on freeing the memory, or can be checked with intermediate calls to checkpoolbounds(pool ID, 0 means check all pools).

See what I mean? It just isn't that difficult to implement decent memory mangement in c. You get to implement memory management t

Re:c ? really?

[fyngyrz]

I was speaking generally; x86 assembler is irrelevant, LEA value,register is motorola-speak but the functionality is the essentially the same for that type of application. Likewise garbage collection - the point is, C++ hides what it is doing with memory objects from you, as well as what code it brings in to manage that. I prefer to have complete control. See my reply to the sibling post to yours if you're still interested. Please forgive my tendency to "think motorola", they were my favorite processors ever for writing assembly.

Re:c ? really?

[bucket_brigade]

a quick search on google turns up 17k hits for "lisp" and 9k hits for "cobol". your point?

Re:c ? really?

[shutdown -p now]

I get the idea, and of course, it's quite possible to do such things in C - I never said it isn't, nor did I say the solutions I've presented are the only possible - merely the most common. Still, you have to admit that a properly written C++ snippet doing the same would lack all the explicit machinery visible in the C snippet, while doing exactly the same things just as optimally. Whether you trust the compiler or not is another matter. ;) Personally, I like to fiddle with disassembler to see what I get from the compiler in the end in the more convoluted cases, and draw my general conclusions from there.

BTW, one thing in your code I can't understand is, why GPID("functionname") (which I assume is a macro which expands to a funciton call with THISFILE) requires a function name? Why not use __FUNCTION__?

Re:c ? really?

[be951]

a quick search on google turns up 17k hits for "lisp" and 9k hits for "cobol". your point?

Not surprising, since there are multiple definitions for lisp. Nevertheless, my point was clear. Reports of the demise of COBOL are premature. And your implication that LISP has fared better than COBOL doesn't appear to be supported by a quick (but by no means comprehensive) measure of job prospects for the two skills. And we haven't even touched on the "LISP good, COBOL bad" discussion.

Re:c ? really?

[hrmot]

Multicore CPUs are likely to kill C.
IMHO, as long as one can spin any thread in C, having multicore CPUs should be transparent. It is duty of the underlaying multi-core-aware OS to manage your C threads onto multi-core/multi-processor platform.

... These aren't so important in a single thread, but they are when you introduce parallelism.
These concepts have been in play ever since. Using synchronization object and taking multi-threading precautions will perfectly do it for C as well. Posix anyone? PThread libs? OpenMPI?

Re:c ? really?

[TheRaven64]

I take it you've never used a language like Erlang. Try writing code that scales well to 64+ CPUs in C. Then try it in Erlang. See which is easier. Threading is a really horrible way of managing concurrency. If you want to do good parallel programming in C, you need to build a better memory model (hint: modern CPUs are NUMA. C assumes a UMA model), better support for message passing (C does not include atomic operations required for this; you need to drop down to inline asm), and a better way of handling aliasing (e.g. only allow unaliased variables to be mutable).

You could build some of these as libraries on top of C, but by the time you've done that you've changed C so much that it's not really C anymore. You can turn Objective-C into C with a simple preprocessor, but I wouldn't try to claim that C and Objective-C were the same language.

Re:c ? really?

[fyngyrz]

Still, you have to admit that a properly written C++ snippet doing the same would lack all the explicit machinery visible in the C snippet, while doing exactly the same things just as optimally.

Oh heck yes, I admit it, that's what I'm trying to avoid - hidden "gifts" from the compiler, particularly hidden gifts that pull in this, which in turn pulls in that, and soon my executable is bloated and I don't really have any good idea why. I want the compiler to do what I say. No more, no less. That is specifically what I value about a c compiler; if I do something, I pretty much know what the compiler will make of it, and that it won't make anything else of it.

BTW, one thing in your code I can't understand is, why GPID("functionname") (which I assume is a macro which expands to a funciton call with THISFILE) requires a function name? Why not use __FUNCTION__?

Because feeding it a string allows you to (a) just use the vanilla function name, (b) append variables and such by jamming a little sprintf() goodness onto a local array, (c) throw explicatory info about the function's purpose while under development.

Re:c ? really?

[shutdown -p now]

Oh heck yes, I admit it, that's what I'm trying to avoid - hidden "gifts" from the compiler, particularly hidden gifts that pull in this, which in turn pulls in that, and soon my executable is bloated and I don't really have any good idea why. I want the compiler to do what I say. No more, no less. That is specifically what I value about a c compiler; if I do something, I pretty much know what the compiler will make of it, and that it won't make anything else of it.

If you mean predictability, then C++ still has it. Granted, there are more things going on in a single line of code than there would be in C; but they are all well-defined and deterministic, and thus possible to account for - so you're still in control. Whether it is easy or not, that's another question.

Re:c ? really?

[mojine]

Print Version

Re:c ? really?

[mojine]

Print Version

Re:c ? really?

[Lord Kano]

The F77 code I play with now is newer (maybe 12 years old at the oldest), but some of the F66 code I played with at a previous job dated from the mid-1960's and is still running in production.

I think it's funny how people are constantly proclaiming the death of something or other, but it's never anyone who has a clue.

How many times does some manager who has never coded an app think that an entire company should move to Java or .NET and replace all legacy programs only to be shot down when someone explains that it would cost millions of dollars to replace all of the stuff that's working just fine right now?

LK

Re:c ? really?

[sashang]

Yeah that's right C++ can't match C. It outperforms it. The STL sort function is faster than qsort http://gamma.cs.unc.edu/GPUSORT/results.html http://gamma.cs.unc.edu/GPUSORT/results.html. I'll leave it to you to figure out why this is true but it has to do with the extra type information you can embed when using templates in C++. I'm willing to bet that a library written in C++ using expression templates, like Boost::uBlas or VSIPL++ will be faster than an equivalent C implementation. Anyway arguing for C based on it's performance against C++ is daft and it annoys me that people still do. Also read this http://scienceblogs.com/goodmath/2006/11/the_c_is_ efficient_language_fa.php. He makes some good points about what C and C++ is good at (mucking with memory addressese) and not good at (numeric computation, efficient optimized code). Now go tell your programmers at your company to use the STL sort because it's faster.

Re:c ? really?

[Richard Steiner]

How many times does some manager who has never coded an app think that an entire company should move to Java or .NET and replace all legacy programs only to be shot down when someone explains that it would cost millions of dollars to replace all of the stuff that's working just fine right now?

We're doing a feasibility study now to see if we can replace some F77 message processing code with Java. It might work, but the old mainframe code can currently receive a message, perform a dozen I/O's, validate it, reformat it, and still get the reformatted response out in around 60 milliseconds on average (from start to finish), and that includes the time spent on the OS2200 system input and output queues.

Getting that sort of low latency using a traditional UNIX+Java+RDMS setup will be challenging.

Re:c ? really?

[Lord Kano]

My employer is STILL finishing up migrating code from VAXen to Alphas. There is just so much damned code that it's taken well over 15 years.

LK

Re:c ? really?

[SoulRider]

No more like, here son wanna try some java? Next thing you know our hero is coding cobol.

A Candidate...

[ackthpt]

Not buying software that hasn't been written yet.

I don't care what's suggested...

[Cap'nPedro]

I won't believe it until NetCraft confirms it!

Number 1

[Anonymous Coward]

Most people's ability to write normal structured english sentances

Re:Number 1

[stinerman]

And the ability to use spell checkers...

Re:Number 1

[penguinwhoflew]

Personally, spelling my pet peeve.

Re:Number 1

[Creepy Crawler]

Jest because ewe can use a spell checker doesn't mean the grammar is correct.

Re:Number 1

[Anonymous Coward]

ORLY?

Re:Number 1

[qray]

Knowing when to use a comma? ;-)
-
Q

Re:Number 1

[Max Littlemore]

Hay! Leave his grammar out of this. She never done nothing to you!!11!!

Trolling.....

[Anonymous Coward]

Trolltalk is dead as Ensign (Jim)(Iluvbees) Trolltalk......

RIP Trolltalk....

LOL @#buttes, failures.

There Are Still Several NetWare File Servers...

[Real World Stuff]

Cranking away, doing what they need to do.
Sometimes it is ~very~ profitable to be "the guy" that can fix them.

Re:There Are Still Several NetWare File Servers...

[spun]

We've got Novell file and print servers where I work. And our main in house application, which was started eight years ago, is written in COBOL. I kid you not.

You have to admit

[Richard McBeef]

He makes a very compelling argument as to why C is dying.

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.

Re:You have to admit

[lord_sarpedon]

...an embeded micro-controller ...with at least a gig of RAM. Cue rimshot.

Re:You have to admit

[Anonymous Coward]

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

Re:You have to admit

[Mr. Shotgun]

How? Because Stewart Padveen said so? Who in the hell is he, and why should I care? From the looks of his site adpickles.com he looks like another spam farmer to me. Not the best authority to appeal to.

Re:You have to admit

[Richard McBeef]

I think it's time to get a new battery for your sarcasm detector. His argument was shit. Anyone who would suggest C is going away is an idiot.

Re:You have to admit

[Mr. Shotgun]

I think it's time to get a new battery for your sarcasm detector. Keeps going and going my ass, damn lying rabbit!

1. COBOL

[Anonymous Coward]

Good.

Re:1. COBOL

[QuantumG]

Ya dreamin'. So long as it is cheaper to hire expert programmers maintain the application than it would cost to rewrite it from scratch, COBOL will continue to be a required skill that fetches high pay.

Re:1. COBOL

[jawtheshark]

Exactly... There are critical Cobol applications that run in a virtual machine in another virtual machine on big IBM iron that keep making money for big banks. The source is not documented and the coders that work on those patches of code make a lot of money. Especially, because I know that a bug in one of those pieces of code can cost millions to a bank. I've seen it happen, and that guy (earning easily 10x what I did) made the bank stall for two hours. With the big bosses in his neck (it was a bug in a change request) he figured it out in no time, the financial cost was huge though.

I don't think he got a bonus that year... or perhaps he did, after all he saved the day. ;-)

Actually, I'd love to know Cobol. It would give me access to one of the securest best paid IT jobs in the banking industry.

Re:1. COBOL

[fishbowl]

"Exactly... There are critical Cobol applications that run in a virtual machine in another virtual machine on big IBM iron that keep making money for big banks."

And this is an area where Linux, very quietly, penetrated. We're a lot closer to world domination than people seem to think :-)

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

[pthisis]

I think they are wrong since C is still used on a lot of embedded systems where C++ is too heavy.

And plenty of the "vibrant replacements" for dying technologies are large, actively-developed C codebases (e.g. Python). If anything, based on what I've seen in the marketplace over the last 5 years I'd say C++ has been largely supplanted by higher level languages but C continues to be used a fair amount (especially in embedded systems as you note, but also for hand-coding performance critical parts of large systems that are mostly in other languages and for some other non-embedded work).

Re:Some of the list looks good

[pla]

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.

Don't forget how well all those "Web" languages works as firmware - Oh, wait, they all depend on plain ol' C to actually bring the hardware up to a level of functionality where all the C-killer languages can make their pretty GUIs.

Re:Some of the list looks good

[QuasiEvil]

Well said... There's nothing like good ol' ANSI C when it comes to building a cross-platform core business component library. (That said, I do write in C++, PHP, Python, Forth, and several flavors of assembly as well...)

I guarantee you, for embedded development and drivers, C and ASM aren't going anywhere, possibly extended with a few C++ features.

Re:Some of the list looks good

[serviscope_minor]

or C++ which I keep under the same heading

Seriously, if you keep C and C++ under the same heading, then you don't know C++. Modern C++ is a world different from modern C, and a modern C++ program would be quite incomprehensible to someone who only knows C.

Re:Some of the list looks good

[Anonymous Coward]

I work with several hundred professional programmers who among them can't code a single "Hello, World" in C.
Yes, hobbyists still know it. Yes, people who like computers still know it. But people who make their paychecks writing the next database backed website for a big company? Nope, they never learned it and stay away from it because they heard it's hard.

Re:Some of the list looks good

[rs79]

"C++ has been largely supplanted by higher level languages but C continues to be used a fair amount (especially in embedded systems as you note, but also for hand-coding performance critical parts of large systems that are mostly in other languages and for some other non-embedded work)"

Apache... C.

Unix kernel... C

Mail daemons... C

DNS daemons... C

"hand-coding performance critical parts of large systems" are usually assembly. The inner loop of Alta Vista is machine langauge (possibly google too, but I don't know). If you can squeeze one more cycle out, you aren't finished.

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

[AuMatar]

Not really. Lets see what C++ adds to C

namespaces- an automatic way of prepending a function with a module name
overloading- it takes about 10 minutes ot explain this to a C programmer
classes- every C program of real size is developed as modules which call each other. A C class is a module without explicit this pointers in all the member functions
templates- a fancy type of preprocessor
exceptions- the only truely new thing

If you really think C++ is that different, you don't know real C.

Re:Some of the list looks good

[Anonymous Coward]

Even games that make extensive use of scripting languages, such as Civilization 4, are still C/C++ for the core functions. I could of told you the same thing from looking at the 1.5-2GB memory usage when playing in-game. The performance of this game is HORRIBLE in comparison to other games, especially given that it is turn-based and few unit movements occur. And I'm including games coded in c such as OpenTTD with 1000's of units moving in real time. OpenTTD is not heavily optimized either.

If C#/other 'new' languages were used to redesign a new operating system... I'd probably be laughing right now at the performance of such systems. The other advantage of c is that it is as low as you can get to the system without having to write in assembly. It is also very fast to code in, as you don't have to type in stupidly long lines similar to (and yes, I made this up before anyone complains):

System.MemoryManager.ASyncAccess.Stream.Connect(Sy stem.DeviceManager.NodeID(System.DeviceMapper.Find ("MemoryModule"))).Write("1234567890")

In c, you just type in short/quick lines like:

memset(offset, "1234567890", 10);

Re:Some of the list looks good

[serviscope_minor]

overloading- it takes about 10 minutes ot explain this to a C programmer

But it makes a huge difference in real code. For instance, a well designed linear algebra library reads like maths in the same way that scalar arithmetic reads like maths. Easier to read means easier to write it correctly. If you don't think that this is important, how happy would you be to give infix notation?

classes- every C program of real size is developed as modules which call each other. A C class is a module without explicit this pointers in all the member functions

Except that in C++ all the work of setting up the classes (constructors) and cleaning up after them (destructors) goes away. Those errors do not exist to make, and the code is shorter. That means easier to read and debug.

templates- a fancy type of preprocessor

In the same way that LISP macros are a fancy type of preprocessor. You can do everything up arbitraty AST manipulation, with a bit of effort.

If you really think C++ is that different, you don't know real C.

But of course, those are all isolated features. The combination is vastly more powerful. If you combine classes, templates and operator overloading you can get things like:

• The SPIRIT parser framework: write your parsers in (nearly) BNF all inside your C++ program.
  
• Lambdas (see the Boost lambda library)
  
• Functional programming (see FC++)
  

And that ignores the really useful day-to-day things like the STL which gives you all sorts of handy things.

Perhaps you should look at some modern C++ code. If you still think that it is C like, then I'd love to see your C code.

Re:Some of the list looks good

[Anonymous Coward]

"templates- a fancy type of preprocessor"

Wow, it's a programming language troll. That's actually kind of impressive in a way that I can't readily quantify.

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.

Re:Some of the list looks good

[Anonymous Coward]

Check out the Boost libraries. The things people are doing with modern C++ are both awe-inspiring and a little scary. I'm not really sure it's a good thing; it's forcing C++ to become something it was never meant to be and everyone might be better off just using a better language that supported these techniques from the ground up. But your parent was correct; if you think C++ isn't very different from C, you really have not been paying close attention to C++ for the past few years.

Re:Some of the list looks good

[Grahad]

You are not looking at it in the same frame as the writer; they are talking about mainstream job opportunities and not the specialized market of development. Out of all the companies out there, how many need to create drivers, operating systems, games etc. They are referring to the every day corporate programmer, like old school COBOL monkeys. With the rapid development tools out today there is no reason to write code in a lower lvl C based language when you can just click and drag...

This is even more true when you consider the consolidation of the computer development industry. How many companies make mass market operating systems? How many companies make video cards? Its happening in the gaming industry too.

Re:Some of the list looks good

[multipartmixed]

> But usually the people who claim to "write their inner loops in ASM" have
> troubles making solid contributions to compiler technology.

It has also been my experience that these people do not know how to profile their code, or analyze an algorithm. Instead, they implement the same slow algorithms just a little wee bit faster (possibly not even measurably)... whereas proper optimization (profiling and thinking steps) could have sped up the same operation by an order of magnitude.

True story, I once rewrote a hand-coded assembler operation in shell script. My version was SIGNIFICANTLY faster. Why? It did a million times less I/O....

Re:Some of the list looks good

[maxume]

Doesn't that last line only apply if you actually need one more cycle? I mean, modern processors are hilariously fast.

Re:Some of the list looks good

[multipartmixed]

> If you really think C++ is that different, you don't know real C.

It's not the syntax that's the big difference. It's the programming paradigm and standard libs. So, not the language per se, more like the WAY the programs are written.

I'm still pissed about C++ templates, though; they just don't seem to be much more powerful than #defines.

Although, I gotta say, what I want to do with them would be pretty tricky for a pre-compiled language...

Re:Some of the list looks good

[rishistar]

s/c/perl/

Re:Some of the list looks good

[Lehk228]

True story, I once rewrote a hand-coded assembler operation in shell script. My version was SIGNIFICANTLY faster. Why? It did a million times less I/O....

did you write 'pwned' with a sharpie on the other guy's forehead?

Re:Some of the list looks good

[scotch]

namespaces - allows group aliasing and lookup/binding changes
overloading - ok, maybe

classes - more than you let on - aggregation, scoping, encapsulation, polymorphism - you can do all in c with something you roll yourself, but chaces are, you'll fuck it up unless you have a pretty narrow use case
template - bzzz - more than a fancy preprocessor

exceptions - once you get them, embrace them, and especially their use with RAII, writing place C is distasteful

I know both, you guys are both right

Re:Some of the list looks good

[coaxial]

BTW a good number of HPC tools and applications are still written in FORTRAN.

Only the apps written by physicists. If the physics community ask for help from the HPC research community, then that's not the case. Seriously though, it would be a shame if the new guard of physicists kepts using the same tools as the the old guard who learned to code on PDP-11s.

Re:Some of the list looks good

[roxtar]

I totally agree. Especially the remark "...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." That is just a plain stupid statement. There are many C only programmers who code firmware and are happily employed. And the "training for a new skill" part is plain defense. Everyone is training for a new skill.

Re:Some of the list looks good

[Gorshkov]

Those errors do not exist to make, and the code is shorter. That means easier to read and debug.

Shorter does NOT mean - nor does it even IMPLY - easier to read and/or debug

Never used, or even *heard* of APL, have you?

Sorry, but I think that succinctness is one of the most highly overrated code qualities I've ever come across - which, coincidently, is one of the main reasons I find pearl so disgusting. Think can be - and quite often *are* - written in such a compact form that they are virtually unreadable to any but an expert ..... and the code *is* often written that way, simply because it's l33t.

I really don't give a rat's ass if my code is a page, and yours in only 10 lines ..... which one is written in the clearest, most logical way? Which one is easier for a newbie to pick up and understand?

People need to write code to be CLEAR - concise should be at best of secondary importance.

"I can write a programme that will do a matrix inversion, create a visualization of it, compute the prime of a 300-digit number AND order my groceries in one line with language XXX, where it takes you 500 in C"

Wonderful, and I'm happy for you .. but which one do you honestly think will be more maintainable?

I can go to my libraries right now, and go through some of the old, crusty code (some of which was written as far back as 1982), underst *and* maintain it, in 10-15 minutes - after just a quick glance. Can you say the same for code you've written yourself, even just a year ago?

Re:Some of the list looks good

[philipgar]

Since when were embedded systems a "niche" field. Unless you want to call the windows world a niche field as well. There are far more embedded systems out there than there are windows PCs. In fact the vast majority of computers are embedded systems. They don't get the glory of a lot of the higher performance systems, but they are extremely common.

In the IT world C may not be useful. But IT isn't about skilled coders as much as it is about finding monkeys to write bundles of code using an alpahabet soup of "tools". A good C programmer is too valuable to work in an IT field. Good C programmers understand the basics of computer architecture, and are extremely familiar with pointers etc. Being a basic "competent" C programmer won't really get you anywhere, it's just a tool that people who know what they're doing can use.

Phil

Re:Some of the list looks good

[Anonymous Coward]

"BTW a good number of HPC tools and applications are still written in FORTRAN."

Hey, we are talking about dead skills here! FORTRAN and AmigaOS should NOT be mentioned in this context.

Re:Some of the list looks good

[Anonymous Coward]

> template - bzzz - more than a fancy preprocessor

Hm.. why? Given that until recently for all I know most compilers implemented them via preprocessors??

Re:Some of the list looks good

[rs79]

"the old guard who learned to code on PDP-11"

The PDP-11 was the new one. So was the PDP-8. Try IBM 1130 or IBM 1800.

(I'm in my 40s)

Re:Some of the list looks good

[LWATCDR]

Actually there are many good reasons to keep using FORTRAN. My it's structure FORTRAN is very easy to optimize and there is a lot of existing code libraries for it.

Re:Some of the list looks good

[abigor]

Yes, yes, I shouldn't have said niche, maybe something like "predominantly used in one field" or whatever. In terms of LOC, embedded development is pretty minor.

Being familiar with "pointers etc." isn't brain surgery. I've been a C programmer for many years, have a metric ton of running code out there in the world, and the weird reverence that some people (mostly those who aren't professional programmers, such as hobbyists and students) have for C has always puzzled me.

You are making an artificial distinction between the "IT world" and some other, higher realm. It's all programming. Some tasks are more trivial than others, and some tasks follow a pretty boilerplate way of doing things in order to improve time to market. Lots and lots and LOTS of former C programmers, who were good at their jobs, now happily code in Java. I'm sorry to burst your idealistic bubble, but that's the real world for you.

Re:Some of the list looks good

[Anonymous Coward]

Instead of C they should have put BASIC (including M$'s).

Re:Some of the list looks good

[pthisis]

"hand-coding performance critical parts of large systems" are usually assembly.

No, they aren't. They're usually C. Occasionally they're asm. Sometimes they're awk or perl or python. It depends on what language the major product is written in.

The inner loop of Alta Vista is machine langauge (possibly google too, but I don't know). If you can squeeze one more cycle out, you aren't finished.

Yes, you are. If you have a program that's fast enough to do the job, wasting time optimizing it is just dumb. If it'll cost you less to get bigger hardware than the programmer time to optimize it, it'd be foolish to choose the more expensive option. Obviously for _some_ jobs, the faster they run the better--but you still have to weigh that against the cost of doing the optimization (rather than working on other useful programs). If you have a mass-market product that a lot of people are going to run, it's more likely that heavy optimization is worthwile.

But if you're at a point where squeezing more cycles out doesn't actually help you in any significant way, you're likely to be done even if the program _could_ go 10% (or 90%) faster.

Re:Some of the list looks good

[pthisis]

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.

The point of my post was that that isn't true, at least not for new projects. Java's flourishing, but 5-10 years ago C++ was the language of choice for a lot of new performance-critical apps. Today I'm not seeing it used nearly as much--places are mostly going with Java or even higher-level languages much of the time, and using small C extensions when needed. Even most of the desktop apps at the last 3 companies I've worked at have been written in Java, C#, or even occasionally Python and other higher-level languages. C++ seems to be going through the middle-life phase awfully early--it's still in high demand, and there's still active ongoing development of existing products (it's not just maintenance/bug fixing for legacy systems by any stretch), but it's really fallen out of favor for new products very quickly compared to what I would have guessed even 5 years ago.

Whereas C continues to fill the same spots it did 10 years ago, and has picked up a little ground as the native code language for many of the new higher-level languages out there. It shows far less signs of dying out than C++ at this point.

(On top of that, embedded is less of a "niche" field than desktop GUI app development--there are a _ton_ of embedded machines out there, and a ton of jobs developing for them.)

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?

[mikee805]

You still ads for ColdFusion developers so would not call it dead.

Re:ColdFusion Dead?

[Lockejaw]

The ACM's web site still uses ColdFusion. What irony.

Re:ColdFusion Dead?

[TheRealMindChild]

Personally, I like(d) ColdFusion. My library of custom tags is quite impressive. But my issue came along when Macromedia bought it and released ColdFusion MX. Suddenly a P3 550 with 384 Megs of ram would die with one or two users. Sorry, but that is rediculous

Re:ColdFusion Dead?

[Anonymous Coward]

Coldfusion seems to do well enough with the millions of MySpace users...

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?

[Frank T. Lofaro Jr.]

Isn't it ironic, don't you think?
<cfoutput>A little too ironic, I really do think.</cfoutput>

Re:ColdFusion Dead?

[asdfghjklqwertyuiop]

Coldfusion seems to do well enough with the millions of MySpace users...

Hahaha... I guess you haven't used it very much. I get "sorry, an error occurred, we're working on it" errors frequently and I don't even use it that much... just keeping in touch with 2 people or occasionally looking at someone's page.

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?

[maspatra]

I dunno, I have to disagree. Of course I'm biased, being a ColdFusion developer myself. I really like the ability to create custom tags, and it has a lot of built-in functions that you can use to combat cross-side scripting and SQL injection that can be a real bear to program otherwise. It's also fairly easily to program in, at least compared to PHP. (the only other DHTML language I'm any bit familiar with) Of course our operation is very small so I don't know how it would stand up to huge loads...

Can't say I'm happy to see it on the list of dying technologies...it limits any future career opportunities for me, at the very least. :)

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?

[artemis67]

With 180 million users, I don't think fair to compare MySpace's performance with any other CF web site out there.

Re:ColdFusion Dead?

[asdfghjklqwertyuiop]

I'm comparing it to the web in general, not just any other CF web site out there.

Re:ColdFusion Dead?

[Timbotronic]

Coldfusion seems to do well enough with the millions of MySpace users... MySpace was written in ColdFusion, but it's running on BlueDragon.NET.

Re:ColdFusion Dead?

[maxxdogg]

Hmmmm....
I remember when Cold Fusion first came out. People ridiculed it because it was "tag based."
But then the XML revolution came around and JSPs were a hit. All of a sudden tags were cool again.
Allaire could have been taken out by Java/JSP back then...but they embraced the new technology and
reinvented themselves into a servlet/jar. (Actually I think they took over an "open" project that
created a cold fusion servlet copy...anyone know about that?)
Anyways, it became and is a solid server side platform especially for integrating html with database data.
It merged with a small company called Macromedia(Flash/Shockwave). Was bought by an even smaller company...ADOBE.

What I like about Cold Fusion is that people who understand HTML will understand Cold Fusion. Throw in some database knowledge and advanced online applications can be created. No need for advanced programming skills and for many sites, even large ones, that is all that is needed.

However it is neither free or open source, and is really quite expensive. I end up hosting my projects at an ISP that supports Cold Fusion anyways, so that is not an issue for me.

The truth is that processing is now shifting back towards the client again and away from the server.
You are seeing more powerful online applications(spreadsheet, word, etc.) taking advantage of processing
speeds and of course ajax/javascript/flash in the browser. The server is becoming ubiquitous as Adobe Flex
and MS Silverlight are showing.

So I agree that the space is getting crowded and many other options are available...but how much do you do on the server these days anyways?

Re:ColdFusion Dead?

[Timbotronic]

I can only hope. Terrible, terrible language. I'm not going to argue that there aren't better options now, but I think its bad reputation is a little undeserved. I think the fact that CF is so simple led to its adoption by a lot of very bad programmers who wrote some truly awful spaghetti code.

The concept of custom tags began with CF and it's JIT compilation gave it a performance edge over PHP and ASP for a good while. Maybe JJ Allaire should publicly apologise for arrays that start at 1 but I think, in a historical context, ColdFusion is like an old unfashionable band that had a positive influence, even if the newcomers are embarrassed to talk about it.

Re:ColdFusion Dead?

[artemis67]

Ok, how many other sites out there have 180 million users?

Besides, it seems to me that MySpace's development team is grossly understaffed. Every time they add a new feature, it's always half-baked.

Re:ColdFusion Dead?

[asdfghjklqwertyuiop]

Ok, how many other sites out there have 180 million users?

Some guesses: google, yahoo, slashdot, wikipedia, MSN...

Besides, it seems to me that MySpace's development team is grossly understaffed. Every time they add a new feature, it's always half-baked.

Idunno about understaffed... think quality vs quantity. Many design aspects of that site are just downright stupid...

Re:ColdFusion Dead?

[Anonymous Coward]

What's with most of the list?

non-TCP/IP?
In industry more and more plants are moving to safety equipment. Safety controllers, Safety switches, Vibration Monitors, Tempurature Monitors, etc... TCP/IP, Ethernet/IP, none of the IP based networks can do this. Packet Loss is not acceptable in Safety. So CAN networks, like DeviceNet, RAD kits, are here to stay for a long time.

C?
Well I think the above comments cover this. C will die someday; but not anytime soon perhaps when we have 'Deep Think'

Network Administrators?
Like the above mentioned, network admins aren't going anywhere, the title might, I notice more and more Network Security Administrators or System Administrators but they seem to be the same people.

Then they toss in OS/2 . . . (I feel a rant starting to build) which was practically dead before it got released thanks to our friend Bill. Why is this even mentioned? Because they couldn't make a top 10 list and thought a top 9 list would be stupid, so they just said, hey what's deader then dead and someone said DOS, and then several people jumped up and said, hey people are still using DOS. Then someone else said OS/2... and everyone said yeah... OS/2. Why not say TRS-80? Why not say the Osborne 1, or better yet the Osborne 2? It's about the same... (end rant)

Re:ColdFusion Dead?

[jbplou]

I'm not sure what they meant by PC Network Administrators but I don't think they meant IIS that is considered a Web or Application server. I think they mean people who basically path desktops, but their are plenty of jobs for SMS people so I don't know what they mean. Probably just crabby way of saying that their are tools around that allow more workstations to be administered by less people

Re:ColdFusion Dead?

[JerRocks]

However it is neither free or open source, and is really quite expensive. There are some quite good free CF alternatives, most notably BlueDragon by New Atlanta. Your other comments are interesting. I'm not a huge Flash fan, so Flex is a bit hard for me to get behind...but the Apollo stuff looks nice. With both Flex/Flash and Apollo you can easily(ish) integrate with Coldfusion to do some pretty cool stuff.

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".

Re:ColdFusion Dead?

[0racle]

what's with "PC Network Administrators"?

I'm not really sure either, but I'm guessing they mean people who administer workgroup setups as opposed to making a small windows domain.

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?

[nuintari]

yes, there are a lot of tech guys who specialize in one very specific thing, and they are all the same. They all act like they are the end all be all of their particular discipline, and that their chosen technology is something that everyone needs. They tend to have a very narrow world view, be very rigid in both skill set and personality, and.... assholes.

Oh, and they are always full of stories about old deployments, that are usually long gone, like their usefulness.

Old Netware guys are the worst.

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

[garett_spencley]

Specializing in one specific thing can be a very good career choice these days, though.

There are so many "generic" programmers and it's more and more common for companies to outsource. If you can find some specific niche that's in high demand and fill it then you'll have a much easier time finding work and you'll probably be paid more too.

But you do bring up a very good point, specialized fields are at the risk of going out the door. So the real trick is find something that's specialized but that has various applications, and always maintain interest in other related IT fields. You don't have to get too specific either, you can specialize in RDBMS systems, for example, without focusing entirely on one particular product like Oracle.

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

[Tablizer]

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.

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).

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.

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

[Rakishi]

So get paid experience in multiple languages/areas by getting a job from the start that lets you do that, sure you may need to sacrifice a bit of pay or whatnot but it is better than the alternative. Personally I'd go insane if I had to focus on a single language in a single app for months on end. Hell I don't even like to focus on a single field for too long so I work on multiple minor projects at the same time.

I'm a statistician by training, I have from my current job paid experience in R, java, python and sql. Right now I'm also picking up some economics and I'll likely focus a lot more on that part as time goes on. Most of the team is getting experience in Java, perl and some statistics.

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

[Rakishi]

Yeah, I agree that there is good money in proper specialization but for that to truly pay off you need to find a good niche more than anything. And of course you need to have a backup option of some sort.

Hey, they forgot

[idontgno]

Microsoft Certified <foo>

Seriously

Re:Hey, they forgot

[Opportunist]

I dunno... every time I think about MS certs, it reminds me of some strange cult with aliens. I mean, courses that cost a fortune, that are worthless outside of the world of believers, teaching you things that are usually useless or just plain wrong outside the little world they created themselves, and every 5 years or so you have to redo them to prove you're still good...

Say, didn't that spaceship supposedly go down somewhere in the north west of the US?

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

[AKAImBatman]

For example, do you really think all that TCP/IP is secure?

Fixed that for you.

Re:C? You must be kidding

[Anonymous Coward]

And that dick head that was quoted... Well good.

Most programmers can't write good code in Java or it's C# clone, we should be thankful they aren't writing in C.

Meanwhile in the real world, C is still used by systems programmers and anybody writing performance sensitive code. These guys are worth triple some .NET weenie and they'll be earning even more than that when all the .NET McJobs have been outsourced.

Re:C? You must be kidding

[mkettler]

For example, do you really think all that strcpy is secure? Fixed it again.

(Not to be flamebait, but those who live in C houses shouldn't poke fun at other languages for having the potential to be used in an insecure manner. Sure C can be coded securely, but it can go just as horribly wrong as ajax can.)

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..."

Re:C? You must be kidding

[Anonymous Coward]

Boy, I bet you sure showed him what was what. Of course he was probably talking about using socket API's directly as opposed to http ones. And yes, that's indeed the way things are going, you don't use sockets directly these days. But you pointed out a technical inaccuracy in his statement and thus showed what a superior life form you are. Gosh I envy you.

Re:C? You must be kidding

[Citizen of Earth]

Read the AC post above this one.

Re:C? You must be kidding

[fiannaFailMan]

What the web can now allocate memory and talk to my hardware?

Never used a webcam, have you? You don't know what you're missing! ;)

The web can invoke SQL commands to interact with a database, which explains why client-server computing has been superceded by web-based apps.

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.

Probably, but it's a lot easier to distribute an application if it just appears in a web browser instead of having to be installed on a desktop PC from a CD.

It's misleading to claim AJAX will solve all these problems because it won't.

How do you know? AJAX seems to be doing just fine in making the user experience better. Flash was once considered a front-runner in the race to bring better usability to web apps, but AJAX seems to be coming on in leaps and bounds, prolly because it doesn't rely on a small team of engineers at Macromedia/Adobe to make it happen.

In short, I think the web is taking over what naturally comes to that medium. It is wrong to say its displaced C.

I disagree. I can't remember the last time I had to install the client-side of a client-server application.

Re:C? You must be kidding

[rm999]

I know virtually zero people in the real world who can get by on just C. It's come to the point where people will mix C++ and C styles in large projects, and if you don't know how to read the C++ you are close to useless.

Yes, there are still a lot of low-level nitch C applications, but the number of C/C++ programmers dwarfs the number of pure C programmers.

Re:C? You must be kidding

[Brandybuck]

Does this guy forget that all of the GNU/Linux Kernel base system is written in C?

There is no GNU/Linux kernel, there is only the Linux kernel. I know you're deeply in love with Richard Stallman and want to bear his lovechild, but please make some attempt at accuracy.

Re:C? You must be kidding

[RightSaidFred99]

So wait, you mean I need to know C to use all those handly kernel and C library system calls? Didn't think so.

C is here to stay, but it's something where fewer and fewer C developers will be needed. And web apps are advancing in usability rapidly. AJAX is the first step, Silverlight is going to rock people's world. As soon as Microsoft wisens up and releases it for Linux, it's game on.

Re:C? You must be kidding

[UncleFluffy]

the number of C/C++ programmers dwarfs the number of pure C programmers.

It's probably accurate to say that the number of people writing C/C++ code dwarfs the number of people writing pure C code. Whether the majority of the former group can be counted as programmers is another issue entirely ;-)

Disclaimer: I write in asm, C, or Haskell, or the code I write does. Low-level for performance, high-level for abstraction. The stuff in the middle is the worse of both worlds. And I still can't decide whether Java is obscene or just amusing.

Re:C? You must be kidding

[rm999]

I'm pretty sure Java is entirely obscene ;)

You seem to have a negative attitude towards C++ - how come? It is a superset of C, meaning it is capable of everything C is. It was designed (IMO quite well) from the beginning to be comparable to C in speed if used properly. On top of this, it was also designed to be more readable, maintainable, and safe. Even in the hands of a novice, C++ is mostly harmless (ignoring memory issues) due to smarter compilers and cheap clock cycles.

As far as ASM - I have studied my share of it in my EE undergrad, and I found it to be close to useless except in the simplest of embedded devices or to replace 10 lines of code in a loop - all while sacrificing portability. Are the clock cycles (that will cost almost nothing in five years anyway) really worth the time required for any other application?

I am not trying to argue - you sound like you have more experience than I do - but I meet very few people who share the same favorite languages as you, and I'm curious why. What kinds of programming do you do?

Re:C? You must be kidding

[Ihlosi]

As far as ASM - I have studied my share of it in my EE undergrad, and I found it to be close to useless except in the simplest of embedded devices or to replace 10 lines of code in a loop - all while sacrificing portability.

I wouldn't call DSPs simple ... and there are families of them out there where the compiler knows only about 40% of the chips instructions. Heck - whole features of these chips cannot be used in any other language than assembly: hardware circular buffer support, hardware bit-reversed addressing, saturation, extended accumulators, hardware polynomial evaluation support, etc..

On the other hand, the C compiler for the "simple" embedded devices (like an 8051) are pretty good. For most applications (where you're not counting processor cycles), you don't need to use assembly.

Re:C? You must be kidding

[lmpeters]

You might be able to write an application in AJAX that takes advantage of a webcam, but I don't think anyone is going to write a webcam driver in anything other than C or assembler any time soon.

Frankly, if your computer is set up in such a way that device drivers can be written in AJAX, either you have a very strange operating system, or you're running an unpatched version of Internet Explorer and the device driver is taking advantage of a security flaw to execute arbitrary code.

Re:C? You must be kidding

[UncleFluffy]

You seem to have a negative attitude towards C++ - how come? It is a superset of C, meaning it is capable of everything C is. It was designed (IMO quite well) from the beginning to be comparable to C in speed if used properly. On top of this, it was also designed to be more readable, maintainable, and safe.

My problem with C++ is that it's unmaintainable, for two reasons: first, it supports (usually in a very ugly manner) a whole host of different programming paradigms that often get mixed inside one project, and second, it allows redefinition of the language to the extent that you cannot make any statements at all about the behaviour of a program unless you've read through every single header file that it references, and the ones that they reference, and so on. (I'm thinking particularly of pass-by-reference and operator overloading, but there are others). In short, it was a nice idea, but they've tried to make it a "do everything you want any way you want" language and that's resulted in bloat, usability issues, and, well, it's just plain ugly. I can write it, and sometimes do, but more often use it as a compilation target.

Even in the hands of a novice, C++ is mostly harmless (ignoring memory issues) due to smarter compilers and cheap clock cycles.

Most languuages are if programs written in them don't touch memory that they don't own :)

As far as ASM - I have studied my share of it in my EE undergrad, and I found it to be close to useless except in the simplest of embedded devices or to replace 10 lines of code in a loop

It depends on the application area, though I would say that the ability to read ASM (so that you can tune the compiler output) is far more important than the ability to write it.

What kinds of programming do you do?

I tend to work close to the hardware/software boundary. In terms of programming tasks, that means I use C/ASM for driver and firmware coding, Haskell for toolchain development (compilers, etc) and algorithm research, Verilog for sizing small hardware fragments, and automatically generated C++ template stacks for architectural modelling (half a million lines of template code that collapses down to a single object instance).

COBOL as number one?

[tcopeland]

Hm, I don't know... I still get people emailing me about this post on a JavaCC grammar for COBOL. COBOL may be dying, but it's lingering on...

Re:COBOL as number one?

[iknownuttin]

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

I know that the big Hartford Insurance companies are still using COBOL , JCL, and big iron. Basically, their IT staffs are all inbred and when they want new blood, get this, they train them!

As far as the other skills on the list, if they are in fact dying, could it because they're no longer needed and the market is just doing its "thing"?

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:COBOL as number one?

[Evil Cretin]

MULTIPLY TEDIOUS BY OVERLY-VERBOSE GIVING COBOL.

Whilst 80% of the world's code is written in COBOL, I have to agree with Dijkstra on this one (see sig).

Re:COBOL as number one?

[R3d M3rcury]

As I've said numerous times (and I'm quoting from somewhere, but I don't know where):

"It's not dead. It just smells funny."

Re:COBOL as number one?

[Alakaboo]

Moreover, there are many corporations in Chicagoland in the finance, insurance, and consultancy agencies that hire said graduates straight out of Northern and put them to work! I was fortunate enough to land on the UNIX of my present employer, but I still deal with mainframe extracts on a regular basis, and all the baggage that goes along with it: EBCDIC, DB2, JCL, etc. It's a real blast.

By the way, they don't teach 250 anymore; they now teach COBOL and JCL in parallel in 465. I still have nightmares about some of the teachers there (you know who I mean). :-)

Re:COBOL as number one?

[dpilot]

Took a while to find any reference to JCL, and there were only 3 in the 330 posts when I scanned. How can you possibly talk about dead or dying IT skills without at least a passing reference to JCL?

I used to do JCL, and was almost decent at it, even had a few procs up in the shared space. JCL was kind of nice, in that nothing happened until Submit. At that point, it's too late. Whatever was going to happen, probably already has. None of this "If I hurry and kill the script maybe I can save the side-effects of that typo" crap.

Re:COBOL as number one?

[clickclickdrone]

I'm currently working on a project for a top 10 (global) bank that's being ported to 'new' infrastructure and it's being built using:
AIX
Korn Shell scripts
C
Cobol
Oracle

Dang, out of date before it starts.

they forget

[Anonymous Coward]

all of these only take into account the more experienced of the computer world- they forget all the rest of the people who now make up the majority. the mere fact that so many people surf myspace, use unpatched windows, can not type in coherent sentences or even understand anything about their computer beyond where IE, AIM or outlook are and still use AOL illustrates this quite nicely.

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

[andy314159pi]

The compromise is to use a TeX based wysiwig like TeXmacs. It's pretty slick and has really nice typesetting.

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

[the_brobdingnagian]

I study physics and in about 2 week I have to take a compulsory "LaTeX introduction" course. This is in the end of the second year. I have not used Microsoft Word to write stuff in about 2 years. LaTeX is all I use when I hand in assignments.

Re:LaTeX

[siwelwerd]

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

Re:LaTeX

[elgatozorbas]

IF ONLY I COULD! Writing LaTeX code is nothing compared to keeping track of Word changing / autoformatting fonts / styles all the time. Apparently some people really don't care if they change from arial to times to courrier, 10pt, 12pt... whatever. If you are used to make good looking decent documents in TeX using a responsive editor, at times you can really go MAD when you receive a 10-page 100MB (text only!!!) document to revise which changes styles all the time. This is really not funny. But no, Word is the standard and therefore everyone has to make documents that suck.

PS: I'm no TeX fanboi. People who ever had to cooperate on documents will no doubt know what I'm talking about...

Re:LaTeX

[Anonymous Coward]

Give me a break. I'm a graduate student in mathematics and 90% of my colleagues are using LaTeX. No one uses Word for any serious work.

Re:LaTeX

[Idbar]

I bet that's the reason why the equation editor of Word 2007 accepts LaTex commands as you type.

Re:LaTeX

[the_ed_dawg]

If it makes you feel better, I would say that about 70% of the graduate students in my ECE program use LaTeX. The only ones that use Word have old, crusty advisors, and they are slowly being converted by feature-creep in the thesis formatting guidelines.

Re:LaTeX

[Gulthek]

LaTeX is for the lazy, real TeXnicians use TeX itself and code their own formatting macros.

Re:LaTeX

[Kupek]

Not in CS. Even the theory people I know write their own Latex.

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.

Re:True story...

[canUbeleiveIT]

Frighteningly enough, the company that I worked for before I struck out on my own was still using cc:Mail in 2003. I've heard that they switched to Notes/Domino since then, but DAMN!!!!

Re:True story...

[CthulhuDreamer]

Our company went the other way. The Lotus Notes group was able to remove all (non-Notes) email servers in the other division because "Notes would be easier to support". Anyone in the other divisions who wasn't a Notes admin (meaning everyone) was pink-slipped and escorted out.

I expect their Novell admins to start ripping out the AD controllers any day now...

Re:True story...

[Frank T. Lofaro Jr.]

Token Ring is technically superior. Much better under load. Much cleaner design.

Re:True story...

[westyx]

Doesn't the token getting dropped/network breaking break a token network?

Re:True story...

[Abattoir]

Here you go, plenty of fuel about how much Notes sucks. http://lotusnotessucks.4t.com/

Re:True story...

[maz2331]

And god-awful expensive it was - especially if you set it up with the old IBM shielded twisted pair cabling.

Re:True story...

[Anonymous Coward]

Oh yeah, that's why everyone's dropping Ethernet and tripping over themselves to install Token ring...

Token ring was better when we didn't have switched networks. Since the proliferation of the switch, token ring has no advantage. It's expensive, the hardware isn't nearly as easy to come by, and certain problems can down your entire network and be hard to pinpoint.

There is absolutely no reason to deploy a token ring network in this day and age.

Re:True story...

[WuphonsReach]

Sadly, Lotus Notes got extremely overextended from what it was good at. (Last time I used Notes full time was back in the v3/v4 days though.)

Notes is a *very* good distributed document management system and workflow system. If that's your problem domain, then it makes a lot of sense to use it. Replication, encryption, and document editing were all extremely well polished and simple.

Great for people who work with laptops, who need access to libraries worth of information, with the ability to make changes (including being limited to a subset of changes), without having to be connected 24x7.

Hell, one of the things that I'm looking for this week is a wiki-like application that allows for multiple-master editing for laptop folks.

Re:True story...

[Frank T. Lofaro Jr.]

Drop tokens get recreated after a timeout - no biggie.

A broken ring is a problem but I believe most cards have a bypass and/or a way to reverse the token flow, so it takes 2 breaks to partition the network.

Re:True story...

[westyx]

*nods* thanks.

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...

Re:If only...

[snowgirl]

Pfff i dont know what ur talking about at my job /* TODO: insert some anedote */ so u c because /* TODO: insert some reasoning */ so stubbing is totally in.

besides with all the verbing i do i like to rite code like i talk & stuff.

still its better than xpath 1.0 i had to write a max function with that:

substring-before(substring-after(substring(concat( ':', $x, ':', $y), $x $y), ':'), ':')

print edition

[Anonymous Coward]

because clicking "next" a bunch of times just to read a small paragraph is lame
http://www.computerworld.com/action/article.do?com mand=printArticleBasic&articleId=9020942

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.

Re:10 more dying computer skills

[Anonymous Coward]

"Dying" impliesz they were alive at some point.

Re:10 more dying computer skills

[Anonymous Coward]

Nonsense. All of those skills have always been rare

Re:10 more dying computer skills

[Anonymous Brave Guy]

I couldn't agree more, except that I'm not sure several of those have ever really been live skills. Most end user software has terrible usability, and always has had. Most systems software has always had terrible security, and the field has always been dominated by urban legends and popular wisdom. Junior geeks have always wanted to develop using the funky new toys, regardless of the business merit of going with tried and tested.

You're clearly spot on with some of them, though. In particular, efficient use of data structures and algorithms seems to be a dying art, with a world full of know-it-alls whose answer is always that hardware is cheap and whatever's in the library is good enough.

Re:10 more dying computer skills

[Delkster]

4. usability

5. interface design

As others have also pointed out, I don't think they ever had such great appreciation.

If anything, though, I think these fields are growing rather than dying. Most terrible UIs I've used have been in relatively old software, or at least not in the very recent stuff. (Or maybe I've just moved away from them, I don't know.)

6. use of testing, version control, refactoring, and other best practices

8. general communications skills

I really haven't been around in the field long enough to know, but are these really going down?

Some of the items on the list were spot on but others made me wonder as they don't seem obvious to me.

Marketshare

[QuietLagoon]

Most of the items on the list had a significant marketshare at their peak, except OS/2. Why is OS/2 even on the list? I'd put FORTRAN on the list before I put OS/2 there.

Re:Marketshare

[Anonymous Coward]

OS/2's use in consumer systems was pretty neglidible but its use in business systems was a bit bigger. Several large organisations (e.g. US post office) made use of it and perhaps the best known is cash machines which up until recently almost exclusively ran OS/2.

Re:Marketshare

[i_like_spam]

Here's why OS/2 should come before FORTRAN.

http://www.monster.com/
    "OS/2" Search --> Results 1-36 of 36
    "Fortran" Search --> Results 1-50 of 210

Re:Marketshare

[QuietLagoon]

but its use in business systems was a bit bigger.

I agree. I was one of those who used OS/2 in a business environment instead of the then popular Windows 3.1.

But still, it did not have a significant marketshare.

Re:Marketshare

[QuietLagoon]

You have to explain to me how those results reflect the comparative history of the two topics.

Otherwise, you will have made the same mistake as the person who wrote the article, i.e., do some simple search, don't think, then write an article based upon incomplete data.

ColdFusion

[GoodOmens]

I beg to defer here. I made the mistake of putting this on my resume (which hasn't been circulated by *me* in the past year or so) and get a call a month asking if I want to do cold fusion. Most offers are in the 100k+ range and they all tell me its because they can't find anyone to do it. I agree its a crappy solution but the market is there but mainly due to lack of interest on the programmers part.

Re:ColdFusion

[Taco Meat]

I defer to beg. ... ... ...

Ok, now, can you PLEASE PLEASE stop spouting off nonsense? There are no ColdFusion jobs out there. And why would you not want to get paid 100K a year to write ColdFusion? It's like getting paid a lot of money to...to...do something really, really easy.

Assembly language

[Theovon]

Maybe this belongs in a different category, but it seems to me that per capita, it's much harder now to find an engineer who could write a line of assembly for any processor.

Re:Assembly language

[Anonymous Coward]

..But Ironically, there are plenty of people who can write C and do assembly level optimization. In certain fields, like dsp, writing your own asm functions to do stuff like truncate floats is par for the course.

The article should have phrased the bit about C differently I think. I mean, having C as a sole skill is pretty outmoded, perhaps. But to be considered a competent C++ programmer, you'd have to know how to use malloc and plain C strings, and how to do at least rudimentary procedural design.

Re:Assembly language

[TheRaven64]

I recently had to write some x86 assembly. Now I fully understand why people invented high level languages and compilers.

Readable version

[whterbt]

For those who don't want the ads and "click to continue" garbage. http://www.computerworld.com/action/article.do?com mand=printArticleBasic&articleId=9020942

Is "Buzzword whore" one of those skills?

[Anonymous Coward]

I encourage everyone to disable Javascript for slashdot.org in his settings
and to disable the loading of images from other servers than slashdot.org as
long as that FUD spewing loser is wasting our precious time here.

The name of his own site says it all:

http://www.randomdialogue.net/
[...]"I have random things to say."[...]

That is what I get when I read Zonk's articles. Random
sensation about bullshit only Zonk cares about. I guess
as a kid Zonk watched too much CNN where every sack of
rice in china is a important and threatening story.

I would rather read the whole duped SCO and Jack Thompson bullshit AGAIN
than any new Zonk story.

Forget it... it's TOO LATE! The market has already decided:

http://www.google.com/trends?q=slashdot%2C++digg&c tab=0&geo=all&date=all

The list: for the javascript:void(0);

[Anonymous Coward]

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

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.

[Anonymous Coward]

You got a big gray beard, too? I don't have a gray beard but I agree with some of what you're saying. Not thinking much of modern languages, though, is almost like being a Luddite.

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.

[Opportunist]

There's no need anymore to know it. And, frankly, I can well understand why people don't want to learn assembler. I know 3 possible applications where it still makes sense to use asm.

2 of which are illegal. :)

So people don't learn it. Yes, it would be a very useful eye opener for many, and show them just why their coding habits are horrible after translation to asm, and why it might not be such a bright idea to simply dump every piece of junk value on the stack. That's actually a very rich source of runtime errors, runtime errors someone without asm knowledge would never be able to find or even understand.

But people only learn languages they plan to code in. And, seriously, there's hardly an application for asm programming anymore. Knowledge of the language could save a lot of time bug hunting, though.

Re:They said something else.

[Elektroschock]

Microsoft J++, dbase skills? --- C-Programmers are very much needed.

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.

[mondoterrifico]

Very good post. Completely agree especially about the math minor. I remember taking every single math course I could get my hands on as an undergraduate (around 12 half year courses).
All the talk about language A or B and "technologies" etc makes me shake my head. Ah well.

Re:They said something else.

[damium]

It's been my experience that any programmer worth his/her salt can pick up a new programming language, be working with it in a matter of hours and be proficient in it in days (with the aid of a good reference manual). 90% of all computer languages are the same, they differ only in syntax, API, and best practice. Syntax takes only an hour or so to learn if you have the basics of CS. API is usually a learn-as-you-go thing. Best practice is harder to pickup moving from one language to another but there are usually some simple guidelines to follow (with examples) in the language documentation.

Re:They said something else.

[m50d]

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.

But if you code in them the way you code in C you won't gain any advantage from using them. The advantages of modern languages are in the things they have that C doesn't have.

Re:They said something else.

[swilver]

Since C is not Object Orientated Programming, I would classify you as a beginning Java/C#/Perl/Python programmer who will have a LOT to learn (especially in Java where Object Orientation seems to really thrive). I would definitely expect an experienced programmer to understand basic concepts like classes, instances, encapsulation, inheritance and polymorphism, not to mention the dozens of patterns that are used all throughout Java. With only C experience, you will still need years to master OO programming and design.

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.

Re:They said something else.

[rs79]

"With only C experience, you will still need years to master OO programming and design"

Oh please. C++ is just a C preprocessor. You can actually use OO concepts in C if you want to and code it that way.

Sometimes it's even a good idea. Not always though, sometimes it's more efficient not to if you know how computers actually work.

Re:They said something else.

[jrumney]

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

Not all developers have a background in Computer Science. Mine is in Engineering, where we learned Fortran, C++ and MatLab, and algorithm analysis in addition to a lot of domain knowledge. Why do I need to know about OS and compiler design to develop high level software for solving real problems?

Re:They said something else.

[Opportunist]

They get through that the same way I got through the electrotechnics courses: Have some asm wiz do their projects and play sponge for the tests (i.e. soak up, pour out, forget). I honestly admit that I didn't understand hardware at all when I got my degree. I couldn't tell a resistor from a capacitor. I knew I would never ever end up in hardware, and if, I can still pick it up. And did in the meantime, out of curiosity and because PICs are cool toys, and it's kinda hard to wire a board without knowing the mere basics of electrotechnics.

But so far I managed to steer clear of a hardware related career path.

Yes, I've done quite a few of asm projects for other students, who thought they didn't need it. And behold, few of them managed system programming. Fewer managed compiler building. And even fewer graduated. And those that did will never get past application programming, simply because they lack the understanding of the basics.

Re:They said something else.

[Opportunist]

100% agree!

Our CS degree depended very heavily on math. We had more math than CS related courses for the bacc. People argued, people lamented, people complained, but let's look at it sensibly: CS is nothing but applied math. Whether you implement an algo in C, Pascal or if you have to Prolog is a matter of taste, preference and strengths a language may have. But it's not a earth shaking difference.

Computer languages are nothing but tools to pour mathematical algorithms into a form a computer can understand and, well, compute. No matter where you look.

Re:They said something else.

[Opportunist]

Because debugging a stack overflow problem in a deeply recoursive algo is a bitch if you have no idea what a stack is. Because library design can give you heavy headaches if you can't tell the difference between a cdecl and a stdcall, and why it matters who cleans up.

Re:They said something else.

[Anonymous Coward]

>>You can actually use OO concepts in C if you want to and code it that way.

That statement is as good as shouting "I know jack shit about OOP !!".

I've heard it trotted out over and over by fools about just about every procedural language. It just tells me that you haven't a clue!

Re:They said something else.

[fishbowl]

>Not all developers have a background in Computer Science.

Here's yet another phenomenon. I don't expect someone who majors in English to go into Medicine. I respect the Engineering curriculum, but it bothers me that engineers often don't recognize that they are crossing fields when they become software developers. I wouldn't expect a computer scientist to be competent at material science, any more than I expect things to work the other way around.

>Why do I need to know about OS and compiler design to develop high level software for solving real problems?

You *don't* and that was not my point *at all*.

Re:They said something else.

[shutdown -p now]

While it was true with C++, it's no longer true with C#, Java, and the rest of the bunch. The reason is simple: GC. You can be a C guru, but modern generational GCs can be very complicated beasts with quite unintuitive behaviour, most certainly not matching what you know from the malloc/free world. It will get even worse with the next generation of mainstream languages, such as Fortress, with their built-in and transparent handling of parallelism.

Re:They said something else.

[ciggieposeur]

If you claim to have a BS in CS at the interview table, but didn't suffer through, e.g.,

I've got a BS in Comp Sci from a decent program in Texas.

a computer organization course (like Hennessy and Patterson style, which is common these days),

My Comp Org class described memory, buses, microcode, arithmetic, instruction encoding/decoding, and as a final project required us to develop a 4-bit ALU from logic gates. We also had a separate course called "Digital Logic" that was using Altera Max+Plus II to develop logical circuits and flash them to a chip (I don't know if it was a real FPGA or somthing else).

didn't have a course where you developed an operating system,

That was an elective I chose not to take.

didn't design a language starting from BNF and build a compiler for it,

"Systems Programming" involved writing an assembler, compiler, and linker for a hypothetical chip.

didn't take 2 years of a lab science,

2 years of a single lab science? That's almost enough to graduate in the other major if you're talking chemistry or biology. Ours required only 8 hours in a lab science.

didn't at least come close to a math minor,

One course away, but only because I had also been an engineering student before and run out to diff eq.

didn't have at least 4 courses at various levels of discrete math, automata, algorithm analyis,

Automata was a graduate level course. Algorithms, data structures, and discrete were required for undergrads.

and didn't have a course that, as a final project, you deliver a significant user app in a high level language

Our final project was a tiny web-based CGI app in C that took me all of two days to complete. This was circa 1998/1999 before web servers plugged in easily into anything but CGI and perl.

(on the order of an original multiplayer game, let's say)...

"Game Design" was an elective that I took -- 3 programmers + 1 artist from the Digital Arts major to design and implement an actual game using DirectX 5.x.

I'd say your school has some explaining to do.

Me too. The databases course was useless -- one week of full-time work with DB2 covered far more material on table and query design that two weeks of "predicate calculus". Nearly every other course could be reduced to about two weeks of full-time study each, and the profs had a tendency to ramble off-topic. The biggest drawback was that it was an "OK" prep for a Comp Sci graduate student and a "slightly-less-than OK" prep for an actual programmer. But then, I've never actually seen or heard of a really decent prep for professional programming work; it seems everyone needs at least two years of full-time experience before they can write passably usable code.

BTW--You forgot to mention an ethics course that covered at least a handful of the more famous fatal software glitches.

Re:They said something else.

[Dirk Pitt]

I respect the Engineering curriculum, but it bothers me that engineers often don't recognize that they are crossing fields when they become software developers

I don't see this as any different than what most developers do - if you have a degree in comp sci/engineering, do you recognize that you're crossing fields when you write software for the medical field? Should all developers have two degrees - one in comp eng, and one in whatever field they're going to write software for?

I write scientific computing software - analysis software for the mechanical engineering field, specifically. We have people like me, with a computer eng bse, and people like the guy sitting next to me, who has a PhD in aerospace eng. I've learned *a lot* on the job about numerical techniques for finite element analysis - something I'd not been exposed to at all in school - and he's learned *a lot* about software architecture. Frankly, given he has about a decade more experience than me, his knowledge about software design trumps mine.

Given a strong background in mathematics and engineering, I don't think it's unreasonable to become interdisciplinary in a specific field given a software background, or vice-versa. And I do think most engineers respect the crossover - quite a few I know have gone back and done grad work in comp sci/software engineering. Conversely, I might go back and do a mechE. But I'm not sure grad school could teach me more than my neighbors have. (sure it could, I'm just saying)

BTW - I've become quite competent at material science. ;-)

Re:They said something else.

[Goaway]

Lots of CS programs these days are just glorified vocational schools, where you learn how to put two classes together to develop an Enterprise Solution. Most programming today is grunt work, but the reality of the situation has not quite caught up with the educational system.

Re:They said something else.

[Anonymous Coward]

Would you or anyone else care to justify this troll?

Re:They said something else.

[jamesmrankinjr]

Why do I need to know about OS and compiler design to develop high level software for solving real problems?

Leaky Abstractions

-jimbo

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

[tha_mink]

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. 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)

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

[Anonymous Coward]

I just started working in the actuarial department of an insurance company. Almost all of our code is in Fortran. Elsewhere in the company COBOL is used. No plans are in place to phase out our Fortran and COBOL code and these languages are used for any new ad hoc programs we need to make.

It's pretty restrictive to work in an environment like this after having been raised on more modern languages, but to be honest I can see how there isn't really anything to be gained by replacing the existing code. All it has to do is make sure that customer service has access to the stuff they need and then all we do is generate reports or pull samples from the raw data.

Everyone seems to be content here. A former IT guy moved to actuarial a few months before me and he regards the mainframe as a beautiful thing, even with its warts.

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

[Anonymous Coward]

I agree that Cobol isn't going to just go away. I just spoke with a recruiter at a Fortune 500 company that said the mainframes they use all programmed in Cobol. This meant for me that I need to go take a 2 week into class on Cobol.

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]

>Sure its a lot easier to program the same thing in a more modern language

Your other comments don't bear that out :-)

I worked in a cobol shop (oil exploration corp, where I programmed in C on HP unix, and never actually touched cobol).

I don't mean to essentially repeat what you said, but it was obvious that business processes had been developed along with software, forms, management structure, controls, and so forth. The problem of replacing software systems wouldn't have been a simple matter of gathering requirements and developing modules to fit those requirements. That's the assumption that leads to the "WTF" factor when you tell the young'ns people still use COBOL. (And read my earlier rant on FORTRAN, which is today in active use, by people who choose it even though they are proficient in modern programming languages!)

On the other hand, there *were* instances where some mainframe COBOL apps were replaced with small desktop apps written in VB2.0 (showing my age, but I was mid-career when VB came out :-)

I think some people think a "big project" is on the order of an OS or a GUI framework, and don't appreciate the scale of what's going on in the big business mainframe world, etc. I worked in that world for a good while, and I'm not even sure I fully comprehend the scale :-)

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?

Re:dovetail

[Anonymous Coward]

What, no BASIC?

They call it C# now.

Re:dovetail

[dubl-u]

What? They call those dying? I did a lot of floppy disk recoveries in college. And even then we were both awed and slightly scared by the one guy who would do recoveries of corrupt magnetic tapes.

Re:dovetail

[Degrees]

You owe me a dollar too. We have a property tax system running on a mixture of COBOL and CICS that keeps on humming. Some of that code was written in the 1960's.... Thing is, property tax law doesn't change all that often, nor does the structure of the data. The programmers that we have love their job because it's easy as heck: write a new report every once in a while, twiddle with things a little here and there, generally work on things that are more interesting; but always be available to work on the property tax system, because that is how we all get PAID.

They did look at replacing it a few years ago, because it seemed the trendy thing to do. As it turns out, every county does their property tax a little different than the next. This means that there is no off-the-shelf / canned solution available. It was going to have be a whole 100% custom system that cost more that $1 million to implement.

And for what? So that we can say that we got rid of COBOL? Our taxpayers deserve better treatment than that....

At some point, the mainframe will become a virtual machine inside a big beefy PC. But I'll bet that COBOL code will still be reading records and printing bills five - ten years from now.

Re:dovetail

[Anonymous Coward]

30 PROFIT!

Re:dovetail

[The Finn]

But 25 years ago, they sure weren't: C was just too damn big and slow to write an operating system in.

someone remind me again what language Unix was written in?

Re:dovetail

[LizardKing]

I wouldn't use C for the kind of applications you're talking about, although if I was forced to I'd look into something like the GNU Scientific Library. However, Java is a good choice for math heavy coding where you don't have the resources to do it Fortran. Arbitrary precision is possible using classes in the standard java.math package, which as the Javadoc states "provides classes for performing arbitrary-precision integer arithmetic (BigInteger) and arbitrary-precision decimal arithmetic (BigDecimal)". I'm not just saying that it's possible to do precise mathematical programming in Java, I know several people who do just that for nuclear physics projects at various academic and government institutions in and around Oxford, UK.

Re:dovetail

[eelcoh]

It's very very good at what it does: business logic. Exactly. And in most cases where COBOL is used, being a good programmer is not important. It is all about your business domain. So if you're looking for a programmer for a mortgages system, and your choice is between someone who knows C and Assembler and someone that knows everything about mortgages but just finished his COBOL-course, you'd better pick the latter.

Re:dovetail

[savuporo]

on the "operatin systems are in C" .. this is true only to a limit. Take two that we commonly refer to as opsyses: linux and windows ( yea i know linux is just a kernel, but nobody "installs linux" nowadays without getting BASHed in the process )

The idea of "Op sys" usually includes more than just a kernel and drivers. It usually has some sort of basic user interface and other facilities included. Kernels are C and assembler, true.
but usually even the most basic installs of linux will make use of some scripting language, just to process startup scripts for instance.
windows wouldnt be windows without large block of COM classes that make up the foundations of how win works. Much of the COM classes are written in c++. windows also inevitably comes with graphical shell, i believe large parts of it are also written in C++

Vista ? i may be wrong but some stuff on it is running on .NET CLI out of the box, which means managed languages, likely C# or abomination called VB.NET

at the most basic level, its always going to be assembler. but i wouldnt be surprised if next installment of Windows for example will consist of very much CLI code out of the box. with drivers moving to userspace, its not hard to imagine a "bridge" driver that will bring some system buses to managed space as well.

Re:dovetail

[Maximum Prophet]

someone remind me again what language Unix was written in?

Assembly. Then it was re-written in C. 25 years ago, (1982) I was just getting into UNIX, BSD on a VAX, and it was C, with the tightest loops in the kernel still in assembly. Remember you use to be able to put assembler code inline in with your C code and it was trivial to link a C module with any other object module. I think that's one of the biggest arguments for C (and UNIX) for that matter, it works and plays well with others. Other languages like APL and Smalltalk want to be their own environment, making it difficult to interface with other languages.

Re:dovetail

[fishbowl]

You're preaching to the choir, Lizard. I know there are good resources available. My point was, that there are people who also realize this, still using FORTRAN in scientific computing, and they think they have good reasons. I tend to think the whole field should be torn down and rebuilt from first principles, but I don't carry that kind of weight :-)

Re:dovetail

[captainstormy]

Acctually, I'm 23 and working in COBOL/Mainframe applications for one of the major consulting firms in the world. We do alot of new COBOL projects in the Insurance and Banking industry. COBOL is certainly a nitch language but its not dying at all. Just last week a big insurance company client of ours signed off to start the development of a brand new system for them, written in COBOL/JCL/Assembler to do their processing for them. They are replacing their 30 year old COBOL system with a brand new COBOL system that by the time its all said and done will cost near 800M bucks. simply put for huge volume processing, mainframes and COBOL can not be beat. Not to mention job options for a person my age that even knows COBOL/JCL/Mainframes/Assembler are almost limitless as every company using those realizes their workforce will be retiring in the next 10 years or so and they need to train new blood.

Re:dovetail

[Uerige]

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.

Where I work, COBOL is pretty much everywhere. Everything that doesn't have a GUI has always, and will in the forseeable future, be a COBOL program or a JCL (calling COBOL programs).

But you do have a point, COBOL is definetly the worst language I have tried, and even though I love programming I would never accept a COBOL-position, however well paid.

Re:dovetail

[Chibi Merrow]

although if I was forced to I'd look into something like the GNU Scientific Library

You had me excited... For the whole thirty seconds it took to realize it's not released as Library GPL... Argh...

Re:dovetail

[sjames]

In the world of IT, nothing ever quite dies. There are still plenty of PDP-11 programs running out there too. The actual mini was long ago replaced by a PCI card hosted by a PC. In the world of IBM mainframes, there are STILL programs running in multiple layers of emulation.

There are a great many legacy apps concentrating in financial and scientific computation. In scientific computing, there are heaps of fiddly details that took years of tweaking to get more or less right most of the time. There's not a good way to verify accuracy, especially in itrerative simulations where a tiny error can be amplified tremendously and program runs last weeks on a cluster.

In the case of financial apps, they simply can't afford the damage to their reputation if they start losing fractional pennies here and there. It's easier to verify the correctness of an emulator than a replacement of the old code.

Either case creates a huge bias towards keeping the 30 year old code no matter what.

The real measure of the "livliness" of a language is to look at new projects that are using it.

Re:dovetail

[juan2074]

Did you learn that on a TRS-80?

C? not dying yet.

[serviscope_minor]

It may be declining since it's heyday but in the embedded world, C is King and will be for a while yet.

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.

They are nuts on the C front.

[shaitand]

Maybe nobody hires C programmers for coding jobs anymore but it is hardly an obsolete skill. There are millions of lines of C code that require an actual C programmer (a C programmer can move to C++ without a problem but the reverse is not true) to maintain and update.

Further anyone working in the *nix world administrating systems and networks is far more likely to get hired with C skills.

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:They are nuts on the C front.

[MightyMartian]

Lots of code is written and will be written in C. Embedded systems aren't going away any time soon, and a good chunk of low-level optimized code will always be written in assembler or C. While the language fashion industry likes to pick a new THE LANGUAGE THAT WILL LAST FOREVER for web-based and scripted apps every six months to a year, the fact is that underneath all that weight of bloated, unoptimized, monstrous, zillion-line library-supported code will be C code holding it all in place. It's true that you won't find too many word processors written in C anymore, but I'll guarantee you that a big chunk of the operating systems they run on are.

Re:They are nuts on the C front.

[Khashishi]

(a C programmer can move to C++ without a problem but the reverse is not true) Why is that, if C++ is (mostly) a superset of C?

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.

Re:They are nuts on the C front.

[grumbel]

Neither is true, strcpy(), malloc(), printf(), #defines and friends will give you the same headache as inheritance, virtual functions and friends. The only advantage that a C++ programmer has is that C is a part of C++, so in theory, he might already know it, but in practice there is still a ton of stuff to learn.

Re:They are nuts on the C front.

[Jthon]

Of course if you're using C99 you don't even need to define your index variables outside your loops.

Re:They are nuts on the C front.

[shaitand]

Yes but we aren't talking about C vs scripting languages. We are talking about C vs C++ and there is no barrier I am aware of preventing someone who likes the C++ design concepts (sorry C++ fans, it is just another way of thinking about the code, not a superior design concept) from writing an operating system using C++ in place of C. The portions in ASM will of course stay in ASM for performance reasons.

Re:They are nuts on the C front.

[shaitand]

'Why is that, if C++ is (mostly) a superset of C?'

That's why. A C++ programmer can set the superset aside and master actual C (just learning the functions briefly while learning C++ is a long way from mastering C) and a C programmer can incorporate the new functions and design concepts in C++ that isn't what I am talking about. When I say no problem, I mean just sitting down and doing it without learning anything.

Why is it a problem for a C++ programmer but not a C programmer? That's easy. For the most part you can write code and compile it in a C++ compiler without modification. TADA, you have written C++. A C++ native on the other hand largely uses the superset and their code won't compile in a C compiler.

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.

Re:They are nuts on the C front.

[scotch]

a C programmer can move to C++ without a problem but the reverse is not true

I've seen that happen - you end up with C code that you just compile with a C++ compiler.

Re:They are nuts on the C front.

[scotch]

Not if you use C99 - come on people, the standard is 8 years old already.

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 do! In fact, it displaced VB as my primary tool of choice back in 1997, for technical reasons (mainly, performance, & yet it is as readable as VB is imo, as well).

Delphi 2.0 swept the floor with BOTH MSVC++ & MSVB (of all places), in "VB Programmer's Journal" October 1997 issue entitled "INSIDE THE VB5 COMPILER ENGINE"!

That's where Delphi absolutely blew away VB in ALL of the tests (except ActiveX form loads, which VB even took MSVC++ out in), & took C++ out on 8 of 10 of the tests!

Most importantly, by HUGE margins (especially in math & strings work, which EVERY program does).

Where Delphi did lose to MSVC++ (only 2 of 10 tests) it was by VERY SMALL MARGINS, far less than where it blew away MSVC++....

It was enough for me to see that developing shareware @ least, Delphi rules. I like it a lot, & used it to create this tool (runs essentially unaltered since its birthdate in 1997 to this day, across ALL Win32 platforms):

APK Registry Cleaning Engine 2002++ SR-7:

http://www.techpowerup.com/downloads/389/foowhatev ermakesgooglehappy.html

That IS the safest & most comprehensive/thorough registry cleaning program there is, bar-none, to this day, even 5 years after I quit developing it, to this day. Enjoy it, if you try it.

(Anyhow/anyway - In shareware/freeware I have done on the side is where I solely control the tools I use, unlike @ work locations, where mgt. calls the shots on tools used & today they follow "He who has the money, wins" because "nobody ever got fired for buying IBM" (replace IBM today, with Microsoft)).

Mgt., even though I showed them such results, was like "Well, can't argue the fact that Delphi IS the superior tool for performance AND rapid application development, but... Microsoft has the ca$h, & will be here tomorrow: WILL BORLAND BE?"

You can't win there, not really, not on a technical superiority level. Much like VHS vs. BetaMax, the 'best man for the job' does NOT always win.

APK

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!

Re:Delphi

[adolfojp]

You can try Lazarus and Free Pascal. They are not anywhere near Delphi in terms of maturity but it can give good results in many situations. Its IDE is also quite user friendly.

http://www.lazarus.freepascal.org/

Re:Delphi

[Mr2001]

Yes, there's a lot of Delphi code out there that still needs to be maintained (or ported). In fact, I hear there's a fast, powerful, free IRC client written in Delphi that's looking for someone to take over development...

There's even Delphi for PHP now. WTF? It uses a completely different language and library, and applies to a completely different field of software, but for some reason it's still called Delphi and the library is still called VCL.

Re:Delphi

[bzipitidoo]

When I was an undergrad, Pascal was big, and C was this "hard" language used only by systems programmers who could comprehend the mysteries of "pointer arithmetic". The ACM's programming contest had just moved from Pascal only to Pascal or C. I saw the way the wind was blowing and learned C on my own while the school was still screwing around with Pascal and PL/I.

I wonder if Borland's troubles kept Delphi from becoming mainstream. Or perhaps the stillbirths of Pascal's descendents, Modula 2 and 3, fragmented the Pascal community and helped push Pascal to the sidelines. Or maybe, it's that C is native to UNIX and Pascal isn't, and 'NIXes have become much more popular over the year thanks to Freedom. Or perhaps C is a little friendlier to international users, as it has more intuitive symbols and less English than Pascal. And, CS has become more international over the years, hasn't it? Probably a bit of all of those. I've never used Delphi (if it cost money, I didn't use it), but it's basically Pascal with a GUI API, isn't it?

Yeah, I agree with everyone else that C shouldn't be on that list. Maybe the others, but not C. I would've put Pascal in there instead of C.

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.

Actually, only one version of Delphi was .Net-only. The latest release is Win32-only, and the prior release targeted both Win32 and .Net. CodeGear (subsidiary of Borland now handling the development tools) is still lagging on Win64 and .Net 2.0/3.0 support, but we Delphi users have grown used to such delays (not that we don't grumble about it).

- T

Re:Delphi

[Anonymous Coward]

Yes, there's a lot of Delphi code out there that still needs to be maintained (or ported). In fact, I hear there's a fast, powerful, free IRC client written in Delphi that's looking for someone to take over development...

There's even Delphi for PHP now. WTF? It uses a completely different language and library, and applies to a completely different field of software, but for some reason it's still called Delphi and the library is still called VCL.

The term "Delphi" originally referred to the IDE/RAD product itself. Later Borland officially called their Object Pascal dialect "the Delphi language" (no link handy). Since Delphi 2006, they seem to be moving toward using the word Delphi to mean their so-called studio IDEs, as in the new (IMHO overpriced) Delphi for PHP product. I'm guessing that the next iteration of the BDS (Borland Developer Studio) will be rebadged as "Delphi Studio" or something similar in an effort to build on that name recognition, regardless of which languages are included. Note that BDS 2006 includes Delphi, C++, and C# regardless of whether you buy Delphi 2006 or C++Builder 2006.

- T

Re:Delphi

[Anonymous Coward]

Delphi is alive and well. Many programs out there are still developed using various flavors of delphi. In fact, I use several versions of it everyday.

Re:Delphi

[Anonymous Coward]

"When I was an undergrad, Pascal was big, and C was this "hard" language used only by systems programmers who could comprehend the mysteries of "pointer arithmetic". - by bzipitidoo (647217) on Thursday May 24, @11:53PM (#19265001)

var
  iValue, j : shortstring;
begin
    j:= Trim("");
    iValue:= Trim("Delphi has pointers, about all I can say... this is only 1 type, there are more... FYI, etc. et al!");
    pIntValue:= @iValue;
    j:= pIntValue^;
end;

* Later...

APK

P.S.=> Check it... should work, lol! apk

Re:Delphi

[Anonymous Coward]

"Yes, there's a lot of Delphi code out there that still needs to be maintained (or ported). In fact, I hear there's a fast, powerful, free IRC client written in Delphi that's looking for someone to take over development..." - by Mr2001 (90979) on Thursday May 24, @07:53PM (#19262553)
(http://www.hansprestige.com/)

Hey, I know you - In fact, I used to post @ your forums in fact, during your finalization of the ViRC client, which iirc, YOU took over @ some point (& needless to say, you did a great job of imo).

How's life etc.?

If I had the time, I'd give that a go myself (taking over your current codebase & working on it), but I am "tied up" with work related duties presently.

(Additionally/admittedly, I also have to say, I do NOT trust (fully) IRC anymore, though I used to be an admin/mod the #Windows95 DALNET Official (endorsed by MiRC creator, K. Mardem Bey) Win32 OS help channel circa 1996-2000).

IRC is/was a GREAT thing, the ORIGINAL chat tool online imo, but lately? It's been getting abused by various troublemakers & I tend to steer clear of it.

That all said & aside: Have you considered putting it up on "sourceforge" (if you have not already)? It'd be one heck of a project for a young programmer to take the reigns over on & get their feet wet coding.

http://www.hansprestige.com/

APK

P.S.=> If any of you readers here like Delphi, & want to see a truly nice iRC tool? Check out Mr2001's vIRC, & if you are coders? Consider taking his offer on taking over the reigns as its developer... you're starting with a great foundation building upon his & his predecessor's work on it! apk

Re:Delphi

[OceanWave]

I've been using Delphi since about 2000. I still do write apps with it occasionally.

Prior to using Delphi, I was using MS VB 5. I found Delphi to be about 500 times faster, and less likely to trash your project when moving it from one development workstation to another. Compared to VS 2003, the object libraries provided with the old Delphi 6 Pro were miles ahead in features and functionality, as well.

It was a little more difficult to get results from the debugger, compared with VB. But the other gains made it is worth while choice.

Delphi is still out there. They have a .NET compatible version, last I heard. There is also a lot of support and additional libraries available overseas. It was quite a bit more popular in Europe than in the States.

(I wish they would release a Mac version.)

Re:Delphi

[Mr2001]

Thanks. I don't use IRC much anymore either, sadly, which is why ViRC development has stopped. I have been porting parts to C#, so a rewritten ViRC 3 may be in the future, but there are still issues with ViRC 2 that deserve some attention.

The project is already up on sourceforge for anyone who's interested.

If they are outdated, why do we need them?

[El Icaro]

Besides C, every other computer skill has a newer (and better, not just newer) alternative. Besides learning them for the sake of learning, which should be good enough to anyone really interested in computers, is it really good for anything? I'm sure knowing these will guarantee you a job for a long time in some company somewhere, but it won't help you anywhere else if you're looking for bigger, more exciting things. And what if this company realizes it's time move on to some other language/development paradigm/database? In the tech world there always seems to be this huge need of "moving on". I'm not arguing it's either good or bad. To me it just is... and seems pretty much unstoppable. We might as well stick with it and play with our Commodores on weekends.

C programming?

[SlashDev]

dead or dying? Most if not all OSes are written in C (Not C++ or C#). Most server software is written in C (Not C++ or C#). Dear God, most languages, compiler and utilities in UNIX/Linux and Windows are written in C. The person who included C in the list is either not a programmer or simply an underpaid VB programmer :).

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.

Re:Web Design

[Frank T. Lofaro Jr.]

Lock her up for being a hacker, doesn't the new patriot act cover that?

But she used open source to do it.

http://blog.tmcnet.com/blog/tom-keating/mobile-pho nes/paris-hilton-hacks-voicemail-using-asterisk.as p

Print version

[Explodicle]

Here are all 10 in one page.

+1

[Anonymous Coward]

MS Windows is an entire computer ecosystem designed for idiots with just enough needless complexity to keep some of them employed as specialist button clickers.

It's not really the skills that are dying, button clickers are not overly skilled. It's the platform that's dying and taking overpaid 'admin' positions with it.

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

[marvlush]

the author of this article must think that all computers use web pages to communicate with the hardware.

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.

WHAT!

[bryan1945]

Basic for the Apple II+ is NOT on there!

Sigh... I'm soooo outta touch.....

command line skills!

[Anonymous Coward]

I think command line skills are dying. I look at the next generation and they are always surprised to see me using awk/gawk/sed/perl/... from the command line to do simple things. Emacs macros, which defined my university years, seem to be totally lost on the new graduates as well. I can recall days when I never used the mouse once while sitting at a computer doing various things. My dotfiles were insanely long. Anyways, these are all just a matter of style, I suppose. But still I certainly feel that my style is different than the new generation.

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:C and PC network administrators?

[jcgf]

C programming is not going away

fixed that for ya ;)

It's more profitable to replace them.

[khasim]

As the article said, Novell is getting ready to "retire" the CNE 6 certification. And they're only up to NetWare 6.5.

Novell is killing NetWare. And GroupWise.

It's a shame. They were good products. I'm still running 7 NetWare boxes with 4 GroupWise post offices. But they will pretty much be reduced to 1 NetWare box with 1 GroupWise post office by this time next year.

Novell should have, long ago, migrated the look and feel of the NetWare utilities to SuSE so that their customers would not have seen a difference when migrating.

Re:It's more profitable to replace them.

[Anonymous Coward]

And to think, I was all but ready to pony up and pay to sit the upgrade to CNE6.

Given that I had that thought FIVE YEARS AGO, I somehow don't feel so bad now.

Last I heard MCSE 2000 holders also have to sit the update exams to MCSE 2003 before the end of this year if they wish to take the upgrade exam versus sitting the whole track.

In other news, The newly reappointed CIC performs illegal act later made legal through executive decree.
Sunset will be @ 20:17

The List

[martinelli]

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

-John Martinelli
RedLevel.org Security

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.

[networkBoy]

Not me. I only know C and lazyC (A.K.A. perl)
-nB

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

[Anonymous Coward]

Most programmers know more than 1 language.

I'd say most programmers who only know 1 language are usually poor programmers. Not as much because they only know 1 language, but because that means they simply don't have enough experience.

The "popular" languages attract lots of people who want to get rich fast, but would you really hire someone who only knows C#? I know I wouldn't, even if all he was ever gonna do was C#. If he only knows C#, he simply doesn't have enough programming experience.

Of course, broadening your horizon by learning new languages and new programming techniques can never hurt.

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

[hooeezit]

If you know only one language, you are either fresh out of a get-a-job-quick diploma school or high school. You better be. If you are in the industry and you know only one language, you are already obsolete! They just haven't gotten around to handing you the pink slip yet. Just knowing Java, e.g, won't get you anywhere unless you know some PHP as well as far as web programming goes. Just knowing C# is not enough - very often, you have to deal with lingering COM code most probably written in VB6 (uggghh) or C++. Or you might need to write an unmanaged DLL in plain C.

Fresh-out-of-school kids take note. If you know only one language, learn another one, preferably one very different from the one you know. It will give you one extra bullet point on your resume, but much more importantly, it will give you a new perspective to programming solutions to problems.

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

[syousef]

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

This has been true for a very long time. For all intents and purposes it's always been true.

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

[multipartmixed]

If you count "shell" as a language (I count it as two with several variants), then it's probably been true since 1977.

And before that... how the HELL could you even GET TO a UNIX box without showing your 31337 skillz punching cards to write FORTRAN programs, some BCPL, some BASIC, some assembler, or maybe JOVIAL?

No, I would suspect that less than 1 percent of 1 percent of 1 percent of competent C coders know at LEAST one other language well.

Me? I consider myself a C programmer, but I know C++, classical BASIC, [bourne|korn|ba] shell, yacc, lex, JavaScript, PHP well enough to use them on a daily basis. (Also PHP, HTML, CSS -- do those count as programming languages?)

I've also worked with S/SL (a compiler construction language), MAX (music event oriented language), Turing, Prolog, SmallTalk, Miranda, TCL, LISP, Pascal, LOGO, Quick Basic, Visual Basic, several flavours of assembler (Intel, MOStek, Zilog, Motorola, DEC and MIPS CPUs)....

And I actually consider myself UNDER varied. I could certainly pick up Ruby, Python, Perl and Java if the mood struck my. Probably two weeks each to moderate proficiency.

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

[sgt_doom]

Wow! I guess this probably means I should give up on that ole Databus language after all? Seriously, though (just this once), I suspect /. is on the way out.

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

[Nevyn]

I could certainly pick up Ruby, Python, Perl and Java if the mood struck my. Probably two weeks each to moderate proficiency.

You might know the syntax, and how to write hello world in much less time than that but either your definition of "moderate proficiency" is very different to mine or I just don't believe you. 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".

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.

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

[syousef]

Learning languages quickly isn't hard. It's the libraries and the patterns that you must follow that require months of experience. The standard C libraries are very small compared to what you're expected to know say on a J2EE project today.

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

[sineltor]

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

Serious programmers who only know a single language are incredibly rare regardless of what that language is. I'm in my final year of a computer science degree and I know more languages than I have fingers. Between the last 3 casual jobs I've held I've used the majority of those languages; too.

I don't understand how people who only know a single language are employable these days.

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

[mcvos]

You might know the syntax, and how to write hello world in much less time than that but either your definition of "moderate proficiency" is very different to mine or I just don't believe you.

What kind of programming education did you have? One of the courses at my university had the explicit goal that after that course you'd be able to pick up any programing language in about two weeks.

And it works. I was hired for my current job as web developer purely on my Java knowledge, and I learned javascript, xslt, and even html and css on the job. The basics of xslt took a few days. Same with javascript. It helps to have a good reference manual nearby, ofcourse.

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

[multipartmixed]

Bingo.

Which is why as an excellent UNIX C programmer, I still get help from a VB-literate friend the odd time I delve into the nasty world of Visual C. He tells me which calls to which DLLs need to be made to do whatever system-specific task I'm unaware of (stuff like forking processes, memory mapping files, that sort of thing).

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

[Nevyn]

What kind of programming education did you have? One of the courses at my university had the explicit goal that after that course you'd be able to pick up any programing language in about two weeks.

Maybe I didn't explain well, or maybe I'm expecting too much out of the phrase "moderately proficient". But proficient is defined as: Well advanced in any branch of knowledge or skill; possessed of considerable acquirements; well-skilled; versed; adept. To assume you'll be even "moderately well-skilled" in two weeks, is to assume a lot, IMNSHO.

Let's take a real world example of python, now when I first looked at python I knew C and perl well, as well as having more than a a few hours experience with a random number of other languages, pascal, asm, lisp, miranda, prolog, whatever.

So sure, within a couple of hours I knew what the syntax for the core language was and I could "write good C in python" ... but I sure wouldn't have called myself "moderately proficient" in python.

After the "virtual two weeks" I had short term memory for the parts of the std. library I'd used, understood some corner cases like "global" vars and had stopped forgetting to put "pass" in places due to the retarded whitespace syntax. But those were/are all small improvements over that initial couple of hours "looks like C without braces" knowledge.

For "moderate proficiency" it was probably months of work away, and involved understanding much more of the std. library, not just what duck typing is but how you can use it well, at least some of the performance concerns with things like growable string data, using yield / closures in the "right" places, using classes and decorators etc. etc. ... just generally having a good chance of writing ok-good python in python.

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

[Nevyn]

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).

So, 40-80 hours or more is "moderately proficient" and then you go straight from that level to "very proficient" at roughly 40 times as long? IMNSHO there is a big different between someone with a couple of weeks and a couple of months experience. Also 3,000 hours is roughly 18 months, and personally I wouldn't believe someone is very proficient with only that amount of experience in C. So your definition of very proficient is probably very different to mine.

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.

It's "obvious-bug free", hell I'm impressed if I do that in C over ten years later. Give me some more of those moderately proficient people! I'm not sure what you meant by "half the OSS code out there", I'm guessing you misspelt "half the code out there" ... and just mean moderately proficient is in the middle of the pack somewhere.

C [to me] implies unistd, stdlib, stdio, strings, etc, but not xpg4, sockets, iconv, blah de blah.

I'd expect an average POSIX/C programer to at least have some understanding of sockets, and with C "strings" is pretty openended ... it's also somewhat harder for me to say where moderately proficient should begin/end, as I'd be tempted to think of anyway still using pretty much any "string" functions from string.h as having moderate proficency at best (which I'm not sure is completely fair).

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

[Zepalesque]

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

Yes - I know C and english ;)

C programmers?

[LinuxInDallas]

Given the source I am not surprised to see this. I can tell you thought that C programming is and will be dominant in small embedded systems (8/16 bit microcontrollers) for a long time.

Wow

[jzuska]

If you are an expert in one of the listed technologies:
1: die
2: adapt

No sarcasm here. Everything on that list is so old anyone that is doing production work needs to be killed.

Re:Wow

[nuzak]

1: die
2: adapt

Kind of tricky getting to step 2, isn't it?

Re:Wow

[peterpi]

The entire games industry needs to be killed, by your reasoning.

The list

[Kuvter]

Another one of those stories where you read only 2 of the 10 and hit Next Page (more ads)
So to save you time RFTA:
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

Re:What? C?

[Intron]

I understand that there is a popular OS written in C++. Here's what Linus has to say about it:

"we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA."

FORTRAN

[Anonymous Coward]

Mark Linton, former professor of Stanford University, once said (in CS 140) that FORTRAN is the "F" word.

How to learn COBOL

[innocent_white_lamb]

I submitted this as an "ask Slashdot" a while back but it was rejected:
 
How would one go about learning COBOL today? After reading about it off and on for years, I have become interested in learning some basic COBOL. What books or resources would you recommend, and what compilers are available for Linux that generate good COBOL?
 
There do indeed seem to be less and less people who know anything about COBOL, but there also seems to be a dwindling supply of COBOL materials to work with and learn from.

Re:How to learn COBOL

[Danga]

How would one go about learning COBOL today?

Believe it or not some educational institutions still teach it. I graduated with a CS degree from Northern Illinois University and COBOL classes were required. Here are links to two that they still have:

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

I wish I could recommend a book for you but the classes I took all used "books" printed by the university bookstore which were special made for the classes. They weren't that helpful anyway. Anyway, while it is unlikely, depending where you live you might be able to find someplace local that still has COBOL classes so I recommend checking around.

Re:How to learn COBOL

[innocent_white_lamb]

Thank you very much for your reply.
 
However, I live in a rather isolated location and self-study would be the only practical approach for me.
 
I'll guarantee that no COBOL courses are taught within 500 miles of where I live, and probably a lot further than that.

Re:How to learn COBOL

[Anonymous Coward]

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. USETHESOURCELUKE
000300 DATE-WRITTEN. 24/05/107 21:04.
000400* AUTHOR SLASHDOT_COWARD
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. UGH-COBOL.
000800 OBJECT-COMPUTER. UGH-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 VISIT LIBRARY ADDING BOOKS TO STACK GIVING MATERIAL
100500 READ BOOKS INCREASING KNOWLEDGE GREATER THAN BEFORE
100501 GOTO GOOGLE
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.

Okay, so that's stolen. Feh! Bet you can't guess what from!

Re:How to learn COBOL

[gnasher719]

'' How would one go about learning COBOL today? After reading about it off and on for years, I have become interested in learning some basic COBOL. What books or resources would you recommend, and what compilers are available for Linux that generate good COBOL? ''

I bought a book about Cobol a few (maybe three years ago), reduced from £34.95 to £5, thought it would make some fun reading while sitting in the garden enjoying a bit of sunshine. After a few pages I thought "WTF? What kind of nonsense is this? What sane person would use that create that kind of language?" dBase and Clipper were sane. Cobol isn't.

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.

C will die when hell freezes over

[Prien715]

So you want to you Ajax? Great! So your client is using a web browser written in Perl and an OS written in Java? And the Perl interpreter is written in assembly? Good good.

C will live as long as performance is important in computing, but I suspect it will be THE low level language (i.e. higher than fortran, lower than Python/Perl/Ruby/Java) and that if anything, Fortran/Cobol will/have become irrelevant since (1) C is very popular and (2) C can be seamlessly integrated into C++. C++ will also live forever due to C's popularity (can write complex graphics code and object oriented code in the same code base (i.e. Civ4)).

I'd vote for FORTH

[Anonymous Coward]

In the 80s I came into being a professional developer primarily using FORTH in embedded systems. Unfortunately after spending about 8 years becoming a master FORTH programmer, I had to move on to another company. Sure I've become fluent in C, C++, Python, Ruby. But none of these other 'languages'; not a single one; allows me to express the solution to a problem as succinctly, elegantly, and beautifully as FORTH. I know there are still a few FORTH jobs around, just none where I happen to be living these days. And to me this is a crying shame.

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.

Re:I disagree with some of the list.

[Skizmo]

Digg me down, but you are really hitting the spot

Re:I disagree with some of the list.

[Liquid Len]

Geez, how many times does this have to be repeated: Fortran isn't dead. Not by a long shot. Fortran 77, IV may still be around for maintenance, as you write, but Fortran 90, 95 and 2003 are still heavily used in scientific programming. About 10 years ago, I started working in physics and some people would always explain how everybody would soon make program in C++, even in science. Well, guess what, it hasn't happened. Why not ? Because as a scientist, your job is to focus on, well, science and the programming language is just a means. You don't want to spend your days looking for memory leaks, coding hacks and whatnot.

As a matter of fact, back then, I was a C fan, and I thought everything needed to be in C. So, I was working on this ugly fortran 77 code I had been given, and I decided to rewrite it in C. It took some time but eventually, it worked. I compiled it, ran it on this vectorial Cray and... although the results were the same as in Fortran, the performance was significantly poorer. In this case, the problem was the cache hit ratio, which was larger in my C code than in the original Fortran codee. In fact, the Cray Fortran compiler had done a better job than me at taking care of the memory, given the underlying architecture. Now, I grant that by working hard on the C source, I could probably have done as well, maybe even better, than Fortran. But, hey, this was not my job and from this day, I decided I would stick to Fortran for my research codes.

Re:I disagree with some of the list.

[Anonymous Coward]

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.

I honestly can't tell if you're being serious or not about this list. What I can tell tough is that this last paragraph is full of sh*t.

3D is huge in the medical arena. Huge beyond your wildest dreams. After stagnating a few years now OODBs are getting huger and huger by the day (probably linked to the incredible of Java in the enterprise space). Oracle is on a buying spree and recently bought for $$$ millions four companies providing in-memory OODBs. Extreme programming in some circles is a big no-no like, say, for OO analysts / translationist working in R-T/E. Memory-efficient and CPU-efficient programming methods are certainly not dead. Quite a lot of people do know what the big O notation is and what a time/memory trade-off means.

Re:I disagree with some of the list.

[jd]

Yes, in the HPC world, Fortran 90 and Fortran 95 are still significant players. If you use the Gnu compiler collection for Fortran, there's an addon - G95 - which I've found produces better results than the standard GFortran. For maths code, Fortran is at least equal to, if not superior to, C. (Did I really write that last statement? :) However, the market isn't growing relative to the growth of the IT market as a whole. It's not shrinking, either, which is what would happen if Fortran really were dead.

Partly due to the lack of really good Fortran compilers for Linux, and also partly due to modern CPUs being designed around many of the concepts of C, there are some areas I would expect to see Fortran but don't. FFTW, ATLAS, OIL and GSL are all based in C with maybe some hand-turned assembly.

Re:I disagree with some of the list.

[ppanon]

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, hyper-threaded 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.

Yeah, because applications like DBMSs don't deal with advanced programming techniques like multi-threading and locks to deal with large loads, they let the OS take care of that. Sure

The O/S can't split up a sequential workload into independent pieces that can be run by multiple cores. At best, processors do a small-grained version of this with super-scalar architectures, but that has limits due to significantly diminishing returns for the resources used.

If you run a lot of independent processes or threads then they can be load balanced on multiple cores. If you want to take advantage of the multi-core processors that are increasingly being the direction of processor hardware development, you're may have to get your hands dirty in the very programming skills you decry.

Any time you have a shared resource that must be accessed by multiple clients, the only way to optimize access to that resource is by minimizing the amount of time that resource is exclusively accessible by a single client. The O/S can handle that for resources it knows about, but it can't do it for the logical resources that an application may need to define.

The good news is that, nowadays, it's primarily the tool and general-purpose app designers that need to worry about it, and not so much the vertical market app designers that build on top of those tools. Just because the market has effectively "outsourced" those skills to some application vendors doesn't mean that they are dying. It does mean that you're likely to get some very poorly performing apps when you have systems which require those skills but few developers who understand when and why they are required.

Re:I disagree with some of the list.

[dlanod]

And if you consider IP to mean IPv4, then the US Government should be informed forthwith that its migration to IPv6 is "dead".

I must ask, why on earth would someone consider IP to only mean IPv4?

Re:I disagree with some of the list.

[Anonymous Coward]

I decided I would stick to Fortran for my research codes.

Wow, you use Fortran for cryptography?

Re:I disagree with some of the list.

[agristin]

"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."

You are conflating physical/layer2 with layer 3 which has the IP. Almost every transport you mentioned competes with Ethernet (not IP) and almost all of those transports can haul IPv4 or IPv6- because of how ubiquitous IP networks are.

FC and Infiniband can haul IP and be hauled by IP (encapsulation look into it).

Re:I disagree with some of the list.

[jd]

I did say pure parallel programming. There's a major distinction between that and merely sharing some data and a few resources. If you can name me one genuinely parallel database in existance - Oracle RAC doesn't qualify - then you may have a point. However, I don't think you can because you're confusing pure parallelism with resource sharing, load balancing and other such stuff.

So what makes something "pure"? It's probably easier to say what it isn't, initially. It isn't about locks. You can write MPP applications that have no locks and yet are totally reliable and coherent. It isn't about shared resources - most resources are sequential by nature, sharing them doesn't change that.

Ok, so when is something "purely" parallel? After all, when you break any application down far enough, it becomes serial. A pure parallel program is one in which there is a clean break between what is parallel and what is sequential. The two are not mixed, there is no hybridization, there is no bastardization, it's pure. There is also exactly one break. On one side, code is parallel and only parallel. On the other side, code is sequential and only sequential. Above all else, a purely parallel program cannot be sequentially coherent from a programmatic standpoint, ONLY from an end-user's standpoint.

Now we get to the OS. Can an OS parallelize? Yes. Automatic parallelizing by OS', in which nominally sequential code is parallelized by the OS on the application's behalf, has existed since the 90s. It's not a big deal any more. This isn't merely about splitting up the odd instruction here or syscall there. We're talking genuine parallelization.

Perhaps more common, though, are parallelizing compilers. These take nominally sequential code and - as part of basic optimization - convert the output into a highly parallelized binary. The earliest compilers I know of that did this were research compilers at my old University, back in 1974. Earlier examples probably exist. These days, many people use message passing libraries and/or OpenMP, but those produce generally inferior code. True parallel optimization has no markup in the code and requires no heavy layering of libraries.

But what of parallel programmers? People who actually write parallel code? Name me one major application in Occam. Just one will do. No? Parlog? Parallel C? Hell, does anyone on Slashdot have UPC even installed on their machine, used or not? What about parallel environments - anyone here using OpenMOSIX or Kerrighed? I seem to remember a couple of folks who used Rocks. Out of the hundred thousand Slashdot readership. Impressive percentage.

Does anyone need to go to that level, though, these days? There are plenty of middleware layers that handle all that. Sure there are. But then you're no longer talking a purely parallel environment, as most of the middleware layers are designed to make things easy, not parallel. Many are sequential (violating the strict two-layer model required for pure parallelism) and many are nothing more than complex wrappers that hide the very parallelism they supposedly promote. They are generally heavyweight - RPC has how many layers? And that's one of the lighter systems! - but offer nothing useful that a plain sockets call couldn't have done. Ok, they can convert data types. And how many hybrid 32-bit/64-bit or little-endian/big-endian clusters do you use on a regular basis?

The vertical app writers had better damn well worry about it. If you write sequential code on top of parallel code, you get marginal speedups. If you write parallel code on top of parallel code, you get giant speedups. Any programmer who writes inefficient code will produce inefficient results.

There is no good news in parallelism, there is however considerable despair and despondency as some trivial load-balancer gets sold as a parallel system (which it isn't), and ethernet-based clusters are touted as fast. (Multi-millisecond latencies just don't compare with 2.5-8 microsecond latencies of Myrinet or

Re:I disagree with some of the list.

[jd]

3D is huge-ish in the medical field (eg: reverse computed tomography), the aerospace industry (eg: CFDs), the military, some engineering disciplines and maybe with some architects. Except for military applications, it's generally static data that can be rotated in 3D, and the 3D is not great. You can forget the output of BMRT - as great as it is, nobody but nobody does that level of 3D in the real world. The (relatively) mediocre 3D of "Elephant's Dream" (which is still damn good) apparently took many, many months to render.

However, all the above fields combined count for some really tiny, insignificant percent of the whole IT industry. It's really cool stuff, sure. It's a great field to be in, if you can get the work - it pays some of the bigger bucks. Toolkits like VTk, OpenGL, OpenDX - or even older stuff like PHIGS - are a marvel to use. But as a market, it's barely breathing. SGI no longer do much graphics, the number of graphics card manufacturers has dwindled to next to nothing, updates to libraries are measured in years or decades, innovations are rare and inventions are all but non-existent.

In the same time as it took OpenGL to do a simple update, computers have moved from single processor, single core machines with dumb terminals to becoming superclusters equal to any modern mini-computer or even super-computer, busses have been replaced with multi-hostable switched networks, graphics cards rival their hosts in compute power, VIA was replaced with RDMA and SDP, internal bandwidth has reached 80 gigabits per second, LAN bandwidth has hit 60 gigabits per second (Infiniband, 10 gigabits per second for Ethernet - 100 Gb/s if you channel bond), and your average LAN party has better sound and video than a 1990s multiplex.

Why so long? Because it was hard? No, because it wasn't priority for anyone. If it had been priority, they'd have had the API finalized in a matter of days.

Re:I disagree with some of the list.

[ppanon]

By your narrow definition of pure parallel coding - like supercomputing itself - it always was, and always will be, a small niche market. An important one to be sure, but a very small one compared to the amount of business application and general purpose application development. And a shrinking one as well. There are whole classes of problems which would require, high-end supercomputers in the 70's and 80's which can be dealt with by modern-day general-purpose computers. Not very well admittedly, for some of the reasons you outline, but well enough that the price premium is no longer justifiable. And certainly there are new classes of problems that could be dealt with by the modern day equivalent, but grant and budget committees seems to be willing to wait until those can be tackled by more general purpose computers as well.

Re:I disagree with some of the list.

[jd]

Which is why it is important to use the addition of the term "pure", in this case. Yes, general-purpose computers can do most things adequately for most people. We use home computers that have x86-based processors, for the most part, because although they're trashy, they're good enough. We don't need a POWER6. We generally don't even need 16-way SMP systems using x86 processors - if you need a 16 processor system, a pile-of-pcs cluster or a grid are perfectly adequate and a fraction of the cost.

The "purist" systems are important, though. When doing medical or scientific 3D, the biggest complaint is that the networks aren't fast enough. You can't do the collective operations, the scatter/gather stuff, nearly fast enough to get the results these people want. This type of work is not CPU-bound, but IO-bound, and is the focus of a lot of attention as networking is where the big money is to be made - if you have a good solution.

Of course, this is about as interesting to Joe Average as a Pure Perl module. Joe Average wants to play Torcs, not brain surgery. Well, I hope, at least. Average systems are, well, for Joe Average, and do an OK job of it on the whole. It would be hard to imagine how one could improve on an average system significantly without adding in a huge overhead of cost, putting it out of reach of the average user. Of course, someone will imagine such an add-on eventually and get very rich from it, but I can't see that being me. Pity.

Non Ad Print Article

[Anonymous Coward]

Click Here

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.

Re:Yet more netware bashing...

[lgarner]

You're right, and when file & print was really the hot ticket, NetWare was it. It was, and arguably is, the best platform for those services.

Now it's 2007. How many networks are built exclusively for "file & print"? What about web services, databases, email, remote access, and other functions? What about custom vertical-market apps? Those are the areas where NetWare failed to keep up.

NetWare is far from gone, but demand for its skill set is nearly so.

Re:Yet more netware bashing...

[Anonymous Coward]

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.

I'm not sure what it matters when Netware was born. What matters today is not just five nines (or how old it is), but five nines running features that are useful to me. Great, it has a file server ... can it do anything else? Is it better at, say, J2EE than a Linux box?

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.

No, it's really not. Pretty much any version of Linux from the past 10 years will do fine.

Re:Yet more netware bashing...

[damn_registrars]

Good point

However, netware does remote access (at least since 5.0), does email (at least since 4.11), and has had a database interface for some time as well IIRC.

I think that part of what killed netware is how people seem to want to re-imagine the corporate network. Whats so bad about having your storage / print server separated from your web / database server? It seems like a logical division of labor (and a distribution of hardware) to me. From there, it doesn't seem like a bad idea to have your webserver and your file server running different OS'es as long as they can talk to each other.

After all, my snowthrower and my lawnmower look a fair amount different, but both run on gasoline and take up space in my garage. What's so bad about that?

Re:Yet more netware bashing...

[whereareweheadedto]

Netware 6.5 has MySQL, Apache, PHP, Perl support, java app server. It's a very reliable platform, but mostly for other Novell applications. Unfortunatelly it seems that Novell is incappable of marketing their products and most people think that Novell=Netware 3.1, 4.11, 5 etc. I am a Linux fan and almost zealot, but I work for Novell partner and seeing/installing/maintaining/using their other apps amazes me. They are good. Just not at marketing :/

Re:Yet more netware bashing...

[beerdini]

I've had a wonderful experience with netware over the years. Its a shame that many of the places that I've hear from migrate away from a perfectly functional netware environment because they purchase a new application that requires a windows server and suddenly the managers have to convert the entire network over to MS for compatibility because the sales rep convinced them that a mixed environment won't run correctly.

Re:Yet more netware bashing...

[rickb928]

Actually, I was running Apache/Perl/PHP/Tomcat on NetWare 5.0. The database threw me until I stole an Advantage engine (dBaseIII). But even before that, in 4.11, I was using BorderManager to enhance my home cable modem experience before you could buy a home firewall for less than $250. And when I moved to a place where cable hadn't brought Internet, I set up PPP and autodialed a 56k connection. Letting BorderManager kill Doubleclick and other ads was fun.

Novell got quite a reputation for *not* being an 'Internet company', even though it had directories, working DNS, and other 'Internet' features before Microsoft could ship them. Oh, and the true fun of connecting Mac clients since about NW 3.1. Other stuff like iFolder got lost in the shuffle. Even NetMail gets ignored. myrealbox.com has been delivering email as a test bed for Novell for a long time. The GroupWise web client wasn't as sad as OWA. GroupWise itself is kinda nice.

Heck, I can even mount a 2GB volume on NW2.15c. NT was pus up to SP4.

Novell lost when Microsoft gave developers a consistent programming model on the client and the server. No one wanted to learn the Novell way, even though the apps I did support on NetWare were largely stable and delivered five nines day in and day out.

And NetWare is so misunderstood that my first MCSE partner pointed out that his home 2000 server had been up for 350 days, and not many NetWare servers made that claim. Yah. Most of mine were over 450 days up, and some could only manage 999 days. Before the counter overflowed. And those were production servers, not the home box that did little or nothing.

The only things potentially more reliable than those old NetWare 3x servers were AS/400s. Now there's a technology that is *obso1337*. My brother has written a web-based support system for a world-wide sales force that works in industrial plants, onboard ships, and in hostile environments with bullets flying overhead and underneath. Connects via IP, SMS, GPRS. Adapts to a cell phone, PDA, laptop, or the borrowed Windows NT workstation the salesperson happens to be near. It's all on some IBM e-Series machine, mostly written in RPG with the necessary Websphere stuff. RPG of course being dead.

And he uses NO Java. Doesn't consider it very good. He renders all his pages with PHP.

ps- I use Notes all day at work. Oh, it's imperfect. But Exchange cannot replace the database and app features of Notes, no matter. You would need SQL Server and today some genuine .NET expertise. Anyone keep score of how many Fortune 500 companies use Notes as their messaging platform? And how many changed to Exchange at what ongoing cost?

One man's obsolescense is another's jus' working.... Whew. What a rant.

I miss NetWare, God help me.

Re:Yet more netware bashing...

[lgarner]

True, NW has come a long way. Then again, so has the competition.

I've run a payroll server, web server, database server (MySQL and Oracle). I also developed a custom app to take printed mainframe reports, separate them by client and publish them to the web server. Of course, Groupwise and BorderManager were the main apps.

Still, there are weaknesses. Protected memory isn't all that robust. I've found some of Novell's own apps to be somewhat flaky (Novonyx web server, specifically). NetWare's inability to easily connect to another NetWare server's volumes always seemed strange.

NW is also the only NOS that I can remember which required you to purchase a competitor's product in order to administer it. You can't manage a NetWare server from a NetWare server. Marketing has always been an issue for Novell, but marketing needs the technology to sell.

Raising the bar

[rumblin'rabbit]

It took me, what, two weeks to learn C by reading K&R? Maybe another two months to get comfortable with the pointers to structures of structures of pointers we used to use back then, and were later replaced (in C++) with classes and containers.

My point being that anyone who just learned C didn't set the bar all that high. It's like a landscape painter who only does sunsets.

Re:Raising the bar

[Anonymous Coward]

Noone learned C in 2 weeks, the learning begins when you finish your first read of K&R. You don't master pointers in 2 months either!

Having learned C, you can learn Java to good standard in few months and javascript in a week.

Re:Raising the bar

[Anonymous Coward]

You are far removed from reality. The ease of learning the basics of C doesn't make it less useful/powerful than more recent languages.

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.

Re:Raising the bar

[rumblin'rabbit]

I guess it depends on what you mean by "learn". I read K&R in a few days and was writing production code in C with reasonable fluency in two weeks.

I admit, thought, that I had previously learned (to various degrees of skill) Algol, Fortran, PL/C, PL/1, and Lisp. There was almost no idea in C that I hadn't met before. Just a variation on a theme.

And pointers weren't no big deal. If you can do Lisp, you can do pointers. Hell, you can do anything.

Re:Raising the bar

[rumblin'rabbit]

The ease of learning the basics of C doesn't make it less useful/powerful than more recent languages.

Well, its computationally equivalent to a Turing machine, if that's what you mean. But C++ is far superior even if you don't learn how to write classes, and there's little reason not to use it. The string class alone justifies its use.

Re:Raising the bar

[rumblin'rabbit]

Oh yeah, and Assembler. We had to do that too.

Re:Raising the bar

[geniusj]

It's all about D ;-).. Seriously, check it out..

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.

Re:Raising the bar

[LizardKing]

Why not just write a C string class? Or use an existing one like that found in glib? For stuff where I can't use GPL or even LGPL code, I wrote my own string class in C that has a similar API to the glib one. It took me all of a couple of hours, and includes a unit test that exercises each function. It removes the worry of memory leaks and buffer overruns from the vast majority of my C code that has tonhandle strings, all without the overhead of C++.

Re:Raising the bar

[Gotebe]

I respectfully disagree. C is enough for that. I, for one, couldn't grasp assembly well until I got hold of C. And couldn't grok C until I grok Pascal. Not very smart, am I? ;-) You need assembly to understand WTF the compiler is doing after you, though. And to get the big picture of small things in your processor.

Re:Raising the bar

[Weedlekin]

"Why not just write a C string class?"

Perhaps it's the fact that C hasn't got classes which is stopping him.

"Or use an existing one like that found in glib?"

There aren't any classes in glib because C doesn't support classes. This is why various supersets that add class support such as C++ and Objective-C were designed.

"I wrote my own string class in C that has a similar API to the glib one."

You're either a troll, or have been somehow isolated from everything that's been happening in programming over the last few decades, and therefore really don't know the difference between a class and a collection of functions. For your sake, I really do hope that it's the former.

"all without the overhead of C++"

I assume you're referring to overhead that adds important stuff for building _classes_ such as encapsulation, inheritance, and polymorphism, which C, through its virtue of having no direct support for _classes_, conveniently avoids.

Re:Raising the bar

[Doctor Faustus]

to understand pointers, or why they can come very handy, you should rather learn some theory about trees, lists and so on.
You don't need raw pointers to do that; object references will do fine. I've actually done AVL trees in Visual Basic 6.

Re:Raising the bar

[LizardKing]

Perhaps it's the fact that C hasn't got classes which is stopping him.

There aren't any classes in glib because C doesn't support classes. This is why various supersets that add class support such as C++ and Objective-C were designed.

Try reading the GObject, GLib and GTK+ documentation and you'll see what I mean by OOP in C, or even try Googling for "object oriented c". In short, a programming language doesn't have to have support at the "keyword level" to take advantage of OOP techniques.

You're either a troll, or have been somehow isolated from everything that's been happening in programming over the last few decades, and therefore really don't know the difference between a class and a collection of functions. For your sake, I really do hope that it's the former.

I assume you're referring to overhead that adds important stuff for building _classes_ such as encapsulation, inheritance, and polymorphism, which C, through its virtue of having no direct support for _classes_, conveniently avoids.

C++ and Objective-C simply added syntactic sugar to C in order to implement classes - which is ultimately just a way of describing behaviour and state better by combining functions (methods) and data (members). There two common conventions for doing this in C, the simplest involves just using a struct to store the data, prefixing functions with the class name and passing a pointer to the "instance" struct as the first function argument. The second convention extends this to include a "class" struct as well as an instance struct, and uses function pointers in the class struct. This is what early C++ compilers (actually preprocessors that emitted C code) often did. Inheritance can be accomplished in either convention by making the superclass the first member of the "derived" class or instance struct, and is often enhanced with macros for compile time type checking.

If you'd like to see a simpler example of OOP in C than Glib, I suggest taking a look at an image metadata parser I wrote (http://www.chriswareham.demon.co.uk/software/iimp arser.html).

Re:Raising the bar

[Weedlekin]

"Try reading the GObject, GLib and GTK+ documentation and you'll see what I mean by OOP in C, or even try Googling for "object oriented c"."

I wrote nothing whatsoever about OO or C in general, but deliberately restricted my responses to classes, which as I said, C does not have. The rest of your comments are therefore a straw man.

Re:Raising the bar

[LizardKing]

Oh fuck off you pedant. If we were to take your insistence on not calling a duck a duck, then we wouldn't be able to call a function a function - after all it's just syntactic sugar that really hides a machine instruction that modifies the program counter. Oh shit, I better not call it a program counter seeing as on some processors that's just a convention not even described in the accompanying documentation. In other words, get over it - a class can be modelled in C and it's still a sight more elegant than it is in some hack like Perl that supports classes "natively".

Re:Raising the bar

[Weedlekin]

"Oh fuck off you pedant."

Temper tantrums probably work at getting your mother to buy you a chocolate bar, but they're an extremely poor debating tactic.

"If we were to take your insistence on not calling a duck a duck"

It seems to be you who insists on calling an amoeba a duck because ducks are made of cells, so they're just amoebas with some "syntactic sugar".

"a class can be modelled in C and it's still a sight more elegant than it is in some hack like Perl that supports classes "natively"

I didn't claim that any Turing-complete programming language couldn't be used to model anything given sufficient effort, and mentioned no languages other than C and C++. So we have yet more straw men, although at least this time they're liberally laced with entertainingly petulant and profanity-strewn tantrums.

Alternative title suggestion

[Anonymous Coward]

Top 10 most valuable skills for freelancers.

I think you made a mistake...

[Necreia]

...a paid VB programmer is overpaid .

Re:I think you made a mistake...

[LunaticTippy]

VB.NET is pretty powerful and you can get a complex app done quickly. What are your complaints about VB?

I used to hate vb back when there were very good reasons (1993) but have learned to be more tolerant. Now I'm well paid and part of my duties are performed in VB.NET, both maintaining legacy code and (gasp!) writing new applications.

Basically (heh) I think there are a lot of good languages and IDEs out there. As long as I have a code-aware editor, integrated debugger, and help for function/class definitions and whatnot I can write solid code in any environment.

Why go through life with one hand tied behind your back?

qmail not there??

[myowntrueself]

Can we please, *please* make this a list of eleven and add qmail?

Please?

Re:qmail not there??

[Etcetera]

Nope! =)

qmail is still out there, living and breathing quite well thank you very much (no thanks to its creator, though -- I'll grant you that).

qmail+vpopmail+mysql lets us handle hundreds of simultaneous connections on hardware I could probably only barely give away now -- better to use it for parts.

It's arcane, but it's keeping up with everything else out there as long as you're comfortable assembling the parts yourself.

Re:qmail not there??

[Anonymous Coward]

Not trying to troll or anything, but... Nope, I still run it on my old hardware off my DSL line for personal email. So granted, I'm not a "mainstream" mailserver-user. But I chose qmail+vpopmail+mysql+Courier-IMAP a few years ago when I set up my server, and when I recently upgraded, I saw no compelling reason to switch. Why learn something new when the old thing works?

There are also plenty of recent patches and addons to keep it alive, like qmail-spp. I'm sure there are people who hate the idea of so many patches and addons, but I like it because it gives me lots of flexibility to attempt to combat spam and such.

Re:qmail not there??

[myowntrueself]

There are also plenty of recent patches and addons to keep it alive

The problem is that the code is so quirky (being charitable there) and the third-party patches are not exactly regression-tested against one another...

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!"

Re:Then Pay the Market Wage

[Anonymous Coward]

The other side of that issue is, adding features or redoing this to do other stuff will only get us X. Trying to pay more for a worker than they would actually bring in wouldn't be tolerated for long.

That isn't much of a problem

[Anonymous Coward]

The tools are a lot better. I used to optimize code for DSPs by hand. That just doesn't work any more. I don't know anyone who can do a better job than the tools.

Given that the chips are cheaper and more powerful, it is pretty rare to find a case where it pays to spend the extra engineering time fooling around with assembler.

On the other hand, C is still the lingua franca in the embedded world. Maybe that will change but C has the advantage that almost any chip has a C comiler. So, to get the advantages of C, everyone would have to agree to use some other common language.

Not growing != dead

[gmuslera]

Probably what those skills dont have is future, in the sense of new companies/developments probably will not be based on them. But still there are working plenty of things that require those skills and must keep being maintained, adapted, or even grow a bit all around. IF you got those skills and are already working on one of such legacy systems, then while they last your skills will even worth more. But if not, better to learn something newer.

Also, I learnt a lot of things based on i.e. programming languages that are long dead and buried by now (like modula/pascal). But not only learnt a particular language, learnt to program, and also to learn. That skill, behind whatever technology is the current implementation, last forever.

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

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

[the_greywolf]

Get back in that coffin, you!

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

[Anonymous Coward]

FWIW, we were taught FORTRAN at university in 2004. I majored in Physics with a minor in Astrophysics.

Platform independent C too was a requirement, the lecturer would choose a complier and platform at random each week and if our code didn't compile and run correctly then we wouldn't get the grades.

We were also taught assembly on two different chips, to such an extent that by the end of our assembly course we could do it without thinking, and had covered more in a few weeks than the folk on the computer science degree programs did in the whole of their time at university - even if they took all the microprocessor and assembly language options available to them.

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

[Richard Steiner]

They are if you wanna work for an airline. :-)

Of course, finding one that will hire anyone at all might be more challenging these days...

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

[dbzero]

Don't you mean Real Admins did it in Edlin?

C is dead, long live C
#include <std.disclaimer>

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.

Simple DOS troubleshooting

[B5_geek]

Thanks to MS & backwards compatibility simple things like changing the mapping on lpt and com ports could still be done on modern computers. There are also wonderful things like ^M = C/R ^H = backspace ...etc... that you still need when in a jam.

counting in binary

[phrostie]

when i took courses in Assembly and 370 Machine language my dad taught me to count in binary on my fingers.

he used to tell me never to show my mom the 0100.

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.

Re:What? C?

[nuzak]

Ways when you can tell when Linus doesn't know what he's talking about:

• He uses words like "fundamental"
  
• He says things in ALL CAPS
  
• He does both
  

BeOS was a perfectly good OS written in C++, to name one.

What is NT?

[WillAffleckUW]

Is that some primitive form of OS/X?

Re:What is NT?

[damn_registrars]

I believe it to be
Neanderthal Technology

Re:What is NT?

[Anonymous Coward]

NT, the foundation for Windows XP. You know, the OS that has 90 something percent of the market.

If you stop playing with ToyOS 10.5, you might realise there's work to be done.

Re:What is NT?

[k3vlar]

John Hodgman, is that you?

Re:What is NT?

[swordgeek]

Nope. NT is a primitive of OS/2, which made the list ironically enough.

Re:What is NT?

[WillAffleckUW]

NT, the foundation for Windows XP. You know, the OS that has 90 something percent of the market.

Does it run on AMD 64 bit chips with true 64 bit instruction sets?

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

[innocent_white_lamb]

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.
 
That depends entirely on the job. A friend of mine has several people typing classified ads all day, and typing is pretty much all that they do. Listen to the answering machine messages, type the ads as the callers dictate them. Enter the caller's phone number, move to the next ad.
 
I'm sure there are many other data entry type jobs that are similar to the jobs that he has too.

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. ;-)

Re:Typing

[Avatar8]

Typing is definitely not a required skill for IT work, but it is a definite boost.

In one half a semester of high school I reached 80wpm w/o errors. I'd guess I'm still around 65-70wpm. Computers, of course, have allowed me to be lazy with quick backspace correction and especially auto-correct in some editors; however, I can typically see how much more efficient I am than my co-workers in regards to time spent typing.

Just the fact that I can input my passwords in two seconds where my co-workers take five to ten seconds shaves of a few minutes every day.

I can generate a 200 word e-mail in the same time most people type 50 words. More time saved.

Due to my speed I can type complete, grammatically correct sentences that gets my point across clearly the first time as opposed to short, choppy sentences that require multiple e-mails to clarify.

I have to record details of trouble tickets, so input of that data allows me to close tickets quicker, get on to the next job and never get questioned on "what I meant" in the work log.

If I were a developer (I script, but not heavily), I think typing would have more of an impact. Granted most code is already written somewhere and only needs to be copied and edited, but that editing goes quicker with good typing skills.

I've done my share of technical writing and system documentation. By all means being able to publish a paper in a day as opposed to a week is noticed by my manager.

When I'm not at work, my typing makes a huge difference for me in MMO's. Again getting the point across clearly and quickly makes a big difference. I despise l33t speak because I see it crippling the English language IMO. For that matter being able to move, cast spells and react without looking at the keyboard is a major advantage. Too bad I don't PvP. :-)

Necessary? Nah. A factor in efficiency, accuracy and ultimately doing an above average job noticed by supervisors? You bet.

Re:Typing

[WuphonsReach]

In my experience, accurate typing requires two things:

- Concentration
- A good keyboard (and a responsive operating system)

A lot of my typing mistakes today are caused by a computer who's CPU is too busy with other tasks to pay attention to my input. (Yes, I'm looking forward to a dual-core laptop... and as much as I like the Tecra keyboard, I think I'll like the Thinkpad keyboard better.)

As for the concentration thing, I type more accurately when I pay attention to the order of the characters in the word. Rather then just letting my fingers attempt to type the word from memory. (And I've made about 4 mistakes while typing this text block. But since "backspace" is a lot faster then waiting for the typewriter to overwrite what I just wrote with correction tape, or waiting for correction fluid to dry, or digging for the typewriter eraser, mistakes aren't anywhere near as expensive.)

Re:Typing

[swordgeek]

Well to be precise about things, I taught myself to touch-type so I could write a story for a girl that I wanted to impress.

As for accurage, all I can say is that it's the most ironic and funny typo I've made in a long time. I'm rather proud of it, in fact.

ONLY C!

[ghostbar38]

Well, they men ONLY C programmers, people that doesn't know C++ as well, and that's true...

Change for changes sake

[minus9]

There are millions of systems written in COBOL which shove data into a database and drag it out again. There is no advantage in rewriting them. Porting them to another language isn't going to make those disks any faster. I really hope Netware keeps going as well, as shared storage there's not much that can claim anywhere near such reliability it just chugs away forever doing its job. Tech "journalists" don't seem to realise that storing and retrieving data is 90% of IT, it may not be terribly exciting but that's just the way it is.

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:experience

[nschubach]

Eh, they still use CF heavily where I work as well. When you get down to the component level, line for line you can't beat CF. I've moved away from Web Development into training software development, but the Web team is doing a ton of fast and neat things with CF. They focus on RAD Web development to meet the demands of an operation not related to web technology and from my experience, it's much quicker to develop a page in ColdFusion than ASP or PHP. For that, I commend CF. However, some of the syntax is a bit wonky, but it hasn't failed to do its task.

Re:experience

[hobo sapiens]

I'll agree. CF is good for what it is good for: quickly getting DB data onto the web.

It'll never be a robust web dev language like C# or PHP, despite all this talk about "enterprise level". CF is bad for that.

I write CF just about every day, and I like it when its used for what it was originally designed for. For high traffic apps, I avoid it. You are just asking to bring your server to its knees, especially now that it runs atop java. I mean, what, it wasn't slow enough and didn't eat enough RAM before? Anyway.

It comes down to this: use CF for what it's for. Need to make a quickie site that interacts with a DB? Need to make a reports site that interacts with several DBs? Great and great. Just don't use it for complex application logic. That's just stupid. But just the other day I was asked to churn out a totally new site for a new director who tapped my boss for something quick and dirty. Well, using CF I was able to make something that worked well, and was even pretty and usable (because writing CF code is easy and fast) within one normal workday of 7-8 hours. I don't think I would have done that as quickly with even PHP or ASP. That's a situation where you want to deliver something functional and professional quickly and don't need anything extremely scalable or robust, and for that CF is great.

The problem is that where I work (for a humongous telecommunications co) its the (myopic) company standard. It's either that or JSP. So you have to oversimplify things by using coldfusion, or overcomplicate things by using java. Sometimes I wonder if they push CF so hard (and frown upon .NET and LAMP) so that all the web devs are stuck working there and stay away from marketable skills? Just something that pops into my mind from time to time. I wonder how many other companies also use it for everything? Probably not many.

Re:experience

[mcvos]

C programmingy
Yes. Just try to tell it to the OSS community. Almost any cool piece of technology (most libraries) are coded in C.

Most Apache frameworks are actually in Java. I don't think I've seen a single line of, or reference to C code at ApacheCon.

Google is your friend...

[Anonymous Coward]

'learn cobol' returns about 994,000 results. Also, TFA mentions a U.S. college that will teach you.

Here's just one random link from the 1.7 million+ results of googling 'linux cobol', to get you started: http://www.freebyte.com/programming/cobol/

Re:Google is your friend...

[innocent_white_lamb]

And which of those 994,000 links would you recommend? Useful and accurate information ~= lots of links on Google, especially for what is apparently a niche subject like COBOL.

Thinking

[hcgpragt]

Nr 1 on the list... Knowing the computer.
I get the feeling that more and more systems are put together without ANYONE in the project knowing what it means on the machine level.
And then, at the last moment the project leader goes to an unlucky DBA and says something like : The project is finished, now you store it. And why is it so slow?

H
Are computer systems becoming to complex to think them through?

it's the perception of its importance that died

[Anonymous Coward]

Many recruiters who know squat about programming languages ask for the fictional "C/C++" language, or C++ alone, thinking C++ as a superset of C, even when offering jobs in those fields where you could be shot if you wrote a single line in C++ (device drivers, some embedded systems etc).

Yes, C is alive and kicking but the middlemen just don't know.

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

[UnknownSoldier]

> where you could be shot if you if you wrote a single line in C++ (device drivers, some embedded systems etc).

SO you use a poor language when a better one will do?! The 70's called. They want their language back.

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++ to get rid of the stupid "typedef struct" type declarations, and other C idioms such as implicit int, no proper bool support, limited variable declarations, etc. There is a reason C++ is popular with us game devs. It got rid of most of the brain-dead C assumptions and annoyances, and lets us have our performance along with code readability.

I'm currently working on an Open GL implementation for the Wii. I inherited some some old C code to use as a base, and it was an absolute mess and painful to read without basic C++ syntax, before I cleaned it up. Doing OOP in C stinks! Use C++ for a few years, then go back to C. You'll realize how many little things are improved.

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.

But I guess some people like being a masochist instead of using a newer language that helps the programmer express abstract and compact idioms.

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

[bytesex]

You must be young. Your tone is aggressive, contemptuous and you think you're the one and only standard the world should be held to. Keep it up. I'm sure you've got lots of friends. I hope you keep 'em when you get older.

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:it's the perception of its importance that died

[UnknownSoldier]

Ah, nothing like shooting the messenger and ignoring the message.

Here's a tip: your word of the day is: Ad hominem; come back when you are willing to engage in a civil conversation.

Cheers

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

[bytesex]

Civil ? 'The seventees called...' ? That's not being nice or civil to begin with. The tone of your post is generally contemptuous and self-righteous; there's nothing civil about it. That's why I said you were young. Young people have a tendency to forget that when engaging in conversation, not everybody around them can readily absorb a 'jackass' mode of dialogue. I'm sorry if I've offended you by calling you 'young'.

OpenVMS

[Anonymous Coward]

First let me say that I am 17, so I missed out on the "glory days" of VAXen and OpenVMS. That being said, I would have to say that this is the one operating system that has dropped the most in marketshare. It will almost never be deployed in new systems these days due to Alpha being dead and Itanium being both prohibitively expensive and sucking, however:

It is still in place in many many many systems, some of which are VMS clusters with 15+ years of uptime. Between its amazing stability and incredible ACL system, many of these clusters will stay in active usage (take for example, the ones controlling the Paris and Amsterdam metro lines). That being said, for an OS that was once omnipresent and known by almost everyone doing serious programming, right now I can very rarely find anyone with any OpenVMS administration/programming/use experience (and of course nobody my age)

Powerbuilder

[Chr0me]

Back at university they only offered certain classes every other term, Database Management being one of them. The semester I could actually take it they chose to teach using Powerbuilder. It was the way of the future or some crap. Needless to say they only used it that semester. I couldn't sell the book and have it to this day, 8+ years later, as a reminder to get the building blocks first and then specialize.

C won't die anytime soon

[ale_ryu]

C is like the marrow of computer programming, the fact that it's not being used as widely as before to write en user software doesn't mean the technology is no longer useful. It's the perfect programming language for many things and it will always be that way.
About Cobol on the list. I agree it's an old and rather anti practical language considering you have to write like 50 lines to print a single hello world on the screen, but there's a University in my city where it's still being taught as part of an asignature (I don't know wich one or what for).
I can't really comment about the other technologies because I never used any of them, I'm 20 years old and never had the chance to try them. But It's always a valuable thinh to have some knowledge of old technologies.
One thing I'd really like to see on that list is Shockwave/Flash technologies, I have serious issues with those.

::Ale::

Re:C won't die anytime soon

[swordgeek]

Glad to hear a 20 year old understanding just how critical C is. (You might be interested in getting a copy of Lion's Commentary, if you don't have it already.)

As for the list, well the list makes the mistake of talking about technologies rather than skills. Knowing C or Cobol or Pascal of PL/1 or Forth will eventually forsake you, but understanding how to program will be transferable to whatever new technology comes over the horizon.

DOS commands

[The13thMonkey]

Can't see the full list cos the site's been /.ed. But I'd be not very disappointed, though somewhat surprised if dos commands weren't on the list.
I sat in front of an (emulated) dos box the other day for a good minute or two while I tried to remember how to ls a directory. How easily we (well, me!) forget.

Re:DOS commands

[k3vlar]

Don't worry, you're not alone. My experience with computers started with the 'dir' command when I was about 12, and that was the last I ever used it. Now, whenever I have to use the command prompt under XP for god-knows what reason, I type 'ls' a few times before remembering...

Re:DOS commands

[multipartmixed]

> Now, whenever I have to use the command prompt under XP for
> god-knows what reason, I type 'ls' a few times before remembering...

I installed the Microsoft Services For UNIX one time, to see if it was useful.

I determined that it was not.

Then I typed 'ls' and it worked...

So I left it on.

Re:DOS commands

[Ritchie70]

At least you probably know what DOS is and how it isn't the same thing as the command line under Windows XP.

At work, we have around 70,000 DOS systems deployed across our company running POS. It took me a while to convince a young guy at one of our vendors that MS-DOS and Windows CMD.EXE are NOT the same thing.

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

[unixpro]

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

whois confirms it - Trolltalk is NOT dead ...

[Anonymous Coward]

t was bought 3 days ago:

   Domain Name: TROLLTALK.COM
   Registrar: TUCOWS INC.
   Whois Server: whois.tucows.com
   Referral URL: http://domainhelp.opensrs.net
   Name Server: NS1.EMPOWERINGMEDIA.NET
   Name Server: NS2.EMPOWERINGMEDIA.NET
   Name Server: NS3.EMPOWERINGMEDIA.NET
   Name Server: NS4.EMPOWERINGMEDIA.NET
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Updated Date: 21-may-2007
   Creation Date: 21-may-2007
   Expiration Date: 21-may-2008

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.

More interesting is what isn't on the list...

[SwellJoe]

One could have been working with Perl, UNIX, and Sendmail while cc:mail, ColdFusion, and NetWare were ruling the roost, and your skills would still be valid and valuable today. Actually, a lot of us probably were doing just that...

I dunno about you, but this tells me that relying on exclusively proprietary technologies is risky, at best. Not just from a business perspective, but from a personal development perspective, as well. So, IT guys are shooting themselves in the foot when they choose the latest new thing from Microsoft (Microsoft has built and killed numerous technologies during that same period...I'm surprised Visual Basic and FoxPro weren't on the list...they were bigger than several of the mentioned technologies and have fallen farther).

Wow

[adamofgreyskull]

No sarcasm here. What operating system do you use that wasn't written in C?
IHBT

Amateur's make me laugh.

[Anonymous Coward]

Name one other system that does everything that Notes does. And I mean everything. That is, support not just email with databases tacked on, but the same kind of extensibility, replication and failover support, multi-platform support (native Windows, OSX and Linux clients), 300,000+ user level scalability and directory integration that Notes has.

Exchange? Don't make me laugh.

Name one.

Yeah its easy to rag on Notes for poor UI design, but when it comes to an "enterprise wide" collaboration system, nothing else even comes close, whether you like it or not.

Re:Amateur's make me laugh.

[AbRASiON]

I work with notes all day long in a govt organisation and I can tell you know, as a PLAIN EMAIL CLIENT it's garbage, complete trash.

Yes it does some other stuff, no doubting it but as a pure email too, ugh.
I just wish we'd switch to outlook for people who don't give a shit about bloody quickplaces and what not.

Christ even Outlook with the Notes plugin but good lord that email client stinks.

Re:Amateur's make me laugh.

[Anonymous Coward]

Fine - it does everything & walk the dog. Except as an end user I really just want a good email solution, and occasionally a calender. Which lotus notes sucks at completely. And cross-platform? I've never gotten the linux client to work despite 10s of man hours of effort between myself and our sys admin - both competent linux people.

Our entire "enterprise" is built around Lotus and SAP and it's a goddamn miracle that anything gets done.

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.

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.

Re:Amateur's make me laugh.

[Anonymous Coward]

I worked for a large corporation like that as well. Our Notes Guru came straight from IBM, and he never had anything to say about Notes, ever. But he kept it running, nary a reboot, server crash, and he got everything to run smooth (not good, but it wasn't a pain), always knew the answers to the questions and always took time to help out. He came in and worked 14 hours on weekdays, and 6 to 10 hours on weekends (on salary!). I never understood how he became a Guru, or could stand to work that much.

Then I worked for IBM. Very few days I spent less than 14 hours at work. Including weekends.

Lotus Notes should die.

Re:Amateur's make me laugh.

[Avatar8]

There isn't one and you know why? Because thankfully the entire development, OS, application, network and infrastructure world realized that piling all of those functions into a single server-client application is poor design, too server intensive, too network intensive, too unstable and unwieldy.

Notes tries to be the end-all, be-all application: e-mail, database, collaboration, forms, newsgroups. It tries, it struggles and it does poorly.

Not everyone needs all those functions yet you have to open the same, bulky, system hogging client as everyone else. I worked at one (horrendous) organization where they tried to use all of Notes functionality. The Notes admins worked diligently to add features people wanted so the company ended up with this monstrous, multi-tentacled beast that slowly crawled its way onto everyones desktop any time it was started. (I won't mention names, but their initials are 'CSC.')

Most of us just wanted mail or contacts. Exchange/Outlook does this much more efficiently and quickly.

Some people wanted to access and share databases. SQL is rock solid, fast and quickly becoming the de facto database server.

Newsgroups? Please, even Outlook Express handles them better.

All the rest of Notes features ends up being file sharing, web browsing or collaboration that can all be done in many different ways simpler and quicker.

Scalable? Sure if you have no budget limit. When I was asked to configure and price out a Notes system and an Exchange system, I quickly discovered that you needed 4x the hardware for a Notes system than for an Exchange system for a given number of people. In essence you could buy four separate systems (mail, database, file, collaboration) for the price of one Notes system. Even then on these "equivalent" systems, Notes would perform much more slowly and crash more often.

There are reasons there is no single solution client: it's impossible to build such a thing to run quickly with stability, very few people need/want all those functions in one application and servers/networks function better when they distribute the workload.

I have the skills to be a Notes admin due to my experience, but I've passed on numerous job opportunities as soon as I see "Notes." No, thank you. Never again.

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.

Re:10 undead computer skills

[dargaud]

Funny, I read your list differently:

• some have been dead for 10 years (Pascal).
• Some have never been used for anything (Prolog).
• some have never worked (formal methods)
• and some have never even existed at all (pure functional programming) !!!

Take this as a troll if you have to, but I don't see examples around.

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.

Re:I'm more concerned with dead USER skills

[petes_PoV]

see the mouse? Press the RIGHT BUTTON

... and after 10 minutes of increasing frustration, ask if they're left-handed and/or have remapped the mouse buttons for convenience.

Oh and let's not forget that it's not pressing the button that starts the action, it's releasing it after the click.

"yes, after you've pressed it, release it again"

Re:I'm more concerned with dead USER skills

[Joe The Dragon]

it's not the users fault that windows hides some extensions by default make coolpic.jpg.exe look like coolpic.jpg

Re:I'm more concerned with dead USER skills

[crabpeople]

Despite the fact that I've told them a million times that they'll pretty much NEVER see a \ in a URL

But if your using windows, you constantly see \'s when working with the machine. In a business environment, many many links are \\SERVER\SHARE for instance. You want to try explaining the difference between a fileserver and a webserver to the average person?

Re:I'm more concerned with dead USER skills

[k3vlar]

Which is funny, since if windows hides the extensions anyways, why don't people suddenly think "Ooh! This one has .jpg on the end, and none of my other jpgs do! I wonder why?"

Seems it would be better to give the exe file an name like 'coolpic.exe' and give it a jpg icon/thumbnail. If extensions are hidden it will show as just 'coolpic', and if extensions are shown, the cat is out of the bag anyways. Problem is, users are stupid. Period.

Re:I'm more concerned with dead USER skills

[kindbud]

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.

No, the first browser that showed the URL sucked way more, because now we have to BRAND the goddamn domain name and trademark it and all the crap that came out of that. No, the Internet would be a much better place if URLs were zealously hidden from the user from the beginning. Apple was on the right track, but the horse was already out of the barn. Too late to close the door.

Re:I'm more concerned with dead USER skills

[techno-vampire]

4) the difference between \ and /

I used to run across this all the time when I did phone support for an ISP. The slash (AKA "forward slash") is the one under the question mark on your keyboard, the backslash is the other one. I'd also tell them, sometimes, "Slash is what you use for a fraction," although I once had an arrogant luser tell me, "I don't do fractions."

Re:I'm more concerned with dead USER skills

[swordgeek]

Wow!

You manage to show that your knowledge is both narrow and shallow at the same time.

"knowing what extensions are"

Extensions are nothing whatsoever to any half-assed operating system, which can read a header to find out the contents of a file. Oh, except Windows--I guess that's all you're familiar with.

"looking at the URL in the status bar before clicking on a link"

This is usually spoofed, whenever it's actually a bad idea to click on a link.

"knowing where downloaded files go"

This is an application and OS-specified location. It could be anywhere, and often is. Hardly fair to blame the users for inconsistent computer behaviour.

"the difference between \ and / ...these people saw a backslash ONCE in their lives while using DOS about twenty years ago"

Um...nope. They see backslashes all the time, in Windows share paths, in Windows file paths, and (as a subset), in URIs that are Windows file paths. file:\\\path\to\file.htm is pretty damned common in the Windows world. Apparently you aren't aware of this.

You don't like being an admin and having to deal with users? Then get the hell out of the field. The reality is this: computers are anti-intuitive, ubiquitous, and understood to be easy. If you can't live with those criteria, then GET THE HELL OUT! You're not helping anyone.

Re:I'm more concerned with dead USER skills

[sootman]

> Extensions are nothing whatsoever to any half-assed operating system, which can read a header to find out the contents of a file.

But USERS can't see headers. Metadata in a filename is a Good Thing.

> Oh, except Windows--I guess that's all you're familiar with.

15 years of DOS, Win, & Mac; 10 years of Linux. But nice try.

> This is usually spoofed, whenever it's actually a bad idea to click on a link.

A) There are plenty of bad links that aren't obscured by javascript, like phishing attempts viewed in webmail.
B) There are many problems that come with not knowing what you're clicking on:
- Clicking on a PDF that will take a while to load
- Knowing if a click will take you to a different domain or not.

> This is an application and OS-specified location.... It could be anywhere, and often is.

Bzzt, wrong. By default, every web browser on every platform will do exactly one of exactly two things:
A) Save the file to a basic location, like the Desktop or Documents folder
B) Prompt the user where to put the file--and again, the default location will be the Desktop or something similar. Knowing how to use 'Find' (and they'd know the name of the file they just got if they would have looked at the name in the status bar first) is also handy.

> They see backslashes all the time, in Windows share paths, in Windows file paths...

Most home users don't connect to servers. Most large companies give users computers with pre-mapped drives. I know this, because whenever I need to tell them to go anywhere else and try to explain how to map a network drive, it's clear that they've never right-clicked on 'my computer' to enter \\servername\share. And Windows, by default, doesn't show the path in the location box or the title bar. Apparently you aren't aware of this.

> You don't like being an admin and having to deal with users?
> Then get the hell out of the field.

I like helping people just fine. And I do it quite well. I just wish they'd learn a few more basics than just "click on the big E, W, or X."

> The reality is this: computers are anti-intuitive, ubiquitous, and understood to be easy.
> If you can't live with those criteria, then GET THE HELL OUT! You're not helping anyone.

I help people day in and day out. I know computers are complicated, which is why I give users plenty of leeway. Like I said, I just wish they had a bit more basic knowledge.

Re:I'm more concerned with dead USER skills

[macshit]

- 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?" This is usually followed by the question "Which one is slash?" God damn you, Paul Allen.

Whoa, the backslash is Paul Allen's fault?!?

I used to think of him as the kinder gentler MS founder, but, ...surely he's going to hell for that one...

Re:I'm more concerned with dead USER skills

[dbIII]

Another classic - filenames. I've seen users put asterisks, spaces and exclaimation marks in a single *nix filename and wonder why weird stuff happened. On windows systems they have named files *.*. On the same windows systems they have put in very long filenames and hit a 255 character limit in the path that a suprising number of programs still have. I you ask them to save an empty test file it will be "client division project date day.work.this .time.test!.dwg" while you stand behind them wondering why if they never learned how to type with both hands or at any sort of speed they are putting in so many letters.

The best thing however is those that forget their usernames - especially if it is their real name and extra points if they get someone else to make the call and you can't find out any details until you are on site. It's all trivial anyway - often people spend long periods of time to tell you how they feel about a problem before you get any information about the problem.

Example - Take angry phone call from subordinate under pressure from boss with problem - 10 minute call with no information other than it has something to do with a computer and refusals to find out more, drive for 45 minutes, 90 minutes waiting and being told by a receptionist how horrible computers are and how busy the client is becuase their computer is not working, 20 minutes getting told about how this problem makes a person feel, 1 second to press the CAPS LOCK key once you get to actually see the computer. If you don't get out quickly after that the embarrassment turns to anger and it's another half hour about how computers stir up emotions - and then attempts to get spyware ridden home computers fixed for free. That is why I mainly work with *nix systems - the users generally do not expect them to run on emotions and black magic. That said - have SCSI problems on a pile of stuff connected to a Sun - anyone have a black goat handy?

Re:I'm more concerned with dead USER skills

[swordgeek]

Well, this is a much more interesting and well considered post than your original. I still don't agree with much of it, but I have a lot more respect for who I'm disagreeing with. :-)

"But USERS can't see headers. Metadata in a filename is a Good Thing."

I've kicked this around for a LOT of years, and ultimately I disagree. Metadata should be (a) intrinsic to the file, and (b) interpreted by the computer, with the results presented to the user. Users should be told, "This is a dangerous file," not "this is a .pif" (or worse, and far more common, "this is .jpg" with a hidden extension, which misleads people with half a clue.)

"There are plenty of bad links that aren't obscured by javascript, like phishing attempts viewed in webmail."

Haven't actually come across those, so I'll take your word for it. Webmail is a fundamental mistake in my mind anyways, but that's a whole other discussion.

"Bzzt, wrong. By default, every web browser on every platform will do exactly one of exactly two things:"

You talk about web browsers, and that's still not entirely correct. First of all, IE and Firefox may save files in a different location by default. Secondly, Outlook will save it in a unique (and possibly different) spot, as will MS Office. Various add-on applications will save files in different locations. Ultimately not all of these things will be consistent in either location or interface, so the user ends up more confused.

"Most large companies give users computers with pre-mapped drives."
That's generally true, but I've had more Windows admins tell me over the years, "type the following to map a drive..."

I guess our experiences are different then. I see a lot of backslashes being thrown at corporate users, and have at a lot of big companies. The number of people I know who have had to manually map a drive and/or pull up a file in a web browser (something becoming more common as more programs ship 'documentation' as lazy crappy HTML docs) outnumbers the people who haven't by a factor of probably 20:1.

Fundamentally, I disagree. I'd like smarter users too, but I think the examples you picked tend to illustrate the problems with OS and interface design more than with stupid users.

Re:I'm more concerned with dead USER skills

[Anonymous Coward]

the question mark is the way to go, every clueless person knows how to ask a question.

Re:I'm more concerned with dead USER skills

[Anonymous Coward]

You might want to look into the book 'The Design of Everyday Things'. It highlights fundamental principles of how objects might ideally interface with humans. A lot of people blame themselves for common problems with the things they interact with on a day-to-day basis, when those problems could usually have been avoided by a better design from the outset. Another thing mentioned is that an interface will NEVER be perfect the first time. So what do we do about that in the world of computers where things are moving so rapidly? I'd say users aren't stupid, so much as they are ignorant and can't keep up with the rapid change in technology. But since that's more intrinsic to the problem than anything, there's no use in blaming users.

The guy that 'doesn't do fractions' might deserver a backhand or two, though :P

Re:I'm more concerned with dead USER skills

[sootman]

>>But USERS can't see headers. Metadata in a filename is a Good Thing.

> I've kicked this around for a LOT of years, and ultimately I disagree.

The thing about user-supplied metadata is that it shows the user what's important to the user. Some users only care about "images" versus "documents" (i.e., text), while others really care if they're looking at JPEGs, TIFFs, EPSs, GIFs, PNGs, etc etc etc. Why do so many users put the date into the filename? Because that's what's important to them. Yes, 'date created' and 'date modified' are stored automagically, but maybe NEITHER date matters--maybe a template was created on 1/1, most of the work was done on 1/2, and small revisions were made on several days following. Neither the creation date nor the modified date are what's important--the user will think of this as "The January 2 version" and that's what's important to them. (Besides, dates only show up in list/details view--some people actually like icon view. Or, on OS X, column view--the default.) And many times, a word is worth a thousand pictures--I can see (and sort by, and search by) the letters 'tif' or 'jpg' much more quickly and easily than I can do anything useful with a folder full of distinct icons. Text has magic inherent properties compared to images or metadata--it can be quickly and easily understood (and searched, sorted, and filtered) by both humans and machines. Mac may have popularized extensionless files but UNIX invented it--but then why are there .pl, .conf, .c, .h, etc etc etc files all over your typical UNIX filesystem? Because that's effing useful!!!!! And really, think about it: why do so many files (which would be named .exe in Windows) in the /bin/ folder lack extensions? Because they're in /bin/--which is effectively another kind of metadata!

One point I will REALLY agree with you on--computers SHOULD be smarter in looking at files. Especially Outlook variants, which just say "Attachments may damage your computer!" to every single attachment I have. I guess no one at MS ever read "the boy who cried wolf." ("You are attempting to read 'The Boy Who Cried Wolf'--Cancel or Allow?" :-) )

> You talk about web browsers, and that's still not entirely correct. First of all, IE and Firefox may save files in a different location by default.

No, I really think I'm right on this one. Clean installs on a virgin system: MSIE, Firefox, Safari, and Opera, on Win95-XP or Mac OS 7.5-10.4: 1 of 2 things happen: 1) the user is asked where to put the file, and the default options are the desktop or documents folder, or 2) the file is automatically saved to the default location, which is either the desktop or documents folder. If the user has changed them, they'll behave differently, but again, that's my point--if the user changed them, they should know what they did and where their files will go. And they should know how to get around in the 'save' dialog. Navigation should be a very basic skill. Even the dumbest person knows how to get around in their house and their neighborhood, and can get to school or work. Same thing on a computer: even if you just go to the same 2 or 3 places all the time, you should know how to get there; and if you get lost, how to right yourself by using landmarks--like the big 'desktop' and 'documents' icons in the left panel of just about any OS dialog. Discussing other apps is beyond the scope of this flamefest. :-)

> I've had more Windows admins tell me over the years, "type the following to map a drive..."

And having told many users that many times, you should see the blank stares I get.

> The number of people I know who have had to manually map a drive and/or pull up a file in a web browser...

Wow. You've got users who know that 'File -> Open' works in web browsers? :-) As for HTML help, that usuall

Wait, they're posters who specialize this much?

[Anonymous Coward]

"I may not be a guru in any one language but at least I won't be unemployed when that language dies out."

English.

Re:Wait, they're posters who specialize this much?

[Rakishi]

I'm bilingual (fluently) and have dual citizenship (one of which gives me EU citizenship as a bonus). I even have a residence and money in banks in both countries of citizenship. So yes, english is included in that statement.

Fixed it for you

[Anonymous Coward]

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

And any large perl program is quite incomprehensible even to the guy who wrote it. :)

Re:Fixed it for you

[alcourt]

That's because most perl coders never seem to learn top down design, instead slapping code down at random, wherever their cursor happens to be when they decide they need to add something.

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:I dare to disagree

[supersnail]

Question:- Which language is your operatings system written in ? answer C (if your box doesnt have IBM written on it.).
Q. What language is you JVM written in? A. C.
Q. What language is your langauge written in? -- A. C if you are using Python, Perl ,PHP, Ruby.

I think C will outlive all other computer languages in use today.

As for COBOL it is the long goodbye, the number of serious COBOL applications
has dwindled from millions to mere hundreds of thousands, and will probably be
overtaken by Java sometime in the next five years.
The main reason for the longlevity of COBOL -- it was the only language that could do fixed point arithmetic correctly -- will no longer true as C, C#, C++ Java et al. are finally going to get built in support
for decimal arithmatic sometime this year.

And SNA I will miss you, those "bits 17 - 21 represent " those wonderful 15 hex digit parameters where
every bit was significant, the "default to the last value used" syntax.

Re:I dare to disagree

[Doctor Faustus]

The main reason for the longlevity of COBOL -- it was the only language that could do fixed point arithmetic correctly -- will no longer true as C, C#, C++ Java et al. are finally going to get built in support for decimal arithmatic sometime this year.
I got a job in 1997 (straight out of dropping out of college) maintaining old MS QuickBasic programs. QuickBasic (or at least the last professional version, which I was using) has a Currency type, which was a 64 bit integer offset by 10000. I believe all versions of classic VB had this as well, and I know for a fact that VB5 and VB6 do.

Of course, how many complaints have you heard about VB being the new COBOL?

Re:I dare to disagree

[Doctor Faustus]

C is probably not going to last. But its successors, C++ and C#, will.
C# is an application language that happens to look like C, just like Java.

I really would like to see a systems programming language sometime that didn't have C's nasty cryptic syntax. I realize a lot of people like that syntax, and I'm not saying they're wrong, but more than one choice would be nice.

Re:I dare to disagree

[JesterXXV]

I think it's completely erroneous to name C# as a direct successor of C. IMHO, it descends from other managed object-oriented languages like Java and Python (and borrowing from lots of other languages as well). It's C-like in name only. Plus it has curly braces, I guess. C++ was more of a syntax extension to C, whereas C# is a different paradigm altogether. Back on topic, C is not going anywhere. C++ may die out as memory management becomes less critical, but C will always be needed as long as low-level hardware control is needed.

Re:I dare to disagree

[TheRaven64]

The Squeak VM is written in Smalltalk. There is a subset of the language that can be compiled to run outside the VM, and the core of the VM is written in this subset, with the compiler and the rest of the VM being written in the full language. I'd be astonished if other languages didn't go this route. I know the Java compiler is written in Java, but I'm not sure about the JVM. Most Common Lisp implementations are written in Lisp.

Re:I dare to disagree

[TheRaven64]

A strongly-typed variant of Smalltalk might be a nice systems language. There are a couple of efforts to run Squeak on bare hardware, with a tiny bit of bootstrapping code written in assembly.

I'd also be interested in something Erlang-derived for systems. In addition to the parallelism inherent in the language, it has the best syntax I've seen for manipulating binary structures.

Re:I dare to disagree

[WuphonsReach]

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.

I think that pretty much nails it.

"C" is very much a general purpose language that runs close to the metal and gives you all the ammo to shoot yourself in the foot.

Languages like COBOL, Pascal, PowerBuilder, CA-Clipper, Fortran are all much more niche languages. They make some very strong assumptions about the problem domain and are very suited for coding solutions in those problem domains.

That is, until the world moves on, and languages like CA-Clipper / DBaseIII / DBase IV start to look very dated. Because they only solved a small portion of a problem and don't integrate well with other software stacks.

link!

[Anonymous Coward]

link because a /. thread with no no-ads link is like a fish without wings

You have to admit-humans are obsolete.

[Anonymous Coward]

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

Try doing it in Forth.

What about Pascal

[ClaraBow]

Does anybody use it anymore? I learned it in high school and now I don't hear much about it. I know that Mac OS classic used it, but that is about it.

C dying for CS, maybe...

[A440Hz]

... but not for engineering. C may be dying for the computing world at large, what with so much OOP stuff out there. But for embedded systems, there are TONS of legacy and even new pieces of code running in C. It seems that for a lot of small-run processors (which I typically work on-- DSPs, mostly), there aren't a) a lot of people writing C++ compilers for the silicon and b) there aren't a lot of developers crying out for object-oriented solutions.

We're quite content with banging out good old C, and of course, for the occasional tight, oft-used loop, it's optimized via assembly. We embedded programmers don't typically want a lot of overhead and data abstraction and such in our code; I've done some C++, and I haven't minded it, but we need visibility into the nuts and bolts of what's going on down on the metal, and C++ just adds a lot of stuff that gets in the way. And yes, I know that C++ can be made to be very C-like, but why bother?

Every processor that I've used that is using a high-level compiler at all is using C. I'll have good job security for the forseeable future knowing how to program DSPs using C and assembly.

PL/I!

[R3d M3rcury]

I still have PL/I on my resume, but I haven't seen a PL/I job in 25 years. Not that I've looked for a PL/I job in 25 years...

I leave it there mostly for laughs.

Re:PL/I!

[Ph33r th3 g(O)at]

I'd be afraid that putting it out there would date me -- it's not like age is an asset for programming jobs.

Re:GoogleFIGHT is your friend...

[Anonymous Coward]

1. C:2,790,000,000 results
2. cobol: 9,260,000 results

Round 2: assembly vs fortran http://www.googlefight.com/index.php?lang=en_GB&wo rd1=assembly&word2=fortran

1. assembly:188,000,000 results
2. fortran:17,200,000 results

Round 3:goat.cx vs tubgirl ... http://www.googlefight.com/index.php?lang=en_GB&wo rd1=goat.cx&word2=tubgirl

1. goat.cx:10,900 results
2. tubgirl:137,000 results

Round 4: porn vs. spam http://www.googlefight.com/index.php?lang=en_GB&wo rd1=porn&word2=spam

1. porn: 101,000,000 results
2. spam: 231,000,000 results

Round 5: windows vs open source: http://www.googlefight.com/index.php?lang=en_GB&wo rd1=windows&word2=open+source

1. windows: 561,000,000 results
2. open source: 713,000,000 results

There - everything you need to know about the intarweb!

9. PC network administrators ?!?!

[newdsfornerds]

Are they joking? I'm a unix/linux guy and when I go job hunting "sys admin" and "network admin" mean WINDOWS. This reporter and his editor are not living on the same planet as me. There are 20 Windows LAN/Desktop/sysadmin jobs for every ONE *nix job. Sheesh. All they had to do is look at craigslist.

One language....

[Savage-Rabbit]

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. I agree. Basically any programmer who only knows one language is in trouble and I don't care what the language is or how fashionable it is at the moment. Excessive specialization is professonal death, you have to keep learning all the time and soak up new technologies and languages as they appear. C developers are almost guaranteed to be proficient at C++ at the very least and they shouldn't have any real trouble moving on to programming in Java as long as they have done some Object Oriented C++ development. People who have avoided OOP and used C++ only for procedural programming will find the transition to Java or C# harder. I also agree that C programming (and programming in Assembly for that matter) isn't going to die out any time soon. It may be getting less common but C is still the language of choice for anybody who wants to write lean and fast code that can't afford any bloat.

Re:One language....

[Frank T. Lofaro Jr.]

Linux clean and fast without any bloat?

Yeah, just like Windows NT.

Ha ha ha!

Re:One language....

[compro01]

Linux can be made clean and fast without any bloat

corrected that for you. it is quite easy to strip the kernel to the boards with the bare minimums of what you need. i have yet to find a way to do as such in windows.

I see a trend

[Joe U]

Cobol
cc:Mail
Coldfusion
C Programming
Certified Netware Engineers

Half of the list starts with the letter C. It's a Conspiracy, I think.

(I don't know where I'm going with this.)

Hacks are here to stay

[Opportunist]

The reason is the way code is created in a corporate environment.

First of all, documenting your code in a way someone else could use makes you obsolete. Job security is what people care about in corps, not the company. Then, working code could make you obsolete, too, while a hack means that you have to maintain and improve the code. As long as it's at least remotely to spec, you're fine.

Dying computer skills

[Anonymous Coward]

Allaires cold fusion started something really cool in the space back in the day. I still kind of like/use it. Its still around, has a cool name and I run into sites (Like Myspace) that run it every once in a while but its not popular. I cringe at the horrible parser codes they must have written to limit html enough to prevent hell itself from spawning from that site.

I honestly think the world can do better than php, asp, jsp, servlets...etc. CF was a *step* in the right direction but for some reason people to this day keep insisting on going down the wrong path. (Yes I know everything!!)

C programming... ??? Pretty much every last ounce of software I have ever used is written in C/C++ and they have the audacity to put this on the list. There are several very popular web platforms that are themselves written in C... Although hopefully the applications on top of those platforms are a wee bit higher level/abstracted. This fact should not magically detract from the language. Neither should the apparent saturation of 'programmers' working part time on one-off web sites/applications for their companies. Most of the worlds COTS software is written in these languages.

OS/2...sniff sniff... I loved OS/2. When the world was running "DOS windows" instead of "NT Windows" OS/2 rocked. I remember the full page WARP ads in time magazine. That was sooo cool.

PM Shell was awesome and PM asteriods and I even remember scrounging enough files from various service packs on IBMs FTP server to manually put togeather a working NFS client for free :) I hear its still used by banks/ATMs.

What replaces COBOL?

[Tablizer]

Sure, COBOL is dying, but what do you replace it with that has the same staying power and is geared toward big companies and financial apps? Java? Java is already considered outdated by some (for example, has a sloppy meta-model, goofy error taxonomy, and does not facilate non-OO coding very well).

Re:What replaces COBOL?

[jjohnson]

Without disagreeing with any of your comments about Java as a language, you're wrong: Java is indeed the replacement for Cobol.

embedded

[www.sorehands.com]

I had a phone interview with a company that built underwater seismic monitors. They would run on battery and every so often be pulled up from the bottom of the sea, data downloaded, and a new battery installed.

This would spin-up a hard drive when ram disk ran out of space. Lets see you do this in C++ or Java.

This is a job for REAL PROGRAMMERS".

Re:embedded

[kbro]

Ok. I can write device drivers in Java. I will just need a virtual VM which supports Java device drivers ... something like Squawk http://research.sun.com/projects/dashboard.php?id= 155/

Re:embedded

[vivian]

well as C++ is a superset of C, I don't see what the problem would be...

Re:embedded

[Anonymous Coward]

I wonder what language Squawk is written in? Seems like the vast majority of Java developers, you've just added a totally pointless layer of abstraction between yourself and hardware that's mearly doing what you could do yourself.

Re:embedded

[www.sorehands.com]

It is called fat. You have quite a bit of overhead when it comes to handling the tables for the object abstractions. Don't get me wrong, I like some of those features, but it comes at a price. And of course, forget templates.

Re:embedded

[EsbenMoseHansen]

It is called fat. You have quite a bit of overhead when it comes to handling the tables for the object abstractions. Don't get me wrong, I like some of those features, but it comes at a price. And of course, forget templates.

You only pay for what you use (in C++). If you don't write "virtual" anywhere, there is no tables for object abstractions. Templates are free, in a certain sense, though their correct use in a highly constrained environment requires skill and thought

Still, I'd write device drivers in C, too. C is a much smaller language, and far more easily mapped into assembler. As I've said for years.. C is an excellent assembler. In fact, I know none better. C++ is an excellent general purpose language, especially suited for high-speed, complicated endeavours, like desktop environments (KDE), browsers (Firefox, Konqueror) and games (UT2004). It is not well suited for low-skilled application developers, though. It is a language that gives you a lot of rope... plenty to build whatever you need, and still hang yourself.

People saying C is dieing are pretty clueless. Or mean something else than the "not used for new stuff" that is usually meant.

Re:embedded

[Anonymous Coward]

that is only if you use dynamic polymorphism at the device driver level static polymorphism is typically used

Re:embedded

[qwijibo]

Java is not a totally pointless layer of abstraction. You can get hardware and operating system independence if you're careful. For many applications, it's much more important to have wider distribution than better performance. I've been a C programmer since the 80's and still write code in C occaisionally when I want something efficient. However, I find that the vast majority of the time I'm better off with something like Perl where I can glue a bunch of pieces together quickly to get something done. The days of being a C only programmer may be dead, but C itself is most certainly not.

Re:embedded

[TheRaven64]

No it isn't. Objective-C is a pure superset of C. C++ is a C-like language with a number of incompatibilities. Every valid C program is a valid Objective-C program, but there are valid C programs that are not valid C++ programs.

Re:embedded

[grub]

well as C++ is a superset of C, I don't see what the problem would be...

C++ is to C as Lung Cancer is to Lung.

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.

Re:I highly disagree with number 9!

[Opportunist]

I've seen both, so I can compare. I've seen clickmonkeys who can't even figure out why their DHCP server keeps assigning IPs they deemed static (because they happened to let them hand out IPs in the static range), and I've seen people who can route heavily heterogenous networks past each other without them interfering, while keeping you connected without a noticable interruption.

Like in every trade, there are fools and wizards. Unfortunately, HR people have a hard time discriminating between them.

Re:I highly disagree with number 9!

[Thumper_SVX]

I was about to post the same rant :)

Seriously, I would say demand for *good* network administrators is only going to increase because of server consolidation. Why?

OK, let me put it this way: How do you think server consolidation is done? It's not done by putting multiple applications on a server unless you're a serious masochist. The best practices with MS systems (and in fact I do this with UNIX systems as well) is to put one application per server OS. Note that I made that point; per OS. The simple fact is that in modern business there's HARDWARE consolidation going on thanks to virtualization. However, typically there is little consolidation of applications to a single host OS because of the fear of a single rogue app taking down multiple environments.

Ironically, due to the I/O constraints and slight performance hit of virtualization (not to mention the perceived "cheapness" of a non-hardware machine), this virtualization typically leads to server propogation. That is, where an application may once have used 4 servers, it may now use 5 (I see a 25% propogation for virtualized app environments where I work). This means that a good Windows admin will be in higher demand because there are more server INSTANCES than there would be if the "consolidation" had not taken place.

This is also completely ignoring where the perceived "cheapness" of the virtual machines leads to redundant application build-outs where none existed before. An application that was on one server sometimes gets two in a virtual environment because the amount of work of putting up a new instance is so small. The performance often has nothing to do with it because the application so under-utilized the hardware it was on originally that there's sometimes an increase in performance going to the virtualized environment.

This is good for the industry in my opinion. We also run virtual Linux boxes hosted on our Virtual Infrastructure clusters (VMWare). Sure, Linux' stability means we could run more than one app per instance... but why? Why not isolate the apps when you can throw up a virtual Linux box in about 10 minutes that has a kernel, basic user-mode tools and no GUI? Then load up your app and you've got a Linux box that can boot in 10 seconds flat and be rebooted without the users noticing an outage. Add in some redundancy on a second box and voila; you've just improved your end user's experience, made your application enterprise-ready, but also added to the server propogation I mentioned earlier. This is almost inevitable.

I see no reason this is going to change any time soon. The FA listed the canceling of Network Admin programs at schools as being the reason they see this going away. I call poppycock on that, too. The reason these classes are dying is because they were set up in the late 90's when "Network Admin" was a high-demand, high-pay career choice and suddenly everyone wanted to be in on the "wave of the future". Well, reality hit, the bubble burst and we ended up with a job market flooded by people calling themselves "Network Admins" who could barely tell you how binary related to a subnet mask (that's important to understand, by the way!) Now few people want to school in Network Administration, so these programs are getting canceled because of lack of demand. Now, it's been a few years since the dot-com crash... so most of the paper MCSEs and CNEs have weeded themselves out of the market. Those few who remain are gunning for management... and power to 'em.

Me? I'm a Systems Engineer, which is sort of a Network Admin on steroids but with no admin rights on the production networks. However, I have been a network admin and still do some work with many good (and some bad) ones. Demand for them is going to increase, not decrease. However, the days of massive salaries for those network admins has definitely come and gone... but good ones can earn a decent wage, and work in a job that can be incredibly rewarding... but only if one understands what the rewards MEAN. You'll only stick with the job if you're good enough to understand that you've made a difference... and how. Systems Engineering is the same.

Re:I highly disagree with number 9!

[Avatar8]

I think the term "PC Network Admin" from TFA is talking about workgroup networks as in less than 10 machines using NetBEUI or IPX/SPX to communicate where you have to set up user level permissions and such. A Network Admin on the other hand concentrates on the client-server relationships and issues.

I'm a System Administrator currently, but in a smaller company I'd be considered the Network Admin as well. I have my CCNA, but I don't consider myself nearly skilled enough to manage more than a handful of routers, firewalls, switches or heaven forbid, a Catalyst or similar network core. I had no inclination that TFA was talking about myself or people in similar occupations. I really think it referred to the workgroup level networking I mentioned.

BTW, for your retransmission issue, do you have a domain controller (DHCP/DNS) involved or only workstations attached to a router? Sounds like you are getting redundant queries that are looping back to the requester. You might try setting the primary DNS on your game system to the local host (127.0.0.1) and the secondary to your gateway or your ISPs primary name server. (This is typically only done for DNS servers.) PM me if you'd care to discuss it further. I had a similar issue setting up SBS 2003 (I know, yuck) for a small business I supported.

Re:I highly disagree with number 9!

[WuphonsReach]

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.

I just wish it paid better...

OTOH, by working for a small company, I only have about 1% of the bureaucratic nonsense that would occur in a larger company who could pay me a larger salary.

I've met the admins who can't find their way out of a paper bag. I have no problem taking their boss's money to fix what they screw up.

C doesn't belong. Period.

[kabdib]

C doesn't belong on the list. Period. I've been using it for (shriek!) 28 years and (as another poster said) it will probably outlast me.

As for PowerBuilder: -)spit(-. What a piece of garbage. Words fail me; I've heard that Arabic is a wonderful language in which to curse, and it might be worthwhile learning it just to express my utter contempt and disgust with that steaming pile of infected . . . (sputter).

Non-relational databases are an interesting one, because there are some amusing things you can do with tailored, high-performance databases (or likewise, embedded ones, where you don't have the horsepower or space for a relational engine).

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

Dead Skills Get Top Dollar

[grapeape]

Around here dead skills like AS400 experience, cobol, pascal and just about anything you think no one uses any longer seems to keep at least a couple of locals busy and making premium consulting pay. As their use becomes more scarce the companies that do still keep the dinosaurs around find it harder and harder to get good help. A friend of mine who had dropped out of IT six years go hopped back in when a company he had done contract work for back in the 90's decided they desperately needed help. They offered him a salary that was absolutely insane compared to what he was making as a teacher and gave him a generour "continuing education" allowance that is letting him get new skills that interest him.

Re:Dead Skills Get Top Dollar

[Shados]

The company I work for has old stuff built on top of Powerbuilder, and we have to pay premiums to a consulting firm to keep the stuff maintained, since the original developers are long gone now. Worse is, the developers of the consulting firm aren't even good at all, but its all we could find... so I can definately confirm what you're saying...

Huh?

[Centurix]

Nonrelational DBMS? Wouldn't that just be a DBMS?

Re:What? C?

[cmowire]

You only think that because BeOS didn't last long enough to get bitten in the ass by their decisions.

I'd love to write a new OS (in the large amounts of free time I have after job, artistic pursiuts, spending time with the wife, and having a living space that isn't disgusting) and I'd love to write it in C++. But writing an object-oriented API without a proper indirection layer to shield you from compiler ABI changes was just dumb. Haiku has to use old versions of gcc for that reason.

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.

I guess I'm getting old

[NSIM]

I had to do a COBOL project on 80 character punch cards in my first year at college, I think our lecturers did it as a form of aversion therapy, certainly worked for me.

I've programmed hierarchical databases (Intergraph had one of its own on VMS)

I've used non-IP networks (Ethernet-XNS again courtesy of Intergraph)

I've met the chief designer/CTO for ColdFusion who now hangs out in a Boston VC

C was the language most of my programming was done in, I actually wrote a GUI front-end to the UNIX man command that had a lot of the features of a crude HTML. I actually parsed the NROFF page to recognize NROFF tags and use them in a similar fashion to HTML, you click on bolded word and have it link you to a related man page. This was written in the late 80s, damn I wish I'd had a software patent :-)

I've never been certified anything, though there are some who suggested I should have been!

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.

diminishing but not dying

[Wansu]

C programmers certainly face diminishing prospects but there's a mighty big code base out there. I'm with the guy who posted about 30 year technologies. Unix, shell scripts and C have been mighty durable. I'm sure perl can be lumped in there. No, C isn't the hot skill that it was 20 years ago but there is still some work.

Another poster pointed out that most longtimers learn several languages. I've been thru Fortran (jcl), basic, C, unix shell(bourne, C, korn, bash), perl, java and now ruby. I've never thought it was all that hard to pick up something new. Just try to do something with it that you couldn't do easily with what you were using.

I suppose in the heyday of printed magazines, hyperbole sold copy. Today, it harvests mouse clicks.

My CNE is still valuable

[TodoRojo]

I got my CNE in 1995. I was a Novell employee at the time. Novell had just begun to see NT in its rear view mirror, but was in denial and didn't consider it much of a threat. I got it just before I left because I knew it would be valuable to me in IT management. It continues to be a tremendous help. I understand ethernet and networking concepts much better than most BS in CompSci grads.

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:Other dead skills

[Slashamatic]

At least one major retail bank in the UK depends upon assembler. A study has been done on the effort to replace it with modern technology and it was found to be not feasible due to the effort involved.

Re:Other dead skills

[Alioth]

If you have a washing machine, microwave or car, you probably use an 8-bit computer. 8 bit processors still sell in HUGE numbers which eclipse the volumes of Intel space heater chips that are sold. Zilog even still sell the 'classic' Z80 CPU, because it's still used for embedded computers. I have a Z80 CPU sitting on my table datestamped manufactured late 2006.

Re:Other dead skills

[Anonymous Coward]

Assembly language is very much alive and well, especially in the IBM mainframe arena. That's how I make my living.

Developers who don't understand the underlying machine architecture are just destined to create bloatware - and to learn the underlying architecture you need to learn assembly/machine language. And a great way to learn the architecture is to study the code created by whatever compiler you are using - whether it's C++, C, or even COBOL.

Re:Ha! C != performance

[WrongSizeGlass]

I seem to remember doing some work a few years back in 'Split-C' and 'Concurrent-C' too. They worked just fine for multi-processors back then so I can only imagine they'd be geared up and ready for multi-cores.

Kernel programmers?

[Anonymous Coward]

Yeah, we don't need those, and that's why they're all on their way to the unemployment line...

That's some pretty odd differing.

[Generic Player]

Differ doesn't usually mean "back up his argument with more anecdotal evidence". The fact that they can't find anyone to do it means its a dying skill. That (plus the fact that it would take for more than 100k to make anyone sane work with other people's CF messes) is why it now pays so well.

Cold Fusion

[c0rrupt0]

I know I cannot wait until this is dead. I always considered this a lazy(wo)mans development and never a serious one.

The big missing one...

[hamster_nz]

...is Serial Comms. I've just spent two hours hooking up a medical blood analyzer (speaking RS232 - and this is a brand new $$$$$ device). The customer had it completely FUBARed. The plug was wired wrong, the fly-lead only had 4 wires crimped, the serial port server was miss-configured....

How many IT people know what a DCE and DTE device is, how XON/XOF works, and how hardware handshaking works? Not many... if any.

Re:The big missing one...

[PigIronBob]

I do, ever wired up your centronics data lines to a bunch of Darlingtons to drive some big ars latching relays, bloody awesome. Aaah, the memories. He's a one trick pony, one trick is all our horse can do...

The problem is broader than just C ...

[GNUALMAFUERTE]

The dying skill is actually _having_ any skills.
Most companys want people that will go to college to learn windows and visual basic, install NT or Ubuntu, go next->next->done, follow some stupid howto to install webinterfaces to manage everything, and sit on their asses all day, producing nice colorful documents about their activities.

When things go wrong, their standard procedure is restart->restart->google->forums->reinstall.

_Real_ Coders and _Real_ Sysadmins seem to be obsolete in most places, and that just pisses me off incredibly.

Re:The problem is broader than just C ...

[Shados]

"Real coders" are obsolete because from a cost effectiveness point of view, where most of the "coding" gets done (businesses that are not directly related to IT), it is not very useful. The main problem in a business environment isn't getting the stuff CODED, its actually figuring out how the business work so you can manage and/or automate some of it. Thats a LOT harder than coding ever will be (in those environments at least...), and the amount of people who both have the skill to handle the business analysis and system architecture part of things AND code like a hardcode "hacker" (not in the blackhat sense), are so stupidly rare its not even worth mentionning.

So between people who can code like gods, but can understand why a business has priorities that might not make sense to your average IT guy, and someone with god-like business analysis and software development skill, but might not know how some low level things work, it is usually a smarter idea to go for the later.

Of course, there are the extremes. Ever heard someone tell you that most web servers are single threaded? I have >.>

They forgot the most dying one- the knowledge of

[$0.02]

BSD

Top ten dead or dying skills? How about...

[dgun]

1. Writing stupid lists for computer world magazine.
   
2. Publishing stupid lists for computer world magazine on spammy websites with tons of crap and pop-ups.

Re:Top ten dead or dying skills? How about...

[dgun]

Score:0, Troll

I hardly think it is my fault that the list was stupid and that the webpage the list was listed on was spammy. If it would have been a less than stupid list on a non-spamish website, I would have given it a better review. But being accused of trolling without getting the pleasure of having actually trolled.....that just makes me sad.:(

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".

Assembly language is as alive as ever

[walterbyrd]

I agree with everything else on your list.

Assembly language is one of those things that you use when have no other choice. And when you really program down to the bare metal, there is no other choice.

Even C will never fully replace assemble language. If assembler language were replacable, it would have been replaced decades ago.

Re:Assembly language is as alive as ever

[Anonymous Coward]

Not to forget that having assembly language skills is really nice to peek at what your compiler is doing. Invaluable when optimizing code.

The C dying point is just silly, as many systems right now are just glorified C virtual machines (UN*X or similar).

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.

COBOL Lives

[CypherOz]

Is the Mainframe (and COBOL) Dead? ... No way!

Mainframes can (and often do) run Java & Linux via ZAAP (Hardware JVM) and IFL (Hardware Integrated Facility for Linux).

System Z (the latest IBM marketing name) is the best platform for transactional processing bar none. (Check the independent TCO studies). !

Factoids...
"200 Billion lines of COBOL code in existence" eWeek!
"5 Billion lines of COBOL code added yearly" Bill Ulrich, TSG Inc.!
"Between 850K and 1.3 Million COBOL developers" IDC
"Majority of customer data still on mainframes" Computerworld
"Replacement costs $20 Trillion" eWeek
Researchers at Aberdeen Group recently found that about 70% of the world's business data is still processed by mainframe applications written in Cobol. According to Gartner Group, that number is closer to 75%.


Links...
http://www.arcati.com/dinomyth.pdf
http://www-03.ibm.com/systems/z/
http://www.computerworld.com.au/index.php?id=19147 25230&rid=-500


Note: Universities are reintroducing COBOL to their IT Courses due to growing demand. See: http://courseprofile.cqu.edu.au/profile.jsp?course id=16508

Life gets better for the COBOL, PL/I or Assembler code cutter, IBM now have Eclipse based tools for editing, debugging, etc. on the mainframe (Eclipse runs in Wintel or Linux Desktop and it connects to you mainframe resources via TCP/IP). The tool even lets you generate / edit / manage z/OS JCL and execute batch jobs etc. (WebSphere Developer for Z)

CICS transaction can be deployed as a Web Service at a click of a button, which means that the traditional transaction processing engine can be easily integrated into the latest SOA based business processes.

"Although most people are blissfully unaware of CICS, they probably make use of it several times a week, for almost every commercial electronic transaction they make. In the whole scheme of things, CICS is *much* more important the Microsoft Windows." Martin Cambell-Kelly, "From Airline Reservations to Sonic Hedgehog" (a History of the Software Industry), MIT Press 2003

"C" will survive until "D" comes along

[stabiesoft]

I expect "C" will be a predominant language until somebody comes up with a really friendly native multi-threaded language. The machine architecture is out of gas using single CPU's. To get higher performance, machines are moving to multiple CPU architectures. Alot of languages support this, but none seem to be very good at it. When somebody comes up with an easy to use multi-threaded language, then "D" will supplant "C" for the OS and alot of applications currently done on "C". My 2 cents

COBOL as a system language

[phunctor]

In about 1976 I was working at an IT installation where COBOL was the mandated only language. It so happened I needed a "diff" program, so I wrote one, in recursive COBOL. Of course, I had to manage the "call stack" myself.

So, COBOL *can* be a "system" language.

--
phunctor

Re:COBOL as a system language

[Opportunist]

And assembler can be an application language. But there are things that have no blessings by the gods of IT, and no programmer should touch them lest his sanity might be lost in the process.

Re:COBOL as a system language

[jedidiah]

Nah. If your architecture is sane (x86 doesn't qualify) then writing a whole app in assembler may not be so bad. On some of the 68K OSes, writting in a macro assembler wasn't that far removed from C. You had access to all the app level system calls and everything.

Re:COBOL as a system language

[Anonymous Coward]

Could you please provide examples of "sane architectures"?

I agree totally.... BUT

[EmbeddedJanitor]

Can I throw away my punch cards? Card punching is one skill I don't think I'll need any more.

C is as important now as it ever was, if not more so. We hear Moores Law blaah blaah, write everything in C# blaah blaah, but that's nuts. Sure PCs are getting more powerful and you can (almost) design a UI with a thread per pixel, but people forget that Moores Law is a wave you can ride both ways.

The obvious fact is that you get more gruntier computers so you can bloat up PC code without too many concerned people. However, the other factor is that small microcontrollers are getting cheaper. Less than 50c will buy you an 8MHz micro that can control appliances etc. You can program that in C, but bloatware won't fly.

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:I agree totally.... BUT

[honkycat]

It's not as bad as you make out...

What used to take 20 cycles now takes 4000 cycles, but those 4000 cycles happen in the same time as the 20 cycles. It's more like 20 old cycles now take 400 new cycles, but those 400 new cycles happen in the same time as 5 old cycles, so there's still a substantial performance improvement. This gives the best of both worlds -- a real world improvement in performance and a faster development cycle (less time spent on optimization).

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:I agree totally.... BUT

[Ihlosi]

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.

Get into embedded development if you're an efficiency fan. If you sell hardware+firmware, at several 10 kUnits (or even MUnits) per year, being able to use a $5.50 MCU instead of the $6 version that has twice the RAM is something that's worth investing several man-months in.

Re:I agree totally.... BUT

[Ed Avis]

Yes we should keep writing efficient code, just like Mel, the Real Programmer.

People were making the same argument twenty-five years ago, why write bloated and slow code that needs a fast 2MHz CPU to run it at an acceptable speed, can't we just make things optimized like the good old days?

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.

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

[adamjaskie]

The numbers 20 and 4000 were completely pulled out of my ass, in case you hadn't noticed ;)

Mainly what I have a problem with is that it took about two good-sized gulps of coffee for a web browser to open up on my old Pentium 100. Now, I have a 3.something GHz machine, running XP, and a web browser STILL takes two good-sized gulps of coffee to open. Either I am a lot faster at drinking coffee, or there hasn't really been a change in real-world application "snappiness" in ten years. Sure, photoshop filters run a lot faster, but why can't applications pop up nearly instantaneously? Remember how slow dialup was? I guess I was expecting a similar change in application startup speed and interface responsiveness. Things are a little faster, but hardly as much faster as it would seem they could be given how much more powerful our computers are these days. The computer may BE faster, but it doesn't FEEL faster.

Re:I agree totally.... BUT

[Money for Nothin']

You're right in that I should've made an exception for embedded devices.

But the nature of those devices is that they ship *lots* of units; the programmers for those projects have their product output (their code, not the device as a likely consumer-buyable unit) go to many times more people than most programmers do, since the majority of programming is done for in-house, internal purposes. Those tend to involve things like .NET or Java + {insert a half-dozen Java frameworks} web development, maintaining old mainframe software, maintaining MFC apps, writing new desktop apps in a few cases, etc...

And hence, one look at the job market indicates that there are a lot more jobs for non-embedded developers than embedded devs. Or, at least, that's true for Chicago...

Re:I agree totally.... BUT

[jedidiah]

That's funny. But I've spent most of my working life cleaning up after that attitude. The "well, machines are faster so we don't have to worry about resources" mentality might work for consumer computing. However, for more serious systems your data is always growing. Your budget is always constrained. Management always wants to do more. So you always go back to optimization.

Sure, machines are getting faster. Requirements are also getting more ambition and datasets are getting larger.

It's all mpeg2 vs. H.264 or some variant thereof.

Re:I agree totally.... BUT

[Wolfrider]

Niiiiice... ;-)

Even 10% on a 16-core could prolly still be optimized a little tho. (You start noticing these kinds of things whilst running vmware in the BG.)

Re:I agree totally.... BUT

[Lorkki]

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).

On the other hand, the more applications I run concurrently, the more resources are wasted by your lazy GUI code and the quicker I'll be wasting my time waiting for things to happen. Luckily, the slowdown hasn't really kept up with hardware development and I actually can run several applications concurrently, as opposed to the earlier days of the GUI.

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. :)

Re:I agree totally.... BUT

[TemporalBeing]

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...

That depends on how you do your calculation. If you compare the cost of the developer's time to write the application and optimize it, as well as the cost of the hardware, and running the hardware (space to keep it, electricity, wires to connect it all, etc.) I would be willing to bet (if I bet, which I don't) that it would over the life of the program come out no more expensive. The fact of the matter is that it costs money to run hardware - money for the electricity, money for the hardware itself, money to connect it all, and money to keep it someplace - and that adds up, and can add up very quickly.

So, compare this - if your application cost $3M to develop the "cheap" way, and cost $6M to develop the "expensive" way...but the cheap way requires that you have 20 computers to perform the same task load as 5 computers for the "expensive" way, what did you save? Nothing. In fact, on those numbers your "cheap" application will mean that you will have to have higher costs for the entire life of the application to run those 20 computers - and that will add up to a lot more than the $3M difference.

Now, if those 20 computers were identical to the 5 computers, the above would be even more true. (For reference in the following we'll notate those computers as "Z" computers.) Though you could also argue that (depending on the program) you might be able to get 5 "Y" computers that could do the load of the 20 "Z" computers, but then you hardware costs are still going to be higher than the original 5 "Z" computers and the costs to run those 5 "Y" computers would still be higher. So, in the end - it still costs more to actually run the "cheap" program than it does to run the "expensive" program.

So - no. The "hardware is cheaper" argument is not valid, and never will be.

Also, you are not guaranteed that computers tomorrow will be faster than computers today, even though that has historically been true. For example, dual core systems are using two slower cores to produce a single processor that performs as fast as a single faster core could to do the same workload. (Moore's Law is still upheld since it really applies to density of the circuitry not the speed. But programmers cannot count on speed increases.) The applications will not run as fast on those slower cores as they would on the faster core, yet the application programmers (especially .Net and Java programmers) are counting on faster processors (and faster cores) to make up for their slower programming environments. It just does not work.

Re:I agree totally.... BUT

[ShannaraFan]

There's definitely room for further improvement. The new dynamic management views in SQL 2005 expose so much valuable information on indexes and query plans, I'm finding all sorts of things that are non-optimal or just plain badly written. Still, the "old" production server hummed along at 70-80% CPU all day long, we're in an entirely new ballpark now.

Re:I agree totally.... BUT

[TheRaven64]

It's all about trade-offs. I can spend a day tightening and optimising code, or I can spend a day writing adding new features. If my code is using less than 10% of your CPU anyway, which are you going to prefer? Code that uses 5% of your CPU instead of 10%? Or code that has more features?

The other problem is debugging. I spent a whole day a couple of weeks ago tracking down a bug. It turned out that this bug was in some inline assembly, where I had passed the address of a value, instead of the value (I think. Maybe the other way around). In anything higher-level, I would have got an error, either at runtime or compile time, doing this. Because it was assembly (on an architecture which doesn't understand the difference between pointers and integers), there was no error, my code just failed a bit later. If I had written slightly less efficient code, I would have been able to spend that day adding features, instead of debugging. Debugging gets harder the bigger the project is, and the more optimised it is. If it is both big and tightly optimised, then bugs are almost impossible to track down. At some point, it's easier to just throw away the existing code and write something that's slightly slower, but a tenth of the size, and easier to work with.

Re:I agree totally.... BUT

[Anonymous Coward]

True, development can be expensive.

After said that, I've been paid by customer's a number times for the job of making a program or a system run faster despite the high-end hardware. And that's in actual industry, not just some obscure number crunching application.

And the sad fact is that without a complete rewrite of a program it can be really hard to overcome shortcomings of bad design.

Re:I agree totally.... BUT

[Money for Nothin']

The thing of it is though that hardware performance growth is outpacing the rate of growth in optimization discovery. Moore's Law has mostly continued to hold for a few decades now (though that may be changing), and its growth rate is 2n/24 (where n = number of transistors at some point in time).

Meanwhile, nobody (that I know of) has discovered a faster general-purpose sorting algorithm than QuickSort -- and that was published 1961. The low-hanging fruit has been picked in algorithm and compiler optimization (though in the latter, it's up to the compiler authors for whatever happens to be the hot new language of the half-decade to implement them).

The main question programmers should face regarding efficiency these days is not "how can I shave another 10% off this algorithm's run time". Except in real-time and embedded apps, nobody really gives a damn about that; if a user waits 0.22 sec instead of 0.2 sec for their Yahoo mail web page to be generated, management really does not give a flying f**k.

The question is more "which algorithm am I choosing, and why?" For better or worse, the margins of acceptable inefficiency have grown since the days of punchcard-operated mainframes... I mean, just look at Java... *cheap shot* Whether Java is as efficient as C++ (a claim I find unbelievable), it surely isn't as efficient as well-coded ASM. But where is the demand for ASM coders? Even on embedded devices, work is done in C, C++, or sometimes Java (although, not being an embedded dev, I'm sure there are still some forays into ASM too)...

Why do you suppose businesses don't pay very many ASM coders anymore? Whatever your views of business, one thing that's pretty universally-agreed-upon is that businesses are very good at doing things on a tight (often *too* tight) budget. Businesses are cheapskates: if it were cheaper to pay ASM programmers than Java programmers, businesses would do it. But they do not...

You are right though that the quantity of data is growing very rapidly too -- maybe faster than the rate of hardware performance growth, I don't know...

Re:I agree totally.... BUT

[Money for Nothin']

The fact of the matter is that it costs money to run hardware - money for the electricity, money for the hardware itself, money to connect it all, and money to keep it someplace

Equivlanet costs. These costs exist regardless of the hardware used.

Also, electricity is cheap (at least here in the midwest, at about $0.085/kWh for residential).

So, compare this - if your application cost $3M to develop the "cheap" way, and cost $6M to develop the "expensive" way...but the cheap way requires that you have 20 computers to perform the same task load as 5 computers for the "expensive" way, what did you save? Nothing. In fact, on those numbers your "cheap" application will mean that you will have to have higher costs for the entire life of the application to run those 20 computers - and that will add up to a lot more than the $3M difference.

At $8,000/host (last I checked - about 2 years ago - an IBM X-series 366 (IIRC, it's a quad-Xeon server w/ 4GBytes RAM) cost about this much), and with a difference of 15 hosts, that's a $120,000 difference.

Hence, for purchase price:
cheap ("hardware is cheaper") way = $3m + ($8,000 * 20) = $3,160,000, versus
expensive ("developers are cheaper") way = $6m + ($8,000 * 5) = $6,048,000

Inflate the hardware costs if you like to narrow the margin; you're looking at adding about $3m/15 marginal hosts = $200,000 per host to make up the difference. If you're buying hardware that expensive, and it's not a mainframe, then I have a bridge in Manhattan to sell you...

Add in electricity (figure each host uses 500watts):
marginal cost of 15 hosts for the cheap way = ($0.085/1000Whr) * 500w * 24 hours/day * 365 days/year = $372/host/year * 15 hosts = $5,584/year for 15 hosts. Figure on a 5 year support contract with the vendor, extending this cost to $27,922.

Add costs of storage:
Figure a sunk cost in an extra rack in the basement where space already exists. The server room guys will have to find a way to fit around the extra rack (where I work, this is a perfectly-reasonable assumption; we have hundreds of racks just in our headquarters)...

Hmm, so far, on the factors you mentioned, the marginal cost of 15 extra computers is $120,000 + $27,922 = about $127,922. Quite a bit less than $3m, I think.

So - no. The "hardware is cheaper" argument is not valid, and never will be.

By your own factors and some real-world price data I've assumed, the "hardware is cheaper" is not only valid, but grossly-so.

Also, you are not guaranteed that computers tomorrow will be faster than computers today, even though that has historically been true. For example, dual core systems are using two slower cores to produce a single processor that performs as fast as a single faster core could to do the same workload. (Moore's Law is still upheld since it really applies to density of the circuitry not the speed. But programmers cannot count on speed increases.) The applications will not run as fast on those slower cores as they would on the faster core, yet the application programmers (especially .Net and Java programmers) are counting on faster processors (and faster cores) to make up for their slower programming environments.

This is true; even Gordon Moore believes his own Moore's Law will fail to hold as we approach the atomic level of PCB lithography. That's part of the drive towards multi-core computing: if increasing the clock cycle is approaching a level of diminishing returns to engineering input/investment, then we start making our apps more distributed and decentralizable; make them run on multiple cores (hence, multi-threaded app dev, whether developers like it or not, is increasingly going to become de rigeur)...

It just does not work.

This assumes over some period of time that the following are true:

1) Har

Re:I agree totally.... BUT

[swilver]

There's one thing I've noticed about modern computers (Windows and Linux). None of them know how to properly manage the disk cache, and they will just keep increasing its size even at the expense of (background) programs. The end result is that when I get back to those background programs, they are sluggish because they're being swapped in. Why these programs deserve to be swapped out to disk so instead of 1.6 GB of disk cache Windows can use 1.7 GB of disk cache is totally beyond me -- eventually I got tired of it and I simply completely disabled swap -- what happens then is a miracle... every program is fast and responsive all the time, even if I hadn't touched it for days.

The worst part of this is though the total stupidity of how disk caching is handled -- a good example is what happens to your system when you watch a movie for 2 hours -- it thinks that (even though we're requesting video data at a rate of like 150 kB/sec) it would be a good idea to completely cache all of this data, to the point of swapping out everything else to disk. After watching your movie, you can make a new coffee before other programs become useable again. So I just keep swap turned off, it will have no choice but the use smaller disk caches and it will leave the stuff I choose to have running alone.

Re:I agree totally.... BUT

[swilver]

One other point I'd like to make, which may also affect your browsing experience, even though a lot of stuff has gotten faster and bigger, a lot of stuff is still about the same as 10 years ago. For example, 10 years ago, I was using a display not that much worse as the one I'm using now (1600x1200 vs 1280x960 then, both in 24 bit), if displays evolved like CPU's, I'd expect to be using a high resolution (300 dpi orso) 8000x6000 display or something by now.

Something similar goes for harddisks -- they still have roughly the same access time as 10 years ago (around 10 ms). Sure they have higher top speeds (10 MB/sec is now like 70 MB/sec) and larger capacity but they're still incredibly slow at loading lots of data from lots of different locations. So if firing up your browser means stuff needs to be loaded from disk, then it will be as slow as always. The only way to speed this up would be to have some intelligent caching (preloading stuff) or making sure everything browser related can be read in one huge chunk of data. I just never unload my browser (and I have swap off) so a new window opens instantly when I want it).

Re:I agree totally.... BUT

[Anonymous Coward]

I certainly try, but I know there are probably a 1,000 ways to do what I do, better.

You're in the right general direction (and I'd hope you'd pick up a copy of Code Complete and read it or have read it).

The cost-effective way to develop is:

1) Design it correctly
2) Code it in a simple manner
3) Profile it
4) Rewrite the portions that will give the biggest performance improvement

Now, implicit in #1 & #2 is making use of the correct algorithms and not doing anything super stupid. Such as using a bubble sort on a list with more then 100 (or 1000) members. Or doing more loops then are necessary.

But it's penny-wise pound-foolish to spend inordinate amounts of time in step #1 or #2 to come up with some super fancy algorithm that is complex, tedious, and difficult to code correctly. Especially for something that the user only does a few times per day and doesn't take more then 30 seconds to complete.

(And somewhere in the middle of all that lies the concepts of Computer Science.)

Re:I agree totally.... BUT

[TemporalBeing]

Add costs of storage: Figure a sunk cost in an extra rack in the basement where space already exists. The server room guys will have to find a way to fit around the extra rack (where I work, this is a perfectly-reasonable assumption; we have hundreds of racks just in our headquarters)...

Sure - if your business owns the property. A lot of businesses do not. If you are replacing an old system, then it may not be as much, but if you are putting in a new system, then you may have to get more space - and that is a monthly cost that can easily be at least a few thousand (depending on where you are - e.g. L.A vs. D.C. vs Johnstown PA).

This assumes over some period of time that the following are true:
1) Hardware engineers do not develop faster computing architectures and hardware
2) .NET and Java aren't improved in their execution efficiency
3) .NET and Java programmers are incapable of improving their skills

Actually:

1. #1 would mean that a new investment in hardware would have to occur, so another couple hundred thousand (using your numbers) for such a return.
2. #2 - efficiency may occur, but as a matter of fact they will always be slower than native code. That is an unchangeable principle.
3. #3 - they may improve their skills, but that doesn't mean the engine will improve.

What I presented simply shows that up front work is cheaper than long term costs to run because the up-front work brings an efficiency that works to its advantage over the long term.

they do pretty indisputably do a good job (generally) of cutting short-medium-term costs.

But usually at the cost of their long term costs and health.

What about async serial comms?

[dhammabum]

terminals, terminal servers, multiplexers, terminal printing, cabling, pinouts, handshaking - alot of knowledge there no longer is use (thanks be).

Not to mention coaxial ethernet...

An alternative Top 10

[Stochastism]

1. Communicating with people instead of machines
2. Commenting and documentation (actually, that's a computer people never had)
3. Coders that know how computers work
4. Coding to a limited memory budget
5. Using debuggers effectively
6. Coding fundamental data structures (like lists)
7. Figuring out computational complexity (why is it taking so long!)
8. Assembly level coding of critical routines
9. Coding/testing/debugging across a slow serial link
10. Reading other peoples code

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?

Re:my experiment

[Anonymous Coward]

java OR j2ee: 18621

c OR c++ OR c#: 18307

c - (c++ OR c#): 4995

Save your old computer books!

[Bushido Hacks]

It may seem silly to hold on to these old books, but trust me, when everyone has forgotten about C, Assembly, Fortran, COLBOL, TCP/IP, Lisp, or all the really really old languages, you can scare the hell out of people.

Hackers also use old languages to hone there skill on old networks. As wireless replaces wired networks, people will realize wireless networks are not that secure and are vunerable to EMP, sunspots, and range of access. When wired networks become important again, you can be ready when everyone else has forgotten.

Not everything that is obsolete is uesless.

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:not my experience

[EricWright]

Based on my limited experience from the mid-late 1990s (my physics PhD and others from my department, a couple math majors, and a few life sciences types I knew), the physical and mathematical sciences were strictly LaTeX, while the life sciences more often than not used Word. My thesis was a jumbled mass of hand-coded LaTeX.

C? COBOL?

[TheRealAnonymousCowa]

Two words that state just why C and COBOL are not dead.

Legacy Software.

Paris should be locked up for life...

[Anonymous Coward]

Is one of the reasons because she's too stupid to realize she's named after a boy?

Not to mention #11

[Reziac]

#11: Compiling BSD. ;)

Nothing I.T. lasts

[DeathElk]

I don't really have an opinion on the list as such, it seems my skill set is current. I do have an opinion however, about the long term value of ALL I.T. work.

I've been working in I.T. in varying capacities since 1987, and as an applications programmer/analyst since 1996. As far as I know, only two of the applications I have created early on in my programming career are actually still being used. The rest have been replaced due to change of functional requirements or business logic, system upgrades or expansions; and so on.

In theory, I can work 50 hour weeks for the greater portion of my life, producing product that will, in all probability, be worthless within years or decades of its creation.

Of course, these efforts are stepping stones in the path of product evolution, and of course, they generate wads of cash for myself and my employers. But I'll often view my neighbour; who is a builder and earns at least what I do; with a certain amount of envy, in that he leaves a tangible structure behind when he closes off a project, and that structure will probably still be there when he dies. Perhaps that's why I built my own house.

Re:What? C?

[scotch]

1992? I tried right an OS in c++ in 1970, bloody stupid idea!!!

User freindly systems are partly at fault

[xinjiang77]

When the programmers want to sell a product, the make it easier for the less-experienced. As system development has gotten more advanced, programmers are able to make critical processes that every computer user should know handled by other programs, instead of by manual input. Kind of like carrying a kid for the rest of his life and not teaching him to walk for the sake of him not getting exhausted. I have to agree with you.

Amazon.com ?

[BBCWatcher]

There are many, many COBOL books available on Amazon.com, including some very recent ones. I suggest reading through the customer reviews and picking up a couple or three to get started. There are some universities starting to provide distance learning in this area, by the way. Marist College comes to mind as one example.

But what about Ada?

[Bonobo_Unknown]

But what about Ada? Or is that just dead, rather than dying?

Re:But what about Ada?

[Matt_Bennett]

Generally, to refer to something as dead, it must have first been alive.

programming is cold?

[Anonymous Coward]

Uh huh. How many remember when the object oriented code revolution was going to eliminate the need for programmers because it would allow business people to just link objects together to easily write any application imaginable? This is why an adviser of mine in college told me to change majors since there won't be any jobs in computer science. That was 20 years ago. Good thing I didn't listen. I figured someone would have to write these objects, and I am pretty good at that.

This time, programming jobs will disappear because of magical elves "offshore" that are able to translate business logic into code despite not having 1) any idea what your business is or does and 2) any contextual experience with which to make reasonable rational decisions when the specification has a logic flaw. Oh, but by 2010, business specifications will have no logic flaws...probably because the people putting them together finally got their objects. The objects don't quite allow you to write your own application, but instead promise to automate spec writing. Right.

I don't know about you guys, but I am not worried. I am glad I have been around long enough that this stuff makes me laugh.

As for the dead and dying languages?

Assembly will never die, because some things just need to be that fast and that custom. A friend of mine writing missile guidance code at Raytheon comes to mind.

C will never die because we will always need device drivers. There are always more devices, ones we haven't even thought of yet. Some programs simply don't need classes. Yes, you could write it using classes, but why? Object oriented code for the sake of being object oriented is dumb. Device drivers don't need classes.

C++ will never die because it is so multi-purpose, it is a good bet when you're not sure exactly what your application requirements will be up front. Many applications evolve greatly from conception to completion. In such a case, having an ultra-flexible language is your friend. (by the way, writing a web application in C++ is far from impossible. It can even be straight forward and rewarding: see http://sourceforge.net/projects/witty/ )

Java will live a long life because there is a whole generation of programmers who think it is better than C++ because it doesn't have pointers and you don't have to worry about memory...until they grow up and discover that they actually want those things. But, with the breadth of the API's, the ever-improving JVM's and now generics and an embedded relational database (Derby)...ok, I admit, Java is ok. It is not what I would have invented, but not so bad. At least there is JNI.

Python, PHP, Ruby, Perl, Tcl, bash, ksh, et al are fun scripting languages that have their place. Some will survive, new ones will arrive. Who cares.

HTML,XML,Javascript - please, for the love of God, can't we all get together and kill this mess? Writing a web application should not be so cumbersome and limiting. We have all these great programming languages and API's allowing for beautiful, readable and self-documenting expression and for what 99% of world views our work through is this garbage? You can blame IE if you want, but Firefox has taken hold and it is ours. Let's change the world...wide web anyway.

C#, um, seriously? This I know: if you know one programming language and it is tied to a single non-standards based OS and a single type of application, you really need to learn a new one. No need to quit your job, just learn something new while you're picking up your paycheck. Visual Studio 2005 now actually has decent STL support. You don't even have to change IDE. The boss won't have any idea.

The rest will have their niche uses. We're smart people. We won't cry when their gone. I didn't cry after writing a kick-ass, cross-platform, thread-safe, database class that wrapped Sybase's ctlib only to see that product's market share disappear. Instead I learned not to tie a class interface to any particular vendor's

This list is dead wrong...

[Anonymous Coward]

for where I'm at.

I'm currently looking for new work, and while there is a ton of Java stuff out there, I'm still seeing a lot of requirements for Powerbuilder, COBOL, SNA, TokenRing and Novell. ColdFusion is still high on the list of the local web development agencies.

Of course, I'm in Iowa, so that may be the reason.

As for C dying off, forget it. C is a good, fast general purpose language. I've actually been seeing more of it requested (and not the visual c junk either) in the past year than for several years. Embedded systems, drivers, etc.

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.

Threads are just a figment of your imagination

[ClosedSource]

Seriously, threads are just an OS or VM abstraction. There are plenty of C-based high-performance embedded systems out there working fine. You don't need threads to take advantage of multi-core processors.

Lucky Last: C will outlive us all

[BillGatesLoveChild]

Out of every language there is today, C and Assembler will be around the longest. Why? Because there's not a programming task alive you can't tackle with this pair. Sure, there are faster ways (and Assembler is these days just a low level and embedded thing), but those faster ways come and go. If you want to write an application that will last, use C++. For performance, it can't be beaten. If you're doing high-performance graphics, VR, games, databases, your a brave soul not to use C++. Conversely, it makes more sense to whip out Ruby or Perl for a website. They'll be around for a bit. (Beware of using flavor of the month languages: Ever noticed how every 2 years MS tries to get everyone onto their 'next big thing'). Anyway: C has it's niche and it's not going anywhere.

C vs C++? A silly distinction given the class the author compared it with: They're the same bloody thing: C++ is a superset of C, and a natural path for any C programmer. Why the hell wouldn't you use it? It makes as much sense to point the finger at C and squeal 'burn her', as it does to point at Perl 5.7 and laugh at how it has totally been done in by Perl 5.8: "I searched on Monster and Perl 5.7 is a dead language! It's over. Bobby Willzammit on Gartner says 'It's history. There are no Perl 5.7 projects. The technology world has moved on. Those programmers better pick something else and learn it fast'"

Ahhhh, yeah. Those who can program do. Those who can't, become technology writers. Think we have to resist these "Top 10" lists for Slashdot. We read them because 10 points promises "Hey, no guff and blather, I'll cut straight to the point", but they're invariably inane.

Anyway: last word ---> C

COBOL Dying

[mwvdlee]

"COBOL dying"... where have I heard that before?

I don't know how the US is doing, but here in Europe, COBOL is still a highly paid skill. Mostly because COBOL requires some low-level knowledge that non of the Java kids seem to know. I'm actually a COBOL programmer that switched to Java for a while (and program in C/C++/PHP/etc. in my spare time) only to go back to COBOL again. In those years I've only seen the dependance on COBOL increase, and that is in a number of large, international financial institutions.
The outside world may proclaim COBOL dead, but the reality is still that more code exists in COBOL than any other language and that new systems are written in COBOL every day.
Based on my personal experience, it seems fair to say that every year we end up with more COBOL code, not less.
COBOL is by far an ideal language, but it has sheer mass behind it, and it's the de-facto standard on mainframes. Mainframes/COBOL serve a purpose not covered by other systems; it has far better performance than Java/C# and is easier than C/C++.

Re:IT is More Than Software

[BruceCage]

This discussion reminds me of a news report a saw a few months ago, from the Wikipedia article on telegraphy:

In the Netherlands, telegram operations ceased in 2004. On February 9, 2007, according to the online edition of the Telegraaf newspaper, the Netherlands national telecommunications company KPN pulled the plug on the last Telex machine in the Netherlands after having operated a Telex network since 1933. Citing the fact that they only had 200 customers for its Telex service remaining, it was decided that it was no longer worthwhile to continue to offer Telex within the Netherlands.

Great list except for C

[talledega500]

Popular? What does that have to do with the fact that every OS is written in it.
The internals dont change much over time.
Anyone who thinks their PC isnt running on C is a moron.
There is still a bit of Fortran in the Windows kernel though ;)

Re:IT is More Than Software

[jpatokal]

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.

And then you get IT vendors muscling into telco and trying to impose IT requirements there. For example, a certain large services company (I'll call 'em "HAL") with a new, fat contract to run a very, very large operator's system recently insisted that, on the giant production cluster that handles all their SMSes, the OS must be upgraded whenever any new patch comes out -- and we're still expected to maintain 99.999% reliability at the risk of draconian penalties. They're about to find out what "don't fix it if it ain't broken" means...

Cheers,
-j.

I agree with most of them except...

[BalkanBoy]

C. C is going to stick around for a while longer before it becomes obsolete. There will always be a need for super-optimized applications, that have to run 'close to the metal', and C is like one step above assembly language, nearly as efficient.

The only serious contender to replace it in real-time environments is probably Java RTS, but since I haven't played with Java RTS, I can't really say anything... and even if Java RTS takes off, in the end, it still is going to end up looking a lot like C, insofar that garbage collection can not be a part of it, which basically reverts Java to a C-like language, with predictable timing needed for real-time apps.... one of the major reasons Java spread like wildfire was the JVM's garbage collecting capability, which isn't necessarily (to the best of my knowledge) useful in soft/hard real-time envs.

If someone has experience with Java RTS, please share... I'm curious.

Thanks!

stupid list for stupid people

[Anonymous Coward]

Too many programmers--and other smelly technologists--are stupefying and stultifying bores who think that the facade they present to the world is somehow interesting, based on the fact that they don't have to use shovels to earn their filthy lucre. Not so.

Lisp is more interesting than C, by the way.

Ted K'zy

So, what are you going to write...

[Rix]

Your Java interpreters in? Certainly not Java. C may (or may not) become marginalized, but it's certainly not going away. You can only build stacks so high before you have to collapse them back down to lower level languages. Unless we reach the Age of Failed Dreams, we will always need C or something very much like it.

Re:So, what are you going to write...

[Max Littlemore]

Concurrent Befunge.

Blinded by ads

[oglueck]

Sorry, I couldn't find the article in that chaos of ads and popups.

Re:IT is More Than Software

[DerekLyons]

And then you get IT vendors muscling into telco and trying to impose IT requirements there.

More accurately you have "IT vendors muscling into telco and trying to impose IT religion". Most IT changes seem (to me) to be chasing that mythical +1% Language of Productivity or Magic Boots of One Extra Flashy Buzzword.

Re:Ha! C != performance

[damium]

Say that to entire highly parallel capable OS's written in C. Also, C has a nice, simple threading model, it's just not quite as nice as some of the others out there (python).

C will stay, but for limited purposes

[mcvos]

C/C++ will stay for quite some time indeed, but mostly for low-level stuff like drivers, OS and some other high-performance stuff that will always remain system-dependent. I think for applications, services and other high-level programming, C will die. The ease of maintainance and system-independence of Java and Python are advantages that C simply can't compete with. So C will stick around, but not for someone like me.

Re:C will stay, but for limited purposes

[Sobrique]

C remains popular, simply because there's a direct correlation between machine code instruction sets, and C. I think it'll stick around for precisely that reason.

I mean, your programs end up as machine code right at the bottom level. The chain of machine code -> assembly -> C -> higher level language I think remains as valid as it always did.

Re:Ha! C != performance

[delt0r]

the problem is a conceptual problem unrelated to language. QFT. There is a lot of slow C code out there. There is a lot of slow *pick a programming lang* out there. The oposite is also true.

Nonrelational DBMS? What about Object DBs?

[mcvos]

2. Nonrelational DBMS

The article only mentions the old non-relational databases from the '80s, but there are other non-relational databases. Due to the need to store objects in databases, object databases are gaining popularity. Most systems still use a relational database with an object-relational bridge, but that doesn't perform nearly as well as a dedicated object database. They're not dominating the database market yet, but it's definitely a useful skill to have.

Unix and C are dead!

[Rsriram]

The reports of death of unix and c are greatly exaggerated.

Yes, they do...

[demon driver]

Yes, they do. While systems are getting more complex faster and faster, we seem to have come from a "know one language, know them all" paradigm, which had some truth in it twenty years ago and earlier, to a situation in which you cannot even be thoroughly proficient throughout one single "language", like with Java, you even need to specialize in areas of it because it's become too complex a field.

And when your assignment changes, or when the next new big thing in software development comes, it's back to school again. The problem is, indeed, the more you're specialized, the less universally you're suited for jobs in case you need to apply. On a side note, that's why especially in IT it would get more and more important to insist that employers provide for one's further training...

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:BAH - 10 already-dead skills...

[Dwedit]

I'd disagree with you on #6. As long as Best Buy exists, there will be a need for home-crimped cables.

What about CORBA?

[atmelinside]

Once it was believed to be "next big thing". Haven't heard anything about it since then.

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...

Actually

[samael]

The percentage of coders who work on operating systems or games is actually pretty low...

Almost all coders are application developers (which means mostly C#, VB or Java) or web developers. No C needed for them.

Python threads suck for multicore.

[SanityInAnarchy]

There, I said it. Go get rid of the fucking GIL. It's 2007 already.

Or better, leave the GIL for third-party extensions, but make the Python core multithreaded when that particular Python app is multithreaded. Otherwise, there's really no point in using OS threads at all -- which is why we love things like Stackless, because if you're not going to support multicore anyway, green threads are the way to go.

What a cavalier attitude.

[jotaeleemeese]

No wonder most code nowadays is complete crap.

Right for the wrong reasons.

[SanityInAnarchy]

He's a troll, yes, but he has a point. C != performance.

I mean, sure, it's just about the best tradeoff we've got now. It's that sweet spot between things like Ruby/LISP/Erlang/etc and assembly. But it still sucks, really.

In fact, there are plenty of projects out there for developing faster-than-C stuff. I'd argue that we're quite a bit closer now. Consider garbage collection -- people even write GC libraries for C, because it's getting to the point where whatever performance you might gain out of tweaking your own memory management by hand is no longer worth the chance of a memory leak, buffer overflow, or random segfault. Or bytecode -- because more information is available at runtime with a bytecode, compared to a real binary, it's possible to do certain runtime optimizations that could theoretically make a C# or Java app run faster than C.

Kind of like how C has really obsoleted assembly for the absurdly vast majority of tasks, because whatever performance gain you might get is offset completely by how insanely long it takes to code ANYTHING in assembly, and because even C is inherently more portable than assembly. Pretty much the only people who need assembly are those writing compilers, those forced to work at a low level for obscure reasons (drivers, bootloaders, etc), or those who need to squeeze every last ounce of performance out of a certain chunk of code -- a chunk of code that's usually part of a massive system that is otherwise written in C or C++.

And I'm just talking about the capabilities of the compiler/runtime. I think the language itself sucks. When you think about it, it's just as hard to imagine an interpreter improving C as it is to imagine a compiler improving Ruby.

And before I'm done, his original point is valid, but I think most of us (including me) misread it at a first reading. Consider: There are a few functional languages which can do things like lazy evaluation and automatic parellism. A program that you write in Haskell, for example, could automatically scale to use as many cores as you have functions -- well, almost, but you get the idea.

C probably does run faster, once you tweak it, but threading in C is hard. In fact, threading period is pretty hard, partly because it's hard to think that way, especially in an imperitive language. But the kind of low-level threading you get in C is just REALLY FUCKING HARD. It's not that I suck at it, it's true, to the point where many people still recommend you take the performance hit and use separate processes just to make sure your program doesn't trip over itself.

So, once again, it's like C vs assembly. Eventually, we're going to switch to a language 90% of the raw speed of C, but takes 5% of the time to develop in. And if you're worried about that 10%, don't be...

Even if we ignore runtime optimizations, there are other reasons to favor the computer (or language, or program, or whateve) doing more work for us -- it may actually do it better. Consider a rules-based spamfilter, like spamassassin, vs a statistical filter, like bogofilter or dspam. The statistical filter, once trained, is going to adapt more quickly to the real world of spam, and is going to come up with ways of identifying spam that you wouldn't have even considered. (A simple example: Any email containing the word "spam" is probably less likely to be spam. Would you rather spend your time writing thousands -- millions -- of these rules? How do you know you even got it right?)

Just like the C-killer will come up with ways of improving performance that you hadn't even considered. Just like a C compiler probably does for assembly.

Re:They said something else. --Found One

[Anonymous Coward]

as requested a comp sci program without most of the theory you mentioned. http://www.rollins.edu/holt/prospects/ug/pgm_compu terscience.shtml

I thought this was going to be interesting

[Anonymous Coward]

aside from c, which isn't going away for several more decades, all the other "skills" are useless and pointless to have anymore. It would be no different than using punchcards today.

more non-news is all I see here.

Delphi

[Organic Brain Damage]

is Turbo Pascal.

C is not even close to dead!

[gatkinso]

That's all I got on that!

Re:c ? really? -exactly

[Locklin]

Exactly, how is the language replacing Java going to be programmed? You need access to these low level operations to properly write a language/compiler/runtime.

I don't get this about C/C++

[wandazulu]

Why does C/C++ never get any love? C and C++ make it onto these lists all the time, then a number of /.'ers claim how it won't die, but live on as a niche or embedded language, etc. In other words, it's a useful language but for a bygone time.

???

How does anyone believe this? It is extremely likely that *every* *single* *program* you use is written in C or C++. Even the languages that supposedly replace C & C++ are written in ... C and C++. Java? Written in C++. Ruby? Written in C. Python? C. The operating system, the editors, the web servers, everything at some point got washed through a C/C++ compiler and generated some flavor of a.out. At the end of the day something has to actually allocate a block of memory for that untyped variable in and the only languages that do that are C and C++.

Maybe the problem is that with C is that there are no illusions, no smoke and mirrors: it's all about the raw bytes and memory blocks. Strings? We got char arrays (don't forget to leave room for the null terminator!). C++ gives you the smoke and mirrors, but maybe too much so (I'm looking at you, operator=() ) plus it keeps all the bit slinging power of C...combine all that together and you have a language that is rightly described as ... complex (then there's templates...)

Every language, every tool, has its purpose and C and C++ doesn't fit the bill across the board; I have written big web CGI programs in C and let's just say it was unpleasant. But I wouldn't think to write an operating system in Ruby either (not that I'm in the habit of writing operating systems). If anything, I fear the loss of people writing in C and C++ because that's where the bits actually get slung and, as other people have pointed out, there are literally no limits to what you can do...the next Rubys, Pythons, Javas, etc., will still need to be written in C and C++ simply because they are the languages that offer maximum flexibility with maximum performance with maximum headache (j/k about that last one...sort of).

Toothpaste...

[xtracto]

This reminds me one of those toothpaste advertisements...

"Use the programming language that *your* IT guy uses"... "C".

So yeah, you might have PHP, Perl, Python, Cobra, Camel, Zancudo, Lisp, Boa and every other beasty programming language, but all of them are ultimately created using C.

Now, it is important to see that each of those are done for a specific purpose, and as such, C has its specific use and will continue to have in 30 years or more. The difference has been that of these languages (say Python, PHP, Ruby, etc) there are lots of alternative languages to do one thing, and this will make some of them less used than others, and hence few of them will "prevail". But there is no other language that can be used to do certain things you can do with C (Not even assembler as it does not have the "portability" of C), hence it is the *only* language to perform certain tasks.

know my shame

[Anonymous Coward]

I work in science (but not math or physics) and I have no LaTeX skills. We recently hired a guy who does. He is making the rest of us look very bad. I was pretty pleased with my MS Word ability, but I have come to realize that much of what I was doing was actually working around MS Word's inadequacies. The feeling is like wearing a pair of thick gloves while trying to do fine work. So, I am now learning LaTeX. If you are reading this threat you probably should learn it too.

It goes like this is:

[cabazorro]

If programs were houses, C would be the hammer.

A developer who doesn't know C is a contractor fumbling with a hammer.

Don't start me with what language is the nail-gun but the idea that the
hammer is going away is by any stretch of the imagination: purely idiotic.

Re:They said something else. --Found One

[fishbowl]

>as requested a comp sci program without most of the theory you mentioned.

That's not missing much for a BA; the only things I see missing are courses in formal grammars, automata, and algorithm analysis.
This school looks like it's training practitioners as opposed to scientists; and that's perfectly reasonable. A BS program would and should be heavy on the theory and should include a supporting science. At my current shop that science pretty much needs to be physics and it's really helpful if you studied chemistry. But then, what we do is actually science. I've been in the business world too, and I realize that in most IT jobs, 99.44% of everything learned in school either needs to be unlearned or else atrophies. Different worlds, of course.

What a sight!

[Docboy-J23]

Muah ha ha, wow! This is so cool! It's like some convention of super-old programmers! Thank you, Lucas123, for making Cryptonomicon come alive!

I could be wrong.

[luckingfame]

It's been a bit since I've coded OpenGL, but isn't all Playstation and 3d gaming coded in C/C++?

In soviet russia . . .

[SpeedyGonz]

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

... you program in sharp sharp sharp C

Not just C

[mnmn]

Some of the items were job titles not skills.

I would put vi and emacs in the list there, and stuff like tex and even tcl/tk. I would put crimping a 10base2 ethernet cable.

What about assembly language programming for DOS (remember Robert Brown's interrupt list?). BASIC is dying too although it'll never truly die.

FORTRAN is probably more deserving to be on that list along with RPG than COBOL.

But I'd never put C there. Just visit any university. However if the author meant C-only skills and not hardware (device drivers), higher level (C++), specific API or other skills, it might work for the list.

Steps for speeding up your web browser

[leoPetr]

1. Reduce cache size to something reasonable, like 10MB
2. Reduce history size to something reasonable, like 500
3. Switch to Opera :D

C... Really.

[Anonymous Coward]

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.

I was going to go off on a rant about how the most common use that I have for my knowledge of FORTRAN is porting old applications to new platforms -- generally just keeping the algorithms and switching over to C. What the heck... I'll do it anyway, via anecdote:

About 7 years ago, I was asked to port an old FORTRAN program (heavy Tensor Calculus) from an old UNIX platform to something which could be run on a WinNT workstation. The old code wouldn't compile, as it was, under the Compaq Fortran95 compiler that they provided me, so I set about going through, and debugging the source... I got so disgusted with the process that I ported the entire application over into ANSI C (in my spare time, over about 3 days), writing my own math libraries, where necessary. The result ran more than an order of magnitude faster on a P-III workstation, under WinNT4.0 than it had on the Sun UltraSparc workstation, and was just as accurate (produced the same results from the same input data set). All that it takes to make the "much happier grammar" of C do the work that used to be best done in FORTRAN is a good set of math libraries. If you use C++, you can even save some effort in translation by using operator overrides in your math library headers. Add to this the much more friendly memory access/control that C/C++ gives you (for e.g. manipulation of large multi-dimensional arrays, pointer stepping can actually be very efficient, if you put some thought into it -- especially if you want to go multi-threaded). What's keeping FORTRAN alive, IMNSHO, is old stuff like GAMS. I haven't actually used code from that base directly in ages, but it's still a good source for algorithmic ideas... which I tend to implement in C/C++.

Tech-Pop-Media == professional shills and trolls?

[walterbyrd]

They say outragous stuff because that makes you read their articles. The more hits on the site, the more they can charge advertisers.

Many of the people interviewed clearly have an agenda: why ask an as/400 recruiter about the need for PC networks? And why are big publishers, like ziff-davis, so totally biased towards big advertisers, like msft?

Bottom line: what do these so-called jornalists know? They don't work in information tech.

The techniques used by the pop-media are no different than the techniques used by 13 snot-nosed punk trollers. The pop-media pros are just more polished.

Holy ad-riddled pages...

[guruevi]

... let's just go to the "readable" story: http://www.computerworld.com/action/article.do?com mand=printArticleBasic&articleId=9020942

My predicition:

[Ihlosi]

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

Email on netware 3.11

[Tony]

I was running Charon, the email server, on Netware 3.11. For the desktop, I had Pegasus running on MS-Windows 3.0 and 3.1 machines. I had an FTP server and gopher running, too, and a btreive database system.

Those who think Netware is just a file and print server have no clue.

Netware was a fantastic product. It is the reason I learned to expect reliability and easy administration from my servers. (For the time, it really was easy to administer. You set it up, and it ran.)

Not sure I like the comparison of C to a dog ...

[LizardKing]

"C++: A Cadillac made by nailing extra chrome to a Porsche." - Phlogisten Verdigris

obit

[slapout]

The C language was declared dead today by report Mary Brandel. C is survived by it's children and grandchildren:

C++
C#
JavaScript
PowerBuilder
Java
D
Objective-C
PHP
and many more.

C was used for everything from writing operating systems to programming game consoles like the PlayStation and GameBoy Advance. His death was unexpected. No one is sure yet who his inheritance will go to.

Bad site!

[Anonymous Coward]

over a 500k download for 2k of content. Two fucking paragraphs of reading material that takes less time to read than it does to download on my shared T1 here at work.

And to add insult to injury, it's a WELL DUH! article. COBOL and notrelational DBMS? How about PFS File, remember that one?

No, I did NOT bother clicking the next two paragraphs in the four page article. Computerworld can kiss my ass. If I'd had enough coffeee I'd have remembered how shitty that site was and not clicked.

Fuck them.

And when I click "Lucas 123" do I get "lucas123.com"? Do I get a slashdot user page for Lucas123? Do I get an email address? No, I get fucking COMPUTERWORLD! Let me fix those typos for you, Zonk and Mary-

Posted by Zonk on Thursday May 24, @05:54PM
from the "promoting my own employer" dept.
Mary Brandel writes

"I 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. My 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.'"

  [+] education, it, technology (tagging beta)

Re: C99 is dead. Long live C90.

[Anonymous Coward]

Not if you use C99 - come on people, the standard is 8 years old already.

I hate to break this to you, but C99 was stillborn. Yes, some compilers implement some of its features, but no compiler that I'm aware of implements all of its features. And as you pointed out, people have had 8 years to implement it. Therefore by definition, C99 was stillborn.

pc network admin

[Meorah]

pc network admin is dying, says guy who works on as400 systems.

Mainstream Centric View

[CyberLife]

The problem I see with this top-10 list is that it seems to be ignoring everything outside of the mainstream. Granted, within the world of the stereotypical desktop PC, the stereotypical office server, and the stereotypical web environment, these ten things may appear to some to be dead or dying. In other areas of the industry, however, they are very much alive and well.

Embedded systems (as others have point out) use C and assembly extensively. Their requirements can't afford the luxury of bloated runtime environments or 500-lines of superfluous wizard-generated framework code. Non-relational databases are used in scientific and engineering settings where the data are often non-tabular. Finally, many applications use non-IP networks where the feature-set of IP is unnecessary and its overhead is deemed too great. High-performance clusters and supercomputer installations are a good example.

People need to realize there is more to computing than what they see at Best Buy or on TV. Unfortunately, the vast majority of newcomers to the industry are only being taught the mainstream stuff, as evidenced by the following excerpt from a real-world conversation:

Veteran: "What is your reason for choosing a SQL database for this application?"
Rookie: "It's what I know."

Vicious circle

[Anonymous Coward]

That is a nasty vicious circle: you do not get recruited for working
in that area because you have no paid experience in that area, thus
not being able to have paid experience, etc.

Can it be broken by lying to the recruiters? How easy is it?
They give no other choice. From what I know I do not think recruiters
appreciate at all hobby experience in any programming language. They are totally obsessed with teamworking and those bollocks. They are scum.

PS: I am not working in IT, I am just a physics postgrad student, but I
will try to move into IT in some time soon.

Sorting punch cards?

[Avatar8]

Dead skill right?

I was going to pick on 9-track tape usage and loading, but I saw another poster comment on still using that.

Does anyone know of punch cards still being used? Did I miss the 1990 report of dead skills that included this? :-)

I had nearly forgotten about them until I started working at my current job. Here they have a "computer history" museum on display. It includes a punch card "typewriter/coder," a punch card sorter and an old IBM machine that reads punch cards.

What about circuit board wiring? I can still do this as a hobby for small projects (model rocket launching), but I wonder if anyone still does it professionally. Circuit board fabrication makes Wozniak's creation of the Apple look like art.

Well...

[jd]

...any transport can encapsulate IP. Or anything else. Networking is highly recursive - almost any output can be hooked into the input of any layer within any other stack, and you can do this as many times as you like. Netfilters in Linux uses this to have hooks in a whole bunch of places. The Intermediate Queueing Device is another ingenious use. MPLS creates as many virtual circuits as you like on a physical network. The list is endless.

Infiniband, however, is a true replacement for layer 4 as well as layers 2 and 3. The protocol is rich, sophisticated and fully routeable - to a target connection, a target multicast group or even a location in the target computer's memory. Indeed, Infiniband was designed with the intention of being totally interchangeable with IPv6 - a proxy could replace one with the other with almost no effort and with no loss of functionality or information. Likewise, Myrinet's MX and GM protocols need nothing on top of them, the way ethernet would, to be routed or delivered to a specific endpoint.

IPv4 and IPv6 are superfluous in such systems, except in their ability to handle legacy protocols. Well, IPv6 has its uses - it has a lot of features that are hard to reproduce on other networks, and it's relatively lightweight - but IPv4 has no value aside from being able to run stuff built for IPv4 alone.

Well...

[jd]

First, the RFCs only refer to IP as IPv4 relatively late on. Second, you will see the majority of dual stack systems referring to "IP and IPv6". Third, when people talk of IP networks, they are referring to IPv4-only networks. Lastly, a lot of people are stupid and/or ignorant when it comes to networking.

Re:What is NT? GNU? OS/2? VMS?

[WillAffleckUW]

But if NT is a primitive of OS/2, then what is GNU? Is that Unix?

And what ever happened to VMS, is that NT on steroids?

Re: Would those be Globe form 5081

[Douglas Goodall]

I have used of ton of these in my life. You are probably safe to loose the cads, but you might want to digitize them first.