Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #937 > unrolled thread

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

Back to article view | Back to comp.lang.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Learning to code by reading code (was: The way to read STL source code) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-18 19:00 -0500
    Re: Learning to code by reading code "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-18 22:34 -0600
    Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
      Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-19 10:42 +0100
        Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-19 22:34 +0000
          Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-20 12:22 +0100
      Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 03:39 -0500
    Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
      Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-19 08:40 -0800
        Re: Learning to code by reading code "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-19 13:17 -0600
          Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 02:32 -0800
            Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 13:02 +0100
              Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 05:09 -0800
                Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 15:11 +0100
                  Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 07:39 -0800
        Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 04:14 -0500
          Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-20 11:14 +0100
            Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 05:13 -0800
          Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 02:49 -0800
            Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 13:02 +0100
              Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 05:18 -0800
                Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-20 13:53 +0000
                  Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 01:32 -0800
                    Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-21 16:16 +0100
                      Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 08:40 -0800
            Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 17:36 -0500
              Re: Learning to code by reading code Dombo <dombo@disposable.invalid> - 2012-02-21 00:45 +0100
                Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:35 -0500
                  Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 08:48 -0800
                    Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 00:12 -0800
                    Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 06:12 -0500
                      Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 04:30 -0800
                        Re: Learning to code by reading code Geoff <geoff@invalid.invalid> - 2012-02-22 10:45 -0800
                          Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-23 01:12 -0800
                        Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 07:34 -0500
                          Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-23 05:46 -0800
                            Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 08:38 +0100
                              Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 08:40 +0100
                              Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 09:38 +0100
                            Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-25 05:25 -0500
                              Re: Learning to code by reading code Dombo <dombo@disposable.invalid> - 2012-02-25 12:50 +0100
                              Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-25 06:13 -0800
                                Re: Learning to code by reading code Gareth Owen <gwowen@gmail.com> - 2012-02-26 07:20 +0000
              Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 08:23 +0000
                Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 08:43 +0000
                  Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:47 -0500
                    Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 10:09 +0000
                      Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:38 -0500
                Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:31 -0500
                  Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 10:05 +0000
                    Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-21 12:21 +0100
                    Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 06:04 -0500
                  Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-21 11:01 +0000
                    Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:59 -0500
                      Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-22 12:59 +0000
                        Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 07:03 -0500
                          Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-24 14:20 +0000
              Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 01:27 -0800
          Re: Learning to code by reading code Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2012-02-20 22:25 +0100
            Re: Learning to code by reading code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-26 08:47 +0000
              Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-26 10:55 +0000
          Re: Learning to code by reading code Nomen Nescio <nobody@dizum.com> - 2012-02-22 08:59 +0100
            Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:59 -0500
              Re: Learning to code by reading code Nomen Nescio <nobody@dizum.com> - 2012-02-22 13:47 +0100
                Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 06:21 -0500
          Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 00:08 -0800
    Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
    Re: Learning to code by reading code Marco van de Voort <marcov@toad.stack.nl> - 2012-02-19 11:27 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#937 — 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

[toc] | [next] | [standalone]

#942 — 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.

[toc] | [prev] | [next] | [standalone]

#943 — 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/machiavelli/niccolo/m149p/chapter23.html
>

Macchiavelli also wrote this, see the "Because there are three ..." section:
http://ebooks.adelaide.edu.au/m/machiavelli/niccolo/m149p/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

[toc] | [prev] | [next] | [standalone]

#946 — Re: Learning to code by reading code

On Sun, 19 Feb 2012 03:54:10 -0500, Rod Pemberton wrote:

> "Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
> news:code-20120219014836@ram.dialup.fu-berlin.de...

>>>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.

So did I, but programming is not what it was 30 years ago. It is less 
coding and much more analysis, design, reuse, testing, integration. 
Learning must focus on most important cases and patterns. These cannot be 
identified without help, at least without wasting much time. Both starting 
from scratch and reading code look poor here.

> 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.

Huh, I would rather prevent students from being spoiled by programming. 
They should learn fundamental things first, e.g. math. Unfortunately, it is 
like sex, they get exposed anyway. (:-))

> 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.

I doubt that an exposure to some machine code is the right tool for gaining 
such understanding. And why did you choose specifically the machine code? 
Why not the micro code? Why not the states of the pipelines and the cache? 
Why not individual transistors? Why not electrons, atoms and fields?

Another objection is that the machine code is not what is really going on 
unless the program is some number-crunching beast. Most of the programming 
issues regarding time, resources, bugs are addressed to the software 
components, synchronization, protocols, hardware I/O, OS calls, the stuff 
you cannot learn looking at the machine code.

