gwu@nujoizey.tcs.com (George Wu) (03/27/91)
In article <18979@milton.u.washington.edu>, black@blake.u.washington.edu (Jim Black) writes: |> Anyway, by far the biggest criticism I would level at C++ is that it's |> a hard language to learn - much harder than C to become expert at. I've heard |> others on the net echo this "steep learning curve" experience. I won't go |> back to C, but I wouldn't underestimate this cost either. I've heard this argument before, and I have to wonder if it's not a matter of learning object oriented programming, rather than C++ itself. When I was in school, data abstraction and code modularity was heavily emphasized. There was also a smattering of object oriented programming, but for me, only as lectures, not programming assignments. Anyways, I found C++ easy to learn. It came naturally. I think the data abstract style of programming C-MU taught me is responsible for this. Granted, C++, and object oriented programming in general, does not consist solely of data abstraction. However, since I already think in those terms, it's certainly one aspect of C++ which I didn't have to learn. I will concede, however, straight C was easier to learn, but in the long run, the (for me) only slightly extra effort to learn C++ pays off. George ---- George J Wu, Software Engineer | gwu@tcs.com or uunet!tcs!gwu Teknekron Communications Systems, Inc.| (415) 649-3752 2121 Allston Way, Berkeley, CA, 94704 | Quit reading news. Get back to work.
jjb@hardy.u.washington.edu (Jim Black) (03/28/91)
In article <1950@news.tcs.com> gwu@nujoizey.tcs.com (George Wu) writes: >In article <18979@milton.u.washington.edu>, black@blake.u.washington.edu >(Jim Black) writes: >|> Anyway, by far the biggest criticism I would level at C++ is that it's >|> a hard language to learn - much harder than C to become expert at. > > I've heard this argument before, and I have to wonder if it's not a >matter of learning object oriented programming, rather than C++ itself. >When I was in school, data abstraction and code modularity was heavily >emphasized. There was also a smattering of object oriented programming, but >for me, only as lectures, not programming assignments. > > Anyways, I found C++ easy to learn. It came naturally. I think the >data abstract style of programming C-MU taught me is responsible for this. >Granted, C++, and object oriented programming in general, does not consist >solely of data abstraction. However, since I already think in those terms, >it's certainly one aspect of C++ which I didn't have to learn. I will >concede, however, straight C was easier to learn, but in the long run, the >(for me) only slightly extra effort to learn C++ pays off. More power to you! :-) I've always programmed using abstract data types though, at least for many years. The main complaints other programmers ever had about my code was that it was too modular :-) (eg, can't edit one big procedure that does everything). In C I emulated single-inheritance techniques using "/*must be first in struct!*/" link hacks and such. Similarly my design/interface debates with other engineers often had me insisting that the bowels of this-or-that module should be hidden (else the interface was wrong), while my colleagues were hoping to trample and snoop all over foreign structures and didn't understand why I wasted my time trying to design interfaces to preclude that. So I felt well-prepared to move into C++, and always felt that it supported programming "the way I thought it should be done" better than C. But it was still complex to learn. I don't think it's a simple a matter as getting used to "data abstraction and code modularity"... It's more the aspects of C++ such as copy/constructor/assignment/destructor semantics that took getting used to for me (get 'em all in there!), stream operator overloading... and the way the object-oriented features are built onto C rather than being chosen completely naturally has at times seemed contrived and awkward. This is the major advantage of C++ of course (the migration path from C and strong compatiblility from C), but it seems to me the major weakness at the same time (just an observation) ... sometimes the syntax is plain awkward. (Pointer to members may be the best example.) One of the things that system engineers have always had trouble with with the 286/386 protected architectures are that there are so many ways of accomplishing the same things, they spend their time arguing over which is best/appropriate ... C++ is reminiscent of that at times too. Getting things to disk and back without replication of effort and some burden on all subtypes is also something that leaves me scratching my head. Another sorespot seems to be metaclasses, or class information ... (which would help in the former problem) ... I find myself exporting prototype objects from class definitions for certain things, for this purpose. We've got a book the size of the ARM that simply discusses how C++ behaves, and somewhat informally at that. That's not PL/1-class complexity, but certainly puts C or Pascal complexity to shame. (Fine! It's a more powerful language. But still...) I'd be interested in hearing whether other participants in this group feel that C++ has a steep learning curve, too. George is the first C++ programmer I've heard say otherwise, but maybe I'm listening to the wrong people..
hitz@sim5.csi.uottawa.ca (Martin Hitz) (03/29/91)
In article <19114@milton.u.washington.edu> jjb@hardy.u.washington.edu (Jim Black) explains why he feels C++ is hard to learn. He asks: >I'd be interested in hearing whether other participants in this group feel >that C++ has a steep learning curve, too. I must admit: Yes, at least myself. Maybe it's because my personal history seems to similar to Jim's :-), meaybe it's because of some of the following reasons: I: C++ is nice to read, but at the same time much more cryptic than C. People said that while (*s++ = *t++); was TOO complex to understand, but x = a + b; may be even more complex (especially, if something goes wrong...), because there are so many hidden things going on. Depending on the case at hand, conversion functions may be called for a or b, followed by ancall to operator+(), eventually using consrtructors for value parameters, then comes operator=() etc. Yes, it looks nice, but do see the impact at the first glance? I admit that (from a puristic point of view) it might be desireable to hide the impact, but as long as I am not the client but the producer of the classes involved, I would rather have a more explicit idea of what's going on. II: There are A LOT of semantic rules/exceptions in C++, many more than I encountered in other languages, like IF a member function is not specified THEN it will be inherited from the base class EXCEPT it is the constructor IN WHICH CASE a default constructor will be generated ... or consider the rules concerning overloaded function call resolution etc. or (that will lead me to III) the rule: IF no operator= is specified THEN memberwise assignment will take place. Now, consider struct X { int x[3]; } a, b; a[0].x = a[1].x = a[2].x = 1; b = a; What does memberwise assignment mean in this case? b.x = a.x ??? Is there such a thing as array assignment? Let's check... III (may be most important): There are still SO many bugs in the compilers... I have programmed in Pascal between 1978 and 1985 and have encountered 1 (!) compiler bug; I have been using C between 1985 and 1990 and have NOT encountered a bug, but I am able to produce an arbitrary number of bugs in C++ (at least in g++ and Zortech). For instance, after the above assignment b has the (correct) value <1,1,1> in g++, while it is still undefined with Zortech! Or: struct X { X& operator & (X &); }; main() { X x; X *y = &x; } For g++, it's okay; Zortech says something like "Line 6: 1 actual argument needed for operator &". Not funny when porting things to the PC. Even less funny, if you don't have the ARM ready to check who is right... So: I like C++ very much, but it is hard to learn. Martin Hitz (hitz@csi.UOttawa.CA)