Useless Language Features

Human beings are all born with a vermiform appendix--a little appendage on our intestines which serves no useful function (but which occasionally gets infected and/or ruptures, frequently requiring surgery). Most programming languages have their own versions of the vermiform appendix.

It was never established that vermiform appendix was vestigial; this was a speculation that Darwin popularized. It's almost as fact-free as the folklore about lemmings committing suicide. "Today, a growing consensus of medical specialists holds that the most likely candidate for the function of the human appendix is as an organ of immunity. Several reasonable arguments exist for suspecting that the appendix may have a function in the immune system. Like the rest of the caecum in humans and other primates, the appendix is a highly vascular, lymphoid organ that produces immune system cells normally involved with the gut-associated lymphoid tissue "

Damn, Doug! Do you have to ruin a perfectly good analogy with facts??? :)

:-)

This is a (partial) list of language features which are useless--ones that do little more than clutter up a language's definition and complicate it's implementation, and are seldom if ever seen in any real code (real code excludes code to demonstrate the language).

Don't put on the list features that you think ought to be ConsideredHarmful (but are nonetheless used). These are for features that nobody uses, and nobody knows how to use--even if the feature is MostlyHarmless.

A separate list is for archaic features--those which were once useful but aren't any longer (assuming modern development and deployment environments; legacy environments, embedded systems, and the like might still benefit from them).

Useless features:

PrivateInheritance (and its evil twin, protected inheritance). A rather poor implementation of ImplementationInheritance in CeePlusPlus. Private inheritance is not useless. See PrivateInterface.
TriGraphs? in C/C++. A really bad way to allow folks with ancient terminals/keyboards missing certain characters (like { and } ) to type in C/C++ code. A better implementation (digraphs) was introduced by the Ansi C++ standard. Can surprise users when they embed ??? or ??! or a similar sequence in a comment and the compiler complains. Most compilers provide a way to disable this particular feature; the documentation for GCC (which avoids editorializing for the most part, except about FreeSoftware) refers to trigraphs as BrainDamage.
auto declaration in C. I've seen this in C code; I must be one of the few in the world. It appears to have been last used circa 1974 in Bell Labs code. It means "this variable is stack-local to the current function". Presumably it was required in the early 12K byte C compilers, which were presumably not aware of when they were in a function or not.

Archaic stuff:

Register declarations in C/C++. Once necessary for high-performance code; nowadays un-necessary due to modern compiler technology (and MooresLaw). Many compilers nowadays ignore the register keyword completely.

This might still be useful when working on embedded systems.

Yes, see below:

Discussion:

If you're using a big compiler on a big CPU with a big clock and big memory and big storage, this is fine (it's so powerful, we can add Windows**2 and no one will notice). If, on the other hand, you write embedded stuff for somewhat smaller processors and somewhat smaller memories, it can be nearly indispensable. MooresLaw has less influence in the AlternateCodeUniverse? of embedded systems.

Even there, modern compilers make register less useful than it once was. Of course, if the only compiler for your processor is GCC 1.5 or something of similar vintage, then register becomes very important.

Actually, I was thinking more along the lines of stuff I have to do daily using variants of the 8051 family. This, and its red-headed cousin, the Z8, along with derivitives of the 6805/6809, are 8-bit CPUs with memory maps reaching all the way up to 64kb and as far down as 64 bytes of RAM. The 8051 is one of the most-deployed CPUs worldwide. Its compilers allow such things as explicit register declarations and in-line assembly. And often, these are not luxuries.

If you get sufficiently small-scale, then yup you have to do this. Another common place where register is useful is DSP programming. When you're writing C code for these environments, non-portable constructs like this abound (one could start to ask whether you are really writing in C, or a similar-but-not-quite-compatible dialect of C. Not that it really matters....)

Modern compilers only help if one can get by using a stack based coding style. When hardware restricts the amount of memory or available processing speed, one can fall back to using a register based approach (assuming use of a register rich CPU; I don't think one can get much out of the 80x86 family in this regard). The Z80 (if my memory serves correctly) provides a duplicate set of registers and requires almost no context switching when going into an interrupt handler (if you never nested interrupts). This can also be done as a convention in 680xx family processor. In a normal programming environment, one needs to write the current state of the system out to memory before performing interrupt code and then read the state back into the CPU after performing the interrupt code. For some interrupts, the saving and restoring context may take more CPU cycles than the interrupt code itself. For memory constrained systems, one can use registers as variable storage and only use memory for program control operations. If one can forgo the use of subroutines, one can program without any RAM whatsoever. This may sound a little extreme, but programming within the world of microcontrollers is often driven by constraints in hardware cost and power; throwing additional memory or faster CPUs at the problem is usually the solution of last resort (and may mean product cancellation).

Though it could be argued that under these circumstances, you should be writing in assembly anyway. PickTheRightToolForTheJob

No, C is definitely preferred for many reasons. You need a good compiler and intimate knowledge of how it works. In these cases C is the right tool for the job.

In C#, the use of the break keyword within Switch statements. VB6 has a far superior switch statement in power, readability and terseness. The break is useless since the next case implies a break and fall-through can be achieved by the missing feature of ranges (case 0-4,7,9:). I've always thought the 'struct' keyword was fairly useless since the compiler and runtime engine should determine whether things live on the stack vs heap.

Something defined with Struct is copied when passing. Very useful when it is not a ValueObject. I thought that was obvious.

I'm not going to get drawn into an argument about break in switch in general, but I don't understand how fall-through can be achieved by the missing feature range of cases. I can accept that when case implies break then break is of little, if any, value, but your logic seems flawed. If this is because I speak C anc C++ but not C# and VB6 then please simply say so and I'll do more homework.