Cee Is Not The Pinnacle Of Procedural

At least 5 times, probably more, I have seen C code compared to CeePlusPlus or some other language as an alleged justification of ObjectOrientedProgramming.

The CeeLanguage is not a very powerful representative of procedural in my opinion. Its claim to fame is CPU-based speed and portability, not its software engineering, conciseness, and developer productivity. So I beg, please stop using C to justify OOP.

[Lisp flame-bait removed and tossed into the ObjectiveAdvantagesOfLisp garbage can.]

Lisp may serve as a possible reference alternative to C, flaming aside.
So what is the pinnacle of procedural? Pascal? COBOL? How do we measure this?


You can write purely procedural programs with RubyLanguage. I'd say that's the pinnacle, unless you have a problem with the OO-ness of the core library.

Ruby is a pure object oriented language, according to their website and propaganda. Therefore you can't do purely procedural programming in Ruby. Or can you, and maybe they lied? Well, when one writes so called "procedural" code in Ruby, it's not really procedural according to a RubyWeenie?; it's just a global object. (However, in my own opinion, and in Wirth's opinion, and many others' opinion, object oriented programming is procedural programming, but with more extensions and abilities added to structs/records.)

It's SchemeLanguage. What is? Surely not the pinnacle of anything.
An example of where C's lack of features may make OO look better is in adding new parameters, especially lots of optional parameters. In C++ you set only the attributes you need, and the rest default to the parent. If C had optional named parameters then you could more easily get similar behavior. Or, if it at least had a built-in associative array to put parameters/settings into.
Things about C that make programming harder or more bloated:

C++ gives you more choices to compensate for these holes. That does not mean that OO is better overall, just that C++ gives you more syntactical options to work around the weaknesses. 12 bad tools are better than 5 bad tools.

Or are they 2.4 times worse? {Usually they are better than doing it by hand or with rocks, but not much more. For example, a stripped screwdriver may still be useful once the screw is mostly loosened already.}

Ideally, though, you want a select group of well-chosen orthogonal tools to keep your toolbox simple and clean but flexible. The C/C++ family does not provide that in my opinion. The C/C++ family's claim to fame is machine portability and machine speed. It serves the machine, not software engineers. Some have called C "CPU-neutral assembler".
Re: "Things about C that make programming harder or more bloated"

I believe C has all a "mid-level" language must have, and few more things. If software engineers need "higher level" tools, then other languages, as already said, exist. C is good at what it is good, and I think it will survive to all these "critics".

Because it is machine-friendly, and for some uses, such as SystemsSoftware, that overrides being human-friendly. Nobody is arguing it has no place or that it should die, only that it's a poor example of what a procedural language can be in terms of the expressiveness side of software engineering.

EditText of this page (last edited February 22, 2012) or FindPage with title or text search