> 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.

Working around compiler bugs rarely requires looking at the generated code. 
I don't remember single case I need that.

>>>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.

MACRO-11 (PDP-11 or VAX) or at least 68k.

> Personally, I wouldn't start them out with a RISC design.

Sure. RISC would prove weakness of your concept. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#954 — Re: Learning to code by reading code

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:16ed9gpu36y61.1pmhcrjbnt3t8$.dlg@40tude.net...
> On Sun, 19 Feb 2012 03:54:10 -0500, Rod Pemberton wrote:

>> 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.
>
> I doubt that an exposure to some machine code is the right tool for
> gaining
> such understanding. And why did you choose specifically the machine code?
> Why not the micro code? Why not the states of the pipelines and the cache?
> Why not individual transistors? Why not electrons, atoms and fields?

Because working with electrons, transistors, gates, registers, etc. isn't
programming. It's when you get to machine code that you can really do that
(by writing software rather than rewiring circuits). Everything else below
that, even microcode, is just implementing it.

> Another objection is that the machine code is not what is really going on
> unless the program is some number-crunching beast. Most of the programming
> issues regarding time, resources, bugs are addressed to the software
> components, synchronization, protocols, hardware I/O, OS calls, the stuff
> you cannot learn looking at the machine code.

Yes, there are many other layers on top of the machine code. None of which
which ever help me, because most other people's software is badly documented
and I can never make head nor tail of it.

You can't look at a few random pages of a 200KLoc C project, for example,
and have any clue what's going on. How the software works is usually in
people's heads (or scattered amongst multiple documents somewhere), not in
the code itself.

But to understand low-level details, then looking at the translated output
(assembly code or machine code) can often tell you things not apparent from
the HLL source. Especially if you're interested in interfacing at the binary
level from another language, then these details (the exact width of a C
'long' for example), are crucial to know. There's usually no need to go 
below machine code.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#968 — Re: Learning to code by reading code

On Sun, 19 Feb 2012 22:34:02 -0000, BartC wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:16ed9gpu36y61.1pmhcrjbnt3t8$.dlg@40tude.net...
>> On Sun, 19 Feb 2012 03:54:10 -0500, Rod Pemberton wrote:
> 
>>> 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.
>>
>> I doubt that an exposure to some machine code is the right tool for gaining
>> such understanding. And why did you choose specifically the machine code?
>> Why not the micro code? Why not the states of the pipelines and the cache?
>> Why not individual transistors? Why not electrons, atoms and fields?
> 
> Because working with electrons, transistors, gates, registers, etc. isn't
> programming.

Programming is about bringing them into a desired state.

> It's when you get to machine code that you can really do that
> (by writing software rather than rewiring circuits). Everything else below
> that, even microcode, is just implementing it.

You mean that the idea is to stop at where some kind of imperative
framework still exist?

How then anybody could learn to program anything of a declarative nature?
E.g. take an SQL statement. According to the theory you may not look at the
implementation of the RDBMS, which is fixed. But there is nothing else. For
SQL, RDBMS is the "hardware." If you are allowed to look into the RDBMS,
you also are into the CPU pipelines...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#960 — Re: Learning to code by reading code

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:teaching-20120219165706@ram.dialup.fu-berlin.de...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
...

>   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.«)
>

Well, I believe I already stated why.  Younger programmers seem to have
problems with many of the basic concepts of microprocessors.  IMO, this
comes from teaching things like RISC, OOP, HLLs, etc.

> [...]
>   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.«

Why is that the best way?  With pencil and paper, there is no ability to
confirm the correctness of the program.  That's one of the fundamental
things taught in math and science: the ability to check your work.  Without
an implementation, how does one do that?

Pencil and paper is good in that it forces you to think out the problem and
solution versus that of trial and error until it works without actually
understanding why it now works.  But, isn't that what math and sciences
classes in school are supposed to teach?  I.e., thinking and problem
solving.

>  [...]
>   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.

True.


Rod Pemberton
PS  I missed the Machiavelli misspelling.  I'm not good with names.
Apparently, I (horrors!) cut-n-pasted.  No, I'm not perfect with spelling
either, but good.  It's not the only word misspelled by you though.  See
"fallacay" "stil" etc.

[toc] | [prev] | [next] | [standalone]

#944 — 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

