Objective-C Overtakes C++, But C Is Number One

mikejuk writes "Although the TIOBE Index has its shortcomings, the finding that Objective-C has overtaken C++ is reiterated in the open source Transparent Language Popularity Index. The reason is, of course, that Objective-C is the language you have to use to create iOS applications — and as iPads and iPhones have risen in popularity, so has Objective-C. If you look at the raw charts then you can see that C++ has been in decline since about 2005 and Objective-C has shot up to overtake it with amazing growth. But the two charts are on different scales: if you plot both on the same chart, you can see that rather than rocketing up, Objective-C has just crawled its way past, and it is as much to do with the decline of C++. It simply hasn't reached the popularity of C++ in its heyday before 2005. However the real story is that C, a raw machine independent assembler-like language, with no pretense to be object oriented or sophisticated, has beaten all three of the object oriented heavy weights — Java, C++ and Objective C. Yes C is number one (and a close second in the transparent index)."

Comments

I prefer Subjective-C

[Anonymous Coward]

But that's just my opinion.

Re:I prefer Subjective-C

[Anonymous Coward]

Heyooooo.

Re:I prefer Subjective-C

[Anonymous Coward]

That would be PHP.

Re:I prefer Subjective-C

[gstrickler]

Having read other programmer's C code, I can say that all C is subjective.

sorry

[Anonymous Coward]

sorry but html and javascript is the future.. it must be true because all the kids just out of college say so.

Re:sorry

[Johann Lau]

That'd be like saying letters are no longer required because we'll all be using words and sentences from now on.

Re:sorry

[Genda]

Our educational institutions have become just one more kneeling acolyte, blowing the beast of many phalli, the corporation.

Re:sorry

[Gimbal]

To my understanding, HTML5 and JavaScript are the driving technologies behind frameworks such as PhoneGap and appMobi. Just sayin' - those languages are mobile platform compatible. (Objective C and Java, each, maybe not so much so)

Re:sorry

[TheDarkMaster]

So far as is necessary to do something slightly more complex, for example, controlling a printer. Will be possible to make an operating system controlling the hardware (yep, bare metal) in a shitty language like javascript? uhh ... I think not.

Re:sorry

[the_humeister]

That'd be like saying letters are no longer required because we'll all be using words and sentences from now on.

That's what the Chinese did!

Re:sorry

[modmans2ndcoming]

I think you mean the Koreans.

Re:sorry

[the_humeister]

Korean uses a phonetic system now.

Re:sorry

[Jeeeb]

That'd be like saying letters are no longer required because we'll all be using words and sentences from now on.

That's what the Chinese did!

Kind of but not really. There are far, far more words in Chinese than there are Chinese characters and characters often don't stand on their own as words. Rather individual characters represent morphemes with a single (or small number of) sounds, which often have no real meaning on their own. These morphemes are then combined to form words. In that sense Chinese characters are like an alphabet, albeit with characters which represent complete syllables rather than individual sounds and which generally (but not always) have some sort of semantic meaning. Secondly if you look at the way characters are formed in Chinese, there is a set of basic characters which are used as phonetic units in constructing most of the other characters. Most of the other characters end up consisting of a basic character indicating the phonological sound and a radical to (very broadly) indicate the semantic meaning of the character. So in terms of both 1. how the characters are used and 2. how the characters are constructed Chinese characters still deal with sound and meaning at a sub-word level.

Re:sorry

[beelsebob]

To my understanding, companies are dropping frameworks such as PhoneGap and appMobi like hot potatoes because they turn out to produce lower quality apps with 0 saved effort, so I don't really see your argument.

Re:sorry

[Anonymous Coward]

That'd be like saying letters are no longer required because we'll all be using words and sentences from now on.

That's what the Chinese did!

Yet, they are now switching back to letters because learning all those words proved to be impossible for the average man. Only scholars could properly learn most of those symbols.

Re:sorry

[sydneyfong]

Most individual Chinese characters do have their own individual meaning(s).

It used to be (thousands of years ago) that characters were essentially words, but these days multiple-character-words are more in fashion. The classical Chinese is still legible to those with a bit of training, and still sees some use in modern contexts.

You are indeed correct that the characters are often constructed with other "basic characters" that contributes a meaning and sound, but that's at a "sub-character" level, not really at a sub-word level.

Disclaimer: I'm not a linguist, but Chinese is supposedly my first language.

Re:sorry

[mikiN]

Javascript is Turing-complete, last time I checked.

1. Write compiler for <your favorite language> in Javascript
2. Write printer driver in <your favorite language>
3. ???
4. Profit!!!

Re:sorry

[angel'o'sphere]

You are oversimplifying quite a lot. Perhaps the lack of a proper word for something like this: æ--¥ is the reason? It is not a character. A better word is ideogram, or symbol or pictogram (but beware: chineese and jap. symbols can be either a pictogram or an ideogram, both terms are a bit special). E.g. a pictogram like this: ç means fire (some wood and the sparks/smoke). This pictogram means human: ä and this: å-- wall or surounded. ås this is now an ideogram, which means prisoner, combining the two pictograms into an "idea"-o-gram.

The next level is writing two or more symbols together, like "storm cloud" or "railway wagon".

You are in so far right that in modern chinese (main land) a lot of new symbols got defined which are simplifications of older more complicated symbols and are used as sylable characters, not as ordinary characters (as in english or german).

From those sylable glyphs you can construct words or sentences and they are mainly used simply to simlplify writing or to be able to write words where you don't know the symbol for (or in case of a newspaper, you assume your audience wont know the symbol).

Anyway just my 2 cents as I only speak/write japaneese and the above is from the "history" and "comparision" with chineese which we did in the japaneese classes.

Oh well after preview I see the chineese chars get mangled, I hope this is a local IE issue and you can still read it, or can cut/paste it into an texteditor that can decipher it :D

Alternatively you can find jap. Kanji here and experiment by searching: http://www.saiga-jp.com/cgi-bin/dic.cgi?m=search&sc=0&f=0&j=&g=&e=prisoner&s=&rt=0&start=1&sid=1341833528_72290

Re:sorry

[TheDarkMaster]

Even Brainfuck is turing-complete. But does not mean it is usable or practical.

Re:sorry

[jellomizer]

Yes HTML and JavaScript is the future... It isn't just the big picture.

back in them olden days We could write any program in any language. We had Companies who had all their apps written in FORTRAN or COBOL or C.

But HTML and Javascript is part of how we develop, but we need a back-end still... Java, Objective C, C, C++, Python, Perl....
HTML and Javascript are mode advanced kin to the VT100 Terminals, or 3270 terminals.... The Terminal/Web Browser handled much of the UI interaction, while the server handled the data and sharing and security.

Re:sorry

[hackula]

I think the argument seems somewhat plausible for clients. For backends, however, ...not gonna happen. I know some people might be using node.js with positive results, but using javascript for large, complicated corporate frameworks sounds like a good definition of hell. If the web 3.0 people do become our new overlords (unlikely, they will probably go the way of the 90s HTML "programmer" before we know it IMHO) I will at least be compiling coffee script. Javascript has a lot of great things about it, but the syntax interferes with productivity on non-trivial projects.

Re:sorry

[gl4ss]

well, there's a new trend to use javascript at the server end too, node.js, basically just using the javascript engine from chrome.
it's ok for some things. mainly I like it because I like php, python and a bunch of other stuff even less(and well, usual setups for java are complicated for simple things).

Re:sorry

[jc42]

... Chinese characters are like an alphabet, albeit with characters which represent complete syllables rather than individual sounds ...

And we've long had a word for that sort of writing, it's called a "syllabary" writing system. Lots of other languages have used syllabary writing. Japanese has two of them. ;-)

It can be funny reading things written about Chinese, with people going through all sort of convoluted explanations that could be instantly simplified if they only knew that we actually have a word for symbols that represent syllables rather than phonemes (or concepts or whatever). Once you know the right terminology, the Chinese writing system makes sense, sorta. Except that it's a historical mish-mash, with no consistent internal structure to the complex characters.

OTOH, there's also Korean, which some time back replaced the messy Chinese system with a home-grown syllabary in which each character consists of little pieces that represent the phonemes in a syllable. So they have a fully phonetic writing system that's very easy to learn (and has been adopted by a few other east-Asian languages).

Now if /. only permitted UTF-8-encoded text, so we could actually give examples using non-European characters ...

Re:sorry

[mikiN]

In Korea, only old people use letters (phonetic characters). The young'uns use ASCII (art).

Re:sorry

[Jeeeb]

I'm not saying that the characters don't have their own individual meanings, just that many don't form words on their own and that the majority of Chinese words are formed through combinations of characters. In other words in a sense the characters are like an alphabet, albeit one where individual characters represent syllables and have their own semantic meaning. I don't think we're actually in disagreement here :)

Anyway, that along with the fact that most individual characters are constructed from more basic units, shows that the Chinese writing system operates on a much lower unit than words and sentences.

Re:sorry

[Jeeeb]

Slashdot doesn't support unicode; welcome to the 20th century your time machine is working ;p I know the characters you're talking about though so it doesn't really mater.

Anyway I think if you re-read my post you would see that what you just demonstrated is exactly what I am talking about, although perhaps my explanation was less than perfect. Explaining using English terminology without relying on too much jargon or making the explanation too long is hard.

I'm not really talking about simplified Chinese vs Traditional Chinese. I'm saying two things 1. (just like you I think) that you have a set of basic characters which are used as phonetic components in other characters. I'm sure you're aware of this and 2. (again just like you I think) that most words are formed by combining characters together, and in fact many characters don't form words on their own, instead they have to be combined to have meaning.

Based on these two points, I think we can see clearly that the Chinese writing system operates on a lower unit than words and sentences, contrary to what the post I was replying to was suggesting :)

Re:sorry

[Jeeeb]

Thank you. Just out of curiosity which other East-Asian languages have adopted hangul? I can't think of any. The Chinese haven't. They use their own characters and Roman characters for phonetic purposes. The Japanese haven't they use Chinese characters along with hiragana and katakana. The Mongolians haven't. They have their own native writing system that predates the creation of hangul. The Vietnamese (not sure if they count as East Asian) haven't. They use Roman characters. The Taiwanese speak Chinese and use non-simplified Chinese characters. I think that covers all of East Asia outside of Korea, unless there are some ethnic languages inside China that are using hangul...

Re:sorry

[jc42]

I've read of it being used for a number of very minor languages in the Philippines and Indonesia, though I don't think any of these would qualify as "official" because the languages have no official standing. A quick google turned up the Cia-Cia language in Sulawesi, with all of 60,000 speakers. There's even a youtube video about it, showing a couple of children's books for teaching hangul.

I think the situation with these languages is that they previously had no written form at all, and couldn't get any sort of official support for a literacy program in a country that wanted them all to switch to the official language(s). It would make sense to adopt a writing system that's easy to learn. I'd also expect that that they might need to make a few minor changes to hangul to fit a language's phonetics. Or they could adopt kludges similar to the phonetic mapping for pinyin, where the sounds of the letters in Madarin don't exactly match any European language. Similarly, some of the hangul phoneme symbols could be mapped differently in another language with different phonemes than Korean.

I wonder if there are any language that have adopted IPA? That would a bit of a challenge for printers, but with the world slowly moving to laser/inkjet printing for everything, that's getting to be less of a problem than it was even a few years ago. ;-)

Re:sorry

[Johann Lau]

That's what the Chinese did!

You mean they're no longer using individual brush strokes, because they have complete symbols now?

Or did you mean to say they forgot how computers work? You wish ^^

Re:sorry

[angel'o'sphere]

Based on these two points, I think we can see clearly that the Chinese writing system operates on a lower unit than words and sentences, contrary to what the post I was replying to was suggesting :)

I don't understand how you come to this conclusion. I would have argued the opposite. Every glyph is either a word on its own, or if you concatanate them they build a complex word like "space launch platform", never the less in this case the singel glyphs still keep their own meaning and can be used in other contexts. Or they are glyphes that are combined into one glyph, like the prisoner example, which is still one word.
The processing of chineese symbols by the mind works also completely on symbol level and not on phonems.
In other words if a chineese can read and write english and has an accident causing that he can not recognize roman letters anymore, he still can read and write chineese.

fp

[Anonymous Coward]

fp!

Re:fp

[Anonymous Coward]

As a (very) amateur programmer, ok, script kiddie. I can't pretend to truly understand this, but what I can say is that the idea of object oriented vs. non object oriented languages has always thrown me off.

Now, I understand that the idea is an object can have several different types of variables as attributes, and can be created dynamically, but I've never seen any text that can give any up front idea of (You can do this in OO/You cannot otherwise) that would sell me on programming that way. Yes, thats not what languages are about, different ones are best for different domains, and so forth, but really slashdot, what is the big draw to OO? The killer feature?

Pointers?

Sincerely,
AC
From the Made-it-to-chapter-16-of-all-of-these-at-some-point-but-no-further-dept.

Re:fp

[Cinder6]

Here's a crazy brief explanation:

The big draw to OO is that it (ostensibly) makes it easier and/or faster to write applications. This doesn't mean that you can make programs with an OO language that you couldn't with an imperative or structured language, only that certain tasks may be easier to implement.

That said, OO isn't always the best option. OO languages are typically a lot more complex and produce slower executables than plain C, so there is a trade-off that can be important in certain situations. As with anything, pick the best tool for the job.

For myself, when I first learned programming (via some books), I learned C before moving to C++. I absolutely hated C++ and didn't see the point of OO programming, due in large part because of the way the book presented it. At the start, the author had you write a C program, and throughout the course of the book, you would change it into a C++ program full of OO goodness. The final C++ program wound up having 50% more lines of code for the exact same functionality, and that was the point where I gave up on it. It was a pretty bad first impression.

So maybe you're reading from the wrong book?

Re:fp

[solidraven]

Objects simply allow for an efficient programming structure for large software. That's the main reason. The real debate is about how far this object orientation should go. There are people like me that are of the opinion: use objects when necessary for structure. Others on the other hand will wrap anything in layers of objects. Dynamic allocation isn't strictly necessary for object support (see C++ to know why). It's just that most object oriented languages now also want to use polymorphism, at that point dynamic allocation is necessary cause it's near impossible for the compiler to predict what'll happen. But it's a rather pointless debate in the long run. To each his own as they say.
It's like the static vs dynamic linking debate that you sometimes hear. There's no real valid answer to that one either, it's a best guess on what'll lead to the best performance. With dynamic linking you don't need to load all the libraries at the start, on the other hand with static linking you don't need to call up the linker each time a library is loaded, and so on... My main advice: stay out of it. There's no real valid answer to these sort of things.

Re:fp

[oakgrove]

Say you're coding a graphical interface and you want two buttons for okay and cancel. They both need to be blue. The toolkit yours using will have an object called Button that has the basic characteristics of what a button its, e.g., a clickable icon that does something. You sub class this Button and give it the specifics.

Button okay = new Button;

Button cancel = new Button;

You now have two objects of type Button. Next you get specific.

okay.onClick(proceed());

cancel.onClick(abort());

okay.color("00f");

cancel.color("00f");

This is terrible pseudocode butyou get the idea. instead of having to code buttons from scratch, you sub class them and only add what you need. typing on a tablet so I hope I haven't been unclear.

Re:fp

[drkstr1]

See, now this is you troll! You even got a few takers. You should teach a thing or two to the Ron Paul troll above. Psshh, amateurs.

Re:fp

[drinkypoo]

I am not really a programmer and certainly not a software engineer so I have no input on what people SHOULD do, but as a person who reads and compiles and occasionally even successfully fixes code (occasionally but not usually fixing others' mistakes, mostly accounting for changes in libraries and such) I find it confusing when code is a combination of object-oriented and not. If I have to remember when I need to do something one way or the other I often seem to have a problem with that. It's valid criticism that there may be something wrong with my brain ;) but it seems to me like it makes more sense to pick a method and stick with it.

Re:fp

[frinkster]

Say you're coding a graphical interface and you want two buttons for okay and cancel. They both need to be blue. The toolkit yours using will have an object called Button that has the basic characteristics of what a button its, e.g., a clickable icon that does something. You sub class this Button and give it the specifics.

Button okay = new Button;

Button cancel = new Button;

You now have two objects of type Button. Next you get specific.

okay.onClick(proceed());

cancel.onClick(abort());

okay.color("00f");

cancel.color("00f");

This is terrible pseudocode butyou get the idea. instead of having to code buttons from scratch, you sub class them and only add what you need. typing on a tablet so I hope I haven't been unclear.

OK:

typedef struct button {
    long long color[3];
    void (*onClick)(int);
} Button;

Button okay;
Button cancel;
okay.onClick =
cancel.onClick =
okay.color[2] = 0xffffffff;
cancel.color[2] = 0xffffffff;

The C version is probably smaller and faster than your version.

Re:fp

[Anonymous Coward]

Have you ever heard of librarys?: code re-use began long before OOP and the converse of OOP is not "coded from scratch".

Re:fp

[frinkster]

Well, that was embarrassing. Wait, no.

I intended this to be a challenge.

Fill in the blanks.

Stupid slash code.

Re:fp

[oakgrove]

Heh. If you want to get fancy, I could chain mine together into a one liner. I was just showing the guy one purpose for OOC. personally, I use object oriented code only when really necessary usually for some kind of persistence otherwise I'm with you.

Re:fp

[bhcompy]

What is a struct if not an object in the philosophical sense?

Re:fp

[jasomill]

The final C++ program wound up having 50% more lines of code for the exact same functionality, and that was the point where I gave up on it. It was a pretty bad first impression.

I'm guessing this was because the authors were exhibiting uselessly "object-oriented" toy programs to illustrate language features. You'd probably have had a different first impression if you'd started with Cocoa and Objective-C. While it hadn't been updated in years and consequently seems to have disappeared down the memory hole, one of Apple's old Cocoa tutorials was something to the effect of "Build a Text Editor in 15 Minutes", where they showed how you could build a TextEdit-like rich text editor with Cocoa in a couple pages of code.

In fact, it's pretty easy figure out how to do this starting from the Xcode "document-based application" template, as there's not much more to it than replacing the label control in the document window with a Text View and implementing a couple methods in the document class to get and set its contents.

Re:fp

[vlm]

the idea of object oriented vs. non object oriented languages has always thrown me off.

Everyone else will attempt to explain OO using OO terms to a non-OO programmer. Thats like trying to teach my dog to sail a boat by speaking Japanese. I'll try a different tack. You know what a computed goto is, right (other than pure unadulterated evil, right?) What if your compiler enforced the hell out of good commenting and error bound checking to let you do computed goto's safely (er, more or less)? Well that is barely scratching the surface of OO. Syntactic sugar mounded on top of syntactic sugar. You know that quote about turtles all they way down, well fundamentally no matter the paradigm its Turing machines all they way down... more or less.

but really slashdot, what is the big draw to OO

When your professor was a little baby skript kiddie wannabe on his TRS-80 Coco-2 running OS/9 and BASIC09 and liking it, object orientation was the silver bullet among the crowd who could not bother to read "the mythical man month" by Brooks. So now you suffer thru OO because it was "cool" back when parachute pants were also cool, and leggings. Much as we're now raising a crop of wannabe skript kiddies who look up to the functional programming and agile methods people who have also never read "the mythical man month" by Brooks, so your kids / my grandkids are going to have to learn functional programming as The_One_True_Paradigm_And_all_disbelievers_should_be_burned_at_the_stake. And I'll still be writing device driver code on PIC microcontrollers in raw assembly, and it'll work great and I'll be liking it.

There's a really nice wiki article you probably need to read. The world is a lot bigger than "OO" "non-OO".

http://en.wikipedia.org/wiki/Comparison_of_programming_paradigms

Re:fp

[PaladinAlpha]

OK:

typedef struct button {

    long long color[3];

    void (*onClick)(int);
} Button;

Button okay;
Button cancel;
okay.onClick =
cancel.onClick =
okay.color[2] = 0xffffffff;
cancel.color[2] = 0xffffffff;

The C version is probably smaller and faster than your version.

That's incorrect. Your version will produce code that is at best as fast as a class with an inline color setter (that should be in the ctor, really) and an inline settable click function. If you use virtual inheritance to override click instead of passing a function pointer, the C++ will be faster, as modern compilers can inline many virtual function calls when they know the type at compile time.

But, as written, the provided class would produce identical assembly to your code, with in addition explicit construction/destruction semantics and easier invocation.

Oh, and by the way, you left color[0] and [1] undefined on both of your Buttons.

Re:fp

[Areyoukiddingme]

What the fuck? Why the fuck would I subclass a button just to make it blue? That's just data, and damned trivial data at that. If your button object doesn't already have some mechanism for dealing with that data, it sucks and I'm using a different object, not yours.

Instead of having to code buttons from scratch, you sub class them...

No no no no NO. Goddamnit NO. Fucking Java. Motherfucking Javascript. They've ruined a generation of programmers.

Subclassing is the LAST thing you should be doing. The very last. First you should be using the customization features built in to the object, and using them directly on an instance of that object. Set the blue color on the Button class and be done with it. If that's not sufficient, use object composition. Most of the time, your object is NOT a Button. It's a something that needs to have a button. Only as a last possible resort do you subclass Button, and you'd damn well better be writing an object that still is-a Button. If you're not, you've done it WRONG.

Re:fp

[phantomfive]

It helps you organize your program.

This isn't really an issue unless your program gets > ~5000 lines. When you have more than 100,000 lines, you spend more time integrating into existing code than you do creating new code. Good code-organization can reduce the integration time.

Re:fp

[styrotech]

Everyone else will attempt to explain OO using OO terms to a non-OO programmer.

OK, with you so far...

Thats like trying to teach my dog to sail a boat by speaking Japanese. I'll try a different tack.

But you're still trying to teach your dog to sail using sailing terms!

Now if on the other hand your dog was Japanese...

Re:fp

[jasomill]

If you're not, you've done it WRONG.

Except that if you read his code, he's not actually subclassing Button, he's instantiating it. He's certainly saying it wrong, though.

Re:fp

[frinkster]

Oh, and by the way, you left color[0] and [1] undefined on both of your Buttons.

The C standard requires the compiler initialize all stack-allocated memory to zero. color[0] and color[1] are exactly as the OP specified. To be safe, they should indeed be initialized to zero. In professional practice, I always memset everything I allocate to 0 for the entire block of memory I have allocated, and then initialize individual members of structures to whatever their default value should be.

Re:fp

[frinkster]

Everyone else will attempt to explain OO using OO terms to a non-OO programmer.

OK, with you so far...

Thats like trying to teach my dog to sail a boat by speaking Japanese. I'll try a different tack.

But you're still trying to teach your dog to sail using sailing terms!

Now if on the other hand your dog was Japanese...

Ah, but is he sailing on a starboard tack or a port tack? And should he tack or jibe the boat? And should he attach the sheets to the tack or the clew of the sail?

Re:fp

[dgatwood]

OO in a hundred words or less:

Object-oriented code is a way of collecting functions and the data types they operate on into collections. Instead of having hundreds of functions that all operate on a particular data type, you group them together into a class—a collection of functions—so that you, the programmer, can easily see the relationship between them.

That's it. Inheritance is syntactic sugar around struct pointer casting. In C++, most of the OO could be approximated with "#define class struct" and slightly different syntax for the methods (use function pointers in C). It's not magic; it's just an organizational tool.

Re:fp

[Waffle Iron]

Oh, and by the way, you left color[0] and [1] undefined on both of your Buttons.

The C standard requires the compiler initialize all stack-allocated memory to zero. color[0] and color[1] are exactly as the OP specified. To be safe, they should indeed be initialized to zero. In professional practice, I always memset everything I allocate to 0 for the entire block of memory I have allocated, and then initialize individual members of structures to whatever their default value should be.

The C standard requires static variables to be initialized to zero by default. Stack variables that aren't explicitly initialized can be random garbage.

To verify that I'm correct, I just tested it:

#include <stdio.h>
 
int main() {
 
    int x;
    printf("x: %d\n", x);
    return 0;
}
 
____
 
$ gcc -Wall t.c
t.c: In function 'main':
t.c:6: warning: 'x' is used uninitialized in this function
 
$ ./a.out
x: 10674164

Re:fp

[lennier]

You sub class this Button and give it the specifics.

Which is nice when that's what your toolkit actually does, but I seem to recall that that's exactly how most Win32 GUI toolkits don't work - that you can't subclass GUI controls at all and have to deal with them as black box objects that you work around.

Re:fp

[Anonymous Coward]

OO is *always* the best choice, depending on your definition of OO. I programmed in C back when C was considered OO. How's that? "modular programming" is what OO was based on. And, like everything else in C, it is what you make of it. C is an OO language, if you write OO code with it. What it doesn't do is enforce OO on you. The OO languages assume a level of incompetence. Back 30 years ago, I took an OO class that exclusively used C. All you young whipper-snappers and your forced good practices. Forcing practices on someone, even good ones, is a bad practice.

Re:fp

[neonsignal]

The advantage of the object oriented paradigm is not primarily that it makes programming easier or faster. It is the better support of separation between different components, which makes it possible to contain the complexity of large projects with multiple software engineers.

Of course, there are other ways of handling large projects (for example, there are examples of large projects written in C that control complexity by conventions about the separation of data and modules). But the object oriented paradigm is a common choice for large software engineering projects.

You might miss this when learning from a text book, since you are often only given small code examples and toy object hierarchies. But that extra 'overhead' around the defining of object abstraction pays off as the complexity increases. For many problems, thinking in terms of objects rather than instruction sequences can make the problem easier to solve.

Starting off with C and moving to C++ is not necessarily a good process, as you will not begin to learn to think in terms of objects; it is a completely different way of problem solving. Even for experienced programmers, the transition from C to C++ can be a six month process, not because of the extra language features, but because it requires a change in approach. Many don't stick at it long enough to realize the benefits.

The trade-off over speed is not an issue at all; for example, C++ is not significantly slower than C. Speed is affected far more by other choices; data structures and algorithms, memory localization, parallelism, and so on.

And you would also be aware that there are other paradigms as well, such as functional programming. These paradigms are not just "different tools for the job". They can have a radical impact on problem solving methods.

Re:fp

[oakgrove]

True. I got lazy on the tablet keyboard but was going to sub class to a blue object then instantiate with the text etc. Oh well. It was just an illustration.

Re:fp

[lennier]

So now you suffer thru OO because it was "cool" back when parachute pants were also cool, and leggings.

So terrifyingly true.

It's interesting to note that the technologies which really made the Net and the Web scale - TCP/IP, HTML/HTTP and SQL databases- are not even remotely related to object orientation. The pre-Net 1980s and early-90s "online services" world, however, was utterly littered with the discarded corpses of object system after object system.

I've come to realise that there's something fundamentally "not even wrong" about the basic concepts of object orientation as it's usually sold. Like postmodernism, if you go looking you find that theres there's no actual definition to it. There's no formal mathematics, no reference implementation, no validity checking. No two experts or language designers will even agree what object orientation is. Is it inheritance? Well then, single or multiple? Either. Interfaces? COM has them, other systems don't. Is it classes? No, because there's prototype OO. Is it private/public members? No, because Javascript doesn't have those. Is it object persistence? Not according to C++ and PHP, but yes if you ask the object database people. Is a JSON data structure an object? Well, yes and no. Maybe.

The term "OO" is applied to systems which have fundamentally incompatible semantics. Good luck trying to get any of that mess to integrate. It only seems to work with a strong centralised hand coordinating the object repositories. The OO people's attempt to standardise objects across systems was Software Components, which gave us COM and CORBA. Those worked in very limited contexts - as a fancy way of loading C++ libraries in Windows - but not at web scale. The IETF answer, which did work, was to just give up on using objects and use prehistoric, pre-OO ASCII-based markup languages - SMTP and SGML/HTML/XML.

We got the Web by NOT using OO. Why do we want to keep trying to apply a failed concept?

Re:fp

[modmans2ndcoming]

umm...if a language is Turing complete then there is nothing that can be done in one language that can not be done in another, so no...you would not see a comparison like that.

Re:fp

[modmans2ndcoming]

duh... you can use cin and cout in C++.

Re:fp

[jimmyfrank]

you forgot, "get off my lawn."

Re:fp

[lennier]

Object-oriented code is a way of collecting functions and the data types they operate on into collections. Instead of having hundreds of functions that all operate on a particular data type, you group them together into a class—a collection of functions—so that you, the programmer, can easily see the relationship between them.

That's the best-case, well-behaved upside of OO, yes. But it has an evil twin called "object-oriented analysis".

Object-oriented analysis is a way of taking your company's essential business data - the data you need to trade and survive, which has been around since before punched cards and which will be around when mind-mapped DNA moon crystals are obsolete - and then wrapping that data together with hard-coded functions hacked up in some quirky, platform-specific language invented five minutes ago and for which all support will evaporate in another ten - and shoving that into a proprietary "business methods repository" running on a database sever which has never been tested written by a company which will go out of business tomorrow.

Next Thursday, when you've left the ICT department for greener fields writing iPad apps in HTML5, your successor will have to work out how to un-hack all that weird platform-specific code, decrypt the proprietary runtime format, extract the actual business data back into some standard database table format which can't include any of the class inheritance structure or "business methods".. and then shove the mutilated quivering remains back into the OO Design process to start the cycle again.

This procedure is called "mixing code and data" and is essential to the OO way of thinking. It is a beautiful shiny butterfly which only wants to be your friend and it is the bestest way of handling data ever imagined.

Re:fp

[Areyoukiddingme]

I saw what he did. But I knew he meant to do what he said, not what he wrote. As he later confirmed. Hence, rant.

Re:fp

[ceoyoyo]

Yes. And there are no shortage of toolkits, libraries, macros and personal styles that use C structs as objects.

They don't do inheritance so well though.

