S
Stefan Ram
Jorgen Grahn said:
It was a quotation of something written by Linus Torvalds,
so he should be the one to be asked whether it was a joke.
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:
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
Noone learns /all/ of a language, and I don't think that was what Ed
suggested, either.
/Jorgen
S
Stefan Ram
Jorgen Grahn said:
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:
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 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.
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
#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 ]; }
S
Stefan Ram
The line quoted above can be deleted from the program.
B
Bo Persson
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.
Bo Persson
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 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
.
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 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
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 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
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
It's certainly true that all these items have their place - they can be
used, as well as abused.
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.
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.
I agree - for a company.
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
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:
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
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.)