C++, a good starting language?

S

Stefan Ram

Jorgen Grahn said:
True, but it was posted as a response to a newbie and without comment.
Someone suggested it might have been a joke: was it?

It was a quotation of something written by Linus Torvalds,
so he should be the one to be asked whether it was a joke.
 
S

Stefan Ram

Ed Anson said:
can learn a language very quickly.

N3797 has 1352 large pages. It requires knowledge of large
parts of ISO/IEC 9899:1999 with about 577 pages and has some
other normative references. Anyone who says that he can learn
this quickly might be subject to the Dunning-Kruger effect.
 
J

Jorgen Grahn

N3797 has 1352 large pages. It requires knowledge of large
parts of ISO/IEC 9899:1999 with about 577 pages and has some
other normative references. Anyone who says that he can learn
this quickly might be subject to the Dunning-Kruger effect.

Noone learns /all/ of a language, and I don't think that was what Ed
suggested, either.

/Jorgen
 
S

Stefan Ram

Jorgen Grahn said:
Noone learns /all/ of a language, and I don't think that was what Ed
suggested, either.

Then, what was it that he suggested?

There might be several hundred persons in this world that
can provide a meaningful answer in source code when asked to
write an example for an application of recursive variadic
templates in C++ out of there head (with only minor typos).

Maybe several thousand?

Possibly, Ed was referring to a subset of C++? In this case,
it depends on the subset. Maybe he was referring to that
subset which is very similar to the languages he already
knows or to a very small subset.

I have a source that says that the human long-term memory
can store about 22 bytes per hour (other sources give other
values, sometimes drastically larger, this is not yet
well-established knowledge). How many bytes of C++ knowledge
does the human brain need to excel at a C++ job interview?
How long would it take to transfer this to the long-term
memory at a rate of 22 bytes per hour?
 
S

Stefan Ram

Paavo Helde said:
(e-mail address removed)-berlin.de (Stefan Ram) wrote in @ram.dialup.fu-berlin.de:
Other sources claim that it takes ca 10,000 hours of dedicated work to
become a real master in any given field. Multiplying by 22 bytes gives us
ca 30 kB, so apparently to be master in any field it is sufficient to store
at most 30 kB. Now it would be interesting to know what is the information
content of the C++ standard?

Actually, the human brain is not a digital computer with today's
digital computer architecture. For example, for the digital
computers, we humans have devised the encodings, such as ASCII
or IEEE floating point. The brain, dynamically, creates its
own encodings. Chess masters can remember many board patterns
with just a few »chunks« in memory, because they store board
patterns in chunks, not individual pieces. But this is not a
digital or binary encoding. So the use of the term »bit« is
not really adequate. It is clear anyways that 30 kB of information
in an optimized »encoding« is more than 30 kB of ASCII text.

Even experts have to look up details in books. But they have
that information »cached« in their memory that is needed
very often, so that it would slow down them too much to always
look it up in a book. To be able to assess /which/ information
is needed so often that it is worth to fill the precious
cache memory ,the brain needs to gather usage statistics with
some significance, which in turn needs some time. Reading a
single book won't do it, such statistics have to use several
sources and experiences.
This depends very much on the nature of the interview. From what I read
from TDWTF, the needed knowledge might be sometimes better measured in
bits, not bytes. See e.g.: http://thedailywtf.com/Articles/Disqualified-
Candidates.aspx

This is the topic where usually the English idiom »to be
able to ["program" or another verb] his way out of a paper
bag« is used (in the negated form).
 
M

mohsin.idpersonal

can you solve this problem
Problem:
According to the Gregorian calendar, it was Monday on the date 01/01/1900. If any year is input through the keyboard write a program to find out what is the day on 1st January of this year.
 
S

Stefan Ram

If any year is input through the keyboard write a program to find out what is the day on 1st January of this year.

#include <iostream>
#include <ostream>
#include <istream>

static const char * const w[] =
{ "sunday", "monday", "tuesday", "wednesday",
"thursday", "friday", "saturday" };