[toc] | [prev] | [next] | [standalone]

#951 — Re: Learning to code by reading code

On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
> news:assembly-20120219023621@ram.dialup.fu-berlin.de...
> > "Rod Pemberton" <do_not_h...@noavailemail.cmm> writes:

> > >learning how that language is converted to assembly [is important]

I don't think so. When I come across a novel language feature I like
to think how it would be implemented. But I use an imaginary machine
(or these days, C!). Long ago I knew Z80 assembler (actually much of
Z80 machine code) but I can't see the utility in converting chunks of C
++ (or scheme or Haskell)into Z80 assembler.

> >   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.

agreed

>  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.

but many C programmers (and maybe C++ programmers) assume these are
inviolate laws! They end up writing horribly unportable programs for
no reason except intellectual laziness and lack of imagination about
hardware engineers (and compiler writers) might do.

Your concentration on assembly code encourages this (naff) type of
coding.

> 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.

nope. I get on just fine not knowing what code my HLL is producing.

> 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.

[toc] | [prev] | [next] | [standalone]

#953 — Re: Learning to code by reading code

Nick Keighley wrote:
> On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
>> "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
>> news:assembly-20120219023621@ram.dialup.fu-berlin.de...
>>> "Rod Pemberton" <do_not_h...@noavailemail.cmm> writes:
>
>>>> learning how that language is converted to assembly [is important]
>
> I don't think so. When I come across a novel language feature I like
> to think how it would be implemented. But I use an imaginary machine
> (or these days, C!). Long ago I knew Z80 assembler (actually much of
> Z80 machine code) but I can't see the utility in converting chunks of
> C ++ (or scheme or Haskell)into Z80 assembler.
>
>>> 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.
>
> agreed
>
>> 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.
>
> but many C programmers (and maybe C++ programmers) assume these are
> inviolate laws! They end up writing horribly unportable programs for
> no reason except intellectual laziness and lack of imagination about
> hardware engineers (and compiler writers) might do.
>
> Your concentration on assembly code encourages this (naff) type of
> coding.
>
>> 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.
>
> nope. I get on just fine not knowing what code my HLL is producing.

This might be the salient point, at least for this narrow part of the 
discussion.

Each foo(), *foo, foo[i], ++foo, foo++, and for that matter, '{' and '}' has 
in my mind very specific implications and costs. As I type or read each 
'if', 'switch', 'for', 'try', 'catch', and 'return', I hold in mind on a 
subconscious level the underlying assembler, albeit on a broad generalized 
model. For that matter, I also hold a simplified model of how awk or perl 
scripts are read and translated as I write them. Reading the Erlang language 
spec recently, I can "see" the interpreter, how it's built (or how I might 
build one), and the runtime cost of many of its constructs. C#'s runtime 
type binding holds few mysteries if you understand COM, and Java's byte-code 
interpreter holds no mysteries at all.

Like some others, I also had my start with BASIC, and then dug into 6502 
assembler to understand the unannotated ROM disassembly. This seemed a 
completely natural progression. (Apparently, Bill and I have an even longer 
history together than I had imagined before this moment.)

Before that, though, I wrote toy-sized FORTRAN without the slightest notion 
beyond "this is how you iterate over these calculations N number of times", 
and "this statement label is how you tie this statement to that other." 
Certainly it's possible to write useful programs without understanding the 
how or why behind them.

While I don't intend any of this to be judgemental, I don't see how I can do 
what I do with just a collection of rote rules and a notion of magic that 
happens under the covers. As perhaps extreme examples, memory barriers and 
fences are vague notions and superstition with that view, and using CUDA 
effectively is not possible at all without an underlying understanding of 
how the parts fit together.

[toc] | [prev] | [next] | [standalone]

#965 — Re: Learning to code by reading code

On Feb 19, 7:17 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> Nick Keighley wrote:
> > On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > wrote:
> >> "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
> >>news:assembly-20120219023621@ram.dialup.fu-berlin.de...
> >>> "Rod Pemberton" <do_not_h...@noavailemail.cmm> writes:


> >>>> learning how that language is converted to assembly [is important]
>
> > I don't think so. When I come across a novel language feature I like
> > to think how it would be implemented. But I use an imaginary machine
> > (or these days, C!). Long ago I knew Z80 assembler (actually much of
> > Z80 machine code) but I can't see the utility in converting chunks of
> > C ++ (or scheme or Haskell)into Z80 assembler.
>
> >>> 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 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.
>
> > nope. I get on just fine not knowing what code my HLL is producing.
>
> This might be the salient point, at least for this narrow part of the
> discussion.
>
> Each foo(), *foo, foo[i], ++foo, foo++, and for that matter, '{' and '}' has
> in my mind very specific implications and costs.

