«

On 12/28/2009 01:17 PM, BGB / cr88192 wrote:
> most of what I saw in, and still do see in, OOP, was the creation of
> large convoluted class heirarchies, lots of classes digging deep into
> the internals of other classes, ...

This seems like design and programming mistakes, though. And these
issues can absolutely crop up in "objected-oriented" C, of course.

> it doesn't help much that, in the Java style of OOP, it is common for
> people to use lots of "static public" variables in classes.

And I'd take issue with "the Java style of OOP", here. I don't think
abusing static public is an officially condoned style by the Java
Powers-That-Be. It certainly doesn't have to be that way to write
applications in Java.

I mean, languages can have genuine faults and programming paradigms can
have weak applications, but blaming them for programmer mistakes isn't
really fair. And if it were fair, I doubt C would be the one left
smelling like roses!

-Beej

"Beej Jorgensen" <> wrote in message
news:hhbn2e$cga$...
> On 12/28/2009 01:17 PM, BGB / cr88192 wrote:
>> most of what I saw in, and still do see in, OOP, was the creation of
>> large convoluted class heirarchies, lots of classes digging deep into
>> the internals of other classes, ...
>
> This seems like design and programming mistakes, though. And these
> issues can absolutely crop up in "objected-oriented" C, of course.
>

granted, but they are less likely.

in C, we would call the equivalent of this "crap code", whereas, from what I
remember, in late 90s Java books, a lot of stuff like this was promoted.


>> it doesn't help much that, in the Java style of OOP, it is common for
>> people to use lots of "static public" variables in classes.
>
> And I'd take issue with "the Java style of OOP", here. I don't think
> abusing static public is an officially condoned style by the Java
> Powers-That-Be. It certainly doesn't have to be that way to write
> applications in Java.
>
> I mean, languages can have genuine faults and programming paradigms can
> have weak applications, but blaming them for programmer mistakes isn't
> really fair. And if it were fair, I doubt C would be the one left
> smelling like roses!
>

ok, programmer issue or not, it may still be the case in many cases.

in C, we see it as bad style, and elsewhere, people can hide between the
magic word "OOP" and think all is well, even if their code is, itself, not
particularly OO as such...


so, in reality here, I am neither taking issue with Java or OO, rather, the
people who don't really know either very well but still hold a sense of
superiority due to their particular language choice (which, from what I have
seen, would seem to be fairly common in both Java and C++ land...).


> -Beej
>

"Duke Normandin" <> wrote in message
news:5Ba_m.57572$Db2.18718@edtnps83...
> On 2009-12-28, BGB / cr88192 <> wrote:
>>
>><> wrote in message
>>news:v74_m.59234$PH1.25421@edtnps82...
>>> I'm learning C (after having taught myself Perl, Tcl, Bash etc). For me,
>>> OOP (i.e. C++, Objective-C, etc) is mind-bogling information overload.
>>> Seriously, does programming *need* to be as convoluted as OOP appears to
>>> me? Cannot C - all by its lonesome - do as good of a job as an OOP
>>> appraoch?
>>>
>>> I'm just trying to set a course for myself. I realize that "languages"
>>> are
>>> simply tools in my toolset.
>>> However, some toos are simply way over the top, IMHO, for most jobs. Is
>>> that not so? TIA...
>>
>> C can do what C does.
>
> etc..
>
> [snip the good stuff]
>
> Thanks for the insight! So what would be *your* recommendation as the
> quintessential OOP language?

this is a hard one...

I would probably recommend looking at a number of different languages:
C, C++, Java, C#, JavaScript, SmallTalk, Self, ... and maybe get an idea of
the generalities (and possibilities).

as well, it is helpful to at least gloss over very different programming
styles: Scheme & Lisp, PostScript, ...

