Re: future of the C++
On Jun 30, 2:51 am, Daniel <danielapar...@gmail.com> wrote:
On Jun 27, 11:05 am, Francis Glassborow<francis.glassbo...@btinternet.com> wrote:
C++ is an exceptionally large language that allows you to
express problem solutions based on several different
paradigms but many find that hard to grasp, they just
think C++ is hard and confusing.
It _is_ hard and confusing :-) You're not seriously suggesting that
it isn't?
Well, there are probably a lot of people in this group who think that
it is neither hard nor confusing.
I think perception of difficulty is influenced by period of exposure
to C++.
Many C++ fans were born during a "good period for knowing C++." I
started learning C in 1988, and C++ in 1996. People who started
programming significantly before then, say, in 1970, and significantly
after, say, in 2005, might think C++ is hard.
Those from 1970 might have learned FORTRAN, COBOL, had their honeymoon
with PL/1 or Pascal. Then maybe Prolog, a few other languages, then C.
But there comes a point where propensity for intensity and
determination to focus wanes, and some of these people might have
finally said, "Ok, enough is enough...C is good enough; it's my
stopping point."
Those from 2005 enters a world where the WWW is taken for granted.
Anything that you might want to know that is known to man is just a
few keystrokes away. State of the art compilers/interpreters in C++
and many other languages are free, online, readily downloadable [this
is incredible IMO]. Computers are so cheap, many kids have several to
themselves. An entry-level "engineering" job, with suprisingly-decent
salary, can be had without a degree after spending maybe a few months
with a $25.00US book.
Now, in this forgiving environment, someone tells you that knowing how
virtual functions work, or how to invoke assembly language from high-
level language using _asm keyword, is good for you. Or maybe it's not
just the language, but principles of data structures and algorithms
disguised as language, like the red-black tree employed by STL set-
like structures. One look and..."Yuck! I'm not learning that!"
So what we have now is a core of engineers, in roughly a certain age
bracket (there are many exceptions of course), who were born at the
"right" time, and have earned the title of professional, making cool
apps; and people born siginificantly earlier, who are near the end of
their careers who might be amused at all the new activity, and people
born significantly later who are saying, "This doesn't seem
fair..there is so much to learn...where do I start?"
But there is one caveat that makes the world of software engineering,
in 2010, interesting...[see below]
The language is hard, but not hard in the sense of a functional
language, where understanding theory is required to understand the
language, and the effort taken to learn it has its rewards. Rather,
in C++ there's just a lot of scattered stuff you have to know to write
reliable code, from case conventions for constants, to notions of
exception safety, to details of memory management, to implications of
default generated constuctors and operators. I think it takes most
programmers a couple of years to pick this up. Even so, most C++
programmers won't know the answers to most of the questions posted on
this newsgroup. Multiple "paradigms"? It doesn't do any of them
well. It doesn't do functional well. It doesn't do OO well. It
doesn't do reflection. It's not elegent. Having both .h's and .cpp's
seems redundant, both contain implementation. There's no date clss in
the standard library (second most useful class after string.) Using
unicode is painful. The std library is full of things that must have
at one time seemed like good ideas, like is and os. It seems to be
difficult even for experts to write good classes, witness the posts on
std::string. It can be painful getting stuff to work. Libraries
often don't work, I tried using boost ublas, and band matrices don't
work.
[Hmm...I would have to disagree with not elegant, does not do OO
well, .h/.cpp, etc. but...]
What is so interesting about software engineering in 2010, and C++ in
particular, is that we are in the very midst of figuring out "how
things should be". Take your std::string class for example. You're
right, it's a bit funky, and not what you might call UNICODE-ready.
A couple of years ago, I tried to make a string class myself, and
floundered, while a reader in this group amused himself at my obvious
ignorance. :) I tried again a few months later, same thing. Then I
tried again a year later, and now I have a String class that feels
"right".
This process of discovery is going on right now, not just with popular
libraries like Boost, but in general. Take for example the current
state of the art string class from International Components for
Unicode (ICU):
http://site.icu-project.org/
This premier string class has a member function,
Ubool unicode_string::isBogus();
....that tells whether the object is in a bogus state, and implicit
violation of one of the most fundamental notions of C++, that the
language itself should be used to prevent objects from assuming an
inherently defective state. Note also that it uses UBool instead of
bool. [I mention this, not to berate the work of ICU programmers, but
to illustrate that we do not yet have a fully-cooked string class.]
So the "regular set" of primitives in C++ have not yet been devised,
despite STL, and I think we are extremely fortunate to be engineers at
this particular point in time, to have the opportunity to find them,
and C++ is the Big Green Light that says, "Go find them!"
Unlike other popular languages before it, like COBOL, or after it,
like Perl, C++ says,
"Ok, we all know that most computers follow a von Neumann architecture
more or less, and this is not going to change for the mainstream
anytime soon. If you be an engineer, I am going to give you a language
of liberation. I am going to give you a language that allows
reachability to almost every conceivable point in the system space of
software engineering. I am not going to tell you how to reach these
points, of course, but I will allow them to be reached, with great
facility, almost entirely dependent on your skill as an engineer."
Of course, there are exceptions to this claim, like lack of lambda
expressions, and more importantly, there is the assumption that the C+
+ script will be compiled into a physical, von Neuman architecture,
where the CPU itself is the agent of interpretation.
But despite these relatively minor assumptions, C++, like no other
language, allows reachability into the entire system space, from the
primitive to the frighteningly complex.
And that is why C++ is so interesting. It's a bit like taking armed
fighters, where they can choose any weapons that they can carry, and
throwing them on a battlefield, and letting each fighter fight to his
best abilitity, dismemberment and death included.
By contrast, other languages restrict which weapons can be used,
restrict the types of enemy to be fought, and during every battle, the
fighters are must be housed in a giant, roving tank, fighting the
enemy indirectly using joysticks (Java interpreter). Wherever the
fighters go, so must the tank (JVM or other interpreter), and when
there is a special kind of monster that requires a special kind of
stroke to be slain, it becomes hard, because the slayer, no matter how
skilled, is stuck inside a tank.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]