|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 09 July 2002 22H:23, Fred K Ollinger wrote:
> > > 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
>
> But if everyone used the exact same grammer then the code would become
> more readable. This is where java, IMHO, shines. I find it the most
> readable language.
But, we're not talking grammer, here. And, even with correct grammer, there is
more than one correct way to write something. That's one of the essences of
most languages. Some writings require languages that can describe subtle
variations and nuances. Poets, for example, would shoot you if you removed
words that had similar meanings or removed meanings when words had more than
one meaning.
Now, programming is almost certainly NOT poetry. But, there certainly are
valid differences in similar, but different approaches, techniques, grammars,
etc. How would you like it if your toolbox was limited to only one type and
size of screwdriver? And, just try to get everyone to agree on which one it
should be.
Java is generally reguarded as simpler than C++ in some ways. I think that may
contribute to why some Java code may be more readable than some C++ code.
Again, simpler is almost always more readable.
Good OO code, however, should be readable no matter what language its written
in. This is true for code that you've written yourself. Poorly written code
is often difficult to read, even by its author, several years later. And, by
read, I mean read and comprehend.
>
> > 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.
>
> Nobody will argue this one. Save my wife, as she says, "if the code was
> hard to write then it should be hard to read!"
>
> > 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.
>
> I really don't mean to trash c++ at all. I like it. I'm just trying to be
> objective here. I'm really not the best person to judge these things, just
> giving my comments in an enjoyable conversation.
I don't think anyone is doing any judging here. Did this become a contest?
What does the winner get? A free compiler? Free as in... Just kidding.
>
> > > 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
>
> Assembly has its place, and I'd love to learn it. In some code (kernel)
> you may mix and match, but not in day to day development of user
> applications (which is where I'm at right now). I honestly don't see any
> advantage to assembly at this particular level.
I'm still NOT saying that you should mix and match programming styles or
languages. What I AM saying, is that the existence of a new style or language
does not mean that we should completely abondon existing concepts, languages,
and knowledge. For example, a good C programmer can become a better
programmer by understanding the assembly language that's "under the hood".
The same goes for a good C++ programmer understanding straight C. It's good
to become familiar with how you'd have to do things if you didn't have OO
concepts. That doesn't mean "don't ever use OO concepts" or "don't make the
best use of both worlds".
Learn about the history and what goes on when you link to "C" libraries. Learn
about call stacks, how arguments are passed in function calls, etc. Don't
forget about this stuff because it's less important in an OO view of the
world. The OO view isn't the only valid view. Sometimes, it's not even the
best view for a particular problem at hand.
>
> > 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.
>
> I wasn't sure when I entered this conversation, but I'm starting to be
> convinced that if you start in c, you really should end in c.
Why?
You can often do much more in C++ with fewer lines of code, and end up with
much more readable and maintainable code than you could with straight C.
>
> > A little attempt at humor: So, if I'm half-assed and you're half-assed,
> > does that make us one complete ass?!
>
> Yes!
>
> > > 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++
>
> Highly likely.
>
> > 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.
>
> Probably too vague to make sense. OK, how about printf vs. cout? I think
> that cout should inherit fprint rather than being different. I heard that
> there are troubles when they are mixed. I don't know. I forgot all about
> printf and only use cout. But they should be the same syntax, cout should
> be called printf and do things a bit better.
But, you have been given two options here. You can provide a method for your
object to return a result suitable for printf, or you can make your object
work with streams, or you can make your object work with both - if you need
or really want to.
The advantage to the cout approach is that if you make your object work with
streams, then you can use it for other streams besides just cout. If you want
to just use it with cout, that's fine too. C++ provides you with much more
power and flexibility that way. This does require you to know what you are
doing. But, once you know what you are doing, its very difficult to give that
flexibility up.
And, printf vs. cout is such a minor aspect of C/C++. sprintf, snprintf,
vprintf, vsprintf, and vsnprintf are much better examples, just kidding.
>
> > 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.
>
> This is where I get mad. Probably similar to where you took exception
> (get it?) to 'broken' as a bio major, I don't like to see bio terms used
> outside of bio b/c the result is ambiguous, things can be argued either
> way, computers are not alive, etc.
>
> I don't think that c++ 'evolved' from c b/c evolving implies that it did
> so itself w/o forethought. Languages are created by humans and they are
> planned. Also, evolution rarely means adding lots of new features that
> don't mix well w/ the old features, but rather changes of the older
> features. c++ did take ideas from other languages. Creatures that evolve
> never do so. If they happen to be similar to others then this is covergent
> evolution, but it's not directed.
>
> When c++ was created, it was to add classes to c. I think that this was
> supposed to be evolved, but it doesn't look that way to me. Sorry.
Well, if you and/or Noah want to learn about the design and evolution of C++,
read it from the source. Bjarne Stroustrup has a book out, titled, "The
Design and Evolution of C++". If you guys want to understand what he did and
why he did it, go ask him, or read his book. And, I'm sure he didn't come up
with all of these ideas by himself, but he was certainly one of the primary
focal points of all of the activity. But, he probably covers most of this in
his book. I haven't read it, but I recommend it to anyone that wants to
discuss his design intentions.
>
> > 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.
>
> True, I remember reading this somewhere.
>
> > I'm NOT recommending SLOPPY coding. I'm definitely not recommending
> > putting
>
> I didn't mean to imply this.
>
> > "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.
>
> Just like everyone's favorite language is written in c. I understand that.
> And c was originally written in assembly.
Actually, I believe that the C++ language was actually written in C++. There
was a preprocessor to generate the C for compilation. But, Mr. Stroustrup
claims that C++ was actually written in C++. I'm sure he would disagree with
some of my recommendations about good design concepts, etc. but this little
nugget is on a FAQ of his somewhere. I could find it if you were interested.
>
> > 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.
>
> I'll make one anyway. What the hey? :)
But WHY? If you just need one function, why not just write one function. I'm
not even suggesting to extern "C" the thing.
>
> > > 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.
>
> Well, there's evolve again. Maybe it did evolve. I don't know.
Again, read above about the book titled, "The Design and Evolution of C++".
>
> > > 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?
>
> I get it. Everything is in c anyway, but other languages have a place.
Well, not exactly where I was headed, but yes, "other languages have a place."
Couldn't agree more with that.
>
> > 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.
>
> Usually plug gives me all my programming advice.
>
> > 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.
>
> I'm trying to figure this out. I would like to agree w/ you, but I should
> probably be studying pascal instead. :) Actually, maybe that was the
> point. If we used pascal then we wouldn't be worrying about this. All
> kidding aside. I'm starting to think this might be something.
>
> > Simpler is usually better and almost always easier to read.
>
> Almost everyone agrees, they just can't make up their mind what 'simpler'
> means.
Yes, there are probably a select few in every group who could argue even the
"which is really simpler" argument.
However, I think if everyone is looking at two things that accomplish the same
goal, most people can achieve a consensus on which one is generally simpler,
unless the difference is not material.
Usually, when two people are asked to implement the same task, one of them
will provide a clearly simpler solution. When the two of them work together,
they can frequently come up with a third solution, which is even simpler than
the previous two. This is one of the reasons that Pair Programming is a
somewhat new and interesting concept.
I'm not talking about words such as elegant, better, etc. But, simplicity is
usually a criteria that most non-argumentative people can agree on. If you
need to, you could switch to # of lines of code as the most basic
measurement, but that is typically an unnecessary over-simplification.
I find that many people don't necessarily LIKE the simplest solution. They
often like some esoteric artifact of a slightly less simple solution. Or,
they try to anticipate future requirements which have not been provided yet.
Again, provided a specific set of requirements and two solutions that satisfy
the requirements, most people can arrive on a consensus of which one is
simpler.
>
> > 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!
>
> This is where java really started to annoy me.
>
> > > 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
>
> I'm not frighted or disturbed by this. I really don't hate c.
>
> > 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.
>
> I don't know if you were reading the list when I decided to 'roll my own.'
> My head still hurts from all that hell.
I may or may not have. What exactly were you rolling your own of?
I don't personally partake in the most literal "roll your own" activities.
But, I'm sure I could find someone that could provide something that would
alleviate that headache of yours... Just kidding.
Seriously, what project were you working on? I don't recall. If it was
specifically a cross-platform GUI C++ library (such as QT), I would
personally recommend finding one to contribute to, rather than "start from
scratch". There are many GUI libraries out there with various strengths and
weaknesses. QT, wxWindows, FLTK, etc.
If you've started one already, I wouldn't mind disucssing it, and possibly
trying to offer some contributions.
>
> > 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?
>
> You have very convincing points. I'm just sitting on the fence, trying to
> take all this in. I never thought that c++ was 'broken' until Noah brought
> it up. I think you think of 'broken' in different ways.
Well, my problem is more with stating opinions using what look grammatically
like statements of fact to me rather than opinions.
Specifically,
"I have some respect for C. Very little for C++ (it's just broken! ..." and
"C++ was designed to be a temporary solution, and imo, it shows.".
Particularly the second statement, the "designed to be a temporary solution"
doesn't look like a statement of opinion to me. In fact, the In My Opinion
(lacking the Humble of course :) was referring to the "it shows".
Sorry, but I still submit that I believe this to be an inaccurate statement.
Gramatically factual rather than opinion, but IMHO inaccurate. I reserve the
right to be wrong, and welcome information demonstrating such.
The concept of "broken" had not specifically gotten discussed much yet, so I'm
not sure specifically in what way Noah was thinking of C++ as broken.
>
> I like c++, I like c, I like java. I like the 'idea' of pascal, but I
> never worked w/ it.
I liked Pascal when I used it. I'm starting to get a little bit of a bad taste
from ObjectPascal...
>
> > 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.
>
> I agree. This is not good.
Well, that was why I posted my first message in this thread.
>
> > 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.
>
> Well, I can see that I'm over my head on this one. I was just spouting off
> my opinions. Good to hear another view on this, though. Thanks.
I'm glad to hear your opinions. I like open discussions. I'm still not sure I
understand some of your opinions on this discussion.
I hope I haven't turned you off to C++, Java, or future discussions with me.
Again, my main concern was to raise an objection to what looked to me like a
couple of inaccurate "statements of fact".
I'm also happy to take this offline if anyone prefers that.
>
> Fred
>
Cheers,
Jason Nocks
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAj0sjjYACgkQ3CryLfCgqRkRjgCfZrXS+v2sbmNMnfaHhsWBdhFQ
YV8An10PzZYkUI4N569LGsP/J5oBB0zu
=gGKn
-----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
|
|