I don't think this has been true for many years. I certainly don't
think it has been useful.

> As I type or read each
> 'if', 'switch', 'for', 'try', 'catch', and 'return', I hold in mind on a
> subconscious level the underlying assembler, albeit on a broad generalized
> model.

I may have done that in the past but I don't think I do now. maybe
deep-deep down in my subconcious there's a Z80 or 68000 running. but I
doubt it.

To me C is the machine at the bottom.

> For that matter, I also hold a simplified model of how awk or perl
> scripts are read and translated as I write them.

never had that for Awk. Certainly not for Perl. this may explain why
I'm a rubbish Perl programmer... I have no semantic model for Perl.

> Reading the Erlang language
> spec recently, I can "see" the interpreter, how it's built (or how I might
> build one), and the runtime cost of many of its constructs.

I'm (in a desultory way) grappling with Haskell. Maybe your approach
would help me.

> [...] I wrote toy-sized FORTRAN without the slightest notion
> beyond "this is how you iterate over these calculations N number of times",
> and "this statement label is how you tie this statement to that other."
> Certainly it's possible to write useful programs without understanding the
> how or why behind them.

I'm not sure I agree. I think tou have to have some sort of idea what
is going on. I've been reading Fowler's "Domain Specific Languages"
recently. And I realised that's where i stole the term "Semantic
Model" from. This is one of those rare books where I go "yes! that's
what I was trying to do/say!". It's like he read my mind, sorted it
all out then squirted it on to paper.

> While I don't intend any of this to be judgemental, I don't see how I can do
> what I do with just a collection of rote rules and a notion of magic that
> happens under the covers.

yes, you have to have some set of primitives and some way of combinign
them, and the primitives must have some well defined semantics
(meaning). I just disgaree that some arbitary assembler is the best
way to describe the semantics. Level confusion at best.

"Dr. I have this pain in my leg!" "Your quarks are misplaced"

> As perhaps extreme examples, memory barriers and
> fences are vague notions and superstition with that view, and using CUDA
> effectively is not possible at all without an underlying understanding of
> how the parts fit together.

[toc] | [prev] | [next] | [standalone]

#970 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:66f82f8c-88e3-4764-8709-3b2fad575c79@y38g2000yqb.googlegroups.com...
On Feb 19, 7:17 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> Nick Keighley wrote:
> > On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > wrote:
> >> "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
> >>news:assembly-20120219023621@ram.dialup.fu-berlin.de...
> >>> "Rod Pemberton" <do_not_h...@noavailemail.cmm> writes:


> >>>> learning how that language is converted to assembly [is important]
> Each foo(), *foo, foo[i], ++foo, foo++, and for that matter, '{' and '}' has
> in my mind very specific implications and costs.

I don't think this has been true for many years. I certainly don't
think it has been useful.

> As I type or read each
> 'if', 'switch', 'for', 'try', 'catch', and 'return', I hold in mind on a
> subconscious level the underlying assembler, albeit on a broad generalized
> model.

I may have done that in the past but I don't think I do now. maybe
deep-deep down in my subconcious there's a Z80 or 68000 running. but I
doubt it.

To me C is the machine at the bottom.

#this is io_x
#C can not be the one machine language.
#it will be the language one machine if it has no Undefinited Behaviour,
#and type of know size, and operation on these type all the same for all PCs
#and i think a way to reach the stack it[C] use for call functions
#and for save variable in the function preamble...
#

[toc] | [prev] | [next] | [standalone]

#972 — Re: Learning to code by reading code

On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:66f82f8c-88e3-4764-8709-3b2fad575c79@y38g2000yqb.googlegroups.com...
> On Feb 19, 7:17 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> > Nick Keighley wrote:
> > > On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > > wrote:
> > >> "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
> > >>news:assembly-20120219023621@ram.dialup.fu-berlin.de...
> > >>> "Rod Pemberton" <do_not_h...@noavailemail.cmm> writes:


> > >>>> learning how that language is converted to assembly [is important]


> > Each foo(), *foo, foo[i], ++foo, foo++, and for that matter, '{' and '}' has
> > in my mind very specific implications and costs.

