|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
> > 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.
> 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.
> > 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.
> 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.
> 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.
> 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.
> 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.
> 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? :)
> > 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.
> > 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.
> 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.
> 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'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.
I like c++, I like c, I like java. I like the 'idea' of pascal, but I
never worked w/ it.
> 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.
> 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.
Fred
______________________________________________________________________
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
|
|