There's nothing wrong with C, and I greatly prefer C to the horror that is C++, but there ARE some things real objects do that are pretty nice in many circumstances. That's why it's nice that Objective-C (and C++ if you insist on doing that to yourself) are supersets of C, so you can happily mix non-object oriented C code and OO code however you like.

Re:fp

[Areyoukiddingme]

Your slashdot ID is lower than mine, so you can take care of it.

Re:fp

[pthisis]

OO is *always* the best choice, depending on your definition of OO.

Believing this is a tremendously bad mistake to make. There are plenty of other high-level programming paradigms that for some tasks can be vastly superior to OO--e.g. straight functional programming in ML or Dylan, or logic programming in Prolog, or explicitly stack-based programming in Forth or Postscript. There is no "one size fits all" when it comes to programming.

Re:fp

[modmans2ndcoming]

it's a struct. no inheritance, no polymorphism. not a class/object.

Re:fp

[ceoyoyo]

YES! Now, explain to me how you got past "C, a raw machine independent assembler-like language"?

Assembler-like? C? C used to be the hot new language that held your hand and did everything for you, unlike assembler. Now C is assembler-like?

Re:fp

[Cinder6]

That's exactly what the author was doing. I've since returned to OO stuff (programming is a hobby, not a profession), and enjoy it much more than my initial impressions. And yes, some of Apple's sample programs do a very good job of demonstrating the ways that OO programming (and Apple's frameworks, natch) can make some tasks a breeze.

Re:fp

[MrDoh!]

I miss this type of stuff on /, Great to see actual geek stuff.

Re:fp

[Areyoukiddingme]

Wasn't me saying C is assembler-like.

I write C. I write C++. I write Python. I write shell script. I've written goddamn VB, when I have to. I was taught how to write FORTRAN77, but I never did once I left the class. And I've written a double handful of MIPS and 8086 assembly. C ain't assembly, that's for sure.

Re:fp

[Cinder6]

I agree. The GP was asking for a killer feature, however, and stated that (s)he was an amateur. I figured "faster and easier" was more exciting than "encapsulation and abstraction" :)

You're right that C++ isn't a snail compared to C. I was thinking of interpreted languages when I wrote that. I disagree with you that different paradigms don't fit the "different tools for different jobs" attitude, but I suspect we're arguing semantics here. Regardless, it is likely you know more than I, so I will concede the point.

Re:fp

[ceoyoyo]

We got the Web? That's your argument?

Object oriented programming is a nice organizational technique for larger programs and code reuse. It works well, if used properly, not least because it imposes a namespace system. Most OO systems also give you some neat automatic features like inheritance.

OO is not a silver bullet, not everything needs to be OO, and nobody, ever, should start learning programming with OO. If you make absolutely everything an object you're either an idiot or a Java programmer (no comment). If you make everything a templated class you're evil and a C++ programmer. If you reject all of OO because some people take it too far, you're no better than the other two.

OO does some cool things. Used properly, at the right time, it makes very nice code. Used badly, it makes a godawful mess.

Re:fp

[Anonymous Coward]

Almost all the C++ books never talk about object-oriented concepts and nor introduce them one by one. Sequence, selection and loop concepts and how they are implemented in the procedural part of the object modules are not clearly explained. Most will teach C for the most part and then jump to OO. OO thinking is difficult to comprehend and one needs lots of experience in that domain. Most authors are contract writers for the publishing companies and have very little understanding of how to teach a language. If you can write simple BASIC code - sequence, selection and loop, then with about 6 or seven rules, you can easily convert them into C code. I have done about 60 simple programs like that to understand the implementation of C. So, it boils down to the following - the best teachers don't write text books as it takes too much time and less monetary reward and the good text book writers have not taught courses to wide audience to understand what should be the "Student friendly " text book should be. In most universities, the instructors select a text book that comes with solution manuals and Power point slides. You don't learn from these instructors. If you have had solid foundation in problem solving, data structure etc., you can learn any programming language any time but takes time to become a professional. No 24 hours book can teach you what you can learn from a good instructor over a period of time.

Re:fp

[Anonymous Coward]

Objects simply allow for an efficient programming structure for large software. That's the main reason.

Sorry, those imaginary benefits are as mythical as unicorns. OOP is objectively inefficient.

Really, this shit has been studied. No benefits in productivity were found for OOP. I'm actually shocked to find that OOP didn't harm productivity!

OOP leads to an incomprehensible mess of dependencies (inheritance is bad, composition is almost worse) -- and design patterns lead directly to over-engineered monstrosities that are not only bloated and slow, but destroy any hope of maintainability.

People get confused because objects can be handy abstractions -- and used extremely sparingly, and only when other modular approaches don't fit the problem as well, can make code easier to understand and maintain. Objects, however, do not OOP make.

Even Alan Kay (the guy who coined the term) regrets it. It distracted from his much better idea: agents that communicate via message passing (incidently, a concept NOT well served by modern OOP languages)

One apology I hear all the time is that no one really understand OOP and that it takes years of study to truly grok the concepts and see the benefits. Well, if that's the case (very doubtful) then half of the promises of OOP are false. It's not easier to use, it clearly doesn't simplify design or development, and to top it all off, it bloats your code with no tangible benefits.

OOP is a lie, a hoax, over-hyped, and over-sold. It's a blight on software development. It needs to die. It's anti-modular (accidentally) and anti-parallel (intrinsically) It's the single worst paradigm (if that even qualifies, as there is so little agreement about what constitutes OOP) for this modern era.

If you're an advocate of OOP, I can automatically assume that you're either an idiot or so insecure that you don't dare question the "mainstream" view, like the average creationist.

Re:fp

[Tough Love]

OO isn't always the best option. OO languages are typically a lot more complex and produce slower executables than plain C, so there is a trade-off that can be important in certain situations. As with anything, pick the best tool for the job.

You got modded up for that misinformation? Perhaps you are not aware that gcc and g++ use the same optimizer and code generator. If you just mindless recompile your C program as C++ then you will get the same executable code. On the other hand, you can often take advantage of C++ features such as member functions to write code that optimizes better than palin C. So the truth is the opposite of what you claim.

Re:fp

[Tough Love]

there are plenty of other high-level programming paradigms that for some tasks can be vastly superior to OO--e.g. straight functional programming in ML or Dylan, or logic programming in Prolog, or explicitly stack-based programming in Forth or Postscript.

OO is orthogonal to all those techniques. If you want to OOP your explicit stacks, you can.

Re:fp

[Tough Love]

C used to be the hot new language that held your hand and did everything for you, unlike assembler. Now C is assembler-like?

C was always considered assembler-like, including by those who wrote it. Non-assembler like languages of the day included Algol 68, LISP, Snobol, TRAC and Simula.

Re:fp

[Tough Love]

I've written goddamn VB, when I have to.

I've written GWBASIC and no matter how hard I scrub, I can't get it off me.

Re:fp

[Tough Love]

Everyone else will attempt to explain OO using OO terms to a non-OO programmer.

How about: "It's like when you stop beating yourself on the head with a hammer".

Re:fp

[Anonymous Coward]

I'd need to double check, but I don't believe that's true. I believe that the C standard says, if you want a variable set to some pre-determined value, you'd damn well better do it yourself because the compiler isn't going to do it for you, be it on the heap or the stack. C is built around efficiency, and it assumes that if you didn't do something, you meant for it not to be done, and pre-assigning a stack variable to 0 would break that paradigm. I mean, what if I write the code
object* next = list.head();
int i;
while((i = object.value())
          next = next.next();
do something with i;

Clearly in that case you wouldn't much want to initialize i to 0, it'd be a waste.

Re:fp

[Tough Love]

Inheritance is syntactic sugar around struct pointer casting.

Control structures are syntactic sugar around gotos and high level languages are syntactic sugar for directly typing the bytes into memory.

Re:fp

[Tough Love]

We got the Web by NOT using OO. Why do we want to keep trying to apply a failed concept?

Still trying to explain why you haven't gotten around to learning C++? Because you obviously haven't. It hurts, but not that much. And then you might have a clue.

Re:fp

[pthisis]

Absolutely, and it's an excellent technique to apply in a lot of cases. Just not always.

Re:fp

[Anonymous Coward]

If you just mindless recompile your C program as C++ then you will get the same executable code.

duh...because it's just C code, recompiling it doesn't magically make it OO C++ code.

Re:fp

[Anonymous Coward]

Valid is probably not the word you are looking for. Objective, maybe?

Valid is something that can be shown to be true, given that the inputs were true. There are cases where you could argue that OO is a valid choice. It just depends on what the assumptions/inputs are.

Re:fp

[subreality]

what is the big draw to OO? The killer feature?

The short version: Instead of putting your data in the code, you put your code in the data, and that makes your code much easier to understand and reuse. Here's a quick Ruby example of doing something procedurally:

def degCtoF(c) ; return (c * 9.0 / 5.0 ) + 32 ; end
def degFtoC(f) ; return (f - 32) * 5.0/9.0 ; end
def format_c_temp(c) ; return "%s degrees F, %s degress C" % [degCtoF(c), c] ; end

oven_temperature_C = 55
puts format_c_temp(oven_temperature_C)

And then again doing it OO:

class Temperature
    attr_accessor :degC
    def degF ; return (@degC * 9.0 / 5.0) + 32 ; end
    def to_s ; return "%s degrees F, %s degrees C" % [degF, degC] ; end
end

oven_temperature = Temperature.new
oven_temperature.degC = 55
puts oven_temperature.to_s

The idea is that by attaching your code to the data, the data becomes "smart" and knows how to process itself. This is a huge benefit for code reuse since the person reusing your classes doesn't have to understand how they represent data internally, or the mechanics of how they process the data. It's already slightly easier to understand with this short example, and the effect is magnified greatly as the size of the codebase grows.

Re:fp

[Anonymous Coward]

Sorry, those imaginary benefits are as mythical as unicorns.

Hey just like your knowledge of the subject.

OOP is objectively inefficient.

Then you don't understand the meaning of the word 'objectively'.

Really, this shit has been studied.

By whom? Evidence? None.

No benefits in productivity were found for OOP.

Evidence? None, what a surprise, decrying something with no evidence and no facts and no basis.

I'm actually shocked to find that OOP didn't harm productivity!

Really? Evidence? None, again decrying something with no evidence and no facts and no basis.

OOP leads to an incomprehensible mess of dependencies

I suppose the very basic concepts of inheritance would seem like an incomprehensible mess to someone with such a small feeble mind as you as to purport idiotic and baseless opinions as fact.

People get confused because objects can be handy abstractions

Judging from your post you get confused WAY before that.

It distracted from his much better idea: agents that communicate via message passing (incidently, a concept NOT well served by modern OOP languages)

There is absolutely nothing wrong with message passing agent paradigms wrt OOP, but it doesn't surprise me that like all the other claims in your post this one lacks merit, basis or citation and is just a poorly articulated emotional complaint to something you clearly have no understanding of.

One apology I hear all the time is that no one really understand OOP and that it takes years of study to truly grok the concepts and see the benefits.

Well it just doesn't.

Well, if that's the case (very doubtful) then half of the promises of OOP are false.

It's not the case.

It's not easier to use, it clearly doesn't simplify design or development, and to top it all off, it bloats your code with no tangible benefits.

Looks like more emotional complaints because you can't understand it, unsurprisingly again lacking any evidence or merit whatsoever.

OOP is a lie, a hoax, over-hyped, and over-sold.

Hey just like your post!

It's a blight on software development. It needs to die.

If you were right it would simply die on its own, but obviously you are just angry at yourself for your failure to understand it otherwise you would have objective (look up the word because your previous use of it suggests you don't understand it) basis for your claims and some evidence to back them, which you don't.

It's anti-modular (accidentally) and anti-parallel (intrinsically) It's the single worst paradigm (if that even qualifies, as there is so little agreement about what constitutes OOP) for this modern era.

Yet more emotional complaints, unsurprisingly again lacking any evidence or merit whatsoever.

If you're an advocate of OOP, I can automatically assume that you're either an idiot or so insecure that you don't dare question the "mainstream" view, like the average creationist.

I suppose the AC with no evidence and an obvious lack of mental capacity to even understand the most basic concepts is a reliable source.

Re:fp

[Anonymous Coward]

The C standard requires the compiler initialize all stack-allocated memory to zero.

And how about heap-allocated structures?

So your C example results in differently initialized objects depending on how they're allocated. Fortunately C++ solves that by having constructors/destructors. The author of the Button class can guaranteed that the entire object is correctly initialized. That's the sort of stuff you don't get from C. Sure, you can fake it in C, but if you're just going to emulate C++, you might as well use C++.

Re:fp

[shutdown -p now]

The C standard requires the compiler initialize all stack-allocated memory to zero.

Not only the standard does not require it, but virtually all real-world implementations don't do that, either.

In professional practice, I always memset everything I allocate to 0 for the entire block of memory I have allocated

That's a bad habit. There's no guarantee in the standard that setting all chars to 0 will correspond to a default value of a type, or even some valid, representation of pretty much any other type. For locals, you'd do better by writing an explicit initializer ={0} - this works with any type, and will implicitly initialize all remaining fields to their default values.

Re:fp

[shutdown -p now]

Variables with static storage duration are initialized to 0 by default. Variables with auto storage duration are not initialized by default.

For heap, malloc doesn't guarantee anything about the contents of the allocated memory block, so it's effectively uninitialized - but then there's also calloc to zero-init.

Re:fp

[shutdown -p now]

. Goddamnit NO. Fucking Java. Motherfucking Javascript.

There's no subclassing in Javascript (unless you mean some third-party library).

Re:fp

[mug funky]

Palin C? I much prefer to code in Monty Python.

Re:fp

[Raenex]

The C standard requires the compiler initialize all stack-allocated memory to zero.

So how many years have you been programming C with this absolutely wrong piece of info? I love how the C guys tout that their programmers are the best because the language requires it, where the reality is that the inevitable mistakes end up much more costly.

Re:fp

[LizardKing]

No no no no NO. Goddamnit NO. Fucking Java. Motherfucking Javascript. They've ruined a generation of programmers. Subclassing is the LAST thing you should be doing.

Can't speak for the JavaScript folks, but in the Java world the best practice is to favour composition over inheritance. So subclassing a button just to change the colour would not be considered good form. The problem with people using inheritance in inappropriate places is down to what I call the "new toy" syndrome. Programmers new to OOP feel they must use it, and to be fair many books tend to place too much empahsise on it (I'm looking at you Mr Stroustrup).

Re:fp

[Areyoukiddingme]

It was kind of a rant. Accuracy took a back seat to histrionics. Java rage spilled over onto Javascript. My bad.

Re:fp

[jps25]

You didn't actually verify it by using gcc but you're still correct.
By using gcc you only tested gcc's implementation-defined C behaviour.
If gcc was strictly adhering to the C std it would tell you that int main() is undefined behaviour on hosted environments and implementation-defined on freestanding environments.

Re:fp

[mikiN]

Oh, how I hate those "Build a gizmo in 15 minutes" advertutorials.

Here's mine:

#include <kitchensink>

int main(int argc, char *argv[]) {
    everything_but_the(argc, argv);
    return 42-6*7;
}

Morale: all those "build an * in 15 minutes" quickies do is try to sell you on whatever libraries / frameworks included in the system, they teach you little to nothing about the usefulness of the language for building completely new things.

Re:fp

[mikiN]

Exactly.

OP sounds like:

void oop_rulezz() {
    Gizmo gizmo;
    Hammer hammer;
    hammer.knock((Nail *)&gizmo);
}

which isn't always the right thing to do.

Re:fp

[solidraven]

You're wrong. I only got to terms with OOP after becoming familiar with hardware synthesis. It is a very natural method if used correctly. I agree it doesn't lead to the most efficient machine code. I also agree that the Ruby and Java style OOP is just a bad idea. Then again, it's a compromise just like everything else about your computer. But the correct naming should be modular programming. OOP is a valid paradigm to pull a program into modular chunks. You can make the rather small parts of code in the module very efficient. They might not tie into the rest of the application in the most efficient way but it'll work just fine. In fact objects are a logical extension of dynamic loading. There are a few set entry points, and everything happens in the library its own memory space or the program's memory space (see this as public, protected and private access in some way). When the code is done executing it'll return to the main program and return its values through some mechanism like a stack. Now doesn't this sound an awful lot like an object?

Being against something in a radical way is stupid, you neglect its possible uses and the advantages it might offer. It's the same with people who are radical against a certain language (except Ruby, you're allowed to hate that one cause it really is a bad idea in terms of readability in my humble opinion).
Personally I find myself aligned with Ada's methodology for modular programming, but sadly many people have difficulties grasping the finer points of the language. Ada allows you to drag pretty much everything out of any system if you use it correctly. Most people just don't like that Ada really won't let you mess around with data types as you wish; you respect Ada's way or you can bugger off. But in return you gain security and speed, the compiler knows exactly what will occur at any given point and is able to produce very efficient code. Still people hate it for various reasons; First of all it was made by the U.S. military, I grant you that's not a good start all things considered. A second problem is the lack of popularity on the internet. I have yet to find a good Ada tutorial on the internet. Third and foremost it's very verbose and strict. Make one mistake and the compiler will come back at you with a long sharp object with the sole intention to pierce your vital organs and your children. Ada programmers will often curse at the compiler like there'll be no tomorrow cause of it. They'll blame it for every bad event on the planet, but at the end of the day they know it'll do its job and prevent them from writing bad code.

Re:fp

[mikiN]

hrmpfh, been out of that stuff too long, must be 'hammer.knock((Nail &)gizmo);'

Anyway, make up your own Gizmo & Nail classes, then try it. Compiler won't complain if you want to nail yourself in the foot, that's the point, (type) pun intended.

Re:fp

[am 2k]

I once read a great explanation in a book for nonprogrammers:

Imagine a procedural program being a stack of bricks. When you're not careful, the stack falls over, and the whole program breaks down. Programmers have the task to keep this stack stable.

When you're using OO properly, you split this stack into multiple smaller ones. So it's easier to balance them, and when one of them does fall over, the others stay intact.

Re:fp

[dgatwood]

True. The friendliness of a language is directly proportional to the thickness of the layer of glaze.

Re:fp

[Rockoon]

The most insightful thing you will ever take from using OO programming practices extensively is that its the politically correct way to write spaghetti code and other "bad practices."

In the days of old before Structured Programming really took hold, people would write code with lots of GoTo's, branching haphazardly around in a hard to follow ways. "GoTo Considered Harmful" they said.

In these enlightened times however, people now use the powerful OO techniques such as polymorphism and inheritance to branch haphazardly around in hard to follow ways. But its OK now because its "Object Oriented."

You will see that global variables are bad if its a structured program, but its quite alright to have a single instance of an object accessible from anywhere and everywhere.

And C++ makes it a whole lot better because of templates. You can completely override every convention while doing your OO stuff, because that makes everything much easier to understand and follow. You will never be asking the question "how the hell did it get here?"

Now there is an even greater power for OO purists to leverage. Its called "lambda expressions" also known as "anonymous functions" because if there is one thing the OO guys need, its another way to hide program flow.

Re:fp

[Anonymous Coward]

You have to be careful when verifying things in this way. You're actually testing two things:

1. The compiler's implementation.
2. The operating system's memory allocation

Some operating systems always clear memory before giving it to user programs. Having garbage in the output proves that GCC allocates a certain way and that your OS didn't care to clean things up. It doesn't prove anything about the C standard itself. Looking at the C11 standard is the best choice here.

I remember in college I had a lot of trouble early on because I'd write my homework on Mac OS X and then try to run it on Solaris or Linux boxes. Many things worked on OS X because the memory was cleared. Sparc hardware showed me where I screwed up passing things around on the stack.

Re:fp

[Waffle Iron]

Local variables in C are almost always on the stack. These are not "allocated" from the OS just prior to use. The garbage on the stack comes from the setup routines that the C runtime called just prior to entering main(); the OS has no control over that.

At any rate, as you point out, getting 0 proves nothing. (In fact, if you turn on compiler optimization, gcc eliminates the actual stack storage and does give you a compile-time computed zero.) However, finding an actual garbage value the way I did proves that either gcc has a bug (unlikely in this case), or that local variables may indeed be totally uninitialized.

Re:fp

[Waffle Iron]

I verified it well enough for the real world.

I mean really. What are the actual odds that if gcc sees "int main()" instead of 'int main(void)', it thinks "Oh! Undefined behavior! Just for grins, I'll do everything just the same, except now I'll fail to initialize automatic variables to zero at runtime. That'll teach 'em."

Re:fp

[hazah]

Try Bruce Eckel's "Thinking in C++". I found it absolutely invaluable. Also, the online version is free on his own site.

Re:fp

[hazah]

You are hitting on different aspects of programming here. For instance, memory management techniques aren't the same as say drawing a line on the screen.

Re:fp

[ichimunki]

Actually, structs can be used to provide inheritance and polymorphism. And if you add a bunch of function pointers to the struct, now you have a what is essentially an object in every sense of the word. See http://stackoverflow.com/questions/351733/can-you-write-object-oriented-code-in-c for more information.

Re:fp

[angel'o'sphere]

I guess if people who have mastered C by programming with it for 15 - 20 or 30 years would have spend the same amount of time doing C++, SmalTalk or CLOS or OCaml they would say the same about such a language.
Point is: every language (family) forces you to think in "idioms" of that language.
Learning to think in those idioms and extending that to patterns is the long time consuming part.
Have you done that you are an artist in any language ... the more powerfull the language the less lines you then need to write.

Re:fp

[ceoyoyo]

I was asking how you could write such a great rant without even commenting on that little gem.

Re:fp

[angel'o'sphere]

I belive you are wrong, except the C standard changed greatly recently: http://en.wikipedia.org/wiki/Automatic_variable

Re:fp

[TechyImmigrant]

Some of us make the instructions that other people invoke in assembly language.
>C ain't assembly, that's for sure.
      Assembler ain't microcode, that's for sure.
            Microcode ain't system verilog, that's for sure.

Re:fp

[angel'o'sphere]

Object oriented code is simple:

lets start with C:

// file: fancy.c
#include "somestuff.h"
int myData;
char* firstWord;

void doSomething(int argc, char **argv) {
      println("in fact I'm not doing anything fancy\n");
      firstWord = argv[0]; ...
}
int main(int argc, char** argv) {
      doSomething(argc, argv);
}

I did not try to make this perfect. So what do we have here? A C file. main is only ment as entry point, as a "class" wont have that, but an constructor instead.

Now lets simply wrap the whole file into { and } and replace the first comment.

class fancy { // was fancy.c
#include "somestuff.h" // this would move, but I keep it here
int myData;
char* firstWord;

        void doSomething(int argc, char **argv) {
              println("in fact I'm not doing anything fancy\n");
              firstWord = argv[0]; ...
        }
        int main(int argc, char** argv) {
              doSomething(argc, argv);
        }
}

Now instead of a C File with a main function that can be started multiple times from the command line (when compiled ofc), occupying one process each and only capable to communicate via Unix IPC features, we now have a class.

#inlcude "fancy"

int main(intc argc, char**) {
        fancy fancy1;
        fancy *fancy2 = new fancy;

        fancy1.doSomething(argc, argv);
        fancy2->doSomething(argc, reverse(argc, argv);
}

What did we gain?

We can now instanciate "the same thing" two times inside the same process, as objects
The two objects can communicate via function calls with each other or other objects.

If the language only would support it (unlike C++), then a class is simply a name, bracers and a keyword wrapped around an ordinary C or Pascal file.

The variables inside of the fancy.c are global static variables.

The variables inside of the class fancy (myData and firstWord) are where ever the fancy object is allocated. fancy1 on the stack, fancy2 on the heap.

Thats it, nothing more magic about object orientation ... at least not on the first glance ;D

Re:fp

[angel'o'sphere]

The last time I worked on programms haveing around 5k lines was 1985 when I started learning pascal.
Since the last ten to 20 years most programs I'm working on are in a few 100k locs or several million locs.

Re:fp

[angel'o'sphere]

Most people don't knwo what turing complete actually means.

For starters: no you can not write a "pointer" in Java. No you can not place some code or some data at an arbitrary memory location.
No, you can not use the non existing pointer to access that memory location. And no you can not use that non existing pointer to call some code in that memory that you can not access.

However: you can simulate a microprocessor in Java, like an 6502. So a Java program can run all what a 6502 can inside that emulation.

Re:fp

[uglyduckling]

The big draw with OOP is that (ideally) it removed the separation between algorithms and data. In traditional imperative programming, you would code set of algorithms, procedures that do different things with data, and the data itself would be stored in arrays or allocated memory accessed with pointers. With OOP you code classes that encapsulate both the data, and the methods that are used to manipulate it. So if, for example, you were writing a file manager and wanted to implement a print function, you could handle files as objects, and as long as each different file type implemented an interface that had a print() function, you could call file.print() to print the contents of that file, without needing to know anything about how the data works within it.

Of course, it's perfectly possible to do that sort of thing using defined APIs in non object-oriented languages, but there is a neatness to the way OOP works that makes that sort of thing a lot easier. OOP hides all of the details of how a class works, and as long as it's coded cleanly, it's quite easy to extend programs to work with different types of data that the original author never intended, by coding classes that implement the same base classes (or interfaces) that the programs expects.

Re:fp

[s73v3r]

Ruby and Java have two vastly different styles of OOP. Java is closer to the C++ style, while Ruby is closer to the Smalltalk/Objective-C message passing style.

Re:fp

[s73v3r]

And congratulations, you've just invented OOP. You just did it without the compiler.

Re:fp

[s73v3r]

No, it's an object. Its a set of attributes on a particular thing. And if you want, you can put some pointers to functions in there that would act on that data. Hell, you don't even need the pointers to functions to be in the struct, you just need functions that take the struct as a parameter.

Re:fp

[solidraven]

Yes, and both are a bad idea; Notice the usage of the word "and". I never implied the styles were identical.

Re:fp

[bhcompy]

Not a programmer by any means(You're out of your element, Donny), but I remember one of the first things being taught in high school APCS ~10 years ago was to always initialize a variable because uninitialized variables are unpredictable. We used a Borland compiler, and it gave random junk in an uninitialized variable if I recall.

Re:fp

[hackula]

OMG, you have clearly never seen a business system written primarily in SQL stored procs. I spent 6 months working on an ERP system that did the majority of its processing in SQL...it nearly killed me (nothing wrong with SQL for actual data tasks though). Also, XML? I would rather store everything in CSV flat files like on on an old school RPG systems than relying heavily on XML.

Re:fp

[jps25]

No, you verified it well enough for gcc.
gcc complains about void main(), which is perfectly valid C in a freestanding environment, so why can't it complain about int main() in a hosted environment?
My best guess is that the gcc devs don't care about the difference between C and C++ mains because int main() is correct C++.
Or they don't know. Or they're just lazy. In any case, if gcc wasn't free and available, I doubt it'd be used as much.

Re:fp

[Waffle Iron]

But I don't care what kind of main() gcc accepts, or what warnings it might or might not print about main(), or why the gcc devs handle main() in any particular fashion. None of that has the slightest relevance to the original discussion, which was about uninitialized local variables.

The fact of the matter is, if local variables were supposed to be initialized to zero according to the standard, then gcc, which is probably the most popular C compiler on the planet, would do it.

Re:fp

[c 0xFF]

And the reason for this is, of course, efficiency. Creating space for local variables is as simple as moving a stack pointer. Initializing them to 0 just takes extra time. Uninitialized static variables belong to a special section of the executable (bss in elf format) that quickly and automatically initializes to 0. None of this is specified by the C standard, but the standard was written to accommodate these optimizations.

I believe there's one exception, which is the initialization of pointers declared as static. These are initialized to NULL, not 0. While generally the same, some bizarre architectures have a different bit pattern for NULL. The GP's idea of memset everything to 0 is technically a bad idea for any structure that has a pointer, although it should be fine for most any modern CPU.

Re:fp

[jps25]

And regarding the original discussion about uninitialised local variables I agreed with you. But that's because of the standard, not because of how gcc does things.
Regarding gcc's adherence to the standard I gave you the most basic example a compiler should get right but doesn't.
All I'm trying to tell you is that if you want to verify that something is according to the standard, then using a piece of code and a compiler is not the correct way to do it, especially since a compiler can do whatever it wants with all undefined and implementation defined behaviour in the standard.
gcc could have easily chosen to always initialise uninitialised local variables to 0 regardless of optimisations.

Re:fp

[cgaertner]

If gcc was strictly adhering to the C std it would tell you that int main() is undefined behaviour on hosted environments and implementation-defined on freestanding environments.

This is incorrect: Additional prototypes of main() are implementation-defined even on hosted implementations, so as long as gcc documents its behaviour, everything is fine as far as the standard is concerned.

However, this doesn't actually apply in this particular case: When a function declaration is part of a definition, an empty parameter list is equivalent to a prototype declaration with a single unnamed void parameter (see C99 6.7.5.3 10 and 14).

Re:fp

[c 0xFF]

C and C++ (from my reading of the latest standards) are virtually identical: they both require main to return an int in a hosted environment. In a freestanding environment, the startup function can be called by any name and with any return type that the implementation wants.

Thus, for hosted environments, 'void main' is specifically disallowed and GCC is doing the right thing.

Now, let's talk about freestanding environments. To say that void main() is "perfectly valid C" isn't quite right. It's certainly allowed under the C11 and C++11 standards, but by no means is GCC required to support it, as it's an implementation defined feature, and very target-dependent to begin with.

So, what we have is GCC supporting the standard, but whose implementation differs from other compilers. The devs made the choice to not support void main and that's perfectly fine. Nearly everybody who declares main as void are doing so in a hosted environment, and warnings/errors and completely justified.

Re:fp

[Waffle Iron]

gcc could have easily chosen to always initialise uninitialised local variables to 0 regardless of optimisations.

That's true. And if my experiment had returned 0, then it would have been a useless result. But it didn't return zero. Instead, it returned garbage, thereby proving my hypothesis to a sufficient degree for the real world.

(In fact, if you turn on optimization, gcc does create a zero at compile time. So turning on optimization does not result in a useful experiment for this case.)

Re:fp

[Areyoukiddingme]

Would have diluted the rant. A good rant can't ramble, or it just sounds like raving. A sharp focus is necessary to drive the point home. And preferably grind it on bone.

Re:fp

[modmans2ndcoming]

I was talking about the capability of the language to build software, not a feature of the language(pointer usage).

Thanks.

Re:fp

[modmans2ndcoming]

because that is soooooooooo much better than just using C++.

Re:fp

[rthille]

We got the Web by NOT using OO.

You realize that the first web server and first web browser were written in Objective-C, right?

Re:fp

[modmans2ndcoming]

in C and C++ it is absolutely NOT an object. in Java and C# and other modern languages...sure, just like any other data type is an object.

Re:fp

[jps25]

The main in C and C++ differ.
The main in C in hosted environments has been either
int main(void) { /*...*/ } or
int main(int argc, char *argv[]) { /*...*/ }
since at least the C89 standard.
http://web.archive.org/web/20050207005628/http://dev.unicals.com/papers/c89-draft.html#2.1.2
C99/C11 Section 5.1.2.2.1
For freestanding environments the standard states that the name and type of the function called at program startup are implementation-defined.
So, yes void main() would be perfectly valid C if the freestanding environment requires it that way.
Obviously gcc doesn't have to support it or any freestanding environment.
I didn't imply it had to, I merely stated that gcc complains about one incorrect main in a hosted environment but not about another in a hosted environment.

The main in C++ in freestanding environments is, again, implementation-defined.
In hosted environments the main shall have a return type of int but its type is implementation-defined.
Any implementation must at least support
int main() { /*...*/ } and
int main(int argc, char *argv[]) { /*...*/ }
Has been like that since the C++98 standard, section 3.6.1.

In C int f(void) is a function with no parameters returning an int,
int f() is a function with no parameter specification returning an int.
They are not the same and should not be treated as such.

So, what we have is GCC supporting the standard, but whose implementation differs from other compilers. The devs made the choice to not support void main and that's perfectly fine. Nearly everybody who declares main as void are doing so in a hosted environment, and warnings/errors and completely justified.

No. What we have is gcc failing to support the most basic part of the C standard, rendering its -W flags at least questionable.
If it can't warn about an improper main, what else is it failing at?
All I really wanted to point out is that using some code and a compiler is no way to verify the standard.
I used main as an example because the OP wrote int main() in his "verification".

Re:fp

[phantomfive]

Yeap. But if you are inexperienced enough to ask why OOP is important, as the GP did, then you probably haven't worked on many programs with more than 5k lines.

Re:fp

[cgaertner]

In C int f(void) is a function with no parameters returning an int,
int f() is a function with no parameter specification returning an int.
They are not the same and should not be treated as such.

This only applies to declarations which are not part of a definition. In particular,

int main() { ... }

and

int main(void) { ... }

are the same.

Re:fp

[jps25]

I stand corrected. Shame on me, I suppose.
No idea why 6.7.5.3p14 had slipped my mind so badly.
Certainly embarrassing enough.

Re:fp

[c 0xFF]

Both C and C++ standards allow for other parameters to main():

The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }
or equivalent;10) or in some other implementation-defined manner.