[...]

> > As I type or read each
> > 'if', 'switch', 'for', 'try', 'catch', and 'return', I hold in mind on a
> > subconscious level the underlying assembler, albeit on a broad generalized
> > model.

[...]

> To me C is the machine at the bottom.
>
> #this is io_x
> #C can not be the one machine language.

probably not ideal. Trying to write an interpreter for another
language has taught me that C is quite awkward for some things. I want
computed gotos!

> #it will be the language one machine if it has no Undefinited Behaviour,

not really relevent. Some assembly languages and even machine codes
have "undefined behaviour". Provide you stick to well defined
operations you have well defined semantics.

> #and type of know size, and operation on these type all the same for all PCs

not relevent

> #and i think a way to reach the stack it[C] use for call functions
> #and for save variable in the function preamble...

can't see the need. For an interprter I hand built the list of
environments ("the stack")

[toc] | [prev] | [next] | [standalone]

#975 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:c2e8b3ce-b516-4693-8cdb-244c17436a12@gi10g2000vbb.googlegroups.com...
On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel
> messaggionews:66f82f8c-88e3-4764-8709-3b2fad575c79@y38g2000yqb.googlegroups.com...
> On Feb 19, 7:17 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> > Nick Keighley wrote:
> > > On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > > wrote:
> > >> "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
> > >>news:assembly-20120219023621@ram.dialup.fu-berlin.de...
> > >>> "Rod Pemberton" <do_not_h...@noavailemail.cmm> writes:


> > >>>> learning how that language is converted to assembly [is important]


> > Each foo(), *foo, foo[i], ++foo, foo++, and for that matter, '{' and '}' has
> > in my mind very specific implications and costs.

[...]

> > As I type or read each
> > 'if', 'switch', 'for', 'try', 'catch', and 'return', I hold in mind on a
> > subconscious level the underlying assembler, albeit on a broad generalized
> > model.

[...]

> To me C is the machine at the bottom.
>
> #this is io_x
> #C can not be the one machine language.

probably not ideal. Trying to write an interpreter for another
language has taught me that C is quite awkward for some things. I want
computed gotos!

> #it will be the language one machine if it has no Undefinited Behaviour,

not really relevent. Some assembly languages and even machine codes
have "undefined behaviour". Provide you stick to well defined
operations you have well defined semantics.

#i'm not agree, a machine has to execute its statement with no UBs
#is one assembly language has UBs for me is not an assembly and can not
#to pilot one cpu

> #and type of know size, and operation on these type all the same for all PCs

not relevent

#it is relevant, each basic oparation for 8,16,32,64,...
#size has to be fully portable

> #and i think a way to reach the stack it[C] use for call functions
> #and for save variable in the function preamble...

can't see the need. For an interprter I hand built the list of
environments ("the stack")

#i see the need because i think C work ok for many time just for the way
#the stack it use
#as someone other had to say, stack is fundamental in the programming area
#but i can wrong on all, because i'm little as a little bird :)
#and i drank some rum for now [but i not drink too much]

[toc] | [prev] | [next] | [standalone]

#976 — Re: Learning to code by reading code

On Feb 20, 2:11 pm, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:c2e8b3ce-b516-4693-8cdb-244c17436a12@gi10g2000vbb.googlegroups.com...
> On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote:
> > "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel
> > messaggionews:66f82f8c-88e3-4764-8709-3b2fad575c79@y38g2000yqb.googlegroups.com...
> > On Feb 19, 7:17 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> > > Nick Keighley wrote:

> > > >>>> learning how that language is converted to assembly [is important]

> > > Each foo(), *foo, foo[i], ++foo, foo++, and for that matter, '{' and '}' has
> > > in my mind very specific implications and costs.

[...]

> > To me C is the machine at the bottom. [the implementation machine]

Note I'm only talking about C/Assembler as the language to define high
level semantics. I think assembler is a poor way to describe
semantics. It's too verbose and too far away from HLLs. It's also
hellish to understand.

> > #this is io_x
> > #C can not be the one machine language.
>
> probably not ideal. Trying to write an interpreter for another
> language has taught me that C is quite awkward for some things. I want
> computed gotos!
>
> > #it will be the language one machine if it has no Undefinited Behaviour,
>
> not really relevent. Some assembly languages and even machine codes
> have "undefined behaviour". Provide you stick to well defined
> operations you have well defined semantics.
>
> #i'm not agree, a machine has to execute its statement with no UBs
> #is one assembly language has UBs for me is not an assembly and can not
> #to pilot one cpu