books can be helpful, but some I would be less sure of. if the book seems
overly evangelistic and the advice sounds suspect, caution is advised ("best
thing since sliced bread" != "solid coding advice").


ultimately though, one may not necessarily choose a language because it is
"best" (if one were to find such a language that is), but more because it
best meets ones' particular needs.


for example, I mostly use C, but I don't claim it is a perfect language by
any means.
another may choose C++, Java, or C#, finding it better fits their needs.

but, ok, this is not a great answer...


> --
> Duke Normandin
> *** Tolerance becomes a crime, when applied to evil [Thomas Mann] ***

On Dec 28, 11:01*am, Donkey Hottie <don...@fred.pp.fi> wrote:
> You can do anything with C (as well as in asm), but that is not
> practical nowadays unless the problem is somewhat trivial. OOP brings
> maintainability, readability and also productivity.

If you equate C with asm in your head you're doing C wrong.

> To me, most OO languages are more understandable than C or PHP. I just
> can't understand most/those script languages. I prefer strong typing and
> a compiler warning about errors before they happen.

You're looking at [or writing] bad C code.

> OO languages bind together 'things' (objects) and possible actions upon
> them. The connection is easily understood by reading the code.

In any decent API this is also accomplished with proper function
naming, feature abstraction, and functional refactoring. It's just as
possible to write a horrible API in C++ as C.

> When you see a 'struct' in C language, you see the 'thing', but you have
> no idea what can be done with it.

So? And when you see a class has a "put" method that doesn't mean you
know what it does with the data you pass it. Big deal.

Usually when examining an API you look at the functions, not the
structures. Structures are just a tool to organize data, functions
are where the action is.

Tom

On Dec 29, 6:59*am, Richard <rgrd...@gmail.com> wrote:
> Tom St Denis <t...@iahu.ca> writes:
>
> > On Dec 28, 11:01*am, Donkey Hottie <don...@fred.pp.fi> wrote:
> >> You can do anything with C (as well as in asm), but that is not
> >> practical nowadays unless the problem is somewhat trivial. OOP brings
> >> maintainability, readability and also productivity.
>
> > If you equate C with asm in your head you're doing C wrong.
>
> Not really. You can indeed do that and get remarkably similar ASM output
> from the compiler if you know what you're doing.

If you equate C with asm in your head you're doing C wrong.

Worth saying once, worth saying twice.

> More so. We are in agreement. Operator overloading, multiple inheritance
> all combine to make reading OO code from printout almost impossible IMO.

Name your methods better, inherit from classes that make sense, etc.
There is nothing wrong with what C++ provides. The fact you're
missing from the argument is the vast majority of software developers
out there are trained [if that] as programmers not developers. There
is a difference.

Think of building architect versus hammer wielding day labourer. The
day labourer still has a skill (welding for instance is not easy) but
you wouldn't ask them to design the building.

Similarly, many "developers" are just programmers who know the syntax
of their language of choice, but aren't really qualified to lay out an
API or make structural design decisions on a project scale. As a
result they plow through the work best they know how and "fix things"
as they go along. Result: **** code that looks like it was patched
together.

Like I said previously, if you started from scratch your C++ and C
solutions to the same problem might look vastly different. People
compare the two with the after product. E.g. "my C++ solution
wouldn't map well to C, clearly C++ is superior" and vice versa. I
personally don't code in C++ since I find C works for what I want to
do (and I express myself better in terms of the C language than OOP
like C++). But that doesn't mean I think C++ is inferior to C.

So to answer the OPs question again, I think the world can survive
without OOP just fine. Most code that runs the world is ASM or C
anyways. But that doesn't mean OOP (Java, C++, perl6, etc...) are
worthless. If you know how to use them, and use them well, they're
just as legitimate as C is.

Tom

On 29.12.2009 13:59, Richard wrote:
> Tom St Denis<> writes:
>
>> On Dec 28, 11:01 am, Donkey Hottie<don...@fred.pp.fi> wrote:
>>
>>> To me, most OO languages are more understandable than C or PHP. I just
>>> can't understand most/those script languages. I prefer strong typing and
>>> a compiler warning about errors before they happen.
>>
>> You're looking at [or writing] bad C code.

LOL actually I meant to write "perl or PHP", that was a disgust on
script languages.

I have nothing against C, I started by career with, wrote two years,
until Borland and MS got their C++ versions out sometimes '92 or so.

When I saw C++, I immediately starter my own class library and went with
OO. That class library was very Java style and I worked with it some 10
years, until I went Java (EE).

>>
>>> OO languages bind together 'things' (objects) and possible actions upon
>>> them. The connection is easily understood by reading the code.
>>
>> In any decent API this is also accomplished with proper function
>> naming, feature abstraction, and functional refactoring. It's just as
>> possible to write a horrible API in C++ as C.
>
> More so. We are in agreement. Operator overloading, multiple inheritance
> all combine to make reading OO code from printout almost impossible IMO.
>

Modern OO languages like Java or C# do not have those imbecile features.


--
http://www.iki.fi/jarif/

Q: "What is the burning question on the mind of every dyslexic
existentialist?"
A: "Is there a dog?"

On Dec 29, 9:37*am, Richard <rgrd...@gmail.com> wrote:
> Wrong. In many cases C is used to do just that because of the nature of
> the language. And my C is pretty handy. How do I know this? Because I
> have done projects where asm was moved into C with a strong look at the
> compiled ASM output in order to maintain driver efficiency. Sure not
> totally portable etc but your claims are plain wrong.

Profile <=> optimize, it's called a feedback cycle dude. Sure there
will be small segments of code that need to be scrutinized for
performance (which may include looking at the asm that the compiler
generates) but overall, people should choose efficient algorithms and
let the compiler worry about how to express that in machine code.

> Yes, but you're wrong. Thats twice you've had to be told. Same as you
> were wrong about macros and inlines.

No, I still think one-liners should be macros, that there are naming
conventions, that code doesn't go in headers, I just let the issue
drop because I'm not an anti-social loser like you are. Some things
are just not worth arguing over. Let it go.

<snip>

Tom

On 2009-12-29, Tom St Denis <> wrote:

[snip ]

> Name your methods better, inherit from classes that make sense, etc.
> There is nothing wrong with what C++ provides. The fact you're
> missing from the argument is the vast majority of software developers
> out there are trained [if that] as programmers not developers. There
> is a difference.
>
> Think of building architect versus hammer wielding day labourer. The
> day labourer still has a skill (welding for instance is not easy) but
> you wouldn't ask them to design the building.
>
> Similarly, many "developers" are just programmers who know the syntax
> of their language of choice, but aren't really qualified to lay out an
> API or make structural design decisions on a project scale. As a
> result they plow through the work best they know how and "fix things"
> as they go along. Result: **** code that looks like it was patched
> together.

Your point-of-view makes sense to me. A tool-and-die maker was once a humble
machinist, e.g. A person may be a hot-shot machinist, but never have the
inclination or wherewithal to "graduate" to the level of tool-and-die
maker. Similarly, a cat operator building a highway, *is not* a civil engineer
laying out same. I get it!

Applying this to myself (and I'm not a professional programmer), I find my
biggest stumbling blocks are designing / crafting / sculpturing the program
I'm working on, and not the actual coding. Sure, I still get acid
indigestion with pointers to structs that contain arrays. However,
by-and-large I go round-n-round, chasing my friggin tail, when I'm trying to
*design* the bloody thing.

[snip ]

> So to answer the OPs question again, I think the world can survive
> without OOP just fine. Most code that runs the world is ASM or C
> anyways. But that doesn't mean OOP (Java, C++, perl6, etc...) are
> worthless. If you know how to use them, and use them well, they're
> just as legitimate as C is.
>
> Tom

I was thinking of that very thing last night! What language is C++ written
in? Java? Objective-C? Smalltalk? Isn't C the common denominator here; and
maybe some asm for speed? At any rate, I'm forging ahead with C, but I've
installed Squeak on my system. What the hell, you only live once..
--
Duke
Alberta, Canada

Duke Normandin <> writes:
[...]
> I was thinking of that very thing last night! What language is C++ written
> in? Java? Objective-C? Smalltalk?

I think the specifications for all those languages are written in
English.

> Isn't C the common denominator here; and
> maybe some asm for speed? At any rate, I'm forging ahead with C, but I've
> installed Squeak on my system. What the hell, you only live once..

Yes, many *implementations* for those languages are written in C,
though I can't speak for all of them. But I certainly wouldn't be
surprised if some C++ compilers, for example, were written in C++.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Mon, 28 Dec 2009 13:06:07 -0700, BGB / cr88192 wrote:

> history is in line here:
> first, there was Simula.
>
> then, C++ borrowed from Simula,

Between those two steps was Smalltalk. Although C++ mostly ignored it,
Smalltalk was largely responsible for popularising the concept of OOP.

Objective-C (which takes a more Smalltalk-like approach to OOP than C++)
is the preferred language for MacOSX GUI development (and before that,
NeXTStep).