An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main:
int main() { /* ... */ }
and
int main(int argc, char* argv[]) { /* ... */ }
In the latter form argc shall be the number of arguments passed to the program from the environment in which the program is run. If argc is nonzero these arguments shall be supplied in argv[0] through argv[argc-1] as pointers to the initial characters of null-terminated multibyte strings (ntmbss) (17.5.2.1.4.2) and argv[0] shall be the pointer to the initial character of a ntmbs that represents the name used to invoke the program or "". The value of argc shall be non-negative. The value of argv[argc] shall be 0. [ Note: It is recommended that any further (optional) parameters be added after argv. —end note ]

You're right that there are some minor differences here. The value of argv[argc], for example. Is a C implementation required to support both basic forms? I'm not sure.

In C, however, the parameters to main() can be just about anything the implementation wants. In C++, other parameters are allowed, with the recommendation that additional parameters be placed after argv.

Meaning, the implementation is free to add extra parameters like:

int main(int argc, char *argv[], char *envp[])

or not have a parameter specification like:

int main()

Or just about anything else, in both C and C++. However, a return type of int is required.

GCC is doing the right thing. BTW, if you're in a freestanding environment, -ffreestanding disables the warning about 'void main' (as well as doing a few other important things).

(However, your point about not using a compiler to verify the standard is very much correct, even if we disagree on this particular situation.)

Re:fp

[dkf]

The advantage of the object oriented paradigm is not primarily that it makes programming easier or faster. It is the better support of separation between different components, which makes it possible to contain the complexity of large projects with multiple software engineers.

For all that, it is the componentization that is the source of the big gain. Having a reasonable degree of isolation and clearly defined interfaces makes things so much easier. OO is a somewhat fickle friend of this approach, especially when inheritance is used. Inheritance is a powerful and oft-misused tool. Some programmers, on finding a problem, think "I'll use inheritance to solve this!" After that, they don't have one problem, or two, but rather a whole family of needy child problems. (If only we could disable inheritance for all programmers who don't know what an "is-a" relationship actually is, we'd fix the problem with bad use of inheritance almost immediately. And there'd only be about 10 people worldwide who actually willingly used it in the first place.)

The trade-off over speed is not an issue at all; for example, C++ is not significantly slower than C.

I take it you're not including the time to compile in that?

More seriously, C++ most certainly has the potential to be slower than C, even without the problems of optimization. (C++ compilers optimize really rather well indeed; they damn well ought to, given how much compiler writing effort has been applied to them!) The real problem is that C++ programs tend to have more levels of indirection, and poorer data locality. That in turn hurts cache efficiency, which hits performance.

The other problem that plagues C++ code is a tendency to take ages for a process to shut down. That's caused mainly by the widespread use of the RAII style of coding (nonetheless a useful technique) and the way that on exit that leads to the C++ runtime wanting to neatly delete every single object. It's a theoretically laudable aim — after all, the object might need special action to release, even though that's rarely true for a majority of objects — but hurts rather a lot in a large program. It's particularly galling to know that the cost of getting everything that was paged out back into memory just to delete them is mainly wasted; the OS could reclaim far more efficiently by just reaping the process.

Re:fp

[dkf]

You now have two objects of type Button. Next you get specific.

okay.onClick(proceed());
cancel.onClick(abort());

This is terrible pseudocode butyou get the idea.

I'm glad you say that it's terrible, since you're registering the result of a function call with the button handler. While that might be what you intended, I somehow doubt it.

In general though, it's normal to deal with GUI objects through configuration and aggregation; subclassing to just set the color and add an "activated" callback is misuse. Instead, a subclass should add significant extra behavior, e.g., those buttons that also incorporate a menu dropdown to select variations on behavior. It's for those sorts of reasons that you use a subclass (assuming that the toolkit doesn't provide the widget already; if it does, writing your own is just dumb).

Re:fp

[s73v3r]

It is an object. It just doesn't have language support for being treated special. But for all intents and purposes, it's an object.

Re:fp

[modmans2ndcoming]

No....it isn't.

C Programming Language

[Anonymous Coward]

However the real story is that C, a raw machine independent assembler-like language, with no pretense to be object oriented or sophisticated, has beaten all three of the object oriented heavy weights

This sounds like it was written by someone who doesn't understand C. You can write object orientated code in C. You don't always need the language to hold your hand. And C is NOT assembler-like language. Not even close.

And as far as sophisticated code, I guess the author doesn't consider operating systems or most system programming to be sophisticated.

Re:C Programming Language

[Lendrick]

Is this a touchy subject for you, AC?

The author didn't say anything about sophisticated code, they said that C isn't a particularly sophisticated language. And it's not. C doesn't have very many bells and whistles -- it's just a very good, general-purpose language. The fact that the language itself is unsophisticated is what makes it good for writing the kind of code people write in C.

Secondly, C is not an object oriented language. I can write object oriented code in assembly language if I want, but that doesn't make assembly language object oriented.

Re:C Programming Language

[EllisDees]

> You can write object orientated code in C.

You technically could...but why would you? If you want to write object oriented C, there's C++. What's the benefit?

Re:C Programming Language

[Anonymous Coward]

Raw fucking blazing speed and flexibility.

Re:C Programming Language

[khipu]

You can write object orientated code in C.

No, you can't. But with some effort, you can write object-oriented code.

Re:C Programming Language

[bbn]

You will often see comments to the effect that C is like assembler or that you can do anything in C it just lacks some syntactic sugar. But that is very wrong. Yes, you can to some degree emulate object oriented programming in C. But how would you go about changing your memory allocation (malloc) to use a copying garbage collector? Or do lazy evaluation Haskell style? How do you implement zero-cost exception handling? (longjmp is NOT zero-cost because it requires setjmp).

These concepts are easy for a compiler that compiles directly to assembly language. Often less mature compilers will compile to C as an intermediate language, but in that case the compiler will not be able to generate the most efficient code. For example, a compiler that uses C as intermediate step can implement exceptions using setjmp/longjmp but this adds extra code at every function call. A compiler that goes directly to assembler can implement exception unrolling using static knowledge about the stack instead for a so called zero-cost exception handling solution.

Similarly, a compiler using C as intermediate will be forced to use a conservative garbage collector such as the Boehm GC. Using more efficient solutions such as a copying garbage collector is simply not possible without knowledge of the stack layout.

Re:C Programming Language

[icebraining]

From: Linus Torvalds
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT (2 years, 14 weeks, 16 hours and 36 minutes ago)

On Wed, 5 Sep 2007, Dmitry Kakurin wrote:
>
> When I first looked at Git source code two things struck me as odd:
> 1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
> it's BS.

*YOU* are full of bullshit.

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out,  that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes:

- infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)

- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.

So I'm sorry, but for something like git, where efficiency was a primary objective, the "advantages" of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage.

If you want a VCS that is written in C++, go play with Monotone. Really.
They use a "real database". They use "nice object-oriented libraries". They use "nice C++ abstractions". And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess.

But I'm sure you'd like it more than git.

            Linus
- - -
From: Linus Torvalds
Subject: Re: Compiling C++ kernel module + Makefile
Date: Mon, 19 Jan 2004 22:46:23 -0800 (PST)

On Tue, 20 Jan 2004, Robin Rosenberg wrote:
>
> This is the "We've always used COBOL^H^H^H^H" argument.

In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:

- the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
- any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
- you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.

Feel free to make up (d).

        Linus

Re:C Programming Language

[Anonymous Coward]

Writing well organized code doesn't make the language object oriented. Agree with you regarding the "assembler like" stuff the author wrote though - guess he doesn't know what he's talking about at all here (Just writing one simple program on an ugly arch, x86 should do very well here, should teach him the difference though :D)

Re:C Programming Language

[Hentes]

You can write object orientated code in C.

Writing OOP code and reimplementing an OOP language are two different things.

Re:C Programming Language

[flimflammer]

So you basically just agreed with what he said?

Re:C Programming Language

[geezer nerd]

Perhaps you cannot remember a time before C++ existed. Object-oriented ideas existed before C++ and some people wanted to use them in their code.

Re:C Programming Language

[geezer nerd]

In American English, one says and writes "oriented". In British English, the word "orientated" is used for the same purpose. Something I had to learn when I left the USA.

Re:C Programming Language

[geezer nerd]

Compilers compile to "object code" or "machine code", not "assembler language". It may be that some simple compilers produce output in assembler language that has to be separately "assembled". And the object code generated by some compilers may have to be interpreted by another program, such as the Java virtual machine.

Re:C Programming Language

[Kittenman]

In American English, one says and writes "oriented". In British English, the word "orientated" is used for the same purpose. Something I had to learn when I left the USA.

So the British book was "Murder on the Orientat Express"?

Re:C Programming Language

[eruza]

You can write object orientated code in C.

The OP never said you couldn't, they said: "no pretense to be object oriented" (Emphasis mine.)

And as far as sophisticated code, I guess the author doesn't consider operating systems or most system programming to be sophisticated.

Again that's not what the OP said, they said C has: "no pretense to be ... sophisticated" They're saying C itself is not sophisticated, that has nothing to do with the code written in C. Sand is not a sophisticated medium, but I've seen sand sculptures that are definitely sophisticated.

However, you are 100% correct in challenging the "assembler-like" comment.

Re:C Programming Language

[Genda]

Code is a way of expressing human thought (language) in a way that binary machines can interpret and perform. There has been a forever search for a language that best captures the grace and power of abstract human thinking elegantly.

One of those searches lead to Object Oriented Programming. An OO language breaks the organization of THINGS in a very natural way for western thinkers. The thought here is that by creating logical constructs representing an OBJECT which has both its own unique qualities and abilities, while at the same time inheriting qualities and capabilities from the family of OBJECT from whence it was derived, that you can perform wonderful things with a minimum of code and that if you were careful in designing your application that it should be easily adaptable and extensible to the vagaries of life. Of course this power doesn't come free, and there is operational code to support its behavior, so tiny problems or very small code may well demand C, while a large application is best implemented in a framework that gives you the logical freedom of an OO environment.

I see you nodding, is that you understanding or falling asleep... sorry if the monologue uses big words, they're part of the concepts. Anyway, languages have intrinsic power depending on their features and capabilities. Arguably, LISP is the most powerful language one can program in today. It is also one of the more syntactically challenging, and demands a fairly healthy understanding of what a machine is fundamentally capable of doing to use to its full potential. There is a spectacular free course available at MIT online, go here to read more about it, and decide if its something you might be interested in. While you're at it, you might want to read up in functional languages (for the more action oriented among us) or just spend a while over at Wikipedia learning about computer languages and how we got here. Definitely read a book on algorithms. Understanding how we take every day problems and reduce them to logical constructs, and how very smart people have optimized the process of managing those problems is a very cool exercise... and it'll grow your brain a notch or two (help you look at problems newly.) Master abstraction and reduction, and you've got a bright future wherever you go.

Re:C Programming Language

[Guy Harris]

From: Linus Torvalds Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library. Newsgroups: gmane.comp.version-control.git Date: 2007-09-06 17:50:28 GMT (2 years, 14 weeks, 16 hours and 36 minutes ago) ... In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.

And, for a view somewhat less harsh about C++, but still not a case of "C++ roolz, C droolz!", see The Old Man and the C, the abstract of which says

"You can't teach an old dog new tricks" goes the old proverb. This is a story about a pack of old dogs (C programmers) and their odyssey of trying to learn new tricks (C++ programming).

C++ is a large, complex language which can easily be abused, but also includes many features to help programmers more quickly write higher quality code. The TeamWare group consciously decided which C++ features to use and, just as importantly, which features not to use. We also incrementally adopted those features we chose to use. This resulted in a successful C++ experience.

Re:C Programming Language

[raftpeople]

I don't use oriented or orientated, I like to mix it up a bit by saying "orientized", for example, C++ is object-orientized.

Re:C Programming Language

[Guy Harris]

Compilers compile to "object code" or "machine code", not "assembler language". It may be that some simple compilers produce output in assembler language that has to be separately "assembled".

I.e., many UN*X C compilers, including but hardly limited to gcc, are simple? Or does hiding the "run the assembler" stage behind the compiler driver (cc, gcc, etc.) mean that the compiler "compiles to "machine code"" rather than to "compiling to "assembler language""?

Re:C Programming Language

[raftpeople]

"Code is a way of expressing human thought (language)..." - I assume you don't mean verbal language when you say language, right? Based on my experiences and those of most other developers I've talked to (not all), what is going on inside a programmers head that needs to be expressed by a computer language does not appear to involve much of our verbal language at all, rather it seems to involve an abstract/visual type of computation/manipulation.

Re:C Programming Language

[Anonymous Coward]

A compiler doesn't need to compile to object or machine code. In fact it's quite common for compilation to be broken into multiple phases with syntax/semantic analysis during the first phase which may result in an immediate representation such as assembly. This immediate representation can often be more easily optimized. A second phase then handles the generation of machine specific instructions followed possibly by further more architecture specific optimizations before producing relocatable/linkable object code.

Compilation is really just translation from a source language to a target language be it coffeescript to JavaScript, C++ to assembly, or C to brainf*uck to assembly to whatever.

Dragon book chapter one.

Books are your friend....well...maybe not *your* friend since you seem to know it all already...

Re:C Programming Language

[Anonymous Coward]

The problem with picking and choosing C++ features is that every project picks and chooses a different set of features. Then when you want to integrate projects or libraries, you're back to square 1, which is that you end up w/ the whole panoply of features and misfeatures, with about 3x more SLoC than necessary because everyone tried to predict the future and solved abstract problems instead of real problems.

With C you don't have to pick and choose. Everybody has the same set of tools, and there are only a handful of sane ways to apply them to any given problem. Rather than obsess over class hierarchies or template syntax, you just code.

Also, Tk is widely considered the easiest and most elegant GUI toolkit in existence, and it's a breeze to use from plain C. Of course, it uses Tcl internally, but Tcl isn't an OOP language. OOP isn't actually very useful, in terms of cost/benefit. Lexical closures and GC are far more useful, and of course neither C++ nor ObjC provide those. When C isn't the best tool for a job, neither, usually is C++ or ObjC.

Re:C Programming Language

[Anonymous Coward]

You can talk about abstraction and grace all you want. When it comes down to it, any programming language is the act of giving an ORDER. It is not a language in the sense that a language involves two way communication by intelligent parties. Your computer will only talk to you if you order it to do so, and it will only say exactly what you tell it to say.

Object orientated programming is a mental tool to help a programmer, not the machine. It is a mental tool to help a programmer write ORDERS to give to the machine. I only say this because you are implying that code is a language. It is not. And abstraction and the ideas of objected orientated coding aren't ORDERS.

Get off your high horse. The computer doesn't understand what you are thinking, no matter how strongly you feel that your human thought has been interpreted by the machine. Give the machine ORDERS, and if abstraction helps you, so be it. But don't let your obsession with abstracting everything get in the way with what you are actually doing. CS professors love OOP. Computers don't give a shit.

Re:C Programming Language

[bidule]

Similarly, a compiler using C as intermediate will be forced to use a conservative garbage collector such as the Boehm GC. Using more efficient solutions such as a copying garbage collector is simply not possible without knowledge of the stack layout.

Gambit-C uses C as intermediate and still has a full copying GC. Maybe that's not quite what you meant.

Re:C Programming Language

[Calavar]

Anyone who complains about STL portability issues clearly hasn't written a line of C++ code in the past decade. STL is the single most portable and consistent library behind the C standard library. And don't even get me started about efficiency psuedo-arguments. std::sort outperforms qsort by a huge margin on most platforms.

And--I know I'm going to be stoned for this--Linus =/= God.

Re:C Programming Language

[Anonymous Coward]

His comments speak volumes about the state of the Linux source code and how the kernel is organized. C and Linux are a perfect match.

Re:C Programming Language

[stepho-wrs]

Should that be "orientised"?

Re:C Programming Language

[cheesybagel]

Actually a compiler is just a tool that translates something written in a certain computer language to another computer language. GCL compiles Common Lisp to C. There used to be C++ compilers (e.g. Cfront) which compiled C++ to C. It does not need to compile to machine code. GCC compiles code to GAS (GNU Assembler) format then runs the 'gas' assembler to generate machine code.

Re:C Programming Language

[Anonymous Coward]

An OO language breaks the organization of THINGS in a very natural way for western thinkers.

The problem is the differences of viewpoints different developers may have on a subject matter and the resulting chaos. I think this is one of the reasons for the Linus quote on object models: "the end result is a horrible and unmaintainable mess." In a corporation, or a disciplined developing group the issue can be solved with ontologies but for a open or an less than defined project that might not be very practical. There is always the alternative viewpoint of partition and conservative extension (leading to the LSP) of the state space.

(for the more action oriented among us)

Put that "declarative orientated". The imperative languages provide the sufficient action for the action-o-holics. Actors, on the other hand, are the objects of our desires and hopes. ;)

Re:C Programming Language

[Anonymous Coward]

Mod parent up. His just ranting and hasn't addressed any part of the C++ Language.

- infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)

This is no different than the "infinite amounts of pain" when the C std library or any other c library doesn't work.

- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

This is no different in C. If you chose a particular method of doing something C and years down the road notice it's not very efficient you still need to rewrite your app to fix it.

Re:C Programming Language

[Anonymous Coward]

I see you nodding, is that you understanding or falling asleep... sorry if the monologue uses big words, they're part of the concepts.

yikes, really?

So you're saying LISP requires a healthy understanding of the machine in order for the programmer to be effective? Large applications are best implemented using OO because of the _logical_ implications? I seriously mean no offense when I type this but,what the fuck did I just read?

Re:C Programming Language

[luis_a_espinal]

And, for a view somewhat less harsh about C++, but still not a case of "C++ roolz, C droolz!", see The Old Man and the C, the abstract of which says

"You can't teach an old dog new tricks" goes the old proverb. This is a story about a pack of old dogs (C programmers) and their odyssey of trying to learn new tricks (C++ programming).

It is a good story and a good experience, but I certainly and strongly disagree with the following:

We never gave consts much thought. Looking back we do not recall any situations in which consts would have saved us. Still, they seem like a reasonable feature, especially in interfaces to class libraries. If an interface rigorously uses consts in its declarations, then users can know which parameters may be modified by which routines. This looks like another feature which is more valuable when producing a public API.

There is a reason why modern languages typically default-qualify parameters and attributes as const (and/or const ref). Having everything const by default makes life a shitload easier for software of any size.

Re:C Programming Language

[Anonymous Coward]

C is not object orientated does mean you can write code that is object orientatedly structured. There where some plans to add some fundamental object orientated concepts to C but the powers that be decided against it because they thought would just be implementing what 'C with classes' (early C++) had already done. I understand that argument but I think its a shame, C is a a language that has a purpose, if adding object orientated elements servers that purpose then go with it. The problem with C++, though I think its interesting as a kind of meta language, is that it doesn't seem to know what it's purpose is, it just seems to have the goal of supporting every possible language paradigm for the sole purpose total completeness. C++ is idealistic whereas C and Objective-C are pragmatic.

Re:C Programming Language

[pthisis]

You technically could...but why would you? If you want to write object oriented C, there's C++. What's the benefit?

C++ is a more expressive language than C. That's not necessarily better, though--I could define an extension to C where the + operator works between a string and an integer as follows:

mystr + myint is defined such that it returns a string of the same length as mystr, but where each element of the return value is myint less than the equivalent char in mystr. So "dddd" + 2 returns "bbbb", "zzzzz" + 3 returns "wwwww", etc.

This language is more expressive than C, but using the new feature is liable to confuse and obfuscate more than it is to help out.

C++ has a huge helping of extended features over C. For whatever reason, it seems to fall into a class of languages (along with PHP, Perl, C#, and Java) that seem more expressive up front but wind up creating less understandable and less maintainable code in the long term than using alternatives (e.g. C, Python, ML, Lisp) has at the places I've worked. Programming language is really a low-level human interface problem, so it's really tough to know until you use a language for a long time in a large group whether it's likely to be a big advance or not--there are some (e.g. Ruby, Scheme, Objective C) that I don't feel I have a grasp on at all yet.

But given pretty considerable experience using both C++ and C, I'm fairly confident that using C++ is a far worse idea than using C for new projects; that's not to say that defining some subset of C++ and using it on a well-defined project might not be a good idea, but essentially to answer your question: Because C++ in practice turns out to be horrifically unmaintainable in most cases compared to straight C, despite seemingly requiring less contortions to write decent OO code.

And studies like TIOBE sort of help quantify this and reassure me that it's not just personal anecdote, it's by and large the experience that most of the programming world has had over the last 15+ years.

Re:C Programming Language

[lennier]

In American English, one says and writes "oriented". In British English, the word "orientated" is used for the same purpose.

Really? I speak British English, and I've never heard that usage. To me, to "orientate" means to get one's bearings by observing one's surroundings. To "orient", on the other hand, means to point or lean or have a tendency in a certain direction.

(Don't get me started on "architecting" and "administrating" either.)

Re:C Programming Language

[ceoyoyo]

Amen. Linus is a pretty smart guy.

Re:C Programming Language

[rrohbeck]

I prefer orientificated. Sounds way bigger.

Re:C Programming Language

[lennier]

An OO language breaks the organization of THINGS in a very natural way for western thinkers.

Yes. And that right there is a subtle trap.

The first problem is that the "tree of subclasses" organisation, while on the surface seeming natural, is not in fact an accurate description of real taxonomies found either in nature or in large software projects. Especially so if the "software" includes business data. It turns out there are an awful lot of platypuses in the real world, things which simply don't fit neatly into the tree.

For example, a classic "toy" example often used in the OO analysis world is a database of employees. Lets see, we have managers, and we have workers. Great, we can subclass those! We'll have an abstract Person class, then personWorker and personManager who are subclasses of Person. Instantiate Jack Smith as an instance of class personWorker. Problem sol - um. Wait. Jack just got promoted from a worker to a manager. Crap. Can our OO system of choice handle dynamically changing an object's class during its lifetime? No, it enforces strict classing, so it can't. Oops. No problem, we'll delete Jack and recreate... oh. His entire work history was attached to that object, linked by opaque reference and not by name or staff ID, and now it's all gone forever. Double crap. Oh well. He's left the company anyway, and now he's come back as a private contractor. We'll just make him a new personContractor. Easy. Yeah, wait, now we're dealing with him also over in the billing system as a personSupplier. But wait, there's more, he just bought some stuff from us, so he's also a personCustomer! Now he's three classes at once! The universe has gone crazy!

Most real OO systems "solve" this problem by either not doing inheritance here at all - therefore completely invalidating the "OO is about inheritance" line - or duplicating the data in multiple objects - thereby invalidating the "OO is about modelling the business domain directly" line. But at this point we're really starting to lose most of the advantages of OO entirely.

But there's a second, even more subtle problem: although OO usually uses "class" as a synonym for "type", it turns out that subclasses are NOT at all the same thing mathematically as a subtype. (Because you can override the behaviour of a class, meaning its behaviour is now not a strict subset of its superclass, but can also be a superset.) In fact there's no really sensible definition of "subtype" at all - Liskov substitutability requires that you define a context within which you want to limit your idea of "equality", and over the scope and lifetime of a sufficiently large software system, that context is going to change radically. So there goes all your type safety. Add in runtime reflection (which was a fundamental principle of Smalltalk, the first OO system, but seems to be an optional add-on recently tossed haphazardly back into the modern variety) and things get even more confused.

And finally, even the idea of typing can become a third subtle trap. Even if you could (which you can't in the real world) restrict your software system to a neat tree of subclasses corresponding exactly to strict subtypes in a glorious Platonic universe - if you look at your code carefully, you find out that your class/type structure, no matter how strict and clever you make it, doesn't actually tell you anything about the behaviour of your objects. It only tells you the calling signature. That you've defined an addOne method in all your IncrementableByOne class structures doesn't mean that any of those subclasses actually have to implement int addOne(int X) as returning X plus one - just that they receive and emit an integer. So after all your compile-time declarations, you've gained a whole lot of not much at all, and you have to implement a whole testing harness apparatus to do by hand what your compiler initially promised it will do.

tl;dr: Just like (insert a political philosophy you dislike), OO is a big idea, a seductive idea, but not actually a correct idea. And attempting to apply thoughtlessly will cause pain.

Re:C Programming Language

[Tough Love]

You can write object orientated code in C.

Having done a lot of that I can confidently state that it sucks beyond belief.

Re:C Programming Language

[Tough Love]

For all his brilliance, Linus is stupid about some things. One of them is his near complete lack of understanding of C++. He obviously has zero skill in it, but he has plenty of skill at getting up on his pulpit and flaming people who do.

Re:C Programming Language

[Tough Love]

- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

This is no different in C...

The same problem is much worse in C. Because you will have grafted a crappy half-OO hack onto it that has accreted stupid numbers of macros, casts and other abuses. And it will be hell to change. Speaking from experience.

Re:C Programming Language

[Anonymous Coward]

I'm sorry, this is just factually incorrect.

A compiler translates a higher-level language (such as C or C++) into assembly then an assembler translates that to object code at which point the linker is invoked. Most user facing compiler commands (e.g. when you type gcc soure.c) will do these three steps automagically. So no, a compiler does not compile directly to object code.

Re:C Programming Language

[SpeedBump0619]

You can write object orientated code in C. You don't always need the language to hold your hand.

Yeah, but sometimes you just get tired of typing the same boilerplate into every single function. I program in C most of the time and have dealt with at least three different "object oriented c" implementations. Every single one ends up with a this pointer (this/self/me) as one of the function parameters and every single one uses some variant of GetObjectFromMember for virtual functions:

void ExitSensorArrivalTimer_v_MSecTimer_expiry( MSecTimer *timer_self )
{
      Sensor *self = GetObjectFromMember(Sensor,m_exitSensorArrivalTimer,timer_self); ...
}

Sometimes a little language hand-holding helps limit the carpal-tunnel issues. This macro is also quite error prone (since C provides almost no type safety when casting pointers to and fro).

Re:C Programming Language

[Anonymous Coward]

What made Linus's butt hurt so much? He sure is mad.

Re:C Programming Language

[GodfatherofSoul]

By that logic, I can write OO code in assembly. If the language doesn't support it out of the box, it's not considered OO.

Re:C Programming Language

[shutdown -p now]

Linus is a pretty smart kernel programmer & architect who programs almost exclusively in C. It's no surprise that he doesn't even want to grok C++.

Re:C Programming Language

[shutdown -p now]

Your post is basically an argument against OOP done wrong (which, granted, is most mainstream languages out there), not against OOP as a concept. Have you seen the object model of Objective Caml? It specifically deals with issues such as inheritance is not subtyping etc.

Re:C Programming Language

[SpeedBump0619]

Creating unusual object structures:
I once played around with a state machine framework that was object oriented c. It had a virtual table at the top of one base class and at the bottom of a different one. Using the same layout in the virtual table allowed multiple inheritance without any special effort and without any wasted space. It's the only object structure I've ever played with that I couldn't implement with C++ classes and inheritance (I guess a *really* good C++ compiler might be able to optimize to that structure)

Virtual Static members and member functions:
There are occasionally times when I need polymorphic behavior, but the behavior itself isn't instance specific. As a contrived example, imagine needing to query an instance of an object for the total number of peer objects that are in existence (I'm probably managing a count during construction/destruction). I need to call some member that is class specific, but that member will only need to use static members to execute. As it is this ends up being declared virtual and the this pointer is (needlessly) passed in.

Those are the only two instances I've run across where I actually wrote code up to the point of noticing that I couldn't do that in C++ (I'm actually still shocked ten years later that there's no such thing as a pure virtual static function).

Re:C Programming Language

[bbn]

Gambit actually has a hybrid system that uses reference counting to solve the problem. It does not scan the C stack and can therefore not move objects still referenced from the C stack.

Re:C Programming Language

[Anonymous Coward]

Similarly, a compiler using C as intermediate will be forced to use a conservative garbage collector such as the Boehm GC. Using more efficient solutions such as a copying garbage collector is simply not possible without knowledge of the stack layout.

a) Build a special stack for local object pointers.
b) Use handles instead of raw pointers.
c) Do some extra bookkeeping work so that you can indeed walk through the important bits of stack without knowing its exact layout.

