Jason on Tue, 9 Jul 2002 17:39:21 -0400


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Pascal?


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 09 July 2002 15H:21, Fred K Ollinger wrote:
> > My opinion is that C++ evolved from C just like ObjectPascal evolved from
> > Pascal. I wouldn't call either of them temporary solutions. Both have
> > evolved, and both seem to continue to do so.
>
> Although, it may appear that C++ "evolved" from C b/c C++ compilers are
> backwards compatable, I think that this does allow for really bad
> programming practices.
>
> Larry Wall is cool, but I strong disagree w/ his TIMTOWTDI idea when it
> comes to programming b/c consistency is very important.

I disagree with the focus here. I think READABILITY is more important than 
consistency. Consistency sometimes, but not always, results in readability. 
If everybody in a group writes similar unreadable code, you still have a 
problem. How about if we try to get everybody to consistently write readable 
code? How does that sound? And, I'm not saying anything about the readability 
of any pearl code I've read or worked on...

Another example is boiler plate comment blocks. If the comments in the comment 
blocks are worthless, then the comment blocks themselves are worthless. 
Consistency bought you nothing but extra comment lines you have to weed 
through to find that you have worthless comments. If the comments themselves 
were improved, then you'd have something.

>
> Usually mixing c and c++ has worked for me, but it does make for messy
> code. My experience comes from using the c++ strings and char arrays
> together.
>

Yes, you should generally pick one approach within a module. I would 
definitely recommend avoiding the mixture of these two string approaches 
within a given application. BTW, If you wanted to trash the lack of good 
string support in the C++ language, I would NOT disagree there.

> c++ is so popular today b/c it mixes w/ c, but that doesn't mean that
> mixing the two is a good idea. If the ideas in c++ are so good, then their
> methods should be used and c methods not used. If the ideas in c++ are not
> so good then there's no point in having them.

This is like saying that if C is was so good, why would anybody still program 
in assembly. For some people/projects assembly language is still the 
simplest/most efficient way to do things. That doesn't mean everyone should 
program in assembly, or that you should always mix C/assembly. For most 
people, C++ should allow people to write better, easier to read, and 
sometimes even faster code with fewer lines of code. That doesn't mean "why 
would anybody still program in straight C". And, just because you can write 
better code in C++ doesn't mean you automatically will.

>
> This is coming from a half-assed c++ programmer who badly wants to master
> c.

A little attempt at humor: So, if I'm half-assed and you're half-assed, does 
that make us one complete ass?!

>
> > I'm sure there are have been many purists that would say (and did say)
> > that any OO language that's not designed from scratch is only a temporary
> > solution. However, I don't believe that any of these people were closely
> > involved with the design and evolution of C++.
>
> I don't think that's what Noah meant.
>
> If c++ gave methods that did _different_ things than c then it could be
> said to have evolved. An example is bash evolving from sh (and ksh).
>
> However, c++ seeks to replace c's methods with it's own. It retains c
> compiling capability, IMHO, in order to get c programmers to learn c++.
> "Look, you can still do c, but if the fancy strikes you, use these better
> methods, too."

You seem to be contradicting in these two paragraphs. You think that c++ 
DOESN'T give you different methods that do "_different_ things", then you say 
that c++ "seeks to replace c's methods". Isn't that methods that do 
"_different_ things"? "Methods" and "things" is a little vague here.

I'll give an example of C++ evolution: the addition of exceptions and 
templates. Is this not evolution in your book? Again, IMHO, C++ has been 
evolving and is still evolving. Very few c++ compilers have caught up with a 
substantial percentage (> 90%) of the features of the language.

And, C++ does not strictly retain "c compiling capability". There is some C 
syntax that is definitely not valid C++. The BASIS for C++ syntax, however, 
is clearly C.

>
> I _like_ mixing c and c++, but that doesn't mean that it's good for me. I
> like perl, and I like being sloppy, but that could make more work in the
> end. I think that the structure in pascal tries to force people out of
> these bad habits.

I'm NOT recommending SLOPPY coding. I'm definitely not recommending putting 
"C" funtion definitions in the middle of a module with a bunch of member 
function definitions. I'm saying that you can CALL a "C" function from the 
middle of a member function definition. In fact, many times you HAVE TO for 
system calls. Unless you want to rewrite your entire system library in an OO 
paradigm. And, I don't recommend that.

