Richard wrote:
Clever Monkey <sp******@clevermonkey.org.INVALIDwrites:
>Ivar Rosquist wrote:
>>On Mon, 20 Aug 2007 12:29:38 +0000, pandit wrote:
I started to learn C++ from my friend's book, C++ Primer. in the
beginning it went good but after i finished 5 chapters it became
complicated. C++ seems like a language with too many features and
functions and right now it seems too complicated and bloated for my
brain.
No kidding! To steal a metaphor, if bloatedness were a brick,
C++ would be the Great Wall of China.
I'm not huge fan of the language (mostly because I've had to maintain
code created during the great March To Standardization) but it was
created to solve a problem that many languages of the day were poor at
doing.
That is, C++ was intended to solve completely different problems than
C currently does, and that "bloat" we are talking about is more about
larger-scale application maintenance using standard frameworks.
And that is exactly where C++ screws up IMO. At the end of the day
frameworks designed and developed in C++ end up having another
"language" on the language which can often be a nightmare.
I always called it the bath time test. Try printing out some C++ and
reading the code in the bath. You better to hell know the overloading
and class hierarchies and the privates/publics back to front or you will
never understand a thing.
I good yardstick, to be sure. I hardly have enough exposure to the
language to form a real opinion, but I recall that once you got the
gestalt of what STL and/or super classes one was leveraging you stop
caring about the implementation and concentrate on local code problems,
which are easy to soak in the bath.
That is, I do at least 80% of my work in Java. To solve problems in
Java, I don't have to care about anything in java.lang, or even in most
of our components, classes or implementations. Decent code will be set
up for good code reuse and logical subclassing. For any sufficiently
large application it helps to have a tool that lets you navigate these
relationships, but I had to do this for large C apps in the past anyway.
I mean, conceptually, a pointer to a selection of structs is just as
opaque as some super-class. I find once I get an idea of what the local
code is doing with these "objects" the rest is just reading source to
find out i.) what the hell the original coder meant and, ii.) where the
actual bug might be. Both of these are bath-worthy projects!
At any rate, learning how to code, read code and debug is a hackerish
skill one can learn with any sort of toolset. C is an ideal tool to
have in one's hacker kit, but those skills are generally transferable
and re-usable.
I personally like to learn a new (artificial) language once a year, and
often deliberately choose one that is outside of my day-to-day oeuvre.
I find it helps keep me sharper.
--
clvrmnky <mailto:sp******@clevermonkey.org>
Direct replies will be blacklisted. Replace "spamtrap" with my name to
contact me directly.