Obviously each approach carries some penalty but that's still far from impossible.

Re:C Programming Language

[goose-incarnated]

An OO language breaks the organization of THINGS in a very natural way for western thinkers.

Yes.

Actually, no, it doesn't. OOP doesn't resemble the way humans think, plan or action in any way whatsoever - psychologists' studies have revealed a lot about how humans tend to think, and none of their studies bear out the assertion "But OO is more intuitive". You, yourself, spend the next few paragraphs explaining why human built structures (like that of an organisation) aren't OO in design.

We don't think in terms of OO, and we never did.

Re:C Programming Language

[beelsebob]

behind the C standard library

Isn't that exactly what Linus said?

Re:C Programming Language

[beelsebob]

The funny thing to us British English speakers is that "oriented" means "facing the orient", i.e. to the east.

Re:C Programming Language

[beelsebob]

No it wasn't, because the british english word "oriented" means "facing the orient" i.e. the east. The orient express was so called not because it was about the concept of being an express, but because it went to the east.

Re:C Programming Language

[Richard_at_work]

And yet he's replying to someone that seems to want to use C++ for the sake of using C++...

Re:C Programming Language

[gl4ss]

in the past decade?
hahahah. ever tried symbian in the past decade?
hasn't stl changed itself in the past decade enough too?

most of the time it's not about effieciency so much as it is about if the shit will compile at all on the compilers you can use for the target..

Re:C Programming Language

[bbn]

Nothing is impossible to emulate, it is a turing complete language.

But the problem is probably harder than you realise. For example the C compiler can chose to store a pointer in registers and it can optimize variables away entirely. For this reason I do not think your option c) is really possible, not without assuming an awful lot of things about the C compiler.

My point was that you can not write C that will do such thing the same way as a program written in assembly. And you can not write a C program that emulates it in a "natural" way. Compilers can generate code that no human would ever want to write manually.

Re:C Programming Language

[Anonymous Coward]

The thing is, Linus is right. STL has one single problem - it defines an interface, not an implementation. If you are writing any sufficiently large scale app, then using STL is just a massive pain in the arse. If you build a dso against one version of stl, and you then need to interface to some 3rd party library (which uses some other version of STL), you immediately start having problems. You quickly end up doing all sorts of cludgy hacks including horrors such as importing two versions of STL into 2 seperate namespaces, wrapping STL objects behind additional pointless layers, etc.

Anyone who claims STL is portable, hasn't had any experience what so ever with true cross platform development (I've been a middleware developer in games for the last 7 years). Your assertion that STL is consistent across platforms is complete and utter crap. Dig a little deeper into those headers (or rather, 4 different implementations, on your 4 target platforms) and you'll quickly find that consistency is something that really doesn't exist in STL implementations. And to counter your time argument, I've been programming C++ professionally for well over a decade.

Re:C Programming Language

[Anonymous Coward]

I think you mean "orientised"

Re:C Programming Language

[Ash-Fox]

If that were true then multiplatform games written in c++ would use STL more often.

Re:C Programming Language

[jabuzz]

Being English I find orientated is a verb meaning to be lined up with something, so I can just has happily be orientated to the North Pole as with the Orient which is a proper noun and is a geographic region.

I never quite get this American notion that English words only have one meaning.

Re:C Programming Language

[beelsebob]

Note – oriented and orientated are not the same word. Orientated – facing in a direction; Oriented –orientated to the orient.

Re:C Programming Language

[aaaaaaargh!]

Arguably, LISP is the most powerful language one can program in today. It is also one of the more syntactically challenging

It is annoying that this nonsensical myth keeps coming up, which must be spread by people who have never done any extensive LISP programming. LISP has without any doubt an extremely simple syntax, in terms of syntactical simplicity it comes right after FORTH and is only surpassed by Scheme. A LISP program is nothing but a collection of S-Expressions. Yes, there are many parentheses, but in combination with prefix operators these are the reason why LISP's syntax is so simple, not vice versa.

When you're doing real LISP programming, the problem is rather it's semantics. Every program and every package creates a re-usable, often domain-specific sub-language, and it is very easy to loose track of all the functions you have, accidentally reinvent the wheel, or translate between redundant data representations. This in combination with lack of strong typing creates a maintainability problem. It is very easy to write obfuscated code in LISP that only very experienced programmers can decipher. However, the reason for this is almost never complicated syntax, which would have to be created by reader extensions and macros, but rather overly complex abstraction in combination with sloppy function naming and/or lack of documentation.

Re:C Programming Language

[Viol8]

"How do you implement zero-cost exception handling? (longjmp is NOT zero-cost because it requires setjmp)."

You seriously think C++ exceptions are zero cost?? The compiler saving the stack for you at a "try" instead of you having to explicitly call setjmp will make no difference to overall performance.

"But how would you go about changing your memory allocation (malloc) to use a copying garbage collector"

Why would you want to? Garbage collection is an inefficient way to free up memory that is used in hand holding languages for low skilled coders.

Re:C Programming Language

[ls671]

I have seen more OOP done wrong than right. In every team I lead, I have to put the breaks on inheritance. For many young dude starting in OOP, inheritance == OOP, and the more inheritance you have, the better.

The GP post first example would be better implemented with a class Person and roles.

One of the first thing I do when assigned to existing code is put the sources into something like Enterprise Architect to get a picture of the code. When it is crowded with inheritance, I know I am in for a hard time.

Inheritance should be used sparsely and where it makes sense. The more the better is a very common mistake done in OOP. The too common "root class" (often called "RootObject") from which all other classes inherit is not the way to do it. Use other classes instead of inheriting all the time! ;-) Person Objects would be linked to a list of Role Objects.

Re:C Programming Language

[dgatwood]

In general, I'd say that anybody who designs his kernel modules for C++ is either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.

Feel free to make up (d).

Ironically, by the time he posted that, there was already a D: "writing drivers for Mac OS X."

The key to making C++ usable was to strip it down so that it was basically C with classes—no STL, no exceptions, no templates, no multiple inheritance, and no RTTI. Once you get rid of all those potential binary compatibility problems, fundamentally kernel-unsafe practices, and debugging headaches, C++ is actually not significantly worse for kernel programming than C, and is noticeably easier to read.

Re:C Programming Language

[bbn]

You seriously think C++ exceptions are zero cost?? The compiler saving the stack for you at a "try" instead of you having to explicitly call setjmp will make no difference to overall performance.

I do not know how major C++ compilers do it (*). I personally made a Standard ML compiler that implemented zero-cost exceptions handling. The compiler will NOT save the stack at a try, it does not need to. Instead the compiler will generate a static map of the stack. At the "throw" point the code will check the return address on the stack. You then take this address and make a lookup in a table that maps the address space for all functions, this tells you what function called you. Then you lookup the static stack map for that function, which tells how to unwind the stack correctly.

There are plenty of papers on the subject. Look it up, you might learn something.

(*) A quick google search shows that GCC does indeed use zero-cost exceptions: http://stackoverflow.com/questions/691168/how-much-footprint-does-c-exception-handling-add

Re:C Programming Language

[Anonymous Coward]

[citatian needed]

Re:C Programming Language

[umghhh]

there is some truth in what he says too. There is a lot of BS around use of this or that language. I have seen horrible code written in java and c++ by people who did not know what programming is. It is a notch easier especially in Java to write 'working' code which attracts all sorts of lunatics. The fact is however these people that mess up java and c++ (as well as other objective languages) written code they also mess up any language - that is their nature. The problem here is that coding itself is just a relatively small an activity that is crucial but not sufficient to produce good applications. You need common sense, negotiation skills (to talk with your colleagues, other teams, customers and their representatives etc), sense for planning and assessing quality and costs etc, AT the end you spend only limited time coding. Good example of what I mean is on ars - winamp and why it went wrong (or why it is perceived so). Quite a good read. SO he is right and he is angry. I was angry too but I noticed this prevents you from getting things done. I code in what I have to.

Re:C Programming Language

[angel'o'sphere]

Well, seems the AC and his modders don't knwo much about C (or its history).

You can write object orientated code in C.
No you can't. You can emulate oo by doing everything yourself what a C++ compiler would do. That is a hughe difference if you program object based and provide the infrastructure by your slef, or if you have an oo language.

And C is NOT assembler-like language. Not even close.
Yes it is. It is designed to be a portable assembler. And when we talk about C and its history we usually refer to K&R C. If you find that ANSI C is to far evolved ... well I disagree. It is still only a portable assembler for me.

  I guess the author doesn't consider operating systems or most system programming to be sophisticated.
Sophisticated concepts and ideas and tools don't necessarily require sophisticated coding. Most of the time Operation Systems are coded very conservatively. E.g. they are not easy to test. So you aim for simplicity and understanability.

E.g. read: Unix Programming Environment (Prentice-Hall Software Series) [Paperback]
Brian W. Kernighan and Rob Pike. There is another standard book about the design of unix, for got the name, someone else might be able to point it out (the old one, not the new one from ERS).

Re:C Programming Language

[Anonymous Coward]

For example the C compiler can chose to store a pointer in registers and it can optimize variables away entirely.

As long as I'm accessing that pointer without invoking undefined behaviour, then no, it can't (of course excepting the "as if"-rule, eg. when compiler decides to inline the GC call and use those registers there directly).

My point was that you can not write C that will do such thing the same way as a program written in assembly.

Yeah, not debating that.

And you can not write a C program that emulates it in a "natural" way.

"Natural" is a matter of viewpoint. To me CPU-specific hacks are less natural than portable code. (probably due to too much c.l.c..)

Re:C Programming Language

[Anonymous Coward]

Not to dump too harshly on C++, which I've programmed in for over 15 years now,
but ...
> decided which C++ features to use and, just as importantly, which features not to use ... any language which has so many 'features' that you have to pick and choose which are the good and which are
bad has got to be too complex for (and unintentionally dangerous) it's own good.

Now, about Objective-C, nice language which does OO in a fairly simple way, yet allows for some powerful abstractions,
mostly via the inter-object message passing paradigm that's built into the language. I particularly like the target-action pattern
that's possible and even NSInvocation. These features make it particularly suited to building GUI apps, but not so performant
for server side - where standard C probably still is the best suited.

Cheerio!

Re:C Programming Language

[angel'o'sphere]

Gambit-C is a scheme to C compiler. So I assume it is not using standard malloc() and free() to manage memory.
Your parent was talking about using the memory management by the stdlib and adding an GC on top of it.
You are talking about generating C code and integrating an GC into it, not relying on malloc/free.

Re:C Programming Language

[Rockoon]

You will often see comments to the effect that C is like assembler or that you can do anything in C it just lacks some syntactic sugar. But that is very wrong.

Its the "assembler like" that really grinds my gears. So not only do we have to deal with C programmers that think its "low level" but also the twits that think its "assembler like."

C is a high level language. Its only low level feature is pointers, but even that is in a high level incarnation that manages type size for you. C is founded upon a simplistic abstract machine, however "simplistic" is not an equate for "low level." The C abstract machine literally has no concept of any actual low level hardware features, so is by definition not low level.

When you look at the wikipedia page for "high level language" it amazingly says "Some decades ago, the C language, and similar languages, were most often considered "high-level", as it supported concepts such as expression evaluation, parameterised recursive functions, and data types and structures, while assembly language was considered "low-level". Many programmers today might refer to C as low-level, as it lacks a large runtime-system (no garbage collection, etc.), basically supports only scalar operations, and provides direct memory addressing. It, therefore, readily blends with assembly language and the machine level of CPUs and microcontrollers."

So all those years of C programmers claiming that they were low level programmers has finally stuck I guess.. but not because C has any low level features.. but because it lacks some high level features.. seriously.. thats the new definition.

Re:C Programming Language

[hibiki_r]

Your type safety only goes away only if you shoot yourself in the foot in the first place. Yes, I can break some generic code by overriding an interface in a way that completely subverts it. But I can also, say, feed a call counting function to a sorting routine that, instead of comparing two elements, returns true if the number of calls is even, and false if it's odd, and make the sorter fail. Oh noes, I was malicious and I broke code! This happens if your language is object oriented, procedural or purely functional.

All we really have to do, in any language paradigm is to make code sufficiently clear as to minimize the chances of your average dev to break interface contracts accidentally.

Re:C Programming Language

[angel'o'sphere]

The main problem with object orientation is the teaching.

As you correctly point out the toy example is a complete wrong design.

There are endless examples for inheritence and I would make a wild guess that 90% are wrong for real world aplications.

In you toy example you only need one single Employee, what he is doing is factored out into a role. Either an enum, or a small class hierarchy "describing" his capabilities and responsibilities.

However as long as OO DBs are not becomming mainstream every OO design is partly bound and hindered by relational DB and mapping constraints.

I fully agree with your points, though.

Re:C Programming Language

[Viol8]

"Instead the compiler will generate a static map of the stack"

Oh really? So its arrived in function X (say strlen()) and its made a pre compiled map of every possible variation of the stack that could exist having arrived at that function including recursion? Function return addresses, parameter values, automatics values?

What a total and utter crock. Perhaps you could somehow get away with it in a functional language since it doesn't retain state but good luck trying it with C/C++.

Re:C Programming Language

[Coryoth]

You just need non-conforming inheritance, or composition, or whatever you want to call it. Essentially its just the ability to "inherit" without also making the result a subtype of what you are inheriting from. Multiple non-conforming inheritance allows easy composition of classes and can be pretty powerful.

Re:C Programming Language

[hazah]

That isn't different for natural languages. The abstractions are simply living outside of the computer for those types.

Re:C Programming Language

[angel'o'sphere]

There are different ways of thinking.

When I program / design / analyse I think in the paradigms required. That means: yes I think in oo.

If I talk with my GF about Sex I use a different vocabulary, though ...

Re:C Programming Language

[Viol8]

Low level in the sense of C means direct manipulation of memory addresses including pointers, usually a fairly obvious mapping of C code to assemby code and allowing 2 way interaction with inline assembly code. Also there is very little implicit assembler being generated unlike with C++ for things such as constructors, destructors, hidden conversions, template code duplication , pre-main() initialisation etc etc.

Re:C Programming Language

[Anonymous Coward]

You chose a very bad example.

Why would anyone create personManager as a subclass of person?

You would create a person, with a list of position instances and dates. You could also have a position class, and have all the jobs use that. Probably not as subclasses, though.

Use composition instead of inheritance.

And there's a chance that attempting to apply _anything_ thoughtlessly will cause pain.

Re:C Programming Language

[Anonymous Coward]

>> STL is the single most portable and consistent library behind the C standard library.

Oh really???

I refer you to std::map::erase. Try using that consistently on both gcc and Visual C++. And that is only one such example.

Re:C Programming Language

[bbn]

Oh really? So its arrived in function X (say strlen()) and its made a pre compiled map of every possible variation of the stack that could exist having arrived at that function including recursion? Function return addresses, parameter values, automatics values?

There are no variations. There is only one copy of the code for strlen in memory. And only one copy of the code that called strlen. That is what we are looking up.

Say the code for your calling function located starting at address X and continues until address Y. And lets assume strlen is going to throw an exception. Since the throw command is in strlen it knows all about the strlen stack layout. It will find the return address Z from the stack. If it was your function that invoked strlen that address Z will be between X and Y. Using a binary search (*) for Z in the static table, the throw code will find the address of the exception handler for your function. It will then unroll the stack back to the state of calling, then jump to the exception handler.

We are now in the exception handler of your function. Your exception handler knows the size of the stack for your function. If the exception is not handled, it repeat the process by unrolling your part of the stack, lookup the return address to find the next exception handler and so on.

Recursion, varargs and what have we is not a problem. It is all handled just like a normal function return, except instead of jumping back to the original calling point we jump to a exception handler.

(*) as an alternative to a binary search it is also possible to store the address of every single function invocation within your code. In this case you can use a hash table lookup instead. This method also enables the compiler to have special handling for each and every invocation point if needed.

Re:C Programming Language

[MadKeithV]

And don't even get me started about efficiency psuedo-arguments. std::sort outperforms qsort by a huge margin on most platforms.

Here's a counterexample: a standards-compliant implementation of std::vector cannot contain aligned types if the single-argument resize member function is ever called explicitly or implicitly, because per the standard it takes a by-value argument, and you cannot pass aligned types by value while preserving the alignment.

Now, you're forgiven for perhaps thinking that is *obscure*, but it isn't if you care about low-level details. SSE instructions require alignment of their input types. An SSE implementation can be 2 to 4 times faster than a regular x86 one on supporting platforms.

Re:C Programming Language

[Anonymous Coward]

You're just being foolish. Being an object oriented programmer who actually knows what he's doing, I'll help you out.

You start with interfaces for person, employee, manager, consultant, client, and supplier.

You also have a back-end database with data tables for person, employee, manager, consultant, client, and supplier, with all tables FKing back to person.

You create your software system so that person is an abstract base class, and the rest are subclasses of the abstract base class. Manager is a subclass of employee (because managers are special employees). Consultant is a subclass of employee because they're special too (hee hee). All employees implement the "employee" interface; each implementation is handled differently in code.

Then, the class holding a person's data is determined by the context (the part of the application your'e in) and the person's current STATUS in that context, with the understanding that a person can have more than one status, and that each status applies to a specific context.

You put the person's employment history in a separate data table and create an employment history object for the employee object to hold. The last entry in the employment history determines whether the person is a plain-old employee, a manager, or a consultant. When you instantiate an employee, you start with an employeeFactory factory object, and it produces the correct kind of employee object. Because they all implement the employee interface, you don't have to worry about any special code, it all just works.

I could go on. The main thing is, if you're going to do OOP, learn patterns, and do it RIGHT.

Re:C Programming Language

[gman003]

C is not a sophisticated language. No objects, no runtime bounds checking, no exceptions. No cruft.

Likewise, a sword is not a sophisticated tool. It's a grip, a hilt, and a blade. If you want to get fancy with a ricasso or pommel, go right ahead, but that's about as complicated as it gets.

But few would say that experienced, trained sword fighters cannot perform sophisticated, elegant tricks. And few would say that you cannot write a sophisticated, elegant program in C.

It's just really freaking hard, because if you do it wrong, you'll chop your own arm off.

Re:C Programming Language

[Anonymous Coward]

However the real story is that C, a raw machine independent assembler-like language, with no pretense to be object oriented or sophisticated, has beaten all three of the object oriented heavy weights

This sounds like it was written by someone who doesn't understand C. You can write object orientated code in C. You don't always need the language to hold your hand. And C is NOT assembler-like language. Not even close.

This sounds like it was written by someone who doesn't understand Assembly language.

Re:C Programming Language

[Calavar]

The standard the following are the proper overloads for std::map::erase:

void erase(iterator pos);
size_type erase(const key_type& key);
void erase(iterator start, iterator end);

If you are using the size_type erase(iterator pos) provided my MSVC++, then you are using a nonstandard extension, so you shouldn't be surprised if your code does not port to GCC.

Re:C Programming Language

[Calavar]

Rebuttal. This is just one guy's opinion, so take it for what you will.

Re:C Programming Language

[Calavar]

You are right to an extent. C++ is not as portible as C, but it is definitely among the top five most portable languages. And yet there is disproportionate bashing of C++'s perceived lack of portability. Meanwhile, Java is praised for its portability. "Write once, run anywhere." Of course, the official JVM was also only written once, and it was written in C++, so Java only runs on a subset of platforms on which C++ is usable. Wouldn't you think that this makes C++ more worthy of the "Write once, run anywhere" label? My point is that, yes, C++ is less portable than C, but it is portable enough for most programs. You can't honestly expect me to believe that Linus wrote git in C because he was worried about whether he would eventually be able to build git on Symbian.

Re:C Programming Language

[Calavar]

This may shock you, but C library implementations also vary from platform to platform. You will have the same trouble using 3rd party libraries that were linked with different implementations of the C standard library. So how does this prove that C++ is less portable than C?

Re:C Programming Language

[Calavar]

Some quick googling suggests that STLport is very stable on Symbian. Nonetheless, I can see where you are coming from--probably not a good idea to write C++ applications for Symbian. But your argument is not a good defense for Linus because I highly, highly doubt that Linus was trying to target systems like Symbian with git. C++ is portable enough for most situations. See my reply to another commenter above.

Re:C Programming Language

[Anonymous Coward]

Your example is broken.
You chose Job Function as your class. Then complained when you changed a persons Job Function.
Which is odd since changing job function, or even having multiple roles is quite common.
For example team leads are often manager/workers in some respects

Better to have
Person, and Job Functions as separate classes,

Re:C Programming Language

[shutdown -p now]

That was exactly why I suggested looking at OCaml. As noted, in it inheritance is purely a code reuse mechanism which does not imply subtyping - it's perfectly possible to have A inherit from B without A being a subtype of B (because, for example, B defines equals in such a way that requires its parameter to be of same type as receiver - the language has the concept of a "self type", which is like an implicit type parameter). For subtyping, it uses compile-time structural typing against the visible surface of the class, which is pretty much the strict LSP definition to the extent it's enforceable by the type verifier. On the other hand, as a code reuse mechanism, inheritance much less restricted than in many other languages - you have full-fledged MI, and fine grained control over the visibility over whatever you inherit.

Re:C Programming Language

[Viol8]

Ok , fair enough. Except that scenario requires the stack to be unrolled in the reverse order to that which it was rolled up. longjmp literally allows the program to immediately jump anywhere in the code without any unrolling being done, it just replaces with stack with whaveter setjmp had saved which in that particular scenario is a lot more efficient.

Re:C Programming Language

[EllisDees]

Who am I to disagree with Linus? :)

Seriously, though, I hate C++ just as much as he does. It feels like a slapped together pile of crap. If you want to write OO, use java.

Re:C Programming Language

[benhattman]

Does that really matter? Of course many of his complaints about C++ are erroneous (though for kernel code I'd agree with the C++ exception mechanism complaint). On the other hand, his work has been incredibly beneficial to the community. The fact is, almost all of us are really dumb about somethings, even if we're really smart about other things. Sometimes, we're even really convinced we're right when we are wrong. Often, the smarter you are, the more convinced you will be about what you're wrong about. These generalizations are broadly true, and in this case they are true about Linus as well.

Here's the thing though. Where he's wrong, he's not really doing any damage. Suppose he convinces some teams to use C on projects were C++ would have been more appropriate. So what? Those teams might waste a little time reimplementing lists or some such thing, but overall they will probably be approximately as successful as they would be without the 'no C++" rants. It's not like he's making erroneous claims for weapons of mass destruction...

Re:C Programming Language

[Anonymous Coward]

But how would you go about changing your memory allocation (malloc) to use a copying garbage collector? Or do lazy evaluation Haskell style? How do you implement zero-cost exception handling?

All of these have been,and are easy to do in c. Implementing your own malloc is exceedincachegly common. Also see kmem_ cache_alloc for the kernel doing more or less exactly what tippy asked for. Oh and goto goto goto for exception handling.

Re:C Programming Language

[Rockoon]

Low level in the sense of C means direct manipulation of memory addresses including pointers

This is essentially the crux of problem with calling out memory manipulation as "low level." The ability to read and write memory is not unique to low level languages at all. Hell, quickbasic had lower level memory access in that the language gave you simple implicit control of the target segment register (DEF SEG) whereas in C you had to use a higher level (FAR pointers) abstraction, which caused the very need to emit implicit assembler for every far pointer use, implicit assembler which you then go on the deride:

Also there is very little implicit assembler being generated unlike with C++ for things such as constructors, destructors, hidden conversions, template code duplication , pre-main() initialisation etc etc.

You have proved my point here. You are declaring C a low level language because of what it lacks rather than what it has. "Low level" used to mean a set of architecture specific features, not a lack of high level features. Somehow you language bigots have managed to redefine what "low level" means to be "that which C does." Its ridiculous but I guess with that wikipedia shit, that you've somehow won. Congratulations on your empty victory.

Soon I guess BASIC will be low level, right? Wont find any constructors, destructors, templates, and so on. Lack of features = low level, right?

Re:C Programming Language

[bbn]

The so called zero-cost exception handling is a tradeoff. It is only zero cost when no exceptions are thrown. The actual exception handling is more expensive than a setjmp/longjmp strategy.

However remember that C++ requires that you run all the destructors during unwinding. You will probably not be able to simply skip through a ton of stack for this reason. Other languages without destructors (most garbage collected languages) can have greater gain from using longjmp.

Re:C Programming Language

[Anonymous Coward]

This is a very common line of argument from pro-C++ religious zealots. Would you care to explain why it's "obvious" that he has "zero skill?" Or would that actually involve independent mental effort on your part?

Re:C Programming Language

[Anonymous Coward]

Woah, what a load of crap. OO means object orientation. It means grouping functions which work on specific data types together, so your code is more organized and it is easier to achieve modularity, a key factor for reuse and reduction of bugs. Inheritance is something made *possible* by object orientation which *allows* reuse. Another way to shot yourself in the foot, but you don't have to. Please burn whatever crap book you read that hierarchy example from.

Re:C Programming Language

[cthulhu11]

In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off",

First time I've ever had /. mention an ex-roommate. When it comes down to it, both C++ and ObjC reek, the former via New Jersey and the latter via Brad Cox. And I do mean "reek" literally.

Re:C Programming Language

[bbn]

Feel free to try to implement a malloc that uses a copying garbage collector. Maybe you should take the Computer Science 101 first to learn what it is though. Or try wikipedia.

To not leave you completely in the dark I will give you a hint: A copying garbage collector will regularly move memory around (copy it). This means the pointers change. You might make a malloc that returns a pointer to some memory allocated by the copying GC, but at some unknown point in the future this pointer will become invalid because the GC decided to move the memory. To fix this, the GC needs to scan the stack and change all references from old pointer to new pointer. And THAT is what you can not implement in straight C because you have no control over the stack in C. You also need a way to flush all register allocated variables onto the stack so they can be scanned. You could easily enough change the pointers if you just knew what data on the stack is a pointer and what is not. However there is no way to tell the difference between a random integer and a pointer on the stack.

A copying GC is a common memory allocation strategy for a lot of computer language implementations. I used it as an example of something that would be very hard to implement in C to illustrate that C is not assembler.

Re:C Programming Language

[Tough Love]

A grain of truth makes for a better rhetorical rant. His ignorance on this issue shows through plainly nonetheless, with a healthy smattering of claims that are clearly wrong.

Re:C Programming Language

[Anonymous Coward]

CLOS can get around everything you mention, quite nicely; but then I've read that the
C++ folks don't consider it an Object system in the first place :)

Re:C Programming Language

[Tough Love]

for kernel code I'd agree with the C++ exception mechanism complaint

That's a blatant logical falacy from Linus - a straw man. Linus is the only one who talks about using exceptions in kernel. An experienced C++ programmer would just compile with exceptions disabled, as I do in cases like this. And by the way, avoiding exceptions on error paths in normal application programming is just sheer stupidity, usually justified by some kind of ancient lore about overhead.

Re:C Programming Language

[UnknownSoldier]

Very well stated!

Summary: An expert knows when TO and when NOT TO use certain tools. In the hands of a novice C++ tends to lead to over-engineered solutions. In the hands of a master C++ can succinctly express idioms.

OOP is a design tool; not an measure of efficiency.

There are times when it is the right solution, and there are times when it is the wrong solution.
i.e. Mike Acton's famous "Typical C++ Bullshit."
http://macton.smugmug.com/gallery/8936708_T6zQX/1/593426709_ZX4pZ#!i=593426709&k=ZX4pZ

Re:C Programming Language

[Anonymous Coward]

You technically could...but why would you? If you want to write object oriented C, there's C++. What's the benefit?

C++ is a more expressive language than C. That's not necessarily better, though--I could define an extension to C where the + operator works between a string and an integer as follows:

mystr + myint is defined such that it returns a string of the same length as mystr, but where each element of the return value is myint less than the equivalent char in mystr. So "dddd" + 2 returns "bbbb", "zzzzz" + 3 returns "wwwww", etc.

This language is more expressive than C, but using the new feature is liable to confuse and obfuscate more than it is to help out.

This is not the fault of the language, however, but of the developer violating the principle of least surprise. Why would I expect an addition operator to subtract from elements of a string? Pragmatically, unless one has a very special application domain that requires it, one wouldn't normally do this.

C++ has a huge helping of extended features over C. For whatever reason, it seems to fall into a class of languages (along with PHP, Perl, C#, and Java) that seem more expressive up front but wind up creating less understandable and less maintainable code in the long term than using alternatives (e.g. C, Python, ML, Lisp) has at the places I've worked.

To be fair, ask what winds up creating the less understandable and less maintainable code, the language, or the developer utilizing it? It's a fair question, IMHO, and one that delineates whether if the fault of C++ is to be a terribly complex language, or simply one that is dangerous to a certain skill level of programmer. (and it also begs the question: does C bear this burden too? Will bad code writers write bad code in every language, or is C circumscribed enough to avoid the more estoric problems C++ brings to the table?)

Programming language is really a low-level human interface problem, so it's really tough to know until you use a language for a long time in a large group whether it's likely to be a big advance or not--there are some (e.g. Ruby, Scheme, Objective C) that I don't feel I have a grasp on at all yet.

I agree with you there. I'd even go so far as to say that even if the language is used for a long time in a large group, it can still be used incorrectly, if the people using it don't develop a grasp of the language.

But given pretty considerable experience using both C++ and C, I'm fairly confident that using C++ is a far worse idea than using C for new projects; that's not to say that defining some subset of C++ and using it on a well-defined project might not be a good idea, but essentially to answer your question: Because C++ in practice turns out to be horrifically unmaintainable in most cases compared to straight C, despite seemingly requiring less contortions to write decent OO code.

And studies like TIOBE sort of help quantify this and reassure me that it's not just personal anecdote, it's by and large the experience that most of the programming world has had over the last 15+ years.

Speaking purely from anecdote, I've worked multiple C++ projects, both large and small, and have had a couple disasters, and more successes. The difference was in that the people and projects who successfully used C++ a) took the time to understand what C++ could do for their domain, and b) implemented their domain using the parts of the language that were well understood, as you point out. As an example, exceptions were often put to the wayside, as they weren't generally well understood by the respective teams. So they weren't used.

Conversely, the disasters were due to maintainability of code bases that were old, combined with what I call the Cowboy Coder mentality, exhibited by someone who at some point in the past was responsible for some part of the code base, and felt they coul

Re:C Programming Language

[evil_aaronm]

You can get to the Orient by going west, too. It just takes a little longer. Technically, since we're on a sphere, you can go north and south, by various degrees, as well.

Re:C Programming Language

[icebraining]

Linus:

I don't actually know the details. I mean Java I really don't care about. What a horrible language. What a horrible VM.

:)

Re:C Programming Language

[beelsebob]

And?

Re:C Programming Language

[Anonymous Coward]

I invented the term 'Object-Oriented', and I can tell you I did not have C++ in mind. -- Alan Kay (father of Smalltalk)

But how would you go about changing your memory allocation (malloc) to use a copying garbage collector?

The same way you'd do it in C++ -- using a conservative garbage collection library. There's no difference between C and C++ in this respect.

Or do lazy evaluation Haskell style?

Maybe with macros... just kidding. ;) You can't sensibly do that in C++ either. And remember Greenspun's tenth rule of programming: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

