|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
> 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.
All of this is enforce, I thought, in pascal. There really are less
choices that are 'right'. This forces people to all code their stuff the
same way which results in less idioms. One could do well by memorizing the
most common idioms. I, personally, would like this.
The size of screwdriver would be limited to a few screws, small, medium,
and large. Instead we have a plethora of screws which lead to a plethora
of tools one needs to even fix the simplest thing. I don't know why this
is a Good ThingTM for anyone save for tool companies. Yes, there are
exceptions, but these exceptions are not the rule. Simple things should be
really simple and harder things will always be a bit harder. Don't make
simple things complicated just to make hard things a tiny bit easier.
> 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.
I think the c-isms that have been taken out makes it easier. Plus it's
syntax looks more like english. I think that c code can be frightening
which is why I want to learn it, but I don't think that this is the most
efficient way to go.
> > > 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.
Yes! You get a shiny copy of gcc! I can't wait. The grand prize includes
the source code that Bell once valued (in court) as costing > $50,000, in
the 80's, I call it gnu utils: binutils, and friends!
> 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,
I think we agree. I think that was the point that Noah was making as well.
cout and printf are the same in pascal and objective pascal, can't
remember what they are, though.
> 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.
Here, here.
> > 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?
B/c as you said above, you shouldn't mix and match language concepts. Wrap
a c-function in a struct if you want oo.
> > 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.
I'd rather have a better printf, only.
> 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.
I agree. I think I'd miss pointers in java. Also, I did think that it was
easier to 'start' a program in c++ than it is in java. Maybe that's just
me. I have been told that there are pointers in java, but they are
'hidden'. And no, I don't mean in the c-code that java is probably written
in.
> And, printf vs. cout is such a minor aspect of C/C++. sprintf, snprintf,
> vprintf, vsprintf, and vsnprintf are much better examples, just kidding.
Never heard of them, but I get the point.
> > > 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.
I might have skimmed it. Shows how much I remember. The main point that no
matter what he says, I don't like the word 'evolved' in this context. I
prefer 'bolted on' :) or 'modified'.
> > > "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.
He probably wrote part of the spec in c, then rewrote that in c++ using
his c coded c++ compiler, then recompiled it all in c++ w/ the c++
compiler, then finished the spec in that subset of c++, then rewrote
everything using all the full methods from the c++ compiler to optimize.
I'm guessing here.
> > > 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.
Cause I'm a novice programmer who had too much oo advocacy. I'm laying off
the future. This was mostly a joke.
> > 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.
Well, that was my point. I saw things in c book done the 'hard way' and it
was easier to read. Then I saw the simple way and I was blown away by both
the terseness and the difficulty to read. I think in the end, I'll take
the terse way, but comment it--this is a black box that does x--just pass
it these values!
> > > 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?
Don't laugh. Please be nice... cp :(
> 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.
I really don't wish to make a lib now. I am using qt to make an installer
and I couldn't find a cp function in QFile (where I would put it). It is
in QUrl, though. What the hey? But yea, I did find it and I'll replace my
crappy implementation w/ this code shortly. It will make things easier on
me.
> If you've started one already, I wouldn't mind disucssing it, and possibly
> trying to offer some contributions.
God, you would flip to see the code. It really is a giant headache b/c it
seems like it should be the easiest thing in the world. Libs are _not_
working that should work. I have one which uses qt only, but it's butt
slow. QUrl here I come!
> > 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".
I'm glad you jumped in then. Always good to hear alternate opinions...I
mean facts. :)
> 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 thought he meant suboptimal. We all know that c++ works in every
possible way, sw can be written that's highly maintainable and reliable. I
don't know anyone who would argue this. Most people would say that
'broken' means unmaintainable, unreliable, and really slow to develop in
b/c of crappy idioms in the language.
> > > 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.
One of the best discussions on computer languages I ever had. I'm
thoroughly enjoying myself mainly b/c of the intelligent remarks, copious
respect,and the total lack of animosity and bad attitude that usually
pervades these types of discussions.
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
|
|