sadly you are trumped by reality. The Z80 (and I believe 8080) had
unused op-codes. By tracing the logic of how instructions were build
you could deduce what these op-codes should do. And on many CPUs they
did exactly what you expected. But I suspect the manufacturers had
damn good reason for not including these instructions so you'd have to
be mad to use them.

I'm sure plenty of things give UB. Divide by zero, large shifts,
contention between coprocessors.

> > #and type of know size, and operation on these type all the same for all PCs
>
> not relevent
>
> #it is relevant, each basic oparation for 8,16,32,64,...
> #size has to be fully portable

(a) not for general programming
(b) if you *really* need them then hide them behind typedefs
(c) not relevent when discussign HLL semantics

> > #and i think a way to reach the stack it[C] use for call functions
> > #and for save variable in the function preamble...

don't need this for HLL semantics

> can't see the need. For an interprter I hand built the list of
> environments ("the stack")
>
> #i see the need because i think C work ok for many time just for the way
> #the stack it use

the C Standard doesn't insist on a stack. You can implement a stack
without access to SP or whatever an I86 calls it.

> #as someone other had to say, stack is fundamental in the programming area

but it doesn't have to be implemented in hardware. And some languages
don't follow simple semantics in procedure calls

<snip>

[toc] | [prev] | [next] | [standalone]

#962 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
news:d3b454ac-ae8e-4bd6-b67e-2e8e4050f849@w4g2000vbc.googlegroups.com...
> On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
...

> But I use an imaginary machine [...]
>

How do you confirm correctness of both high-level and low-level code with an
imaginary machine?  Is your confirmation of correctness imaginary also? ...

That's one of the problems with the ANSI and ISO C specifications: it
doesn't specify a working machine model.  Without it, there is no reference
working version of C that other implementations can be compared against.
Without it, everything in the specifications is open to interpretation as to
accuracy.  That's the major problem that plagues the pedants on comp.lang.c.
Each of them has their own model in their head of how C works and what the
English words and phrases in the C standards mean.  The British frequently
have a different understanding of "either-or" versus Americans.  It seems
that not one of the pedants has ever programmed in assembly or believe they
need to.  None have read "The C Rationale", or read historical works by the
C creators like "The Development of the C Language" or "Portability of C
Programs and the UNIX System" or "The C Language Calling Sequence" etc which
explain what C is supposed to do and make reference to assembly.  If they
did, none of them would ever argue against the understanding that C is built
upon assembly and assembly is needed to fully understand C.

Forth programmers hate the fact that their early specifications did specify
a machine model.  The problem wasn't that they specified a model, but they
specified a very narrow model that wasn't able to adapt, or had radical
changes in the following specification.  But, that is far better than not
specifying one at all.  Many Forths were able to comply very accurately with
their machine models.  That allowed Forth to be widely implemented.  Today,
a couple of the early specifications are loved, and still used while a
couple are hated.

> (or these days, C!).
>

I'm not familiar with the C! language.  Did you mean the C language?
Perhaps you meant C# language?  It seems that Wikipedia, Esolangs, nor
Google or Yahoo, will find anything on C! or C exclamation language ...
HOPL is inaccessible for some reason.

However, if C! is a C derivative, it most likely inherited the basic
functionality that a programmer needs to know.  Most C derivative
languages have kept that functionality because it has become standard
due to microprocessors.

> [...] but I can't see the utility in converting chunks of
> C++ (or scheme or Haskell)into Z80 assembler.

Yes, converting C++ for ARM to Z80 to understand how a HLL is converted to
assembly would be questionable ...  You'd want to study the ARM assembly
code generated for C++.  They need to understand how a HLL is converted to
the assembly for their platform.  They need to know how basic language
constructs are converted to assembly, e.g., pointers, control-flow,
procedures or function calls, etc.

> > 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.
>
> but many C programmers (and maybe C++ programmers)
> assume these are inviolate laws! They end up writing horribly
> unportable programs for no reason except intellectual laziness
> and lack of imagination about hardware engineers
> (and compiler writers) might do.
>
> Your concentration on assembly code encourages this (naff)
> type of coding.

Ok, this is the same BS portable C argument that plagues comp.lang.c
thought ...