How do you implement zero-cost exception handling? (longjmp is NOT zero-cost because it requires setjmp).

Again, this is not something C++ can do either. Exceptions are NOT zero-cost (at a minimum, they bloat your compiled code... this is unacceptable for some environments). More to the point, C++ exceptions are one of its most brain-damaged features. Most C++ programmers do NOT know how to write correct, exception-safe code... and doing so is a major pain in the ass even if you DO know how to do it safely. Face it: exceptions don't make sense unless your language is garbage-collected. In a garbage-collected language, most of the allocated resources are just memory, and you can safely leak those when an exception occurs. If you use exceptions in C++, anything that allocates or deletes memory needs extreme care to get it right. It's literally not worth the effort.

At my day job, we write AAA game engines in C++ but we never use C++ exceptions. In fact, some of the console compilers don't even *support* C++ exceptions properly, since no one in the game industry uses them.

Re:C Programming Language

[Anonymous Coward]

Clearly someone has not spent quality hours with numerous architectures and countless flavors of compilers. Templates are the major source of cross platform issues.

Re:C Programming Language

[pthisis]

I could define an extension to C where the + operator works between a string and an integer as follows:

mystr + myint is defined such that it returns a string of the same length as mystr, but where each element of the return value is myint less than the equivalent char in mystr. So "dddd" + 2 returns "bbbb", "zzzzz" + 3 returns "wwwww", etc.

This language is more expressive than C, but using the new feature is liable to confuse and obfuscate more than it is to help out.

This is not the fault of the language, however, but of the developer violating the principle of least surprise. Why would I expect an addition operator to subtract from elements of a string? Pragmatically, unless one has a very special application domain that requires it, one wouldn't normally do this.

No, the C-with-extended-addition language (which defines the + operator to work as in the example) is at fault as a language--in this case, it's the language itself that violates the principle of least surprise. (Note that the example is not of a language with operator overloading where a programmer defined a poor + operator; it's of a language that defines the + operator as given).

It's an obviously broken feature to illustrate the fact that more expressiveness in a language does not automatically mean that the language is better. Now, obviously the developer can work around a broken language feature by not using it (and many successful C++ projects are successful in large part by defining an acceptable subset of the language to use), but the need to do so is a sign that there's at the very least a bad smell in the language itself.

Speaking purely from anecdote, I've worked multiple C++ projects, both large and small, and have had a couple disasters, and more successes. The difference was in that the people and projects who successfully used C++ a) took the time to understand what C++ could do for their domain, and b) implemented their domain using the parts of the language that were well understood, as you point out. As an example, exceptions were often put to the wayside, as they weren't generally well understood by the respective teams. So they weren't used.

Yes, it's far from impossible to write good code in C++. But in my experience some languages tend to lead you more naturally toward writing better code and others do the opposite. All of them require some effort, and as you note a reasonable eye for maintainable design. But C++ has, on the projects I've worked on, been one of the languages where we've spent more time fighting the language than normal.

Re:C Programming Language

[robi5]

Excellent post, platypus and all. There are some ways of dealing with these effects. It's not a defense of object orientation, I'm more into functional programming and polymorphism, and feel uneasy when someone thinks "encapsulation" is such an integral concept to OO. So instead, here are a few things that _can_ be done about platypi (?) and real life ready modeling:

1. Some languages (e.g. Common Lisp) allow you to change the class of an object. The programmer can support such conversions by setter functions that get executed automatically (maybe lazily) when, for example, a new slot that is characteristic to the new class is read.
2. Multiple inheritance enables multiple roles for an object.
3. In Lisp, you can even automatically generate by code some of the above (at compile-time or at run-time), such as class changes or even the creation of a new class that inherit from other classes. Attention has to be paid so aspects are orthogonal (see next point).
4. Aspect-oriented programming 1. Identify aspects of what you model, and compose from them. For example, there is a class Person, and it has various aspects, for example as a physical person in the office, and as a holder of a job, and as a node in the organizational graph. If these concerns are kept separate, then aspects of behavior cause troubles less often.
5. Mixins. One way to do this is to define "abstract classes" that in themselves don't get instantiated, but they get mixed in into classes that do. For example, a dynamically generated subclass of a Person could have an Employee mixin or a Contractor mixin, or both! No loss of history when the class gets changed, and one mixin takes care of payroll related stuff (Employee) and the other takes care of an accounts payable account (Contractor).
6. Never delete an object! In almost all systems, deletion needs to be undoable; logs must be kept; the system must remain auditable. So it's easiest not to delete, conceptually speaking. Technically, to avoid running out of memory, an object could be archived: once its effects are properly aggregated everywhere, it can be archived to persistent storage such that it can be reloaded on request.
7. Identify what's intrinsic about an object, and never change those. Things like name, social security ID etc. are not intrinsic to a person. Often the best such "key" is the object identity itself (SQL equivalent: unique id) and nothing beyond it.
8. Everything that is not intrinsic is varying - usually as a function of time. Create those time-varying assignments (e.g. a name to a person) as a time series of separate objects. And the advice, "Never delete an object" still holds. Don't lose history of what happened to entities or their relationships.
9. As a corollary to 6,7 and 8: never change an object! Well, at least not at the conceptual level. If an object has a technical purpose (it serves a technical _aspect_ of the solution) such as maintaining a rolling time series aggregation or other caching so things don't have to be recalculated from scratch every time, those must change and you control how its time-varying behavior works (e.g. by saving daily and monthly aggregates). Which requires...
10. Aspect oriented programming 2. Now it's not in terms of modeled entity behavior, but the behaviors of your system. Spaghetti code (by extension, almost everyone's code) is characterized by a haphazard mixture of aspects, similarly to how the gut's content is a mixture of what went in, we want no sight of it. Often, a well-intentioned function starts by going through a series of assertions or other validations, then some precomputations happen, and some output (into a log, the console and as a function return value), and of course there are some other side effects that are made. Aspect oriented programming separates concerns. Make sure that you decompose your function into these: a pure (side effect free) function that just return a result purely based on its inputs and nothing else, and is understood by a literate domain expert. For example, a loan

Re:C Programming Language

[bidule]

Gambit-C is a scheme to C compiler. So I assume it is not using standard malloc() and free() to manage memory.
Your parent was talking about using the memory management by the stdlib and adding an GC on top of it.
You are talking about generating C code and integrating an GC into it, not relying on malloc/free.

Gambit does "compile to C as an intermediate language", although only using C as a VM. Which is not writing OO code in C, I'll admit.

Re:C Programming Language

[Anonymous Coward]

Orientater(n) One who aligns potatoes

Re:C Programming Language

[Anonymous Coward]

Ironically, by the time he posted that, there was already a D: "writing drivers for Mac OS X."

I do seem to recall seeing some old-time NeXT kernel hackers regretting the decision to switch to C++ for IOKit, though. The equivalent layer in NeXT's original kernel design -- "DriverKit", I think? -- apparently used Objective-C.

IIRC, you have a considerable amount of experience writing IOKit drivers and/or infrastructure. What's your take on Obj-C vs. C++ for this application, if you have one?

Re:C Programming Language

[Anonymous Coward]

Except SSE types are not part of the C++ language. They aren't even part of the C language.

Re:C Programming Language

[badkarmadayaccount]

What's wrong with Ads in comparison, in technical details?

Re:C Programming Language

[badkarmadayaccount]

Prototype OOP with message passing semantics, one level type system, and class based interfaces. Done.

Re:C Programming Language

[Anonymous Coward]

C is good for what it was designed for, which is programming close to the hardware. It is good for writing operating system kernels and device drivers since that was its original purpose. It is not and never was a good general purpose language. The tragedy is not that C is still around today, but that it so commonly used for things it was never designed for.

Re:C Programming Language

[Anonymous Coward]

Why Java? It has a broken OO system.

OO is about message passing not nouns.

See Smalltalk and to a slightly lesser extent, Ruby to see an actual OO system.

Look at this graph

[Anonymous Coward]

I count about 100 more possible headlines of the form "A overtakes B". Must we see them all here?

Agreed.

[MrEricSir]

C's philosophy doesn't integrate well with Ayn Rand's.

Re:Agreed.

[Anonymous Coward]

God bless Ayn Rand. And God bless Ron Paul. If all of these "Progressive" Slashtards would stop complaining about these two, the world would be a better place. GOD BLESS RON PAUL!

Re:Agreed.

[Anonymous Coward]

C's philosophy doesn't integrate well with Ayn Rand's.

Like hell it doesn't.

With C and Ayn Rand - you're on your own.

No pussy footing around with pee-pee holding concepts like "garbage collection", "array bounds checking", "welfare", "free health care".

Those are all for fucking wimps who need something to protect their incompetent asses.

Re:Agreed.

[Anonymous Coward]

God bless you and Ayn Rand and GOD BLESS RON PAUL! I have a feeling the lib-tards are crawling around and they are going to mod you and me down. THEY ARE SUPPRESSING OUR FREEDOMS! You can't praise Ron Paul these days without some lib-tard modding you down. All welfare recipients, immigrants and Democrats should be sent to jail! To protect our freedoms.

Re:Agreed.

[Genda]

So strange... I find Ayn Rand completely guilty of the very same romantic notions that got the founders of Communism (she so despised) into so much hot water. Perhaps its true what they say about choosing your enemies well. Both presumed that the underlying greatness and magnificence of the human spirit either as a society or as a specific productive individual would prove the guiding light for humanity. In fact humanity has shown precious few guiding lights and for the most part, we are little descended from our primate ancestors. This isn't to say that we aren't capable of transcendence, simply that you can't depend on that to build a social or philosophical framework.

Design the system that demands human transcendence, inspires greatness, and puts strict limits to personal power and responsibly accounts for the grosser of human foibles and frailties, and you'll have a winner. We had that system in the form of checks and balances, until the "Randian" among us began to systematically dismantle those very defenses against our poorer natures, beginning in the 80s. Up until then, we had the time and means to look at the future we wanted as a society, not just a few social (read financial) elites, and strive towards that future wisely and with due consideration. Now we're in a kettle of fish. Those elite have proven to be every bit as ignorant, self obsessed/serving and foolish as everyone else and they've squandered the future on extra McMansions, expensive cars and yachts, and the virtual hijacking of our society.

C is a great language. You can't any closer to bare metal without slugging assembly around, and as we move to more and more intelligent particles infiltrating everything from household appliances to ubiquitous sensors in the roads we drive on, you better believe that C will bring consciousness to the dross matter that surrounds us. I can only hope, that we can put aside our prejudices (not only racial, but societal), and begin to replace belief systems with educated inquiry, and treat the future with our intelligence rather than our primate predilections. It is the only hope I can see for a future worth living in.

Re:Agreed.

[WrecklessSandwich]

I think you're looking for Objectivist C.

Re:Agreed.

[drkstr1]

You need to work on your subtlety before trolling here. Go grind some levels on Reddit first, then come back and try again.

Re:Agreed.

[Anonymous Coward]

Anything more subtle would be subject to Poe's Law.

There really are idiots out there, lots of them, that believe this stuff.

Re:Agreed.

[Anonymous Coward]

all illegal immigrants should be sent back to whence they came. america for americans.

Re:Agreed.

[turbidostato]

"all illegal immigrants should be sent back to whence they came. america for americans."

Wasn't that Sitting Bull motto?

Re:Agreed.

[sam_nead]

Don't knock having primate ancestors. Some of my best friends are primates.

Re:Agreed.

[arth1]

C is a great language. You can't any closer to bare metal without slugging assembly around

Yes and no. Forth tends to be closer to bare metal, albeit rather stack heavy (although, of course, far less so than modern languages that have to bring their own gigabyte sized virtual stacks).
But it's bottoms-up, stringing minimal operations together to build bigger blocks, instead of the opposite, where you do seven layers of abstractions and tell that you want something done which you then pass through a black box and have no idea nor care what occurs at the other end.

Re:Agreed.

[Genda]

By all means, there's nothing wrong with primates... fine animals. They just tend to form hierarchies along lines off dominance, commit acts of violence on one another including infants, they're greedy, scheming, back-stabbing, self serving Machiavellian bastards (to paraphrase one of the world's leading authorities on primate research.

So we aren't as bad as baboons and we aren't as good as bonobos. We fall neatly on the primate continuum of behavior (good and bad.) The problem is that we have nukes. A pissing contest among humans could end in a 20 mile wide blue glass ashtray. All I'm saying is that as good as being a primate has gotten us so far, its perhaps time to begin rising above the worst of our inclinations while rising above them still makes a difference.

Re:Agreed.

[Anonymous Coward]

It was nice knowing you, white man.

Sincerely,
1/16th Native American

Re:Agreed.

[lennier]

But it's bottoms-up

Yes, Forth programming does tend to go a lot smoother when you drain a glass each time you have to look up the stack effect of a word.

Re:Agreed.

[BergZ]

Ayn Rand would approve. To paraphrase:
C is C.

Re:Agreed.

[BergZ]

Damn I wish I had saved my "C is C" joke for this comment instead.

Re:Agreed.

[Anonymous Coward]

"By all means, there's nothing wrong with primates.."

Yes, I've met them and they are us.

Re:Agreed.

[sg_oneill]

Forth is a bit like darts. I paradoxically get better at darts the more I drink. Thus I'm very fond of darts, like I'm very fond of forth.

Somehow I feel that if I did forth for a day job, my liver would be destroyed.

Re:Agreed.

[NalosLayor]

Christ, only on /. could the statement "Objective C is now more popular than C++" turn into a pissing match about objectivism and then morph into a discussion about evolutionary behaviorism. I don't know if I should be disappointed or proud, to be honest.

Re:Agreed.

[Anonymous Coward]

You really need to pick up a book.

There have been plenty of guiding lights. Ayn rand is a minor writer and pseudo philosopher, yet she garnishes more esteem than the greats? Ahem. It is you who are the problem. Read more often and realize you have no understanding of the English language or symbolism. Read humbly. It is revealing that you are are commenting about C and bring a writer into discussion; you are truly handicapped at understanding abstract ideas and real languages.

To be a better programmer is to be a better primate.

Re:Agreed.

[Anonymous Coward]

So we aren't as bad as baboons and we aren't as good as bonobos.

That's not what your mom says.

Re:Agreed.

[Anonymous Coward]

10/10 would bang

Re:Agreed.

[mug funky]

there was a precedent set centuries ago when immigrants were actively selected from their homes and shipped to the USA in order to work slavish jobs for very little benefits. literally second-class citizens (well, not citizens at all).

Re:Agreed.

[Anonymous Coward]

I call Bull Sit.

Re:Agreed.

[Savage-Rabbit]

"all illegal immigrants should be sent back to whence they came. america for americans."

Wasn't that Sitting Bull motto?

http://i173.photobucket.com/albums/w50/alix2304/cartoons%20II/Immigration.jpg

Re:Agreed.

[Anonymous Coward]

Easy to factor that in, as long as you're sober enough to type Ctrl-H at the end of a word that is. If not, just follow the natural tendency of your head to nod down slightly, stack effect will be on the status line at the bottom of the window.

Re:Agreed.

[Anonymous Coward]

big?

Re:Agreed.

[Anonymous Coward]

This kind of entertainment is the main reason I read /.. As I cackle out loud it soothes my dirty and mad soul a little and I make it a bit further in the long unrelenting slog towards a likely non-singularitarian death :)

The penultimate reason for reading /. is --of course-- writing obscure AC posts :D

Happiness for the wins!

Re:Agreed.

[angel'o'sphere]

Forth is only closer to the metal than C when it is running on a native Forth proccessor.

If not it abstracts everything away that the underlying machine gives/has. So how can it be close to something that it is abstracting away?

Re:Agreed.

[arth1]

Forth is only closer to the metal than C when it is running on a native Forth proccessor.

If not it abstracts everything away that the underlying machine gives/has. So how can it be close to something that it is abstracting away?

Because the same instruction leads to the same piece of code, every time. When you do "dup +", you can know what code it creates. It won't be different when done a different place. You can follow the program, step by step, and know what the CPU does.

Re:Agreed.

[Anonymous Coward]

Proud, obviously. Though a tangent, still connected. Had this been completely out of the blue, on the other hand...

Re:Agreed.

[Anonymous Coward]

How about detatched?

Re:Agreed.

[Anonymous Coward]

Your understanding of primates is really lacking and seems to be based primarily on chimps. Gorillas, orangutans, gibbons etc. do not have the same behavior as chimps. And bonobos are not 'good' as you think just because chimps act like monsters

Re:Agreed.

[sFurbo]

It's called state-dependent learning. Basically, it is easier to recall (or do) things when your are in the same state as when your learnt them. So when you have mostly been playing dart while being drunk, you are better at it when you are drunk. It is also a great excuse biologists use to get "getting rats drunk" past the ethical review board.

Re:Agreed.

[Rakshasa-sensei]

Actually we're closest related to Chimpanzees and Bonobos, the violence and the constant sex parts in one has lead to civilization.

Re:Agreed.

[Anonymous Coward]

I think you're forgetting that many of the behaviors you laud are emergent properties of our collective primate predilections and belief systems actually are a vestigial form of educated inquiry.

It's easy for us as a culture to look upon these remnants of social evolution and wag a a tongue of loft prose at them but at one time these behaviors served a very important purpose (and perhaps still do).

I think we need to stop looking at man as something to overcome and accept the fate of our present: a perpetual bridge to and from places we are still struggling to understand.

Re:Agreed.

[Anonymous Coward]

Disappointed, because it's clear the participants aren't well-versed in any of those topics.

Re:Agreed.

[Anonymous Coward]

The fallacy of composition ...

Re:Agreed.

[angel'o'sphere]

When a forth interpreter is running on a 6502, you don't know what the 6502 is doing. You only know what the Forth VM is doing.
Hence: you know nothing about the bare metal.

Re:Agreed.

[catmistake]

C's philosophy doesn't integrate well with Ayn Rand's.

Possibly this is due to incorrect labeling. Objectivism is an ideology, not a philosophy. Although a libertarian might evangelically object to this assessment, a philosopher will always ignore them after pointing out the incompleteness of it's epistemology, the question-begging logical fallacy of the foundation of it's ethical system and the egocentric anarchism underlying it's politics as evidence that Objectivism fails to meet any reasonable standard of a true philosophy– especially if the philosopher has been drinking.

Re:Agreed.

[jnork]

"...a 20 mile wide blue glass ashtray."

Mommy and Daddy still won't use it, they don't smoke any more. But they'll proudly put it on the coffee table (though it doesn't match the decor), and it'll collect paper clips and buttons and other assorted debris.

The biggest problem is fitting it into your backpack to take home from school.

Re:Agreed.

[Anonymous Coward]

I took this as a pun about having "prime mates" i.e. best friends. If this level of subtlety and nuance wasn't intended and was ultimately supplied by myself, please provide your address and I'll send you my bill right away.

Re:Agreed.

[jnork]

http://xkcd.com/84/

Re:Agreed.

[whitroth]

Wait - I thought Ayn Rand got Social Security and Medicare? And I thought she married someone so she could come to the US in the first place, then screwed him over?

Meanwhile, C doesn't screw you over - it does just what you tell it to do

                    mark

Re:Agreed.

[arth1]

When a forth interpreter is running on a 6502, you don't know what the 6502 is doing. You only know what the Forth VM is doing.
Hence: you know nothing about the bare metal.

Interpreter? VM? What kind of Forth are you talking about?

http://wiki.strotmann.de/wiki/Wiki.jsp?page=A%20FORTH%20ASSEMBLER%20FOR%20THE%206502

And you don't even have to use a forth assembler - in general, when you define a word in Forth, it's compiled, and will be the exact same code every time. You can look up the address to the machine code in the structure for the dictionary entry.
Yes, this is closer to the metal than most languages.

Re:Agreed.

[Saija]

I'm with you about how this thread reach this other topic, but i found the study about the baboons informative

Re:Agreed.

[mikiN]

Congratulations, you won the Puzzle Prize!

