Learning to code by reading code (was: The way to read STL source code)

Newsgroups: comp.lang.c++,comp.lang.misc
Followup-To: comp.lang.misc

Stanley Rice <heconghui@gmail.com> writes:
>But if you said that reading others' code is not the way to improve your
>programming skills, I have no ideas how to improve it. Reading the

Reading others' code /is/ the way to improve the skills:

- Of course, one should select code written by masters,
not code written by arbitrary authors. For example,
in the realm of C++, one might read boost source code.
In the realm of C, source code for GNU commands.
For Java, read the source code of the standard library.
In the realm of Pascal, "TeX - the program". And so on.

- A good way to enforce active reading is a goal, like
porting the code or modifying it.

- Reading masters' code must, of course, not be all that
one does. One also has to read books and do other
programming exercises. Reading masters' code might
comprise, for example, 20 % of all programming activities.

Newsgroups: comp.lang.c++,comp.lang.misc
Followup-To: comp.lang.misc

On 2012-02-18, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> - Of course, one should select code written by masters,
> not code written by arbitrary authors. For example,
> in the realm of C++, one might read boost source code.
> In the realm of C, source code for GNU commands.
> For Java, read the source code of the standard library.

I think it also depends on if you are a system programmer, a library
programmer or an application programmer.

> In the realm of Pascal, "TeX - the program". And so on.

I don't see the use of that, in a dialect that is basically dead for 20
years. When doing Pascal you will mostly like start in Delphi.

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:reading-20120218195201@ram.dialup.fu-berlin.de...
> Newsgroups: comp.lang.c++,comp.lang.misc
> Followup-To: comp.lang.misc
>

I put comp.lang.c++ back on. Mr. Rice makes some wildly incorrect
assumptions, IMO. Hopefully, it'll also end up indexed in the correct
thread on c.l.c++.

> Stanley Rice <heconghui@gmail.com> writes:
> >But if you said that reading others' code is not the way to improve your
> >programming skills, I have no ideas how to improve it. Reading the
>
> Reading others' code /is/ the way to improve the skills:
>

Wrong! Wrong! Wrong! Freakin' wrong!

Reading others' code only exposes one to the inherent flaws of thinking and
bad code implementation others, which one - especially the novice,
inexperienced, or average intellect - then accepts as their own - since the
code different, perhaps novel, and therefore *must* be better (sarcasm) -
because they don't yet understand just how truly *bad* the idea they're
reading is. Reading other's code is one of the absolute worst things one
could do, especially for a novice who is one likely to be very accepting
when reading others' code. It's like taking pure water (you) and drinking
polluted river water (others) and ending up with a mix.

> - Of course, one should select code written by masters,
> not code written by arbitrary authors.

Just how does one judge a master? If you aren't a master yourself, you
can't judge who is a master ...

That entire idea is so flawed. A guy with average intellect will only
recognize a range of intellect similar to his own. He'll recognize that
which is slightly more or less bright than he, but won't recognize dumb and
genius level ideas as such. So, a guy with less than average intellect will
recognize the code by an average intellect guy as being a "master". The
majority - who are supposedly of average intellect - will be scratching
their heads in confusion asking: "Why does this guy think that guy is a
master? That guy's code is no better than my own ... I don't get it." The
same is true for the average guy, the slightly above average guy, the
brilliant guy, the genius guy. It's only partially true for the
super-genius guy who will only recognize code worse than his own ... So, in
effect, you're saying one needs to locate super-genius guy and have him
waste his time reviewing code to classify who is and who is not a master
before anyone can study the other "masters".

> For example,
> in the realm of C++, one might read boost source code.
> In the realm of C, source code for GNU commands.
> For Java, read the source code of the standard library.
> In the realm of Pascal, "TeX - the program". And so on.

I doubt any of the code produced by the open-source movement could be
classified as "being written by masters". There are too many people with
*widely* varying intellect levels, most of whom are only of average
intellect, to claim that the cited code in it's entirety is somehow
brilliant. For the code to be brilliant, a single brilliant individual
must've coded it or a team of similarly brilliant individuals must've coded
it. Both of those are things which were unlikely to be present during the
codeing of any of the code you've suggested as being "master" level.

> - A good way to enforce active reading is a goal, like
> porting the code or modifying it.