No matter how much you abstract it and wrap it, the actual system call is 
usually burried in there somewhere. And that's OK.

Now, imagine that you have an existing API that your company has been using 
for 20 years. If you can come up with a nice OO approach, great! If not, 
don't force a bunch of objects down everyones throats just to say "we're 
doing everything 100% OO".

The point is, don't assume that you have to throw out ALL of the world of 
procedural programming to adopt an OO approach. This does NOT mean that you 
should just switch back and forth for no reason. The point is, you should 
incorporate new ideas for a reason. And, incorporating new ideas should not 
always require starting over from scratch. Use what you've already learned 
(procedural programming), then add the new concepts (OO).

To me, OO does not mean "don't create procedures anywhere". IMHO, it does mean 
simplify and group functions with relevant data. If you don't have a set of 
related functions and have no related data that you need to keep with that 
function (different data every time you call the function), then you probably 
don't have a new type of object.

>
> > Also, it would seem to be completely counter-productive to work on the
> > design of a language that you intended for obsolescence (sp?). Not that
> > it couldn't have happened that way. But, I'd be very surprised if that
> > was actually the way that Bjarne Stroustrup intended.
>
> Did he take ideas from other OO langs and bolt them onto a c compiler?
> That's how it's looked to me.

No, the C++ language would have been created in a much shorter timespan if 
that was the only goal. As it was, it took about 10-15 years to EVOLVE most 
of what the C++ standard is today.

>
> I've heard so many people talk about these really cool oo langs (small
> talk) that can't be used for compatability reasons.
>
> > BTW: I believe that Eiffel was a from-scratch OO language, and I haven't
> > seen any new development with that language in quite some time. I don't
> > doubt that someone is working on it somewhere in the world, though.
>
> I have read a lot of mind-numbing Eiffel advocacy, among it suggests that
> the mess w/ deps in linux seems to be some brokenness in c/c++ itself. I
> doubt this may be all the story b/c the book goes on to praise java for
> dealing w/ lib problems, but I have had lots of puke on my screen when I
> don't have all my paths set up right. I do wish there was a magic way out
> of dynamic library hell. I don't think that static linking everything is
> the answer, and I do think that apt-get is a step in the right direction,
> but I still have messes w/ libs getting mucked up all the time. Mostly
> this is my own fault, tinkering, but still.
>
> > There's nothing stopping you from using printf in a C++ program. It's a
> > function call and is perfectly valid. IMHO, the intent of C++ was exactly
> > not to throw away C, but to add OO concepts. Also, the words are "support
> > object-oriented programming", not REQUIRE it. When you write C++ code,
> > you often can and do need to call functions with C-style syntax. This is
> > perfectly valid, acceptable, and common practice in many of the most OO
> > development groups. C-style functions are NOT BAD. They just might not be
> > AS GOOD, or as readable in a true OO app.
>
> But I'd rather keep using all C-style functions only and only use c++ for
> improving things that weren't in c all ready. My point is I don't want to
> have printf and cout b/c I think it's a mess. I guess the answer to this
> is not to use C-style functions at all.

If you aren't going to make any C-style function calls, then what system 
library do you plan on using?

Or, if you mean not to create any NEW C-style functions, what if it's just a 
couple of lines of code that would often repeat and totally unrelated to any 
other code? The repeated object instantiation and method call alone might end 
up giving you more lines of code and might actually make your code more 
difficult to read than a simple function call. Plus, you should not create a 
class that makes no sense.

If someone were to tell you to always create classes, even if they make no 
sense, I would recommend finding someone else to give you OO programming 
advice.

Again, I'm NOT saying don't create classes. I'm saying HAVE A REASON for the 
class. If you can't find a reason (and you've thought about it first), then 
maybe you just need a simple function.

As a result of creating 1 C-style function in its own module (function.h and 
function.cpp), have I introduced sloppy programming? I don't think so.

Have I negated all of the benefits of OO? No, I don't think so. In fact, I 
reserve the right to create a class later and move that function to the new 
class if a compelling reason shows up (when the requirements change, and they 
will).

