|
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 |
Re: Learning to code by reading code (was: The way to read STLsource code)
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. |
Re: Learning to code by reading code (was: The way to read STL source code)
"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 |
Re: Learning to code by reading code
"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. |
Re: Learning to code by reading code
"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) |
Re: Learning to code by reading code
"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. |
Re: Learning to code by reading code (was: The way to read STL source code)
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 |
Re: Learning to code by reading code
"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. |
Re: Learning to code by reading code
"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 |
Re: Learning to code by reading code
"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 |
Re: Learning to code by reading code
"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 |
Re: Learning to code by reading code (was: The way to read STL source code)
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.
|
Re: Learning to code by reading code
["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. |
Re: Learning to code by reading code (was: The way to read STL source code)
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 |
Re: Learning to code by reading code
"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 |
| All times are GMT. The time now is 10:31 PM. |
Copyright ©2009