The way to improve your code is not by reading others' code, but by 1)
really learning what elements the language provides, 2) writing your own
code using the language elements, and 3) learning how that language is
converted to assembly. You can read about implementing something, say a
linked-list, numerous times, but until you've actually done so, you won't be
able to identify and correct your own mistakes of implementation or of your
thought process, which will happen no matter how good your memory or
thinking is.


Rod Pemberton

"Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
>The way to improve your code is not by reading others' code

But we should not forget that there are more man-hours in
maintenance programming than in programming a new program
from scratch. That means the typical work day of a
programmer is not writing his own code (as you wrote »your
code« above), but maintaining code written by someone else.
And the first step to do this properly is to read and to
understand that code that is to be modified. So, training to
read code also is just a preparation for the very activity
that will most often be exercised when being a programmer.

"Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
>Reading others' code only exposes one to the inherent flaws of thinking and

The same could be said about reading a programming book.

>Just how does one judge a master? If you aren't a master yourself, you

The same could be said about judging a programming book.
(Macchiavelli wrote about this, see the last paragraph in

http://ebooks.adelaide.edu.au/m/mach...chapter23.html

)


>That entire idea is so flawed. A guy with average intellect will only
>recognize a range of intellect similar to his own. He'll recognize that

Yes. This means that a person with an above-the-average
intellect will perform better. But this is a general
principle, it does not apply to reading source code only.
However, one might critize the implied assumption that the
intellect is something fixed, see

http://en.wikipedia.org/wiki/Mindset_(book)

"Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
>learning how that language is converted to assembly

Even given a specific source language and a specific
assembly language, there is no specific way »how that
[source ]language is converted to assembly«, this
instead depends on the compiler[ author].

Moreover, this will not be possible, when the language
to be learned already is an assembly language.

On Feb 18, 12:56*pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Newsgroups: comp.lang.c++,comp.lang.misc
> Followup-To: comp.lang.misc
>
> Stanley Rice <hecong...@gmail.com> writes:
> >But if you said that reading others' code is not the way to improve your
> >programming skills, I have no ideas how to improve it. Reading the
>
> * Reading others' code /is/ the way to improve the skills:
>
> * * - Of course, one should select code written by masters,
> * * * not code written by arbitrary authors. For example,
> * * * in the realm of C++, one might read boost source code.

I suggest "chewing the meat and spitting the bones" with Boost.
Some of it is great, but not all of it.


Brian
Ebenezer Enterprises
http://webEbenezer.net

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:code-20120219014836@ram.dialup.fu-berlin.de...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
>>Reading others' code only exposes one to the inherent flaws of thinking
>>and
>
> The same could be said about reading a programming book.

.... as well as blogs and (no surprise here) usenet posts.

>>Just how does one judge a master? If you aren't a master yourself, you
>
> The same could be said about judging a programming book.

This is a different point. The gain in reading books and others' code is
broader exposure to ideas, approaches, and idioms. We aren't all so learned
that only the true masters have something of value to teach us.

>>That entire idea is so flawed. A guy with average intellect will only
>>recognize a range of intellect similar to his own. He'll recognize that

Your cup overfloweth, Grasshopper.

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:code-20120219014836@ram.dialup.fu-berlin.de...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
> >Reading others' code only exposes one to the inherent flaws of thinking
>
> The same could be said about reading a programming book.
>
> >Just how does one judge a master? If you aren't a master yourself, you
>
> The same could be said about judging a programming book.

It depends entirely on the book. Is the book teaching how to program a
certain language or is the book teaching only language concepts? If you
can't tell whether a book is teaching how to program a language, teaching
just the concepts of a specific language, or teaching generic programming
concepts, you'll never make it as a programmer.

> (Macchiavelli wrote about this, see the last paragraph in
>
> http://ebooks.adelaide.edu.au/m/mach...chapter23.html
>

Macchiavelli also wrote this, see the "Because there are three ..." section:
http://ebooks.adelaide.edu.au/m/mach...chapter22.html

> >The way to improve your code is not by reading others' code, but by 1)
> >really learning what elements the language provides,
>
> From which source?

E.g., Harbison and Steele's "C: A Reference Manual" is one of the best books
ever written on C and doesn't teach a single thing about programming in C...

Basically, you want to learn the language elements from one which does not
teach how to program. You want one that is purely technical in nature.
Sometimes, these are referred to as programmer's reference manuals. Good
programming concepts should not be required by the language: structured
programming, object-oriented programming. If the language doesn't allow the
programmer to produce junk or "spaghetti code" or use pointers, the language
is most likely worthless. It's up to the programmer to put the puzzle
pieces together using pure programming concepts they've learned from other,
non-language specific, sources.

> >2) writing your own code using the language elements,
>
> Starting to code without having every read example
> programs written by others?