int main()
{ int y; ::std::cin >> y; int d = 1; int m = 1; int s = 0;
if( !( y % 4 ))s = 1; if( !( y % 100 ))s = 0; if( !( y % 400 ))s = 1;
if( m < 3 ){ m += 13; --y; } else ++m;
s = d + 26 * m / 10 + y + y / 4 - y / 100 + y / 400 + 6;
s = s % 7; ::std::cout << w[ s ]; }
 
B

Bo Persson

Juha Nieminen skrev 2014-05-29 11:05:
Linus Torvalds is an example of a person who may be quite talented in
one aspect of computer programming, but who's extremely dogmatic about
another aspect of it for rather stupid reasons.

The sheer stupidity of his arguments against C++ can be seen even in
that short quote above: He is literally saying that C++ is "made more
horrible" because lots of poor programmers use it. As if the quality
of a programming language is determined by how many poor programmers
use it.

By that standard C is also a horrible language (possibly even more so).
Yet by Linus' twisted logic that's not so. In his twisted mind C somehow
makes people write good and efficient code by necessity. I don't really
understand what kind of fantasy world Linus lives in in his mind.

Linus is in a position where he himself makes his own statement true.

Those of us who know how to write proper C++ will now never supply any
code for the Linux kernel, so Linus only sees "horrible code".

Those who know how to write proper C code WILL show their code to Linus,
and he recognizes that as higher quality. :)


Bo Persson
 
D

David Brown

Linus Torvalds is an example of a person who may be quite talented in
one aspect of computer programming, but who's extremely dogmatic about
another aspect of it for rather stupid reasons.

The sheer stupidity of his arguments against C++ can be seen even in
that short quote above: He is literally saying that C++ is "made more
horrible" because lots of poor programmers use it. As if the quality
of a programming language is determined by how many poor programmers
use it.

By that standard C is also a horrible language (possibly even more so).
Yet by Linus' twisted logic that's not so. In his twisted mind C somehow
makes people write good and efficient code by necessity. I don't really
understand what kind of fantasy world Linus lives in in his mind.

Linus certainly tends to exaggerate his points, and to express his
personal opinions as though they were indisputable facts. To a fair
extent he is justified in this - the topic was one of his two personal
projects, the "git" version control system. He wrote the software, at
least the initial version. He administers the project, and he gets to
choose the language(s) used for it. He was asked why /he/ did not
choose C++ for /his/ project - not for a blanket statement of opinion on
all uses of C++ in software development.

And I think there is at least some correlation between programmer
abilities and programming languages, and how "good" a programmer has to
be to be "good" in particular languages. It is very easy to write bad
C++ code - a lot of C++ programs start off trying to have a good
structure, and end up bogged down in layers of complication and
abstraction. I have seen such systems, with so many layers of factory
functions, delegating classes, wrappers, abstractions, etc., that it is
almost impossible to find code that actually /does/ something other than
pass responsibility on to another function or class. That is the kind
of thing that Linus is afraid of letting into the kernel.

I don't think C makes it easier to be a /good/ programmer than C++ does
- but I think C++ makes it easier for a poor or mediocre programmer to
make a bigger mess than with C. And it is easier for a good C
programmer to help the mediocre C programmer improve his good than with C++.
 
J

Jorgen Grahn

Juha Nieminen skrev 2014-05-29 11:05:

Linus is in a position where he himself makes his own statement true.

Those of us who know how to write proper C++ will now never supply any
code for the Linux kernel, so Linus only sees "horrible code".

Those who know how to write proper C code WILL show their code to Linus,
and he recognizes that as higher quality. :)

Actually (and it came as a surprise to me) that quote seems to come
not from the kernel mailing list but from the Git mailing list, when
people discussed picking/using a string library:

http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

I'm disappointed.

/Jorgen
 
J

Jorgen Grahn

.
Linus certainly tends to exaggerate his points, and to express his
personal opinions as though they were indisputable facts. To a fair
extent he is justified in this - the topic was one of his two personal
projects, the "git" version control system. He wrote the software, at
least the initial version. He administers the project, and he gets to
choose the language(s) used for it. He was asked why /he/ did not
choose C++ for /his/ project - not for a blanket statement of opinion on
all uses of C++ in software development.