The first inherent problem with that argument is that microprocessors have
standardized on a basic computing architecture.  Nearly all computing
platforms today use that architecture either because they are microprocessor
based or because they use the same hardware, e.g., memory.  They
standardized way back around 1974.  Mainframes followed suit slightly later.
What that means is that almost no one today - or in the past two decades for
that matter - has access to obscure, obsoleted, perverse platforms - or
other platforms that *NEVER* shouldv'e have been used to create the ANSI C
standard in the first place - where "portability" of C or C++ is actually
needed.  Have you ever had access to a non-emulated EBCDIC platform in your
entire lifetime?  (No.) Have you ever had access to a 16-bit byte platform
in your entire lifetime? (No.)  Have you ever had access to a 9-bit
character platform in your entire lifetime? (No.)  So, like it or not, it's
entirely up to the users of obscure platforms to fix the "non-portable"
nature of C code for their platforms.

The second inherent problem with that argument is even C that is
specification compliant is truly only 30% portable.  And, that again is due
to standardization of microprocessors on 8-bit bytes for ASCII or EBCDIC,
contiguous memory, two's complement integers, generic integers so pointers
are the same size, etc.  Another 50% of C can be made to work correctly, but
it's not portable by default.  The compiler has to make it work.  And, 20%
of C is just non-portable.  IIRC, you were on c.l.c, so I shouldn't have to
mention stuff like setjmp, signals, buffering, POSIX based file I/O, 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.
>
> nope. I get on just fine not knowing what code my HLL is producing.