Why not? I did.

Many years ago, I taught myself BASIC followed by 6502 assembly. I did so
without *any* books on programming. I only had one trivial programming
class prior to that, in LOGO. BASIC and 6502 were learned entirely from
programmer's reference manuals which did not teach any programming concepts,
like structured code, etc. After learning those, I had Pascal in High
School, Fortran at University, followed by self-taught C, and a PL/I variant
learned entirely on the job, etc.

Personally, I believe that individuals who have not learned how to program
in assembly at a young-ish age, i.e., early teens or pre-teen, never fully
grasp certain programming concepts, like the concept of null. Those who've
learned later tend to have problems with understanding how the OOP, or
dynamicly typed, or HLL language they prefer doesn't generate the assembly
they expected. Assembly is the foundation upon which programming
languages are built. As a professional programmer, you must understand what
the high-level code is being converted into. If the compiled code doesn't
do what the high-level code was "supposed" to do, it's your job that's on
the line. You can argue that the C or C++ compiler is not compliant with
the ANSI or ISO specifications all day long, but that won't get you anywhere
with an angry employer.

> >3) learning how that language is converted to assembly
>
> So one also has to learn at least on assembly language,
> which processor do you suggest?

6502. Maybe Z80 ... You had to ask. Many of the fundamental concepts are
still present in microprocessors that were developed in that era, e.g., x86.
Languages that flourished upon 8-bit micro's also contain many of the needed
concepts, e.g., C and Forth. Personally, I wouldn't start them out with a
RISC design. Unfortunately, that goes against most current collegiate level
thinking. University professors have embraced the idea that "RISC is the
future", even though it's fundamentally flawed. Unfortunately, modern
languages and architectures are obsoleting the ability to learn some of
those concepts, but the need is still present to use HLLs, e.g., 8-bit
bytes, contiguous memory, etc.


Rod Pemberton

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:assembly-20120219023621@ram.dialup.fu-berlin.de...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
> >learning how that language is converted to assembly
>
> Even given a specific source language and a specific
> assembly language, there is no specific way »how that
> [source ]language is converted to assembly«, this
> instead depends on the compiler[ author].
>

I believe that's partially true, but not entirely. Many assembly languages
are very similar. Microprocessors standardized on certain concepts around
1974 or so, e.g., 8-bit bytes for ASCII and EBCDIC, contiguous memory,
pointer size equivalent to integer size, typeless integers, etc. Many HLL
compilers, e.g., for C, produce the nearly the same code but adjusted for
different platforms. But, it's still the programmer's responsibility to
understand what that HLL code is producing for their specific tools. That
usually just means learning what the tools produce.

> Moreover, this will not be possible, when the language
> to be learned already is an assembly language.
>

Mr. Rice's examples were all HLLs.


Rod Pemberton

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:maintenance-20120219010917@ram.dialup.fu-berlin.de...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
> >The way to improve your code is not by reading others' code
>
> But we should not forget that there are more man-hours in
> maintenance programming than in programming a new program
> from scratch.

True.

> That means the typical work day of a
> programmer is not writing his own code (as you wrote »your
> code« above), but maintaining code written by someone else.

True.

> And the first step to do this properly is to read and to
> understand that code that is to be modified.

No.

Again, you're biasing a novice's understanding with code they don't
understand which may be horrid. The first step is for the person to become
proficient in the language. They don't have to be a master, but they should
be strong in the language. Once proficient, reading the code of others is
no longer a challenge and they can recognize the worth of the code they've
read. If they're able to recognize that it's worthless, they can correct
it. If they can't, they'll propagate that garbage forever via cut-n-paste.

> So, training to
> read code also is just a preparation for the very activity
> that will most often be exercised when being a programmer.

No.


Rod Pemberton