And I think there is at least some correlation between programmer
abilities and programming languages, and how "good" a programmer has to
be to be "good" in particular languages. It is very easy to write bad
C++ code - a lot of C++ programs start off trying to have a good
structure, and end up bogged down in layers of complication and
abstraction. I have seen such systems, with so many layers of factory
functions, delegating classes, wrappers, abstractions, etc., that it is
almost impossible to find code that actually /does/ something other than
pass responsibility on to another function or class.

Leaving Linus aside for a moment ...

I've seen that kind of code a lot. Full of those things you mention.
I don't think I mind any of the things you list, as long as they bring
some benefit to /this/ particular software project.

Design, to me, is supposed to /highlight/ the interesting parts of the
code. If it suffocates it, it has failed.

Assuming "abstraction overkill", the "fantasy castle effect" or
whatever we should call it is a bad thing:

(a) What does it say about the quality of the programmer?
(b) Are C++ programmers extra vulnerable to abstraction overkill?
(c) If so, why?
(d) If not, are most programmers so bad that they will start to
produce nonsense if you give them powerful enough tools?
Or will the worst ones give up if all they have is C?
(e) Do C++ projects attract high-level architecture people who mess
up the design and then leave, while C projects are run more
pragmatically because they're less attractive to predators?

I don't have the answers.
I don't think C makes it easier to be a /good/ programmer than C++ does
- but I think C++ makes it easier for a poor or mediocre programmer to
make a bigger mess than with C. And it is easier for a good C
programmer to help the mediocre C programmer improve his good than with C++.

I don't see why that would be, in a project. The things you describe
are on the architecture and design levels, and the mediocre programmers
probably aren't allowed to unilaterally decide that part, if there are
good ones around.

Also, decent C++ design isn't that hard to learn -- IMHO what you need
to know in 90% of the cases is summarized in one chapter of TC++PL.
Arrange your code as types, modeled after concepts in the problem domain.
Use type safety. Use RAII. Use the standard library. And so on.

A company could have a rule that if you thing you need 15 layers of
virtual inheritance, you need to discuss it with someone first.


No matter if "you'll mess up if you use C++" is true or just a popular
idea, it is a problem. To me personally, to software projects, and to
C++.

/Jorgen
 
J

Jorgen Grahn

....
I've seen that kind of code a lot. Full of those things you mention.
I don't think I mind any of the things you list, as long as they bring
some benefit to /this/ particular software project.

In a separate posting because it wasn't relevant to my main message,
here's something I found (http://www.charvolant.org/~doug/xkb/html/)
which summarizes my feelings sometimes:

Oh yes. I've been through there on my trip around the image.
The giant vaulted Klein bottles covered with mosaics of other,
different, Klein bottles ... the rows of gargoyles on the
roof, each holding a sign reading "See Previous Gargoyle" ...
the little food stands around the base, where they sell you
food stand vouchers, redeemable for food stand vouchers at all
food stands except this one ... the hall of the penitents ...
the giant Romanesque stained glass windows, built out of
thousands of tiny LooksLike blocks, lit from behind by the
radiance of the great Aka ...

Truly one of the architectural wonders of our age. I've been
there alright. And I bought postcards.

--- Steve Taylor

(I have no idea who Steve Taylor is.)

/Jorgen
 
D

David Brown

Leaving Linus aside for a moment ...

I've seen that kind of code a lot. Full of those things you mention.
I don't think I mind any of the things you list, as long as they bring
some benefit to /this/ particular software project.

It's certainly true that all these items have their place - they can be
used, as well as abused.
Design, to me, is supposed to /highlight/ the interesting parts of the
code. If it suffocates it, it has failed.

Assuming "abstraction overkill", the "fantasy castle effect" or
whatever we should call it is a bad thing:

(a) What does it say about the quality of the programmer?
(b) Are C++ programmers extra vulnerable to abstraction overkill?
(c) If so, why?
(d) If not, are most programmers so bad that they will start to
produce nonsense if you give them powerful enough tools?
Or will the worst ones give up if all they have is C?
(e) Do C++ projects attract high-level architecture people who mess
up the design and then leave, while C projects are run more
pragmatically because they're less attractive to predators?