For the unlucky ones (_don't_ despair, see below):

- The answer to the Symmetry Breaker riddle: Instant Multi-ball! An exponentially increasing cascade of them, actually, sticking to everything else and making the ride more manageable.
- Smilies: they should have sent some into space (especially those 60's / 70's 'acid house' ones) with SETI instead of those elaborate patterns'n'stuff. Would prove that humans have both self-knowledge _and_ knpw where their towels are: don't take things too seriously. Sending anything else just may piss off ET by underestimating their intellect. (Also, who knows if some colonists from Despair Inc ever got trapped in orbit around a black hole (talk about a major depression!), they might appreciate the boost.)

Re:Agreed.

[micahraleigh]

False. Marx despised what he called "subjective idealism" which is why the soviets preferred councils (because they're herd-based).

Re:Agreed.

[bjdevil66]

Design the system that demands human transcendence, inspires greatness, and puts strict limits to personal power and responsibly accounts for the grosser of human foibles and frailties, and you'll have a winner.

The problem is that people don't really want that winner of a solution.

Why? Because that system already exists and is functioning today - true Christianity. The guiding light is God (a perfect human we're made in the image of and are supposed to strive to emulate as much as humanly possible). The strict limits on personal power are voluntarily self-enforced, and the accounting/responsibility comes in this life (karma) and the next (judgment). And true Christians aren't afraid of the advancement of knowledge/science/learning. Instead, they embrace those disciplines and seek to be leaders in those fields. (Any "Christian" that claims otherwise - hiding behind ignorance, prejudice, and fear - isn't a true Christian.)

Sorry to go off-topic a bit - I have no clue how to tie that into C vs. C++ - but I had to add that to your insightful post.

Re:Agreed.

[Eponymous Hero]

ayn rand bashing is so bourgeois but this was funny. joke approved.

Re:Agreed.

[angel'o'sphere]

Not every forth is compiled to assembler :D

Re:Agreed.

[Anonymous Coward]

incompleteness of it's epistemology
foundation of it's ethical system
underlying it's politics

"its".

I guess you don't understand languages either

[Anonymous Coward]

You can write reusable functional code in any language .... but you CAN'T write object oriented with it.

Re:I guess you don't understand languages either

[Anonymous Coward]

typedef struct {
        int (*open)(void *self, char *fspec);
        int (*close)(void *self);
        int (*read)(void *self, void *buff, size_t max_sz, size_t *p_act_sz);
        int (*write)(void *self, void *buff, size_t max_sz, size_t *p_act_sz); // And data goes here.
} tCommClass;

http://stackoverflow.com/questions/351733/can-you-write-object-oriented-code-in-c

Re:I guess you don't understand languages either

[Anonymous Coward]

you are aware that the first C++ compilers simply generated C code from the C++ then compiled to that.

Oh, and I've seen several OO languages written in C as well, that some senior engineer who "didn't trust C++" came up with. The only thing you don't get with these is enforcement of visibility with private/public, which isn't strictly required for OO. But polymorphism and the lot, yup, all that was there.

Re:I guess you don't understand languages either

[Anonymous Coward]

Void pointers scare the shit out of me and make me very, very happy at the same time. I wonder why that is.

Re:I guess you don't understand languages either

[Anonymous Coward]

You can also use GObject.

Re:I guess you don't understand languages either

[Coryoth]

Enforecement of public private can be done: simply have your base object struct have a void pointer field called private and declare and allocate a private data struct as static in the .c implementation of the class. Voila, private fields and methods as needed.

Re:I guess you don't understand languages either

[geezer nerd]

Of course you can write object-oriented code in C. It has been done many times.

An object-oriented language has lots of syntactic help for the purpose, but all languages compile to some type of runtime code structure. If you understand what code gives the object-oriented behavior you want, then you can write it in C.

And yes, the poster who said C was assembler-like likely has never seen an assembler language, I would guess. I do remember writing a C routine once which had an initialized array containing hex representations of machine code to do a particular highly specialized task, and then using some coding wizardry to get the locus of control into that array when needed. Ah, those were the days.

Re:I guess you don't understand languages either

[dfghjk]

Considering that C++ was originally implemented as a preprocessor for C, there's an existence proof that says you are wrong.

Re:I guess you don't understand languages either

[brokeninside]

You can write object oriented code in assembler if you want.

It's easier to write object oriented code if the compiler supports syntactic sugar around the pillars of object oriented code (inheritance, polymorphism, encapsulation, message passing, etc.) but such syntactic sugar is not strictly needed.

Re:I guess you don't understand languages either

[Bill Currie]

doesn't need to be void, even. (I'm sure purists will complain about _t being reserved)

[header file]
typedef struct something_s something_t; ...
something_t *private stuff;

[C file]
struct something_s { ...
};

I use this sort of construct quite a lot.

Re:I guess you don't understand languages either

[Coryoth]

It's easier to write object oriented code if the compiler supports syntactic sugar around the pillars of object oriented code (inheritance, polymorphism, encapsulation, message passing, etc.) but such syntactic sugar is not strictly needed.

More importantly, most of that can be handled well by a little bit of background plumbing at the beginning -- after that it takes a trivial amount of extra boilerplate for each you new class you care to add. See GObject, for example. And you can certainly go far with less plumbing work than GObject: inheritance, encapsulation and polymorphism can all be handled easily with structs and macros and 5 minutes to write a base object class.

Re:I guess you don't understand languages either

[MrEricSir]

You can write reusable functional code in any language .... but you CAN'T write object oriented with it.

The obvious counterexample would be Gnome's GObject. It's a C-based OOP framework, which GTK is based on.

Re:I guess you don't understand languages either

[vlm]

And yes, the poster who said C was assembler-like likely has never seen an assembler language,

C doesn't look like 6502 or 1802 or 10f220 assembly, but if you squint you can see some PDP-11 addressing modes in there. Because a primary dev box was a ....

Also I see aspects of BAL from MVS370 but maybe thats just dead brain cells flickering.

Re:I guess you don't understand languages either

[Anonymous Coward]

Ok now make it type safe.

Re:I guess you don't understand languages either

[luis_a_espinal]

typedef struct { int (*open)(void *self, char *fspec); int (*close)(void *self); int (*read)(void *self, void *buff, size_t max_sz, size_t *p_act_sz); int (*write)(void *self, void *buff, size_t max_sz, size_t *p_act_sz); // And data goes here. } tCommClass;

http://stackoverflow.com/questions/351733/can-you-write-object-oriented-code-in-c

So, you think that is object-orientation? Oh boy.

Re:I guess you don't understand languages either

[aardvarkjoe]

So, you think that is object-orientation? Oh boy.

From wikipedia: "Object-oriented programming (OOP) is a programming paradigm using "objects" - data structures consisting of data fields and methods together with their interactions - to design applications and computer programs."

The GP's method certainly qualifies. Just because it doesn't include all the sugary syntax or features that are included in your favorite so-called "OOP language" doesn't mean that you can't do object-oriented programming in C.

Re:I guess you don't understand languages either

[dgatwood]

And yes, the poster who said C was assembler-like likely has never seen an assembler language, I would guess.

Oh, but it is. C is actually very, very close to assembly language, with only the most unimportant CPU-specific details abstracted away. The primitive types in C are almost always natively supported by the CPU in assembly language, with few exceptions. Instead of having to manage your own stack, it mostly manages it for you, but it still leaves plenty of room for shenanigans, particularly because it doesn't enforce the number of arguments any more than asm does. And if you use varargs, you pretty much are doing direct accesses to the stack using indexed addressing. Simple asm.

Accesses to a struct are just a tiny bit of syntactic sugar on top of an indexed load/store. Goto is a jmp, setjmp and longjmp just set a register and then perform a jump to that address The if/then commands have near exact ASM equivalents (albeit with a couple of extra jump instructions thrown in), and even while loops are just a couple of instructions (not counting whatever calculations must be performed to determine which path to take).

C abstracts away some stack management details, register quantity limits, etc., but it really is little more than portable assembly language, by design. It was intended for systems-level programming, and does that job well, in part because it is such a thin layer compared with most other languages.

Re:I guess you don't understand languages either

[ceoyoyo]

I think that falls under "you don't always need the language to hold your hand."

Re:I guess you don't understand languages either

[Anonymous Coward]

Oh, but it is. C is actually very, very close to assembly language

Only in that it compiles tightly. Otherwise, it's not at all like assembly.

COBOL, on the other hand, is much more assembly like by design (undoubtedly in how you structure your code). On old mainframes, you'll find long lines of COBOL compile to just a few machine instructions.

It's part of what makes the language so damn efficient. C can also be extraordinarily efficient, which is probably why it gets compared to assembly so often. Of course, well into the 1990's inline assembly was common in C programs where performance mattered.

Re:I guess you don't understand languages either

[Tough Love]

Considering that C++ was originally implemented as a preprocessor for C, there's an existence proof that says you are wrong.

Skipped your theorum proving class, then?

Re:I guess you don't understand languages either

[DeathFromSomewhere]

I think that falls under "I hope to the great FSM that I never have to maintain your code."

Re:I guess you don't understand languages either

[Z00L00K]

Using void pointers is the same thing as posting as an Anonymous Coward at /. .

It is of course a great way to hide the inner workings of the functionality but at the same time it will also make it a lot harder to debug your code and it will also hide stuff from the compiler so that problems that might have been discovered at compile time won't be seen.

Re:I guess you don't understand languages either

[Anonymous Coward]

Doesn't sound like you know what OOD is. That method qualifies, and you also get inheritance and polymorphism. Perhaps you shouldn't be so smug next time?

Re:I guess you don't understand languages either

[devent]

You don't need to get to functions pointers if you don't need polymorphism. It's like making (in C++) all methods virtual just for fun. You can have static OOP in C:

// in header file
typedef struct FileClass;

int FileClass_open(FileClass* this, char* fileName);
int FileClass_close(FileClass* this);
int FileClass_read(FileClass* this, void* in, size_t size, size_t* actualSize);
int FileClass_write(FileClass* this, void* out, size_t size, size_t* actualSize);

// in C file
typedef struct { // all your data
} FileClass;

int FileClass_open(FileClass* this, char* fileName) {
        thisc->data
}

// usage
FileClass class;
int ret = FileClass_open(&class, "filename.txt");

Btw, I'm not a system developer so I'm using names that are not acronyms. Are there still so many C compilers that can't handle names with more then 8 letters? I wish C would get namespaces, so I don't have to write FileClass_ prefix so it won't collide with the C standard libraries.

Re:I guess you don't understand languages either

[jasomill]

In the present context at least, Objective-C seems like an even better counterexample, given that its syntax, however convenient, is not required to use the underlying object system provided by the lightweight runtime.

Re:I guess you don't understand languages either

[shutdown -p now]

t if you squint you can see some PDP-11 addressing modes in there

Can you give some examples?

(I kinda like figuring out how PLs get to be what they are)

Re:I guess you don't understand languages either

[ballpoint]

And
*(char *)pc = c;
as Insert Characters under Map.

Re:I guess you don't understand languages either

[Anonymous Coward]

Ok now make it type safe.

Easy:

struct comm_class {
    int ( * open ) ( struct comm_class *self, char *fspec );
    int ( * close ) ( struct comm_class *self );
    int ( * read ) ( struct comm_class *self, void *buf, size_t len );
    int ( * write ) ( struct comm_class *self, const void *buf, size_t len );
};

Re:I guess you don't understand languages either

[beelsebob]

Personally, I just go with not exposing the struct at all in the header... But then, when writing OOP code, I go with not exposing any object fields that aren't methods in the header too.

Re:I guess you don't understand languages either

[BonzaiThePenguin]

I wish C would get namespaces, so I don't have to write FileClass_ prefix so it won't collide with the C standard libraries.

#define CLASS_MEMBER(return_type, p...) CLASS_MEMBER2(CLASS_NAME, return_type, p)
#define CLASS_MEMBER2(class_name, return_type, p...) CLASS_MEMBER3(class_name, return_type, p)
#define CLASS_MEMBER3(class_name, return_type, member_name, params...) return_type class_name##_##member_name(class_name *this, ##params)

#undef CLASS_NAME
#define CLASS_NAME FileClass

CLASS_NAME(int, open, char* fileName);
CLASS_NAME(int, close);
CLASS_NAME(int, read, void* in, size_t size, size_t* actualSize);
CLASS_NAME(int, write, void* out, size_t size, size_t* actualSize);

I'll leave it to you to figure out how to use this pattern to #define namespaces. Also, there's a *lot* more you can do with the preprocessor if you really push it.

Note: ', ##' might be a GCC-only extension.

Re:I guess you don't understand languages either

[beelsebob]

Objective-C is not preprocessed into C any more though (though the original implementations worked like that). These days it goes through LLVM byte code to machine code.

Re:I guess you don't understand languages either

[Anonymous Coward]

I'm just guessing here, but GP might be talking about the C operators for pre-increment and post-increment, and pre/post decrement.

I've read that early C compilers were pretty stupid, and if you wrote the code right you got a speed win. Consider these two examples:

/* first example */
while (*dest++ = *src++);

/* second example */
for (;;)
{
    *dest = *src;
    if (!*dest)
        break;
    dest += 1;
    src += 1;
}

Both of these copy a string. A decent modern C compiler should emit equally efficient code from both of these (or possibly identical code from both of these!) but my understanding is that the first C compilers would emit better code from the first one. The post-increment lets you specify "fetch and then increment" and "store and then increment" without going to assembly language. The compiler should notice, in the second one, that first we fetch and then we increment, and should emit that fetch-and-increment instruction; likewise with the store-and-increment. But back in the day you got better performance if you knew about this and coded like the first one.

Re:I guess you don't understand languages either

[TheRaven64]

From Alan Kay, who coined the term and is the authoritative source on what it means:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

The definition earlier might just about squeeze in, but only just, in a cargo-cult completely-missing-the-point kind of way.

Re:I guess you don't understand languages either

[TheRaven64]

The only thing you don't get with these is enforcement of visibility with private/public, which isn't strictly required for OO

According to Alan Kay's definition (and, since he coined the term, I'll stick with his definition), hiding objects' internal state from anything outside is one of the three features that are vital to object orientation. You can, of course, implement this with opaque types in C.

Re:I guess you don't understand languages either

[TheRaven64]

First, LLVM is not bytecode, LLVM IR has a bitcode serialisation, but that's largely irrelevant. Second, the GCC implementation also went straight to native code without going via C. That doesn't, however, alter the grandparent's point. There is a rewriter in clang that will translate Objective-C into C. Message sending in Objective-C is implemented by a call to the objc_msgSend() function, which takes the receiver and the selector as arguments.

This, however, is where the grandparent's point breaks down slightly, because it is not possible to implement objc_msgSend() in C: it must pass all of its arguments on to the method, and it is not possible to write a C function that passes all of its arguments unmodified to the callee. The C standard is full of things in the standard library that work around this, like fprintfv() and so on.

That said, the GCC and GNUstep runtimes also provide a two-stage lookup, where the runtime just returns a pointer to the method and the compiler calls it. This is possible to implement in pure C, although an equally efficient implementation of the message sending on the caller side would be quite horribly unreadable.

Oh, and full disclosure: I am the maintainer of the GNUstep Objective-C runtime and the open source support for Objective-C in clang.

Re:I guess you don't understand languages either

[beelsebob]

Second, the GCC implementation also went straight to native code without going via C.

Not initially actually, initially the implementation was purely CPP macros.

That doesn't, however, alter the grandparent's point. There is a rewriter in clang that will translate Objective-C into C.

Incorrect, at no point is the objective-c code rewritten into C code, it is compiled directly to LLVM IR, not via any other language.

Message sending in Objective-C is implemented by a call to the objc_msgSend() function, which takes the receiver and the selector as arguments.

The fact that C function calls are inserted does not magically make it a conversion into C code. It is entirely possible to insert a call to a C function in LLVM IR, without ever producing the C representation. The fact that the obj-c runtime is written in C does not mean that the compiler converts to C and then to machine code (possibly via some other steps).

Re:I guess you don't understand languages either

[julesh]

GGP's example is a late binding mechanism. You can build on it using the pImpl pattern to achieve "protection and hiding of state-process". Local retention is just a design issue, anyway, and "messaging" is somewhat ambiguous in this context (is a function call a message? perhaps. but if not, C++, Java, et al are not supporting OOP either).

Re:I guess you don't understand languages either

[LizardKing]

Interesting. I read the Smalltalk 80 book a long time ago, but I seem to recall that the state of an object was "public" in the C++ or Java sense of the term. Never really got to use Smalltalk in anger so my recollections may be wrong - I was only really studying it to see how it had influenced Objective-C and the NeXT development framework (which in turn had a major influence on Java).

Re:I guess you don't understand languages either

[luis_a_espinal]

Doesn't sound like you know what OOD is. That method qualifies, and you also get inheritance and polymorphism. Perhaps you shouldn't be so smug next time?

It's not being smug when it's about pointing the folly of reinventing the wheel, poorly, out of a square block and claim that it is a wheel. You guys are the MadTV Stuarts of software development (ma, look what I can do.... with structs and pointers to callback functions.)

One could say that programming in assembly using nothing but unconditional jumps and cond jumps is just the same as structured programming because, after all, structured programming will get translated to its assembly/machine language jump-based equivalent.

Or functional programming is nothing but pointers to functions...

For that matter one could have an array of locations one can jump to in assembler and call it OO (not OOD or OOP as those are somewhat different animals stemming from OO). You can simulate inheritance, and you can simulate polymorphism... with a lot of elbow grease.

Now, I'm going to slow it down for you one more time. Here is the operative expression.... a lot of elbow grease In the GPP's example, you have to extensively rely on programming by convention to make sure

1. - you call the right callback (or method if you so wish to call it)
2. - you obtain and truly enforce encapsulation (given that everything in in a C struct is "public")
   • -- you could use a pimpl-like idiom via an opaque pointer to alleviate reliance on programming by convention (and to achieve something of a "limited private" type as in Ada.) However, now you have to rely on dynamic memory allocation (which is not suitable in all contexts, and not justifiable when allocation is best done on the stack.)
3. - you do not have implicit self-recursion. You have to pass the this/self pointer explicitly, again by convention to make sure the pointer is addressing the right data of the right type. You have to manually create the dispatching yourself, or put a lot of elbow grease to create a dispatching mechanism via macros and other functions... and programming by convention.
4. - your inheritance three is constructed also by convention (via a "super" pointer or nested struct being part of the structure). You have to ensure everything is aligned (as opposed to leaving the compiler to decide how it will align it.)
5. - the polymorphic behavior you get is limited to method overriding (you can't have true method overloading capabilities).
   • since this is a fundamental part of message passing (which is the true core of object orientation), your options for creating rich models is severely impaired.
6. - there is no transparent run-time dispatching. Under this scheme, imagine a struct B inheriting-by-convention from struct A (via a "super" pointer or nested struct). And the super-type struct A has a method of interest to client code using B (say pointer to func "foo".) To call "foo" on struct B (to send a message "foo" to an instance of B), you cannot simply say B.foo(...). You have to say B.super.foo(...).
   • -- so now you have severely coupled, in an extremely explicit way, the target of message foo to only those supertypes in the inheritance tree that actually have an implementation for it. The dispatching is no longer transparent, with potential maintenance issues.
     • --- you better get that shit right boy, otherwise you'll be in a lot of pain down the road. This is true in every programming scheme, but it is more so in this context.

The last part is the most important one. Message is the meat of OO. Everything else is just gravy. And the transparent message dispatching mechanism that makes OO economical is being thrown out of the window (along a lot of other things) with the GPP's supposedly good example.

Now, there are situations where this approach is useful (I've used it myself for building plugga

Re:I guess you don't understand languages either

[sonamchauhan]

I guess they scare you, because its your job to write them.

I guess they make you happy, because its your job to write them. :) Just guessing

Re:I guess you don't understand languages either

[laffer1]

There are several pieces of the FreeBSD kernel that use this technique as well. It's a great example of real world code.

Re:I guess you don't understand languages either

[angel'o'sphere]

LOL ;D

you should have not ommitted the second line: Programming techniques may include features such as data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance.
All that is impossible in plain C regardless how you tweak it into an OO harness.
So according to my book fancy macros in C make it object based but not object oriented.
And even if you disagree: having to use fancy macros every singel line does not make it a "language" at all iin my definition.

Re:I guess you don't understand languages either

[bstamour]

You can simulate inheritance in C: just store an instance of the parent struct in the derived struct, and you can access inherited members via self->parent->method( );

Similarily for polymorphism: just cast it to a pointer to the base struct. If you lay your struct out nicely memory-wise this should be a safe operation.

If you can write it in assembly you can write it in C. And all that fancy C++ stuff has to eventually make its way down to ASM at some point.

Re:I guess you don't understand languages either

[TheRaven64]

I read the Smalltalk 80 book a long time ago, but I seem to recall that the state of an object was "public" in the C++ or Java sense of the term

Nope, it's protected. Smalltalk does not provide any syntax for accessing the instance variables of another object. There is no obj.ivar or obj->ivar. Instance variables appear in the symbol table and can only be accessed from the current object. The idea of object orientation is simple: small models of computers that communicate by message passing. Computers can't (usually) see the implementation details of other computers that they communicate with...

Re:I guess you don't understand languages either

[TheRaven64]

Not initially actually, initially the implementation was purely CPP macros.

Nope, that was the StepStone compiler. The initial GCC implementation did not.

Incorrect, at no point is the objective-c code rewritten into C code, it is compiled directly to LLVM IR, not via any other language.

I never said it was in the standard compilation pipeline, I said:

That doesn't, however, alter the grandparent's point. There is a rewriter in clang that will translate Objective-C into C.

If you don't believe me, run clang -rewrite-objc and look at the output. Seriously, I wrote some of this code, I know it exists...

The fact that C function calls are inserted does not magically make it a conversion into C code

The question is whether Objective-C can be implemented in C.

Re:I guess you don't understand languages either

[Anonymous Coward]

void *buf

Isn't typesafe

Also, now make a second struct that inherits from it.

Re:I guess you don't understand languages either

[TheRaven64]

Nope, that was the StepStone compiler. The initial GCC implementation did not.

Actually, rereading what you said, it was never true:

Not initially actually, initially the implementation was purely CPP macros

Brad Cox's original Portable Object Compiler was written as CPP macros. The first Objective-C compiler was a preprocessor that generated C code, but it was not implemented as CPP macros, it had a custom parser. A C preprocessor macro can not match [a b: c] and turn it into anything.

Re:I guess you don't understand languages either

[TheRaven64]

Brad Cox's original Portable Object Compiler

And I should read what I wrote before hitting submit. This should read Object Oriented Precompiler (OOPC), from the 1983 SIGPLAN paper.

Re:I guess you don't understand languages either

[aardvarkjoe]

you should have not ommitted the second line: Programming techniques may include features such as data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance.
All that is impossible in plain C regardless how you tweak it into an OO harness.

The phrasing of the sentence makes it clear that those properties are not to be considered part of the definition. (And in any case, some of those certainly can apply to programs written in C -- data abstraction and modularity, most obviously.)

And even if you disagree: having to use fancy macros every singel line does not make it a "language" at all iin my definition.

I never said that C was an "object-oriented language." It's not. But you can do "object-oriented programming" in C. There's a difference.

Re:I guess you don't understand languages either

[vlm]

AC pretty much has it. Also the orthogonality where you can pretty much do any addressing mode or operation to any register on the -11, just like you can do anything to any variable name in C.

Now old fortran where the first letter of the variable name implies the variable type, is kind of like some cruder, more limited assembly languages where you can only increment certain registers and only decrement others (thinking system/user stacks / heaps here) and some CPUs where only certain registers can do memory ops and strange transfer / exchange / copy register to register rules.

Also the -11 had enough registers and addressing modes that assembly programming was not as much of a game of "how do you use the single accumulator?" like assembly programming on a -8. Programming the -8 is like programming on those ancient BASICs where you only get variable names A-Z and you've got 27 data variables to shuffle, or only have single dimensional arrays implemented in the language but 3-d of data. The -11, much like C, was more flexible.

Re:I guess you don't understand languages either

[Anonymous Coward]

Considering that C++ was originally implemented as a preprocessor for C, there's an existence proof that says you are wrong.

I wasn't around, but Stroustrup says (in The Design and Evolution of C++) it wasn't.
He used an intermediary C representation in (some releases of) Cfront, but (a) so do many compilers for different languages and (b) he just wanted to avoid writing the machine code generation for N different CPU architectures.

Re:I guess you don't understand languages either

[ceoyoyo]

The maintainability of code seems to have very little to do with how much the compiler holds your hand, and very much to do with how you write it. I've seen quite a bit of assembler code that is MUCH easier to understand and maintain than almost all of the MatLab code I've ever seen, and a good deal of the C++, Java, whatever is cool this week, code. Programmers today seem to have poorer self discipline skills because they rely on the language to catch their errors and force them to do things correctly. Until we've got true AI, a person (i.e. the programmer) will be better at that than the computer.

The only language feature I've ever seen that consistently makes code more readable is Python's whitespace requirement. Even that can be used for evil though, if somebody makes a habit of mixing spaces and tabs.

Re:I guess you don't understand languages either

[hackula]

Bzzzzzt. wrong. OO is nothing but a design pattern and can be implemented in any language. I use a wacky C variant for a lot of my GIS work. We have built an OO framework around it to great effect. It is not as pretty as an out of the box solution you would see in something like C# or Python, but it gets the job done just fine.

Re:I guess you don't understand languages either

[hackula]

Dynamic languages get by without type safety just fine. I use static and dynamic languages on a daily basis. The type safe languages let me "sleep at the wheel" a bit more and let the compiler do the work, but if I am using proper TDD, it is never a problem with the dynamic languages.

Re:I guess you don't understand languages either

[Tyler Durden]

Oh, but it is. C is actually very, very close to assembly language,

Do tell.

with only the most unimportant CPU-specific details abstracted away

This makes no sense whatsoever. Requiring the programmer to write the "CPU-specific details" is the defining characteristic of assembly language. Without this, no language can be considered remotely close to assembly.

Re:I guess you don't understand languages either

[hackula]

Yes, that is object-orientation. The example was to counter the claim that writing OO code in C was impossible. This example is sufficient. Now clean OO is another story. Of course, if you really want OO and have a choice, pick one of the many languages that is designed and optimized for OO. Sometimes, the language you use is not a choice, so you make do with what you have.

Re:I guess you don't understand languages either

[angel'o'sphere]

That second sentence and also the third one are teh definition of OO.

But you can do "object-oriented programming" in C. with the drawback that the official term for this kind of programming is not "object oriented" but "object based".

Re:I guess you don't understand languages either

[angel'o'sphere]

You can simulate inheritance in C:
Exactly my point. You are simulating it. Simulating is not the real thing and hence you are not doing the real thing but something different.
just cast it to a pointer to the base struct *cough*, *cough* ... are you sure it is that simple? Especially if you have multiple inheritance? *cough*

Sorry, I'm not tryin to bash you, however: using a non OO language to simulate OO is called object based programming (there are even languages that are considered object based as they lack many featrues of a true OO language). Secondly: the term OO is defined by its inventor. Claiming you can do that in a non OO language is like claiming you can write the recipe for a cake in DNA sequences. Sorry, while we all understand what you are talking about (and likely many of us wrote their own object systems in C) we also know: your terminology is simply wrong.

Abusing C to have "objects" is not object oriented programming, sorry.

Re:I guess you don't understand languages either

[jc42]

From Alan Kay, who coined the term and is the authoritative source on what it means:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

Heh. I've occasionally used that and other similar quotes to explain why "OO" projects take so damn long to get working right.

The critical concept is "information hiding". What this often means in practice is that things bog down trying to debug something that doesn't work the way the programmers insists it must, but they can't find the problem, because it's carefully hidden from them by the structure of the language. From a debugging viewpoint, "information hiding" is a bug, not a feature. It often means that the needed information is hidden from the debuggers. This hiding was provided intentionally by the language designers.

It can also be "interesting" to face situations where result of a simple-looking operation is due to the interaction of a large number of details, each "inherited" from chunks of code scattered across a hundred or more small source files.

So maybe a preference for "plain C" is based on the experience that it's difficult for your programmers to hide things from each other in C. They can find bugs and get things working sooner in a language that doesn't provide tools for hiding what's going on from the people working on other parts of the code.

Re:I guess you don't understand languages either

[aardvarkjoe]

That second sentence and also the third one are teh definition of OO.

That is one opinion, although obviously not a universally-held one given that the Wikipedia definition explicitly does not require those as part of the definition.

Re:I guess you don't understand languages either

[DeathFromSomewhere]

Hmmm, maybe it's just a coincidence then that every piece of code I've seen that has made heavy use of void* has been write-only junk. Personally I'm of the opinion that a programmer should rely on computers to do the boring mechanical work like checking for type safety. People are exceptionally bad at things compilers are good at. Anywhere I can get my tools to do work for me is a good thing.

Re:I guess you don't understand languages either

[Anonymous Coward]

I just loved writing assembler on the PDP-11. Flat addressing model, vectored interrupts, memory mapped IO, ...

Re:I guess you don't understand languages either

[Anonymous Coward]

"You guys" huh? What makes you think I would actually choose C for an object oriented design. Making some pretty big assumptions there.

Suffice it to say you can redefine what OOD is in your head all you want (add all sorts of additional clauses, go down the "no true scotsman" route if that makes you feel better) but it's been well understood for many years and it's not about to change just because you want it to.

I think we can add arrogance to the smugness now.

What he proposed is object-orientation. Is it good object orientation? Probably not. But it is all the same.

Re:I guess you don't understand languages either

[Anonymous Coward]

C is actually very, very close to assembly language, with only the most unimportant CPU-specific details abstracted away.

Yep - pesky irrelevant details like the size of an int.

Re:I guess you don't understand languages either

[Anonymous Coward]

Very true; after years programming in Macro-11 (actually, originally in octal in ODT) it's not hard to see the influence PDP-11 assembly practice had on C.

014747

Re:I guess you don't understand languages either

[Anonymous Coward]

The critical concept is "information hiding". What this often means in practice is that things bog down trying to debug something that doesn't work the way the programmers insists it must, but they can't find the problem, because it's carefully hidden from them by the structure of the language.

That's not what information hiding is. Try the Wikipedia article.

Re:I guess you don't understand languages either

[jc42]

I think you mean "That's not what information hiding is supposed to be." ;-)

I understand quite well what it's supposed to mean. But I was talking about the way it's used in the Real World of corporate IT. Call me cynical if you like, but I think lots of people know what I'm talking about. In some organizations, the OO approach has done a lot of good. In other organizations, it has contributed greatly to the building of software horror stories that end up as examples in The Daily WTF. C++ and java are great tools for misuse by people with a bureaucratic bent, and can easily be used to build software that's incomprehensible to all but the original authors.

I'm guessing that this is what has led to the decisions to stick with C, despite all its problems. C was designed as a "structured assembly language", after all, for writing low-level OS code that has to be close to the hardware. Using C as a higher-level language is essentially a violation of its original design, and others have explained why it's not very good as a general-purpose language. But when C's supposed successors produce bureaucratic messes that an organization can't fix, it's easy for people to blame the language and decide to stick with the more basic tool that people think they understand better.

Re:I guess you don't understand languages either

[angel'o'sphere]

That is one opinion, although obviously not a universally-held one given that the Wikipedia definition explicitly does not require those as part of the definition.
As often, wikipedia is then wrong, however I understand the "may" introducing the second sentence as a phrace to make the sentence more interesting and not as a "can have".
If you read the whole article especially the section: Fundamental features and concepts
you see that most of the points are required otherwise it is not OO.
Also keep inn mind: wikipedia articles are written by people liek you and me, if you had written in inheritence e.g. would not be require, if I had written it, it would be :D
Bottom line: Alan Kay defined the term. So we should agree with him and not random authors on wikipedia :D

Re:I guess you don't understand languages either

[Anonymous Coward]

Yeah, POC was written by David Stes, the infamous usenet troll. He seems to have finally given up.

(IIRC, POC is a translate-to-C design. It probably doesn't implement any modern Objective-C features given Stes' rather absurd level of hatred for anything Apple did to the language.)

Re:I guess you don't understand languages either

[Anonymous Coward]

This is as relevant as saying that Assembly can have OOP too.

Re:I guess you don't understand languages either

[Anonymous Coward]

Or you can simply use Objetive-C... very little extra added to C, just the bare minimal for OOP and keep and mix where needed good old tried and trust C code

Re:I guess you don't understand languages either

[Anonymous Coward]

http://www.planetpdf.com/codecuts/pdfs/ooc.pdf

Java and C duking it out

[SplashMyBandit]

Java's apparent decline seems to be because of the financial slump. Where the number of new enterprise projects using Java has reduced. Most of this work was deferred and is starting to pick up again (at least as far as I can see). Some of the apparent 'decline' in languages is due to the introduction of new languages. The absolute number of projects using any language may be increasing but with new languages being introduced the proportion for any one language becomes diluted.

That said, C deserves to be right up there because it is still completely relevant as a 'lingua franca' (common language) for talking to hardware or operating systems. It also has the same benefits of Java in that the language is small and the convention is to place complexity in the libraries rather than as arbitrarily added keywords. This is not very exciting for many Slashdotters but for regular joes it allows them to get things done while working on huge, long-term projects (where the set of staff that start the project aren't necessarily those that finish it) where being able to follow other people's code is critical. This doesn't make for good press or excitement in the blogosphere or conference circuit but these two stalwarts pretty much let you solve any problem in any computing environment (portability matters!).

Re:Java and C duking it out

[geminidomino]

Java's apparent decline seems to be because of the financial slump. Where the number of new enterprise projects using Java has reduced. Most of this work was deferred and is starting to pick up again (at least as far as I can see)

I'm sure Oracle's mongolian horde of lawyers factors in there somewhere, too.

Re:Java and C duking it out

[ADRA]

Maybe so, but outside of Slashdot, I've never heard someone decide to change away from Java because they were worried about Oracle in the least. I've seen companies open parallel .NET shops to work with customers in that ecosystem, but never just up and quit Java (and none that even considered it because of any perceived legal problems).

Re:Java and C duking it out

[geminidomino]

Maybe they didn't change away from it, since that would involve trashing already invested time and money, but there's certainly a non-zero number of developers who went another direction at the start of a new project because of it.

Re:Java and C duking it out

[Decker-Mage]

Actually I think that's half the story. The other half probably has to do with the rocket-scientists trying to obtain the near millisecond response time required for today's financial markets so C get dusted off for a return engagement. That's just a guess, though.

Re:Java and C duking it out

[Anonymous Coward]

Java and C have been swapping #1 and #2 spots for the last 5+ years now. It's not news, except insofar as most news these days tries to manufacture conflict where none actually exists.

Re:Java and C duking it out

[SplashMyBandit]

That may be so. Projects in flight won't move away from Java and projects about to start now have more certainty that Oracle can't push their patent hoard around to disrupt Java (or Android) so easily. I don't think that the .NET patents have ever been tested - but no one really worries about that as users (and the Mono implementers seem happy enough, since they'll never get enough compatibility to threaten Microsoft's leadership in .NET anyway). So perhaps you are making a theoretical argument about people being hesitant to adopt Java - in practice there are enough alternatives (eg. IBM, OpenJDK, GCJ) that it was never much of an issue (one of the beauties of having multiple vendors with almost-perfectly compatible implementations [there can be wrinkles, but these are relatively small]).

No, I think Java usage has dropped for the reason I outlined in my original post, the business sector where Java rules the roost are deferring projects. With economic growth I'd be surprised if Java's usage doesn't take an uptick (in the same way you can see a stampede to try out Python half a decade ago, followed by a drop in Python and corresponding resurgence in Java as people moved back).

As much as many Slashdotters love to 'dis' Java for not being cool enough, or not having their pet language feature, is it the 'C' of the object oriented world - ubiquitous and effective. It's not always the best solution in any domain but it is always a viable solution in any domain (meaning you get to re-use your existing code, tools and techniques no matter what problem you have or what target platform you are going for). That makes it a good choice for many developers and teams of developers.

Re:Java and C duking it out

[angel'o'sphere]

I think everyone who never used Java seriously but bitches about it serverily underestimates the tool support given by Eclipse etc.
Also they underestimate libraries and frameworks like hibernate and last but not least scripting languages like Groovy.
If there was a proper standard library for EVERYthing that is portable ... and if there where true refactoring support in a good IDE for C++, much more people had sticked to it.

But well, how do you again have an object platform independed serialized from client to server into a DB and back out of it again in C/C++? And how many lines of code do you have to write for that (regardless of tool support)?

Re:Java and C duking it out

[leuk_he]

>But well, how do you again have an object platform independed >serialized from client to server into a DB and back out of it again >in C/C++?

Did that in 1995 in C already with some help from the RPC implementation of sun. Ok, that was RPC with portable datastructures, not really object oriented.

But on the other hand, object oriented was a buzzword some decades ago, but still it is not understood very good by a lot of developers/ desingers.

Re:Java and C duking it out

[hackula]

The Java vs C# divide has a lot to do with geography in my experience. In my area, almost all shops are .Net/C#. There are actually more Ruby/Rails and Python/Django shops in my area than Java. I happen to be in a mid-sized southern coastal city. I have heard a similar trend in the DC area. At the same time, there are plenty of places where Java dominates and the majority of devs would not touch C# with a ten foot pole. I have absolutely no idea what could be causing the trend, but it seems to hold true IME.

Re:Java and C duking it out

[hackula]

Very true. No one starts a project asking "hmm... should I do this in Java or C?". At this point, they are not even in competition. If you are writing a low level kernel module, It will be in C or C++. If you are writing enterprise-y corporate software, you are looking for the language with the biggest framework behind it; most likely Java or C#. For the space in between, you will use whatever you have the most experience with. Specialty languages are sprinkled in as needed.

Objective-C not required to create iOS Apps

[Anonymous Coward]

"Objective-C is the language you have to use to create iOS applications"

There are plenty of games and other iOS applications that are written in C and C++.

Yes, there is a little bit of "glue" code required for interaction with Apple APIs, but the implication here is that you can't use another language write the majority of an iOS Application, which is wrong.

Re:Objective-C not required to create iOS Apps

[solidraven]

The real problem here is that they assume that search engine popularity translates into language popularity. It's not cause a bunch of hipsters want to learn how to make an iOS application that it's actually going to become the programming language of choice for a majority of the developers.
C in combination with some form of assembly still holds the absolute first position in terms of how much its actually deployed. Every mainstream OS its core, bootloader, ... was written in C and assembly. And lets not forget about all the microcontrollers out there. Almost all mainstream microcontrollers are programmed in C and assembly. And there are a whole lot more microcontrollers out there than CPUs. Lets take the 8051 as an example; If you knew how many USB controllers actually use an 8051 internally. I'd go as far as appointing the 8051 assembly a top 10 spot if the amount of deployed units of software is taken into account.
C++ holds its second spot without problem simply due to the fact that it's compatible with C and it does offer native object extensions.
The top 5 will probably be completed by Visual Basic, C# and Java for enterprise applications. They're perfectly fine languages for such goals and they do their job well.
After that it becomes tricky, most likely a couple of web languages like PHP and Perl in combination with a few of the old gems like Ada and FORTRAN. Ada is used in the aircraft industry on a regular basis and FORTRAN is the corner stone of weather prediction. Two rather interesting languages (not really programming languages though) would most likely also show up on there: VHDL and Verilog.
Anyway, I would just wish people would stop linking to the TIOBE index cause it actually has 0 value compared to real research into the subject. I'd rather see them do a study trying to correlate suicide statistics in the programming community with the programming language that was being used at the time, that might actually give more information about how good a language is than a couple of search engine hits.

Re:Objective-C not required to create iOS Apps

[Anonymous Coward]

Could you pont to some of this 8051 USB microcontrollers?
.
I've been struggling with ARM, PIC and AVR. I'd wan't to give the old C51 a chance with a new samall project I've got.

PD: I love VHDL, but I think it should have remained as a hardware description language. Any sane person should go the system-verilog way.

Re:Objective-C not required to create iOS Apps

[umghhh]

that is a rare insightful and informative as well as interesting post. There is always a problem with choosing a proper proxy for your measurement. There are subjects that are not available for such statistics as in your example so this TIOBE thing should be taken for what it is - a measure of how many people actually have problems with particular language at the time. Nothing more but nothing less. It is some indication but not very good one for how much work is being done in particular language. I still go for c++ followed by c and java. Each has its own good and bad things.

Re:Objective-C not required to create iOS Apps

[solidraven]

The Cypress EZ-USB FX2LP ( http://www.cypress.com/?id=193 ) is a nice example of the 8051 still doing its job. If you want something more specific I suggest using Farnell to find one that suits your needs, they allow you to sort on 8051 and 8052 designs.

And VHDL for anything else than hardware synthesis is indeed something only a lunatic would use. But for building up systems it is a common choice in academic settings. Verilog isn't near as predictable as VHDL, and SystemC hardware synthesis is rather problematic.

see plus

[Anonymous Coward]

What they don't tell you is C++ (NDK) is used in Most Android games or else it will be slow as hell. Google doesn't want to tell you that because they want you to use Java. Of course C,C++, Objective C > Java.

Re:see plus

[Anonymous Coward]

What they don't tell you is C++ (NDK) is used in Most Android games or else it will be slow as hell. Google doesn't want to tell you that because they want you to use Java. Of course C,C++, Objective C > Java.

Java is only slow for programmers who don't understand what they're doing.

Seriously - it is.

Of course, if you understand what you're doing, you can program in just about any language and you'd never post anything as uselessly trite as "Objective C > Java".

Re:see plus

[0123456]

Java is only slow for programmers who don't understand what they're doing.

Or those who have to do anything complex and CPU-intensive.

Re:see plus

[SerpentMage]

BS!

I have written fast programs in both Java and C# that are maybe 10% slower than pedal to the metal C or C++. It really does depend on how you write the code. There are things that make Java and C# very slow. In fact I think one can argue that the current incarnation of C++ is a dog in terms of performance. With all of that template "goodness" you are just loping on stuff that Java and C# can do in an easier manner.

BTW for reference I write financial algorithms that include Monte Carlo simulations.

Re:see plus

[0123456]

BS!

I have written fast programs in both Java and C# that are maybe 10% slower than pedal to the metal C or C++.

Good for you: for i = 1 to 100 is pretty fast in any language.

Now try doing complex signal processing in Java.

Re:see plus

[Anonymous Coward]

BS!

I have written fast programs in both Java and C# that are maybe 10% slower than pedal to the metal C or C++.

Good for you: for i = 1 to 100 is pretty fast in any language.

Now try doing complex signal processing in Java.

Or anything with a GUI for that matter.

Re:see plus

[antsbull]

Weird how eBay threw out Microsoft technologies to use Java then isn't it? Could be, that you don't actually know what you're talking about and most likely that you don't work on enterprise scale projects.

Re:see plus

[PaladinAlpha]

In fact I think one can argue that the current incarnation of C++ is a dog in terms of performance. With all of that template "goodness" you are just loping on stuff that Java and C# can do in an easier manner.

Templates carry no run-time overhead, unlike the C# and Java generics, etc. That's why template-driven programming produces such fast code.

Re:see plus

[marcosdumay]

CPU intensive tasks are fine. The Sun's JVM used to have some problems with memory management, but I don't know how it is now (and don't know about other VMs).

Of course, there is also all the imprevisibility of Java. It doesn't make your task use more CPU, but it can make it fail for taking too much CPU time at the wrong moment.

Re:see plus

[Anonymous Coward]

be fair, templates have no run-time overhead, but they sort of are the god of code bloat. Nothing increases the size of your executable quite in the way that liberal use of templates can.

Re:see plus

[shutdown -p now]

I have written fast programs in both Java and C# that are maybe 10% slower than pedal to the metal C or C++. It really does depend on how you write the code.

.

How did you deal with the fact that .NET x86 JIT has extremely crappy floating point codegen (it uses x87 opcodes, for Christ sake!)?

Re:see plus

[bbn]

Templates carry no run-time overhead, unlike the C# and Java generics, etc. That's why template-driven programming produces such fast code.

I do not know about C# but Java generics use type erasure, meaning the specific type does not exist in the compiled byte code at all. There is no overhead. All generics does is ensuring your code is correct at compile time.

C++ templates is something completely different. It is both more and less than generics depending on how you view it.

Re:see plus

[Anonymous Coward]

Sure, if you live in a magical universe where your L1 instruction cache is of infinite size.

Re:see plus

[umghhh]

there are tradeoffs with every choice. If you work on an application where the 10% gain on one parameter is worth 20% loss on other(s) then you chose this one. That is something that 'partiuclar programming language' nazis hardly comprehend. In most of the cases that 10% speed increase does not matter but it does matter if you can read your code easilly. Majority designers are just lame - does not matter in what language. For masters of the trade there are differences but they are not comprehensible for us mortals. Then there are people like Linus who do not see the point of the whole discussion - they have made the choice and their hammer is ready to hit any nail because they are so good in it. Alas majority of us have no choice we code into existing code base which besides being shitty is also written in particular language that usually is not preferred choice for us we still code in those.

This whole discussion is not fruitful but amusing.

Re:see plus

[X.25]

BS!

I have written fast programs in both Java and C# that are maybe 10% slower than pedal to the metal C or C++. It really does depend on how you write the code.

So what did you write? hellworld.java?

Re:see plus

[UnknownSoldier]

> templates have no run-time overhead

That's not exactly true.

With lots of templates it tends to lead to excessive code bloat. On the PS3 you typically want to optimize for _size_, not _speed_, due to the small sizes of the caches.

Re:see plus

[Shoe Puppet]

I've seen GUIs in Java applications that were much better -- both in quality and speed -- than most "native" GUIs. Of course they didn't use Swing.

What a loud of garbage

[Billly Gates]

C is hardly in demand at all in the job market compared to other languages if you check monster.com and dice. I am not saying it is not important as operating systems tend to be written in it, but most demand is not to write operating systems or do very low level things.

Java was tops the last time I looked followed by C#.net, with php third but I would not be surprised if .NET overcame Java and php is becoming more and more popular.

Any other measure of importance is subjective and biased as every nerd has his opinion on why his tastes are better. But job openings and demand truly show what the market wants and is willing to pay which equals value/importance. Fact is I saw only one C programming position advertised in the last 7 years. .

Re:What a loud of garbage

[Anonymous Coward]

Guess you're looking at other jobs than other people, at least in the embedded area noone would even think about using any of the languages you seem to prefer. Haven't seen more than a few job offers asking for any of those, and wouldn't like one either - but one should better not expect that personal view to be a good representation of the overall job market...

Re:What a loud of garbage

[Skapare]

I just ran across a company that does almost all their in-house development in C. They are not hiring. They have no trouble finding C programmers when they need more, and those they have are very productive.

Re:What a loud of garbage

[superwiz]

Don't treat number of posts on dice or monster as indicative of anything. Most of them are daily re-posts for non-existing jobs by resume-collection mills. Jobs which actually exist and get filled statistically end up being much more rare on those sites.

Re:What a loud of garbage

[s122604]

There is a lot of .net interest right now.
I'm getting hit up by recruiters asking me about the tiny bit of C# Asp.net experience that I have (other technologies are much more prevalent on my resume). There's enough interest that I'm thinking about getting the set of magic books that everybody gets and going ahead and getting my certification.

IIS/asp.net/c#/Sql Server isn't the answer to everything, but it allows small to medium sized business to do things that are fairly good, fairly quickly, with programmers that are fairly skilled (and therefore fairly cheap). The purists and self-appointed alpha geeks might howl, but it turns out to work for a lot of folks.

Re:What a loud of garbage

[Billly Gates]

I just ran across a company that does almost all their in-house development in C. They are not hiring. They have no trouble finding C programmers when they need more, and those they have are very productive.

Which is why C is not top 1. There are more programmers than positions fluent in that language which was exactly my point.

Re:What a loud of garbage

[Billly Gates]

Don't treat number of posts on dice or monster as indicative of anything. Most of them are daily re-posts for non-existing jobs by resume-collection mills. Jobs which actually exist and get filled statistically end up being much more rare on those sites.

Other metrics are all biased as everyone has their ideal language. Real world demand and valuation on what someone is willing to pay for something should be the metric as it is what society needs the most. That is economics 101.

Re:What a loud of garbage

[superwiz]

. Real world demand and valuation on what someone is willing to pay for something should be the metric as it is what society needs the most.

Absolutely true. Which is exactly why you shouldn't treat the number of posts on Monster or Dice as indicative of anything. Read the gp post again for the explanation.

Re:What a loud of garbage

[hackula]

Good thing I am not a C programmer I suppose. Everything about a language is secondary to demand.

Re:What a loud of garbage

[hackula]

Yep, 2 or 3 unsolicited calls/emails per week is typical for C#ers in my area.

Bravo that C is still relevant.

[PerlPunk]

As much as I like languages like Perl and Java, where memory is managed for you (kind of), there will always be a great need for languages that brings programmers as close as necessary to the workings of the machine itself.

Re:Bravo that C is still relevant.

[gbjbaanb]

yes, those 2 needs for performance are: cloud and mobile.

Both have energy issues, so efficient code means more battery life or less electricity bill. Nowadays, no-one cares about the old desktop area, so native code is coming back.

Re:Bravo that C is still relevant.

[k.a.f.]

As much as I like languages like Perl and Java, where memory is managed for you (kind of), there will always be a great need for languages that brings programmers as close as necessary to the workings of the machine itself.

Yes, mostly for writing kernels and virtual machines.

Re:Bravo that C is still relevant.

[hackula]

Do what most of us do who need super optimization: write the 2% of the algorithm that is causing the performance hit in C, then wrap it all up in C# or Python (or any of the other "ergonomic" languages).

"machine independent assembler-like language"?!?

[Brannon]

What? What idiot posted that garbage? Oh, timothy...

Understood.

There are several problems with that article

[93 Escort Wagon]

1) The one stated in the summary - the C++ vs. Objective C graph is on a very small Y axis that exaggerates the differences.

2) They've included Javascript, apparently in it's seldom-used server-side form, to intimate its popularity is going down (AFAICT they don't bother to mention this differentiation).

3) In their 2011 vs 2012 table, they indicate a language's change in table rank using arrows - one point in change equals one arrow. Visually that makes it look like some languages (e.g. Visual Basic .NET) are exploding when in reality it's just that lesser-used languages need smaller increases in usage to make it look like they're taking off. VB .NET is in 15th place - the language in 10th place, Ruby, only has 1.77% penetration.

Re:There are several problems with that article

[jmerlin]

I find it hilarious that Obj-C is ranked so far above something like Javascript. These indexes are meant to rate popularity, right? So subjective qualitative WTF-is-wrong-with-your-language arguments aside, the sheer volume of Javascript programming going on in browsers (that includes a large portion of phone-based software in webapps built for phones) should surely dwarf Obj-C. I also find that JS questions tend to dominate SO, too, much more so than Java, Obj-C, or C/C++. In fact, the numbers from SO are:

231,861 questions tagged 'Javascript'
91,526 questions tagged 'Objective-c'

So as you say, I can't find these indices valid at all, as they fail horribly to be accurate. For instance, the transparent index lists JS as a "script language." Nice.

Re:There are several problems with that article

[Anonymous Coward]

There is an even bigger problem... I'll just quote the definition of the index:

The ratings are calculated by counting hits of the most popular search engines.
The search query that is used is
+"<language> programming"

At this point I stopped caring and so would anyone else. If they had put this definition near to their ‘data’ we probably wouldn't even be talking about this.

Re:There are several problems with that article

[TheRaven64]

A lot of toolkits now generate JavaScript automatically from your server-side code, so the number of people that need to write it by hand decreases, in much the same way that few people need to write assembly by hand now that compilers exist.

Re:There are several problems with that article

[hackula]

Very true. Another decent indicator is to look at the language rankings on Github. It definitely skews things away from corprate type projects, but clearly there is a whole lot going on in Javascript. It blows just about everything else away.

Shifting market or shifting paradigm

[tomhath]

I have to wonder if the world is ready to move back to a simpler time. So much of programming these days involves building "infrastructure" with all the industry approved buzzwords (factories, patterns, aspects, reuse, blah, blah, blah); sometimes it's better to just bang out the application and move on.

Re:Shifting market or shifting paradigm

[Anonymous Coward]

Which world? In the world of operating systems, they tried the same buzzwords and failed.

Re:Shifting market or shifting paradigm

[Anonymous Coward]

have to wonder if the world is ready to move back to a simpler time. So much of programming these days involves building "infrastructure" with all the industry approved buzzwords (factories, patterns, aspects, reuse, blah, blah, blah); sometimes it's better to just bang out the application and move on.

I've been continually amused by all the Academic nonsense filtering into modern languages. Big scary words for simple concepts many of which are wrought with peril.

Factories god damn when I found out what a factory was I broke out laughing.

Ever tried looking for jobs using C?

[Jiro]

I don't get it. If you try searching for jobs programming in C, you'll find that almost everything that matches the search is Objective C, C++, or C# (or, on some poorly run job sites,a C++ or C# job where the punctuation got lost and it's displayed as C). Sometimes a job will say C/C++. C is rare as hen's teeth except for embedded development and there aren't *that* many jobs in embedded development.

I just went to monster.com and searched for C. What I found starting at the top was:

-- C++ job that lost the punctuation
-- Objective-C
-- C# job that lost the punctuation
-- C/C++
-- Objective-C
-- C/C++, C#
-- C/C++
-- Objective-C

etc. The first C job was item 14 (and is embedded). The next C job, ignoring the false hits on such things as A B C, was item 24 (also embedded), and C wasn't the main skill required. So how in the world can C be number one?

Re:Ever tried looking for jobs using C?

[geek]

That's because most of the jobs using C are engineering jobs that work at the hardware level and it's assumed you know and use C at that level.

Re:Ever tried looking for jobs using C?

[Animats]

Mod parent up. "The popular search engines Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings." That's rather lame. Exactly how do they search for "C", anyway? Do Sesame Street episodes brought to you by the letter C count?

The decline in C++ is probably real. It's on the way out as an application-level programming language. Big, complex applications with serious performance requirements and elaborate internal data structures, like 3D CAD, benefit from being written in C++. But there's no reason to write a routine desktop business app in it any more. Just moving windows and menus around and talking to the database can be done far more easily by other means.

Re:Ever tried looking for jobs using C?

[Anonymous Coward]

How does this answer parent's question. The first 13 job listing never mentioned C as a requirements. Are you assuming all those jobs are "engineering jobs that work at the hardware level and it's assumed you know and use C at that level" ? I don't see how iPhone app development using Objective-C assumes you know how to use C at the hardware level...whatever that means.

Re:Ever tried looking for jobs using C?

[labnet]

That's because most of the jobs using C are engineering jobs that work at the hardware level and it's assumed you know and use C at that level.

Of the 7 electronic engineers here, all can code in C. There are probably a few other discicplines in science/engineering/graphics where C is a subset of your main capability.

Re:Ever tried looking for jobs using C?

[Anonymous Coward]

Not trying to defend C, but maybe they are just looking for engineers who can do the job with whatever tools they choose, hence no "C jobs".

Re:Ever tried looking for jobs using C?

[Dogbertius]

Perhaps because it requires extreme competence and a grasp of programming languages as a whole, including operating systems, Boolean logic, and chip fab (to a limited degree) in order to be a capable programmer at the minimum?

For the record, it took me all of a single weekend to master C++, Java, and C# by the time I was 25 years of age.

Maybe it helps to learn things from the ground-up the first time rather than bitching about how difficult it is years later.

Re:Ever tried looking for jobs using C?

[SvnLyrBrto]

In many cases the person writing the listing for Monster, Craigslist, or whatever, is not actually an engineer who knows exactly what skills that specific job will require. He's an HR type who kinda sorta knows a little bit about what a programmer does, can write a flowery description of how wonderful the company is, can write up a generic description of what entails a good employee, and knows all of the latest technical buzz words, but not necessarily what they mean.

In these cases, the hiring manager may ask HR for candidates who know C. But the HR guy sees that objective-C and C# are "trending" on Facebook, on LinkedIn, in the "twitterverse" and in the "social media blogosphere"; and he puts them on the listing instead of plain old C.

There are also jobs where it's just assumed that you know C. My first job out of college was like that. I was hired because I'd studied Ada in school and the job description didn't list C at all. But the actual job involved quite a lot of re-implementation of existing Ada code into C. And it was just assumed that, as a programmer and computer science graduate, I knew C by default.

Re:Ever tried looking for jobs using C?

[Anonymous Coward]

> there aren't *that* many jobs in embedded development

Know how I know you're a moron?

Re:Ever tried looking for jobs using C?

[Skapare]

Or it could be that there are enough C programmers around that it's not necessary to advertise for jobs. Only about 10 to 15 of open positions ever get listed on the big job boards. And those are the ones where management (or in some cases HR) stuck in too many requirements that make it hard to find people (maybe because they only want top one percent rock star programmers).

And that one requirement of programming in C makes for a fine barrier to select for to programming talent that can get the job done, reducing the need for hiring extra grunt programmers.

Re:Ever tried looking for jobs using C?

[Idbar]

Brilliant conclusion! Can you imagine the results from a search engine looking for any single letter!?

Let's try this. Let's call the programming language A, and see what your web search returns. The reason why many job postings include C++ is to allow search engines to find them easy.

If they had called C, the Efficient Compiled Programing Language (ECPL) for sure it would be much much easier to find on a web search.

Do you remember when Google wouldn't even show C++ due to some issues with the + sign?

Re:Ever tried looking for jobs using C?

[DarkAurora]

Can't be half as frustrating as being on the other end trying to find C programmers. I've been searching for months for a C person with a Linux apps focus that can actually program. I've found tons of people with job experience going back to before I could walk that can't even produce FizzBuzz.

Re:Ever tried looking for jobs using C?

[Jiro]

I'm a moron because I know how to count to 14?

Re:Ever tried looking for jobs using C?

[Jiro]

Since I am trying to compare C, C++, C#, and Objective-C, the fact that a single search returns them all just makes the search more convenient. If they had called it ECPL I would have had to search for ECPL or C++ or C# or Objective-C and I would have gotten the same results (except for the false hits).

Re:Ever tried looking for jobs using C?

[Jiro]

I just googled FizzBuzz, to which I have to ask, "Seriously?"

Is your job posted anywhere on a job site I can get to?

Re:Ever tried looking for jobs using C?

[Anonymous Coward]

Actually, no. I came to conclusion that Qt library is the best, easiest and most flexible one. C# is Microsoft madness with all the consequences, Java has problem factory. Yes, all three languages/frameworks work, but for next big project I'm choosing C++/Qt.

Re:Ever tried looking for jobs using C?

[WaffleMonster]

The decline in C++ is probably real. It's on the way out as an application-level programming language. Big, complex applications with serious performance requirements and elaborate internal data structures, like 3D CAD, benefit from being written in C++.

It's on its way back cause CPU cores are not getting anymore powerful and power cost of computation is increasing in mobile apps.

But there's no reason to write a routine desktop business app in it any more

Anymore? Seriously in the past 20 years who would choose C for writing boaring business apps?

Just moving windows and menus around and talking to the database can be done far more easily by other means.

This never changed. The trend you are assuming ever existed in modern times died ages ago with the advent of clarion and foxpro.

Re:Ever tried looking for jobs using C?

[Raenex]

Mod parent up. "The popular search engines Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings." That's rather lame. Exactly how do they search for "C", anyway? Do Sesame Street episodes brought to you by the letter C count?

TIOBE is good for generating bullshit headlines and boastful articles about misleading statistics.

The definition is pretty simple. They search for: +"<language> programming", then they try to look for false positives to get a "confidence" factor, and then use that to scale the resulting number of hits. They also include some search term qualifiers for certain languages, but I didn't see any listed for C.

This is really, really poor for a language with many false positives like C, because there are so many false positive results returned, but they are only looking at the first 100 results. The first results will have the fewest number of false positives, while the later results will almost all be false positives. What they are doing is assuming a linear relationship where instead it is most likely an exponential dropoff.

The fact that C is now on top is almost for sure due to the rise of false postives due to Objective-C gaining popularity.

Re:Ever tried looking for jobs using C?

[Anonymous Coward]

Well if you think counting the ads until you hit a certain keyword tells you anything about how many embedded jobs there are, then yeah...

Re:Ever tried looking for jobs using C?

[erixm]

And it's even worse for Go, which is predictably rated very low by TIOBE. Of course, you would think Google of all companies should have known better than to pick a name for a programming language that is impossible to search for...

Re:Ever tried looking for jobs using C?

[Jiro]

Actually I just tried Googling up+"C programming". It goes to 62 pages--far more than the first 100 results--and there are virtually no false positives. Very few of them were Objective-C. So this part of the survey seems to be okay, strange as it may seem.

Re:Ever tried looking for jobs using C?

[hackula]

IDK, the D programming language is not even on the list. explanation?

Re:Ever tried looking for jobs using C?

[hackula]

You would not believe how many people who apply for programming jobs cannot complete FizzBuzz. In my experience (I have probably interviewed around 100 people), I would call it at about 1 in 8. I give every possible concession too. I write out the instructions, explain them verbally, tell them they can ask a question at any time (clarifications or straight up help solving the problem), tell them they can write the code in any language regardless of what the position requires or what is on their resume, tell them that Googling is not only allowed but encouraged (You could literally copy and paste the answer, and that would be allowed), I let them know that they have 1 hour to complete the problem, and I let them know that pseudocode is perfectly acceptable if they get stuck at any one place.

I was absolutely dumbfounded at how few people can actually accomplish this. Often, as testing was last, I was already convinced that the person was a sure thing and saw the test as mostly a formality... no longer.

FYI, fizzbuzz is only a filter question. If someone gets it right, that is not enough to get hired. If they fail this, then the rest of the questions are a waste of time and they get the door for essentially being dishonest about their skills. The rest of the questions are not brutal, but they do require a bit more. Usually something like "Here is the first chapter of Moby Dick. Sort all of the words by frequency and display them as a list with the number of occurrences of each word beside them". Basic stuff that shows they know the language they say they do, can do basic problem solving, and have an operational brain.

Re:Ever tried looking for jobs using C?

[Raenex]

So this part of the survey seems to be okay, strange as it may seem.

You just highlighted the problem. I get back 10.6 million hits for the search term +"C programming". You looked at 620 results and assume by that you can tell what the other 10.6 million results contain. Your 620 is a rounding error on an what is a very lopsided distribution that is skewed to better results at the very beginning.

love me sumodat objective-c

[Anonymous Coward]

if u aint using objective-c then u a programming chump

C lives!

[jpostel]

Wherefore art thou Dennis Ritchie?

Re:C lives!

[jjeffries]

He's going to be late... as in the late Dennis Ritchie.

Re:C lives!

[Anonymous Coward]

He's going to be late... as in the late Dennis Ritchie.

You were never any good at threats.

We need a new language

[CockMonster]

Power and syntax of C, safety of C++, useful compiler errors like Java. NO HEADER FILES!!!

Re:We need a new language

[Anonymous Coward]

Try D

Re:We need a new language

[Anonymous Coward]

Go?

Re:We need a new language

[luis_a_espinal]

Power and syntax of C, safety of C++, useful compiler errors like Java. NO HEADER FILES!!!

Wut?

Re:We need a new language

[Anonymous Coward]

Power and syntax of C, safety of C++, useful compiler errors like Java.

NO HEADER FILES!!!

D?

http://dlang.org/

Re:We need a new language

[solidraven]

The java compiler gives useful errors?

Re:We need a new language

[betterunixthanunix]

safety of C++,

What safety are you referring to there? The things that make C unsafe also make C++ unsafe, and on top of that, you have things like:

int f(char*);

int f(int);

std::string f(){} // Compilers are not required to return an error here

int operator,(int a, int b){ //...} // Does not necessarily work as expected

Classname::~Classname(){memberOfStreamType.close();} // Could cause abort() to be called; more likely to do so in C++11

Only experts can be expected to write reliable or safe code in C++, and even experts can be surprised by the ways things can go wrong. Like C, C++ is riddled with ambiguous statements, undefined behavior, unpredictable results, and C++ also adds unreliable constructs. We need a language that is not like C++ when we write high level programs.

Re:We need a new language

[Anonymous Coward]

Perhaps he meant "actually has the safety that C++ pretends to have".

Re:We need a new language

[luis_a_espinal]

Perhaps he meant "actually has the safety that C++ pretends to have".

Indeed. I would go even further than that. C++ does not pretend to be inherently safer than C (sans a few things, like requiring prototypes.) All C++ aims to is to facilitate the building higher abstractions on a OO paradigm using a systems-level language with C compatibility in mind. If people choose C++ for safety, they are out of their minds. If safety is a primary concern, tThere are better languages (Ada or Java) that have some formalized notion of safety as one of the driving forces behind their design.

Re:We need a new language

[Anonymous Coward]

Power and syntax of C, safety of C++, useful compiler errors like Java.

NO HEADER FILES!!!

It already exists and is called D.

Re:We need a new language

[hazah]

Probably type safety.

Re:We need a new language

[angel'o'sphere]

Yes it does, it usually tells you exactly what you did wrong. In Eclipse you can hit ctrl-1 and get a menu for easy fixes (like adding a cast or importing the missing type(a bit similar to #inlcude, but more precisely an "extern something" declaration) )
Ofc, you can also wait till a mouse hover for clicking comes up.

Re:We need a new language

[solidraven]

Yes, but that's the UI interpreting the output of the compiler for you. The actual compiler errors aren't nearly as clear as you might think. Oracle/Sun's java compiler is about on par with GCC in terms of error reporting in my opinion.

Re:We need a new language

[angel'o'sphere]

Erm, the UI uses either the ecplise compiler or the javac compiler. There is no interpretation.
The error messages are similar whether you use the build in one or an ant or maven build or javac directly.

However similar errors might yield slightly different messages, depending on vendor (IBM/Oracle or Eclipse foundation).

However I never saw an irritating one ...

Re:We need a new language

[hackula]

The first two are mutually exclusive.

Re:We need a new language

[solidraven]

If it gives a list of possible fixes it's sure as hell doing some for of interpretation.

Re:We need a new language

[angel'o'sphere]

Why do you think so? The eclipse internal compiler surely is not interpreting its own error messages to give hints for fixes ...

Re:We need a new language

[solidraven]

It does have to interpret the messages at some level, lexers for example aren't known for giving the best error messages (most of the time they don't have sufficient information to do so). Often the compiler will go looking for the exact mistake itself if it gives a good error message.

Re:We need a new language

[Anonymous Coward]

Why? that would be something like modula3 but with C sintax

Use Objetive-C instead with apple or gnustep/etoile framework

C, Cex & Cun

[Anonymous Coward]

Come to the C-side

C you Soon

OH I GOT MODDED DOWN???

[Anonymous Coward]

I GOT MODDED DOWN?????

Proof that political correctness is overrunning Slashdot. This makes my blood pressure rise so much I have to take another pill! WHERE IS OUR FREEDOM? Taken by Barack Hussein, I believe.

Re:OH I GOT MODDED DOWN???

[Anonymous Coward]

It's not about political correctness. It's about mentioning this "god" fantasy thing and talking about USA politics in a thread about computer languages.

Re:OH I GOT MODDED DOWN???

[ozmanjusri]

It's about mentioning this "god" fantasy thing

It's no fantasy.

God started out as a C coder, got bored and tried to rebuild the project in a self-built language similar to Brainfuck http://en.wikipedia.org/wiki/Brainfuck, now called DNA. The signs are everywhere - in fact GCC is still being used in places, notably to produce Alanine.

Of course, it's an old project, abandoned long ago. There's cruft, commented out code and dependencies everywhere, The APIs are wildly inconsistent, the whole thing is a virus and worm magnet. Even fork bombs are rarely trapped.

The documentation is archaic and unreadable, rewritten from the original by ancient geeks.Modern coders can only guess at what it means, and according to Nietzsche, the guy who wrote it left the company long ago.

About the only thing going for it is a very effective, if slightly weird, bootstrapping process.

Re:OH I GOT MODDED DOWN???

[Anonymous Coward]

...and I thought God was a Higgs boson, kicking around in a pinball machine (aptly named Symmetry Breaker) operated by some bored hyperdimensional kid. How wrong I was! :-)

Re:OH I GOT MODDED DOWN???

[Anonymous Coward]

And don't forget that the hypervisors (plural) run outside of time. One can't do garbage collection when the garbage is eternal, only transmutation.

Re:OH I GOT MODDED DOWN???

[Anonymous Coward]

Best Slashsdot post ever!

Re:OH I GOT MODDED DOWN???

[Anonymous Coward]

- in fact GCC is still being used in places, notably to produce Alanine.

Isn't phenyl-alanine --oops I mean aspertame-- --oops, I mean nutrasweet-- the shit they put in 'low cal' soft drinks that pretends to be sugar, but makes kids sick and gives people cancer?

Re:OH I GOT MODDED DOWN???

[Tamerlin]

So, you're saying that the explosive overpopulation of homo retardus is just a fork bomb?

Re:OH I GOT MODDED DOWN???

[ozmanjusri]

Actually, I was thinking at a cellular level, where a fork bomb is analogous to cancer, but that'd work too...

C is number ONE...

[Anonymous Coward]

C is number one...hundred, in Roman numerals, that is. Hence the popularity, it's the Benjamin Franklin of programming languages, and as we all know, it's all about the Benjamins!

Greeting from beyond

[Anonymous Coward]

#include <stdio.h>

int main()
{
    printf( "suck my wind, bitches.\n" );
    return 0;
}

- from "The C Programming Language", 2012 edition

Re:Greeting from beyond

[Anonymous Coward]

Too bad it's undefined behaviour unless you're in a freestanding environment.
Your C++ is showing.

D?

[Anonymous Coward]

Shame D is moving so slowly.

C is the most portable

[phantomfive]

My guess is that C, besides being a good low-level language, is popular because it is the most portable.

C code runs on any platform, the first thing people do when they make a new platform is create a C compiler. If your library is written in C, then you can write bindings for it from practically any language. Then the Ruby guys can be just as happy as the Java guys.

Probably more importantly, recently, if you want to write an app for both iPhone and Android, you can just code the backend in C, and all you have to do is create a GUI on top for each platform. You can't even write standard Java on either platform.

Re:C is the most portable

[91degrees]

Probably. An important aspect of the portability is that you can get it for even the most low power devices - even the tiny devices used on smart cards.

And nothing of value was said

[johnlcallaway]

All languages come with compromises, and it's still a matter of selecting the one that gets a particular task done in an optimal manner given all the parameters of getting the specific task done with whatever compromises are allowed, the skills available, using the program, and maintaining it going forward.

And that's not something to be settled by a popularity contest.

For what it does, C is the best

[phantomfive]

If you are looking for an imperative language that is flexible and lets you treat memory as memory, then C is the best language out there.

If you're looking for a language that abstracts all those computer bits out, and makes your job as easy as possible, you might want Ruby, C#, Prolog, or something else. But C lets you get a good feel for what your code is actually doing on the computer.

Re:For what it does, C is the best

[Anonymous Coward]

Exactly. The cost+benefit of C++ and ObjC just can't compare to C or a higher-level language.

People use C++ and ObjC because they want to pretend like they're using "C", but don't want the effort. The results usually suck hard.

C really hit a sweet spot, and it just can't be emulated. Some other higher-level languages have sweet spots of their own. C++ and ObjC are just middling languages, where nothing quite resonates.

Re:For what it does, C is the best

[Anonymous Coward]

"lets you treat memory as memory"

Are you sure about that?

: It is undefined behavior to cast an int* to a float* and dereference it (accessing the "int" as if it were a "float"). C requires that these sorts of type conversions happen through memcpy: using pointer casts is not correct and undefined behavior results.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

OBJECTIVE C IS BEST C

[Anonymous Coward]

deal with it.

Just started learning objective C on thursday and

[physburn]

retvalue = [object methodname]; // YUCK YUCK YUCK

Simplicity and clarity

[Anonymous Coward]

K&R (also known as the bible) is only a couple of hundred pages long. C is a simple language. You can read C code and not have to worry about strange gotchas. C++, on the other hand, not so much ... you can never be sure someone hasn't overloaded something beyond recognition. The rules of other languages are also way complicated and make it hard to understand what's going on.

You can write more concise code with other languages but the plethora of rules means that you will have more trouble understanding that code. Anyway, you can totally write fully structured code in C and that takes away many of the supposed advantages of other languages.

The only major language that is clearly better than C, in the clarity and simplicity department, is Python. The code is easy to read and doesn't have a lot of complex rules that will cause confusion.

Re:Simplicity and clarity

[marcosdumay]

You can read C code and not have to worry about strange gotchas.

I didn't know they retired the C preprocessor.

Re:Simplicity and clarity

[DeathFromSomewhere]

You can read C code and not have to worry about strange gotchas.

#define + -

Good luck.

Re:Simplicity and clarity

[viperidaenz]

I haven't found any strange gotchas in Java. Am I looking in the wrong place?

Re:Simplicity and clarity

[solidraven]

Yes, but keep in mind. The C preprocessor is the only thing that stands in between the sanity of the average C programmer and the great void.

Re:Simplicity and clarity

[Rockoon]

The C preprocessor is most definitely the languages best feature. Both simple and powerful at the same time. I cannot think of a language that has done it better.

Re:Simplicity and clarity

[bytesex]

Depens on what you're trying to do with it, and how long you've been involved. If, like me, you were with Java from the first days, you'll remember your anger at them completely overhauling the GUI and IO APIs, and the lack of debugging possibilities. Oh, and strictfp of course. And the format of jars, and the command-line format. Oh, and nulls as arguments to ambiguous methods. Oh, and casting of course. There's always casting.

Re:Simplicity and clarity

[solidraven]

I won't argue with you about that, it's simple and very powerful. Other languages have tried to enhance it but in the end they all go back to the original design. It's not the most elegant thing in the world but it gets the job done.

Re:Simplicity and clarity

[marcosdumay]

It's pretty and powerfull. No argument here.

Also, at the wrong hands it is much more dangerous than operator overloading or any other C++ only feature that people like to complain.

Re:Simplicity and clarity

[hackula]

Almost all of the popular languages are pretty straight forward and (nearly) free of gotchas. Add a framework, and madness ensues. C does absolutely nothing to fix this. For the most part, I could care less about what language I am working in. The ecosystem and various libraries surrounding the language, on the other hand, make an enormous difference.

Java is evil?

[Anonymous Coward]

So Java is used by the financial institutions and we know that the whole finance industry is evil and crooked. That makes Java the tool of the evil crooks and therefore Java is evil and crooked by association.

After all, it's always taking memory that I've allocated by my hard work and saying that it's for my "convenience".

And Java is now an Oracle product, too.

Evil++

"Overtaken"?

[MacGyver2210]

Who says it has overtaken anything? For who? Where I code, we all use good 'ol C++. No matter how many times we tried to adopt Obj-C it just failed. Unless we wanted to write an iPad/iPhone app. Is this actually posted by an Apple shill? That would make more sense to me.

I have never found a non-Apple task that works better in Obj-C than a C/C++ setup.

Survey is skewed by iOS developers

[kriston]

This survey is skewed by iOS developers trowelling out tons of appstore apps of questionable utility.

Re:Survey is skewed by iOS developers

[Anonymous Coward]

aka software that people actually use vs software NOBODY uses.

Re:Survey is skewed by iOS developers

[ceoyoyo]

Sure, because there aren't any C++ developers trowelling out tons of apps of questionable utility.

Re:Survey is skewed by iOS developers

[Anonymous Coward]

*** Alert ***
Bad-ass over here!
*** Alert ***

Re:Survey is skewed by iOS developers

[hackula]

The bottom 99% of apps in the iOS app store have something like 1% market share (numbers made up, but feel free to look it up). Nobody is using "Free Fart App # 53".

TIOBE is worse than useless

[Anonymous Coward]

Monster.com shows Objective-C tying with FORTRAN for a very small number of jobs: 5, in the entire Denver job market.
Not something I am going to base any career decision on for now.

Re:TIOBE is worse than useless

[jcr]

If there are only five Obj-C jobs open in Denver, perhaps you should be looking in a wider area.

-jcr

Re:TIOBE is worse than useless

[Anonymous Coward]

I think that if there's only 5 obj-c jobs in the Denver area, it probably means it's not a very useful skill. You are aware that Denver metro is second in the number of tech jobs in the country, losing out only to silicon valley? When I got laid off a couple years ago, it took me one month to find another software job in the Denver area, my company alone needs to hire 30+ software devs, and are having a hell of a job finding people as the market is so competitive for s/w engineers/computer engineers.

Re:TIOBE is worse than useless

[jcr]

I think that if there's only 5 obj-c jobs in the Denver area, it probably means it's not a very useful skill.

What it means to me is that Denver is not quite the hotbed of development activity that you seem to believe it is.

You are aware that Denver metro is second in the number of tech jobs in the country, losing out only to silicon valley?

That's news to me. The last time I was looking to hire someone in Denver, I had about fifty applications for the gig. As for Denver being "second only to silicon valley", I'd need to see a source on that. Judging by the headhunter pings I get, you're way behind NYC, DC, LA, Chicago, Los Angeles, Seattle and Atlanta.

-jcr

C, raw machine independent assembler-like language

[Anonymous Coward]

Mikejuk obviously has no experience programming in assembler and/or C. Not all languages that are not "object oriented" are raw or assembler languages.

C is a simple, well defined language that allows almost any program to be written - look at its ubiquity and persistent popularity for writing a very wide range of programs. It is far removed from the hardware details that assembler languages deal with (CPU registers and instruction sets, in particular). Where it not so, C programs wouldn't enjoy the high degree of portability that they do.

It is hard to guess what Mikejuk imagines a "sophisticated" language to be. Perhaps one that wears tuxedos, drinks martinis with the upper crust at swish affairs and puts on posh manners and accents to impress the debutantes? Or is she just trying to say that C isn't complicated, in a sophisticated manner? In which case, it's a feature, not a fault.

C is an assembler-like language?

[Anonymous Coward]

Since when?

good (or too late) timing for C++ 2011 standard?

[awollabe]

Arguably, the new 2011 standard could push C++ back to number 1, as it addresses a lot of the usual weaknesses of C++ (better memory management, type inference, threading, etc.). But I suppose it depends on how many people are willing to learn and code to the new standard.

Re:"machine independent assembler-like language"?!

[Dwedit]

Well, it IS a machine-independent assembly-like language. Use the -S or 'save temps' switch on GCC, and see the ASM code it generates. Don't forget your -O2 or -O3 switch, otherwise the code is really bad.

Please stop this.

[Anonymous Coward]

Please, please, slashdotters, please stop these tiobe index horserace stories.

I'm begging you, they are so damn foolish, they bother me enough to post about it.

Keyword count on the www pages is not a precuse measure of real world usage. And looking at day to day changes in such an index is extracting data from noise.

Re:Just started learning objective C on thursday a

[batwingTM]

The first language I learnt in Highschool was Hypertalk, more of a HTML forerunner (it was 1990) than a real programming language.
when I got to Uni and was studing Engineering they taught us C. When I started my Computing course the first language they taught us was Smalltalk, if you start talking about real OO languages you cannot ignore Smalltalk

Objective-C is really a bastard child of C and Smalltalk, and this messaging behaviour really flows back to Smalltalk's influence on the language.
I hated Smalltalk back then, as did most of my classmates, but I guess it has made Objective-C a but more straightforward for me as I have played in a language that communicates like that.

I have heard from my Programming friends (mostly Games programmers) that C++ is losing traction. C# is taking it's place (Not a massive departure syntax wise, and C# is used by 3rd party suites like Unity) and Objective-C is gaining popularity, even if it is from a GUI design point of view.

I'm not sure if I believe that Objective-C has overtaken C++, but the trend is there.

Your CLU to early OO

[Skapare]

Indeed there was OO before C++. I first learned it in a language called CLU. But the language itself was not really mature. I just took the object abstraction idea back to assembly language when I abandoned CLU.

Re:Your CLU to early OO

[Anonymous Coward]

So, one could say, you... got a clue. B) ...or didn't, as the case may be.

Re:Your CLU to early OO

[shutdown -p now]

The first "real" OO language was Simula 67, and in fact it's a direct ancestor of C++ - if you look at Simula, you suddenly realize that the first version of C++ was more or less C with Simula OOP constructs grafted on top (this is where "virtual" came from, by the way).

Re:Your CLU to early OO

[TheRaven64]

In Simula, every function was a closure and classes were functions that returned themselves. C++ got a half-arsed attempt at closures last year.

Re:Your CLU to early OO

[shutdown -p now]

In Simula, every function was a closure and classes were functions that returned themselves.

IIRC, at least in the original Simula this wasn't the case, because you couldn't declare a function returning a function, so in effect it had a limited form of closures, with no ability to escape - inherited pretty much as is from Algol 60.

I also don't get the "classes were functions" part. Sure, a class body could actually have code, but that was more like a constructor. I'll grant you that Simula classes are closures in that they can capture outer variables, and outlive the scope from which they capture (if you return a capturing object via a superclass reference).

C is the NCC-1701 of C-like languages

[russotto]

No bloody sharp, no bloody postincrement, and certainly no bloody "objective". Just C. Accept no substitutes.

Re:C is the NCC-1701 of C-like languages

[jbolden]

Given that roughly 100% of the Objective-C work is designed to go with the Cocoa libraries which are in Objective-C and use Objective-C conventions, what would be the advantage of pure C?

Re:C is the NCC-1701 of C-like languages

[viperidaenz]

When you're not using Cocoa, what would be the advantage of Objective-C?

Re:C is the NCC-1701 of C-like languages

[jbolden]

I don't know that there would be one. The last quarter century of Objective C development have all been driven by Cocoa at NeXT & Apple. Objective C never found a niche outside of Cocoa. Cocoa is, for all practical purposes, part of the language itself.

and of course

[superwiz]

generation of future C-programmer-turned-C++-programmer are being trained to think they know the one true way to code. They,too, someday, will try out C++ for its standard libraries and then will end up writing the most awful C++ code anyone has to read. And until their brain gets rewired for object-oriented thinking, they'll be laughing off everyone telling them that the garbage they write has to be actually readable by someone or it's pretty much useless. They will scoff and they will feel self-righteous. And then someday they will realize that they themselves can no longer read what they wrote. They will start thinking of ways to program in a way that is not just some throw-away code readable by a very small group of people. And then they will start coming up with ideas... the way they came up with ideas the first time they learned to program (only to later on realize that it's all been described in standard textbooks and that they didn't really come up with anything innovative). This time around it will be no different when after all the scoffing and all the flaming they'll pick up a copy of the 4 horsemen, read through it and nod along thinking to themselves "why haven't I read this before?" It has all happened before. It will all happen again.

TIOBE is complete crap

[Tough Love]

TIOBE is essentially just a big troll site. Their methodology is so far beyond unscientific it's not even wrong. Here is the result of my own unscientific poll:

C: About 234,000,000 results
Objective-C: About 41,400,000 results

See, C++ dominates Objective-C by more than a factor of five. You can take that to the bank. You're welcome.

Re:TIOBE is complete crap

[scoot80]

See, C++ dominates Objective-C by more than a factor of five. You can take that to the bank. You're welcome.

I don't think the bank would accept it. Your unscientific poll doesn't include C++... just C and Objective C.

Sure it *can* be

[Anonymous Coward]

Sure it *can* be done, but it fucking sucks. Compare programming Qt and GTK and you'll see why.

(Not that OOP is the be-all and end-all of programming. Frankly, it sucks for many problems, but GUI toolkits is one place where it's very useful -- mainly because of polymorphism.)

Re:Sure it *can* be

[MrEricSir]

Sure it *can* be done, but it fucking sucks. Compare programming Qt and GTK and you'll see why.

If you're talking about C vs. C++, sure. But keep in mind GObject/GTK has bindings for C++, Vala, Python, etc.

May Not Be a Fair Comparison

[NicknamesAreStupid]

I have written apps in C++, Objective-C, and others such as C#. I have always wound up using C in those apps, too. All of them make provisions for its use. The reason I used the other languages was the tools associated with the development environments such as Xcode and Visual Studio. For example, getting to the iOS APIs is not as easy for me just using C, but some things are easier for me to write in C, and the wrappers are straightforward.

Therefore, the survey might include usage such as mine, which could tag every app I ever wrote as a 'C' app. FWIW

Irony

[arthurpaliden]

Ayn Rand ended her life on Medicare. Which is kind of ironic don't you think?

TIOBE is 'real research'. Just misunderstood.

[sgtrock]

From their own description:

The TIOBE Programming Community index is an indicator of the popularity of programming languages... ...Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.

emphasis in the original

I think it's fair to say that if you take TIOBE for what it's worth, there's a lot to learn about how programming languages wax and wane in popularity over the years. Surely that's worth something.

Re:TIOBE is 'real research'. Just misunderstood.

[shutdown -p now]

If you look at the description of how they compute the index, it's essentially useless for any practical purpose. So why even bother debating it?

'C' - The language of technocrats

[TapeCutter]

On slashdot, it's a point of pride not to RTFA. Also it's much more interesting to go from Objective-C to Objectiv-isim to the spectrum of primate behaviour. The language popularity thing is just something for people who like talking about football ladders.

What we need now is another tenuosly linked meme...In my copy of 1984 there is a reference to a fictional document that describes the different languages spoken by various groups. One of those languages is 'C' - the language of technocrats. So it follows that if using objective-C makes one a Randian, I guess my long time use of 'C' means I'm an Orwellian technocrat. The odd thing is, I do believe the public service should be staffed with experts who are unaffraid to "speak truth to power".

Re:'C' - The language of technocrats

[mikiN]

Just name the new programming language C-homsky (after this guy). All problems solved.

good news

[smash]

Hopefully this will bring more developers to GNUStep / Etoile.

Sarah's C sounds betters

[ls671]

Palin C? I much prefer to code in Monty Python.

Sarah's C sounds betters...

Re:Sarah's C sounds betters

[Hognoxious]

Yeah, but have you tasted it?

Re:Sarah's C sounds betters

[ls671]

Not yet, only Aunt Jemima's CC :

http://www.auntjemima.com/aj_products/easyMixes/coffeeCake.cfm

Re:Sarah's C sounds betters

[mug funky]

gross, i was thinking of Michael Palin, making the python reference relevant.

dammit, i thought i was being clever, but /. is drawn to US politics like a magnet.

Popularity Index is Daft

[Anonymous Coward]

This is just another one of those 'Jim floats -> Jim is made of wood' matters. Don't know how so many people can be so daft not to see that the language popularity indice is simply created from the number of internet searches on the matter. Of course Objective-C will score high because 10 people trying to figure out just how the hell to use the bolloks will generate as many searches on Objective-C in a single month as a 10000 people that knows how to program C++ does on the latter in the same period. I write C++ 9 hours a day 289 days a year and probably perform a search related to it once a month. So the indice adds 2 and 2 and comes up with 5. Too many of this kind of stupidity going on in the world really.

utterly useless

[srealm]

Worst. Metric. Ever.

Using web searches? Seriously?

Given the sheer volume of code that will never, ever show up on a web search, the most they could hope to capture accurately is open source code. Which does not even come CLOSE to capturing the popularity of a language. The amount of commercial, closed-source code that is just ignored by this metric is disgusting to the point it makes it completely irrelevant.

At most, it shows what is trendy in the open source world. But having worked on a number of proprietary, multi-million line ode projects, that never see the light of a search engine, I can tell you're some languages are still as popular as ever in the corporate world. For example I have not noticed any significant decline in end for C++ programmers. Nor have I seen. Big uptick in places hiring for Objective-C. At least, not that are actually willing to pay living wage in big city.

And if not to try and inform people where to spend their 'learning time' for bet benefit (ie. to get the best job) then what is the point of such rankings?

Great post. Echoes of Bill Kent's "Data & Real

[Paul Fernhout]

http://www.bkent.net/Doc/darxrp.htm
"Data and Reality illustrates extensively the pitfalls of any simplistic attempts to capture reality as data in the sense of today's database systems. ... the value of this book resides in its critical, probing approach to the difficulties of modeling reality in typical information systems... it is very well written and should prove both enjoyable and enlightening to a careful reader. -ACM Computing Reviews, August 1980"

And also:
http://conferences.idealliance.org/extreme/html/2003/Kent01/EML2003Kent01.html
"The identity problem is intractable. To shed light on the problem, which currently is a swirl of interlocking problems that tend to get tumbled together in any discussion, we separate out the various issues so they can be rationally addressed one at a time as much as possible. We explore various aspects of the problem, pick one aspect to focus on, pose an idealized theoretical solution, and then explore the factors rendering this solution impractical. The success of this endeavor depends on our agreement that the selected aspect is a good one to focus on, and that the idealized solution represents a desirable target to try to approximate as well as we can. If we achieve consensus here, then we at least have a unifying framework for coordinating the various partial solutions to fragments of the problem. "

I thought you were going to also make a point about non-Western cultures often being less "object oriented" in their language learning (and perhaps more "relation-oriented" which I've heard in the past)...

Also, Alan Kay, who coined the term "object oriented" for Smalltalk, and said C++ was not what he had in mind, suggested later he should have used "message oriented", since message sending and processing is really at the heart of Smalltalk.

Herb Schildt is smiling

[Anonymous Coward]

The godfather of C, Herbert Schildt, is smiling today. Maybe he'll take the Windows 95 chapter out of his C book and release a new edition!

Who the fuck cares about Linus T's opinion?

[Anonymous Coward]

He also has an asshole, As do I. I just try not to emulate mine as much as he does.

So he can't figure out how to write clean C++ code. Fine. So he prefers C - even better. Whatever. Not sure why this matters.

Eiffel

[charnov]

I'll stick to Eiffel.. thank you very much ;-)

0 based arrays have no place in a modern language

[ThirdPrize]

Unless you are doing string or memory manipulation in c, then yes, you can use them. In all other languages it should be banned. I remember tutting when i read that c# had caved in to the c programmers and included it. There is just no need because 1) it is not obvious (eg, _month[0]="Jan" or things like that). 2)Use an iterator, that's what they are there for.

Of course that is just my opinion.

Re:0 based arrays have no place in a modern langua

[ThirdPrize]

And for that matter, don't get me started on Objective C either. Worst of both worlds.

The Tortise And The Hare

[assertation]

The competition between Microsoft and Apple is really starting to look like The Tortoise and The Hare.

Apple suffered so many humiliating defeats back in the day.

Now, they are dominating everything beyond desktop PCs.

Even Objective C is making a comeback.

Apple is really having the last laugh.

Note, I'm a linux user and not particularly a fanboy of either company.

Re:C, raw machine independent assembler-like langu

[ThirdPrize]

Well, C is one step above assembler but not much more than that. Most of its commands and operations map onto assembly quite nicely (x++ to increment a variable, etc) and outside of the libraries, there is not much "high level" functionality built into it. Its portable as most of it is "lowest common denominator" stuff.

No header files?

[Anonymous Coward]

What is wrong with header files?

Helps keep my code nice and clean.

Re:Just started learning objective C on thursday a

[ceoyoyo]

Stuck in your ways hey? There's nothing wrong with that syntax, it's just unfamiliar to you.

revalue = object.methodname(); would be as yucky to a SmallTalk or Objective C programmer who had never used anything else. Personally, I used to write PyObjC code, so I barely see the difference anymore.

Makes sense

[slapout]

There's a C compiler for almost every platform. And most of the compilers/interpreters for other languages are written in C.

Re:Just started learning objective C on thursday a

[Anonymous Coward]

I'm confused, how is that much different than OOP in C++, and grabbing a value from an object's accessor function?

Purely out of curiosity, I mean

The C myth

[Anonymous Coward]

Until hardware supports C++/Java/C# etc... at a native level, e.g. that compilers don't convert to C or the higher level language isn't based/written in C, then you'll start to see C decline.... rapidly.

Obj-C and iOS show this as an example. iOS is Obj-C compiled/processed at the h/w level.

WHOA there pardner!

[Anonymous Coward]

return 42-6*7;

Better do another code review before running that. In some locales, that divides by 0 and returns NAU.

May the Forth be with you.

[Anonymous Coward]

So are you saying it takes a fifth to do Forth?

Assembler Like?

[Anonymous Coward]

" However the real story is that C, a raw machine independent assembler-like language..."

Okay...it is now obvious to me that you have never used C before...and probably not C++ either. I'm still scratching my head about that "machine independent" part as well. I would NOT say that C is machine independent as it compiles down to machine code...and machines are notoriously fickle about their machine code. Maybe what you meant to say was that there are standards-compliant C compilers available for most (maybe all?...probably not *all*) platforms out there.

And what exactly do you mean by "raw?" That one's got me scratching my head as well.

Anyway, I expect C to be around for a very long time. Like Java, html, javascript, etc., it has its place...

Won't argue... but

[LostMyBeaver]

haha I love the but... do you?

I've programmed all of them professionally with multi-million line code bases and frankly... in recent years the extensions to C have made it a far more sophisticated language than ever. With extensions like variable length arrays in structs to allow for easier construction of classes (yes, they don't call them that, but they might as well) and things that just feel like hacked in RTTI, C has grown VERY sophisticated and even in some cases object-orientedish.

C++ has become a bit of a disaster. They have added ridiculous features like Lambas which may my rear end itch. They're a kinda neat feature in many ways, but I feel they will almost certainly be abused as opposed to used. It will attract JavaScript style programming which is painful to look at. I had hoped they would have added constructs for things like functional programming, but instead they made classes for that. The real problem with C++ in recent times is that the standard C++ library is a cludge of template on template on template. Also, with many companies I've encountered, we don't know how to treat the licensing for the templates when using GPL/LGPL implementations. It seems that since you're not linking to them so much as basing your code on them, even LGPL would require you to open source your code. It's a bit of a mess. So, we use Qt in most cases since it does everything the Standard C++ libraries do but without the licensing questions.

Objective-C is the least understood by the author of the article. There are certainly thousands of open source iPhone and Mac apps coming along, but it's VERY rare that a program is written in that language as opposed to wrapped in it. You have to code Objective-C to simply create an app, after that, you can use C, C++ or just about anything else (thank to SWIG) to write the rest of your app. If you look at the Mono.NET stuff which is REALLY popular as it's as easy as it gets, it compiles C# or CIL into Objective-C which is then compiled natively to the device. So, this can easily be considered writing in Objective-C, but in most circumstances, it would account for 1% or less of the actual program. The rest in C++, C# or C.

Now, I would be willing to believe that C# is quickly taking a high position in the open source since any C++ programmer can code it with almost no experience and it works on every platform known to man. Mac, Windows, Linux, iPhone, Android, Windows Phone... I don't know but maybe even Symbian. I even heard there's a Java back-end for it somewhere which could be used to make an app for BlackBerry... who the hell knows why... but there you have it. Oh.. and thanks to Unity3D, there's GOBS of C# apps.

C++ vs. C

[Anonymous Coward]

I would never choose C++ because of it's "OO" features (classes and inheritance). I use it because of templates and operator overloading making it easy to write a lot of generic code which the compiler can inline and optimize for me. You could do similar stuff in C with macros but gets extremely clunky and it is very hard to get type safe.

The whole concept of OO programming is totally overrated. I like to use "interfaces" as defined in Java, but I must say I really dislike inheritance. In C++ you can be inspired both from Java and functional languages like ML. And you can do it semi low-level: You write it high-level but everything will become very simple and effective when compiled due to compiler optimization. Something you can not do with a language like Java - and can't do easily in C.

There Doesn't have to be an App for That

[fm6]

I'm not an iPerson, but I notice that most Android apps are simply ports of web applications. In that use case, simply making the original web site mobile-friendly is a better use of resources. I would predict that the fascination with mobile apps will go away when people realize this, and then Objective C will be a much less popular skill.