Reading code of all varieties and in many languages is useful so as to makethe process of absorbing written code a core skill. There's some bad habitarguments, but these don't hold up in the light of experience. Such arguments are from the productive simpleton slave line of programming, instead ofthe learn far and wide line of thought, and programming what you need.

["Followup-To:" header set to comp.lang.misc.]
On 2012-02-19, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> "Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
>>The way to improve your code is not by reading others' code
>
> But we should not forget that there are more man-hours in
> maintenance programming than in programming a new program
> from scratch. That means the typical work day of a
> programmer is not writing his own code (as you wrote ?your
> code? above), but maintaining code written by someone else.
> And the first step to do this properly is to read and to
> understand that code that is to be modified. So, training to
> read code also is just a preparation for the very activity
> that will most often be exercised when being a programmer.

Following that logic, you shouldn't look at "master's" code either, since
the code you will be maintaining most likely won't be done by a "master".

Finding tricks to analyse dodgy code won't be learned by looking at perfect
oode.

Ebenezer wrote:
> On Feb 18, 12:56 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>> Newsgroups: comp.lang.c++,comp.lang.misc
>> Followup-To: comp.lang.misc
>>
>> Stanley Rice <hecong...@gmail.com> writes:
>>> But if you said that reading others' code is not the way to
>>> improve your programming skills, I have no ideas how to improve
>>> it. Reading the
>>
>> Reading others' code /is/ the way to improve the skills:
>>
>> - Of course, one should select code written by masters,
>> not code written by arbitrary authors. For example,
>> in the realm of C++, one might read boost source code.
>
> I suggest "chewing the meat and spitting the bones" with Boost.
> Some of it is great, but not all of it.
>
>

Yes, some libaries are so full of configuration macros and workarounds
for ancient compilers that you will have a hard time even finding some
code.

Been there, done that.


Bo Persson

"Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
>Many years ago, I taught myself BASIC followed by 6502 assembly.

This was the same sequence in my case, with the special
twist that I did not have access to a computer in those
days, so I wrote my BASIC code on paper with a pencil and
did not see it run for some months until I then eventually
got access to a BASIC implementation on a personal
electronic transactor.

But there might be a fallacy here: When one has learned
riding horses in a special way, this might stil apply today.
Horses do not change so fast. But the landscape of
processors and programming languages has changed, even
though the 6502 is still manufactured today.

The fallacay could be: »I learned programming this way,
therefore, every one else also should learn it this way.«
(»Because I only know the way how I did learn it, I cannot
imagine any other possibility.«)

When you learned a language with a 0 pointer, you possibly
understood it in terms of certain 6502 behavior, so it
possibly seemed to you that your 6502 knowledge helped you
to understand the 0 pointer concept. You possibly never made
the experience how it is to learn a 0 pointer concept
without ever having been exposed to an assembler language
before, so you possibly cannot imagine how someone could
grasp the 0 pointer concept without a 6502 model in his
mind. But that does not necessarily mean that it is really
necessary for someone else to learn things in this order.

In my case, for example, I could say: »The best way to learn
programming for everyone is to write the programs on paper
with a pencil for some months, before one starts to sit in
front of a keyboard.« But soon young people will have to
learn how to use a pencil just for this, because they start
to write using keyboards - there are indeed some schools who
are already dropping the teaching of longhand IIRC.

In my case, the good thing about writing code on paper was
that I did not rush to execute my code, but instead took my
time to write and re-read it carefully and then learned to
»mentally execute« the code: Because I had no implementation,
I »executed« each statement mentally trying to imitate what
the machine would do. A capability, which surely is helpful
in programming.

PS: I made a spelling mistake in another post, I wrote
»Macchiavelli«, but the correct spelling seems to be
»Machiavelli« - sorry.

PPS: some quotations about pencil programming:

»When I wrote TeX originally in 1977 and '78, of course
I didn't have literate programming but I did have
structured programming. I wrote it in a big notebook in
longhand, in pencil. Six months later, after I had gone
through the whole project, I started typing into the computer.«

http://www.gigamonkeys.com/blog/2009...t-testing.html

»He declined offers of typing help, and just kept
writing away in pencil. He rewrote parts, copied
things over, erased and rewrote.

Finally André took his neat final pencil copy to a
terminal and typed the whole program in (...)
the VTOC manager worked perfectly from then on.«

http://www.multicians.org/andre.html