I don't have the answers.

Interesting questions. I could come up with /some/ answers, but /good/
answers would require a lot of thought. One obvious point is that if a
language offers a lot of choice and features, people are going to use
features that they think are interesting or "cool", even if they are not
necessarily the best options. And if a language is big, it is hard for
people to know everything - they are going to pick options that are
sub-optimal or overly complex, simply because they are not aware of
better options.
I don't see why that would be, in a project. The things you describe
are on the architecture and design levels, and the mediocre programmers
probably aren't allowed to unilaterally decide that part, if there are
good ones around.

In a centralised and tightly organised development environment, that may
be true. In a more loose projects, such as is common in many widespread
open source projects, there is not such a clear distinction between the
high-level designers and the low-level coders. People often get
involved in different parts of the project, and submit code for comment,
improvement, and inclusion in the project. My point is that if a
mediocre C programmer submits some code, a more experienced developer
can often make suggestions or fixes that get the code up to the quality
they are looking for. But with C++ code, there is a greater chance that
the type of abstractions and structure chosen by the relative beginner
(either beginner to C++, or beginner to the project) simply does not fit
well with the project, and the code will be unfixable.
Also, decent C++ design isn't that hard to learn -- IMHO what you need
to know in 90% of the cases is summarized in one chapter of TC++PL.
Arrange your code as types, modeled after concepts in the problem domain.
Use type safety. Use RAII. Use the standard library. And so on.

A company could have a rule that if you thing you need 15 layers of
virtual inheritance, you need to discuss it with someone first.

I agree - for a company.
No matter if "you'll mess up if you use C++" is true or just a popular
idea, it is a problem. To me personally, to software projects, and to
C++.

Agreed. I can't say how much it is a problem, and how much it is just
perceived to be a problem - but either way it is a problem.
 
J

Jorgen Grahn

I'm not so sure of that. The mess might look a bit different in C than
in a typical C++ program, but probably not any less messy.

Many C projects, even popular ones out there, are sometimes quite ugly
code. For example a lot of the source code of mplayer is really, really
ugly (with single functions approaching 500 lines of code, with not even
a single comment, and so on.)

My experience too.

It's somewhat ironic that the Linux kernel is really well done[1].
It's done the way I (a C++ guy) would have done it, if I needed
maintainable yet efficient and portable code and was restricted to
using C.

/Jorgen

[1] IMHO of course, and the parts I've looked at.
 
R

Reinhardt Behm

Juha said:
Yet if you read the article, it's a very vitriolic attack on C++ in
general (rather than simply being a "why C++ isn't used in git" in
particular).


I'm not so sure of that. The mess might look a bit different in C than
in a typical C++ program, but probably not any less messy.

Many C projects, even popular ones out there, are sometimes quite ugly
code. For example a lot of the source code of mplayer is really, really
ugly (with single functions approaching 500 lines of code, with not even
a single comment, and so on.)


Are you sure of that? It seems to me that in C++ it's much easier to
suggest what to avoid and what to use instead because of the tools that
C++ provides out-of-the-box (mainly in its standard library).

Most tasks requiring dynamic memory allocation are very complicated in C
because you can't get around manual memory management. In C++ many of
these tasks become much easier and simpler.

--- news://freenews.netfront.net/ - complaints: (e-mail address removed) ---

This reminds me of a quote from Chuck Moore, inventor of Forth.
"Forth is an amplifier for all skills of the programmer, the good and the
bad."
Or put in other words, with a bigger hammer you can destroy bigger objects.
In this sense C++ allow to create a bigger mess than C because the
"amplification factor" of C++ is larger than that of C.

OTOH C++ make it easier to create better structured code.
 
S

Seungbeom Kim

The reason that I chose C++ is that because it's extremely powerful,
low-level like C, and has high level things too, like classes and
objects. Am I going through the right path? Or should I switch?

I suggest you take a look at Stroustrup's article "Learning Standard
C++ as a New Language" <http://www.stroustrup.com/new_learning.pdf>.

(Definitely it can be biased, but this is a C++ group after all.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,830
Latest member
ZADIva7383

Latest Threads

Top