Then, I'd quess you won't get fired for producing faulty code either ...
So, that qualifies you as either a novice or hobbyist.  (Yes, I suspect you
probably aren't ...)  A professional would do so as a matter of course.  How
do you know your compiler is compliant with a specification, or your
compiler accurately implements what you expect your code to do?
Testing only?  What if you missed something you could've caught had you
simply just read the assembly?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#964 — Re: Learning to code by reading code

On Mon, 20 Feb 2012 04:14:15 -0500, Rod Pemberton wrote:

> "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
> news:d3b454ac-ae8e-4bd6-b67e-2e8e4050f849@w4g2000vbc.googlegroups.com...
>> On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
>> wrote:
> ...
> 
>> But I use an imaginary machine [...]
> 
> How do you confirm correctness of both high-level and low-level code with an
> imaginary machine?

Huh, the whole idea of a correctness proof is to do it *before* running the
code. You need no machine for that.

> Is your confirmation of correctness imaginary also? ...

As any confirmation is. Moreover, such imaginary confirmations are much
stronger than any tests. Because they hold not only for a concrete machine
and a concrete run, but for any machine and any run.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#973 — Re: Learning to code by reading code

On Feb 20, 10:14 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Mon, 20 Feb 2012 04:14:15 -0500, Rod Pemberton wrote:
> > "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> >news:d3b454ac-ae8e-4bd6-b67e-2e8e4050f849@w4g2000vbc.googlegroups.com...
> >> On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>


> >> But I use an imaginary machine [...]
>
> > How do you confirm correctness of both high-level and low-level code with an
> > imaginary machine?
>
> Huh, the whole idea of a correctness proof is to do it *before* running the
> code. You need no machine for that.
>
> > Is your confirmation of correctness imaginary also? ...
>
> As any confirmation is. Moreover, such imaginary confirmations are much
> stronger than any tests. Because they hold not only for a concrete machine
> and a concrete run, but for any machine and any run.

and proving a chunk of assembler is correct is far harder tahn proving
a line of an HLL is correct. This "look at the machine code" only
works for trivial bits of HLL; pieces where you "run the assembler in
your head". I'd like to see him prove a quicksort implementation
correct after its been comoiled to assembler (io-x- that's /not/ an
invitation...). and as soon as any optimisation occurs the human is
left for dust.

[toc] | [prev] | [next] | [standalone]

#966 — Re: Learning to code by reading code

On Feb 20, 9:14 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> news:d3b454ac-ae8e-4bd6-b67e-2e8e4050f849@w4g2000vbc.googlegroups.com...> On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>

> > But I use an imaginary machine [...]
>
> How do you confirm correctness of both high-level and low-level code with an
> imaginary machine?

How do you "confirm correctness" by translating it into I86 assembler?
to me "correctness" is a mathematical property.

And if its good enough for Knuth...

> Is your confirmation of correctness imaginary also? ...

code inspection, DbC, unit test

> That's one of the problems with the ANSI and ISO C specifications: it
> doesn't specify a working machine model.

that is one of it's major strengths.

Though I've read a few language definitions in my time and *none* of
them went anywhere near the bare metal.

> Without it, there is no reference
> working version of C that other implementations can be compared against.

there is a clear definition of the semantics of each primitive.
Luckily uncontaminaed by any particular implementation.

We are beginning to repeat ourselves and making no progress in
convincing each other.

I've made my points. Re-read my previous posts if wish for
reiteration.

[assume massive snippage]

> [...]  None have read "The C Rationale",

I have! lovely document.

<snip>

> [a Clike language] most likely inherited the basic
> functionality that a programmer needs to know.

exceptions, closures, continuations, modads,

lost of stuff C doesn't provide.

<snip>

> > > 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.
>
> > but many C programmers (and maybe C++ programmers)
> > assume these are inviolate laws! They end up writing horribly
> > unportable programs for no reason except intellectual laziness
> > and lack of imagination about hardware engineers
> > (and compiler writers) might do.
>
> > Your concentration on assembly code encourages this (naff)
> > type of coding.
>
> Ok, this is the same BS portable C argument that plagues comp.lang.c
> thought ...
>
> The first inherent problem with that argument is that microprocessors have
> standardized on a basic computing architecture.  Nearly all computing
> platforms today use that architecture either because they are microprocessor
> based or because they use the same hardware, e.g., memory.  They
> standardized way back around 1974.  Mainframes followed suit slightly later.
> What that means is that almost no one today - or in the past two decades for
> that matter - has access to obscure, obsoleted, perverse platforms - or
> other platforms that *NEVER* shouldv'e have been used to create the ANSI C
> standard in the first place - where "portability" of C or C++ is actually
> needed.

if in the following by platform you mean hardware then in many cases
"yes I have used such things". But if by platform you mean "have I
programmed in C on these things" then "no"

> Have you ever had access to a non-emulated EBCDIC platform in your
> entire lifetime?  (No.)

but I've encountered none ASCII character sets.

> Have you ever had access to a 16-bit byte platform
> in your entire lifetime? (No.)

yes. And used HLLs on them.

> Have you ever had access to a 9-bit
> character platform in your entire lifetime? (No.)

I've encountered 5 and 6 bit character sets. I've used 24 bit
machines. I've used 1's complement machines.

<snip>

> > > [...] it's [...] the
> > > programmer's responsibility to understand what that HLL
> > > code is producing for their specific tools.
>
> > nope. I get on just fine not knowing what code my HLL is producing.
>
> Then, I'd quess you won't get fired for producing faulty code either ...
> So, that qualifies you as either a novice or hobbyist.  (Yes, I suspect you
> probably aren't ...)  A professional would do so as a matter of course.

no. I known plenty of professional progarmmers and vanishingly few of
them look at the assembler. Most would laugh at the idea.

> How
> do you know your compiler is compliant with a specification, or your
> compiler accurately implements what you expect your code to do?
> Testing only?  What if you missed something you could've caught had you
> simply just read the assembly?

in my experience compiler bugs are very rare

[toc] | [prev] | [next] | [standalone]

#969 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:2bc2a617-e283-44c7-9fd3-63d2887b896e@y10g2000vbn.googlegroups.com...
On Feb 20, 9:14 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> news:d3b454ac-ae8e-4bd6-b67e-2e8e4050f849@w4g2000vbc.googlegroups.com...> On
> Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>

> > But I use an imaginary machine [...]
>
> How do you confirm correctness of both high-level and low-level code with an
> imaginary machine?

How do you "confirm correctness" by translating it into I86 assembler?
to me "correctness" is a mathematical property.

#io_x in his ot language
#balle; non puoi dimostrare la correttezza matematica di una espressione
#che ha diversi risultati dipendendo dalla macchina effettiva in cui gira...

And if its good enough for Knuth...

> Is your confirmation of correctness imaginary also? ...

code inspection, DbC, unit test

.....
> Then, I'd quess you won't get fired for producing faulty code either ...
> So, that qualifies you as either a novice or hobbyist. (Yes, I suspect you
> probably aren't ...) A professional would do so as a matter of course.

no. I known plenty of professional progarmmers and vanishingly few of
them look at the assembler. Most would laugh at the idea.

#so they program what? not a machine, a machine need a precise language
#pheraps they program their imaginary machine != every machine in this planet

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.misc

csiph-web