Am I saying, "Always start with C-style functions"? No, definitely not. If I'm 
using an OO approach, I am generally looking for classes to group related 
functionality and data.

Again, what I am saying is: Don't create a class just to create a class. If it 
makes the code LESS readable and there's no compelling reason to do so, don't 
do it!

Simpler is usually better and almost always easier to read.

>
> > Here's an example: If you have a "C" function that does exactly what you
> > need, you don't need to create an object that simply calls that function.
> > However, if creating an object, or moving the function call to an already
> > existing object, simplifies much of the rest of your code, then do it.
> > IMHO, the biggest gains still to be realized from OOP is code
> > readability.
>
> Here, here. Although, it takes a while to get used to oo. I gave myself
> ulcers when I made way too many classes, at first, and I spent time trying
> to pass variables from class to class. I still don't think I have that
> right. I'm not saying personal incompetence makes for a bad language, but
> I'm saying all things in moderation.
>
> In many small programs, I don't see the point in oo at all, in even mediam
> size ones, I'm in hell if I don't do at least a little modularization.

OO is very much about encapsulation. If you only have a couple of lines of 
code in your app, guess what? It's already encapsulated. Dear lord, please do 
NOT create objects just to create objects. They really ought to have a reason 
for being created!

>
> > I completely (but respectfully) disagree with this description. I believe
> > that it is fairly common knowledge that Java is a direct descendant of
> > C++. I believe that this is spelled out in pretty much every Java book
> > I've ever read.
>
> I like java for this reason. It has all the good stuff from c++, but none
> of the rough edges. I'd probably use it more often if it had a free
> compiler to create binaries using swing libs. I all ready learned qt so I
> don't need this so much anymore.
>

QT is generally a good OO GUI library. And, you can avoid dealing with many of 
the "C" style system library calls. But guess what? Those system library 
calls are inside the QT library. They don't just go away. Sometimes its more 
efficient and less code to just call the system library directly. And, that's 
OK! Most of the time, though, you should stick with what's provided by QT and 
not worry about what's underneath.

> > In addition, one of the ways that the Java certification exam tries to
> > trip you up on is on some of the subtle differences between C++ and Java.
> >
> > Well, I hope you didn't take any of my message as an insult. I did,
> > however, take objection to statements like "C++ is broken" and merely
> > "intended as a temporary solution".
>
> This was news to me, too. I did see the point, though.

Well, it would be news if it was true. Which, I'm fairly certain that it 
isn't.

I've put some very successful projects into production for a number of 
companies in very short timeframes using OO concepts with C++. If the 
language was broken, then that wasn't possible, yet somehow it happened 
anyway. And, if Mr. Stroustrup intended something to replace C++, what 
exactly was that? When will he start working on that?

>
> > And, you seem to be trying to indicate that Java stems very closely from
> > ObjectPascal and is simply similar to C++ in some elements. I believe
> > that you have that entirely backwards.
>
> Well if you are going to copy an older oo language, there's only so many
> ways you are going to want to change around the syntax.
>

I'm not strictly talking about basic syntax. Noah mentioned the design or 
intent of the designers. I'm simply quoting the designers and giving my 
interpretation of what I see there. I'm still unsure if either of you 
disagree with my interpretation of the quotes I gave you.

> I think that this is like saying BB King sounds a lot like the Rolling
> Stones. Hmm.
>
> Fred
>

IMHO, we are fortunate to have these language choices. I'm glad to see 
ObjectPascal available, even from more than one source.

However, I don't want to read inaccurate statements about the design of a 
language that I do use quite frequently.

We're starting to get into good OO design principles a bit. There's definitely 
a lot of room for debate there. And, that goes for no matter what language 
you are using.

Cheers,
Jason Nocks
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj0rV64ACgkQ3CryLfCgqRlXZwCfVeUAZdYVzu+7ii3Yo2nha/p3
88wAn3qr4CFyrRrN2LF01eTMzQo17WuY
=boTy
-----END PGP SIGNATURE-----


______________________________________________________________________
Philadelphia Linux Users Group       -      http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion  -  http://lists.phillylinux.org/mail/listinfo/plug