Real programmers? or myopic egotists
[1/3] from: kenneth::nwinet::com at: 26-May-2001 14:23
Hi all, been to any good jousts lately?
(this is a long post and it rambles so for those of you that just want to
hit the delete key, I promise not be offended ;-))
At 16 I could have been the best at something. At 42 I've determined that I
have too many interests to become an expert at any one of them. So I
ramble. Ok, you can call me shallow. ;-) OTOH, I've noticed as have
others the close ties between genius and insanity. Which brings us to
Charles Moore.
Not to take anything away from Chuck Moore but he reminds me of a
Minneapolis programmer (not a young guy) I once knew that thought
hexadecimal was much more natural and so regardless of what language he
wrote in he always used that representation (even when decimal was the
natural way to express the number.) ...and this was a guy that worked with
computers that used 9 and 36 bit cpu's. Am I alone in thinking this funny?
> I think of a router as a very simple thing that takes
> data in and sends it out. Perhaps it more complicated
> than that. -- C.M.
There's a paradox here. On one hand it shows a person somewhat out of
touch, but on the other hand it shows someone that better than most
understands the power inherent in fundamental abstractions. So he invents a
language where all programmers are an island and in the process breaks the
heart of those that see the potential inherent in the fundamental design.
It makes me wish I were a better programmer or better visionary (or perhaps
just a programmer with more time) so I could take elements of his design and
build on them to come up with something better. I'm attracted to Rebol
because I see some of those elements existing here.
> >If it succeeds, these people will prefer to look at scripts
> >instead of black boxes...
<<quoted lines omitted: 4>>
> If so, then that view is shared by some eminent programmers
> including Charles Moore, the inventor of Forth.
I want to talk more about C.M.'s thoughts on real programmers, but first...
It amazes me when someone disparages the 'black box'. I think Joel pointed
out that, even machine language represents a black box because as has been
mentioned it sits on top of microcode. The abstraction of the black box is
always there and is where power (there's that word again) comes from. (Does
it stop at Quanta? I don't know, but I suspect not.)
For me the issue is which black boxes are foundational and which are
programs themselves rather than tools for programmers (I'm not quite happy
with how I expressed this thought, but I'm not sure how to better express
it.)
I have to be careful here because I'm not arguing that a language should not
include these 'programs themselves' but that they should be part of a
library (which then paradoxically makes them a programming tool.)
My thoughts are a little muddy on this issue. For example, I would not
classify most visual components like textboxes and such as foundational to a
language. Although I would want to be able to easily create new widgets
with language elements that are foundational. Others might reasonable see
this differently, so perhaps it's just a matter of where you put the fence.
Another example, printf doesn't seem foundational to me (C programmers
probably think this sounds weird, especially since it can't be written in C
because printf does not have a fixed number of parameters (C++ could
however.) I would say it's not foundational because it includes both
formatting and output. To me, printf is something a programmer (or library
builder) would create for their own use, but not include as a fundamental
part of the language. Ok, so it's part of the standard library then, hey
guys, cut me some slack. I see printf as a programming kludge, not well
thought out (but have no problem with format specifications and escape
sequences in general ---as opposed to using special symbols--- as in APL
keyboards and there ilk.)
To me, Rebol's use of refinements is very appealing. Although using
different words may be more concise (print, write, out, send, etc.) My
purist heart likes the idea of a single word (copy perhaps) that takes a
pointer to a buffer and redirects it to another buffer with some
preprocessing dependant on a refinement.
Then I realize that taken to the extreme it becomes ridiculous (say copy is
the only language element) and the refinements become the language!
Copy from the keyboard into a buffer. Copy from a blob to a screen
location. Copy this range over that range using Xor. Etc. Shades of turing
machines!
OTOH, datatypes are another way of supplying a refinement that seems closer
to doing things the way they should be done. It allows the computer to do
the housekeeping that computers are really good at and frees the programmer
to think about the fundamentals of the algorithm they are writing.
Doesn't it strike some with awe that the exact same bits, depending on how
they are interpreted can be both data and code, can represent a letter of
the alphabit (another freudian? Alphabet,) or a color on a screen, or the
address of that color on the screen? There's something fundamental here
that is almost a religious experience (hey, and I don't even do drugs! It's
a natural high. Ok, aspirin on occassion. Feel free to take a few
yourself. *** Insert Medical Legal Disclaimer Here *** What a world we live
in? I spilled coffee on myself for months at McDonalds and they never game
me a million dollars? Incredible huh?)
Ok, now on to my fundamental objection to CM's elitist attitude: Real
Programmers Kluge! They patch! They connect things together that no one
had considered putting together. Real programmers maintain the code that
elitist programmers didn't have time to get right or have to adjust because
the specification changed. I believe in elegant code. I love the power of
simplicity. I'm constantly telling the guys I work with that code that
doesn't exist doesn't produce an error (Ok, I know that's not exactly true
and wish I could find a better way of phrasing the concept.) I'm often
reducing 500 lines of code into 100 that does the job better and with more
flexibility and that other programmers can understand without having me
around to explain it to them. I also know there are other guys that do that
better than I do. I don't do it just to be rewriting other's code (which I
think is insulting to the original programmer and often unproductive or
counter-productive) or because I somehow know better. But in my book,
maintenance programmers are the unsung hero's that keep things working after
the Real Programmers are long gone. Yeah, I'd much rather be doing
something original and less like housework, but the piles would be getting
pretty high if we didn't have these legions of dumb programmers out there
doing their job. Occasionally, making things harder for those that follow,
but so what? That's just the way it works and no amount of moaning or
elitism is going to change it any time soon.
I find myself both agreeing and disagreeing with both the conservative and
radical view's expressed on page xviii of R:TOG. Both start by saying that
programs become too large to be completely understood. My view is that it
takes a combination of both discipline and mind expansion. The key is to
carefully choose the abstractions that are to be considered fundamental. I
see this as the craft of a language designer. The use of the word craft as
in craftsman is deliberate.
When a language turns into some obscenity of characters ' -#@$ %" I think
something is fundamentally wrong. I think that when indirect memory
references become a series of pointers to pointers, then something is
fundamentally wrong. I think that when you have to introduce stack
manipulation words like pick, rot, dup, drop and swap (my favorite) it may
not be wrong, but something isn't quite right either. Actually, why doesn't
somebody use Pluck? What? Prejudiced?
I hear the arguments regarding stacks vs. registers and think... Why not
have the first 16 or 256 elements of the stack map to registers?
************* you can safely ignore this section (or everything for that
matter ;-)) ************************** comments on elitism continue below...
This leads to what I admit is an ugly notation but suppose... (and here a
better choice of letters or replacing them with actual words sounds fine to
me. A shorthand version might also exist in that case.) BTW, I got this
wrong which I'm sure you'll all be able to spot.
R5 would directly address the fifth element on the stack (leaving it on the
stack.)
A5 or @5 might indirectly address memory pointed to by the fifth element.
U9 to use it like A9 but also removes it from the stack.
P10 to pick the tenth element and remove it from the stack sliding
everything else up (or perhaps everything down to that point since
presumable the value picked goes to the top of the stack.)
I99 to insert the top of the stack into the 99th position.
Inc25 to increment stack location 25 and... (Inc might be an alias for Inc0)
Dec25 to decrement it (Yule get used to it.)
S200 to swap the top of the stack with the contents of R200. S1 would be
the equivalent of forth's swap word.
T42 fill a Target register with an indirect address from register 42.
C11 to copy the count in R0 from A11 to Target which was the last Txx
indirect reference.
Z11 to copy from A11 until a zero value.
F255 fill the target with the value at R255 using the count on the top of
the stack.
Then you've got logical operations like...
AND, XOR, OR, ROR, ROL, SHR, SHL,NOT that could include register references
and...
For example: @XOR4 to exclusive or the value pointed to by A4 with the top
of the stack (otherwise known as the accumulator!)
I would assume that hardware could be produced that handled all this
shifting of data in an efficient manner.
The reason for saying R5 rather than the more flexible R 5 is that I
envision R5 being a literal register in hardware. For portability this
could just as easily be a virtual register in software, in which case R 5
would then be preferable as a notation (because a virtual machine can easily
adapt itself to a non-fixed number of registers.) Charles Moore even went
on to create a forth chip in hardware so I don't see why this couldn't be
done.
The key to all this (and why there even is a stack vs. register debate) is
that registers are usually better at being registers than they are at being
stack elements. To change the stack you can just change the stack pointer,
not so easy with registers. But that doesn't mean that registers can't be
incorporated into the top of the stack in an efficient manner or that stack
manipulation couldn't be made to work efficiently. Under the covers R0 -
R255 could be some sort of mapped array (pointing to the real R0 - R255.)
Anyone care to make an emulator? I'll start...
Registers: [R0 R1 R2 R3 ... ]
***************** back to charles****************************
C.M. thinks real programmer don't need floating point. Hello? Sure
floating point has it's problems (like when comparing and exact dollar value
to the same value in a SQL database and having it fail!) And scaled
integers are certainly faster, but real life uses a lot of real numbers.
Conversion is the computers job, not mine. If that means I'm not a real
programmer, then you can bite my real...
oops! Please forgive me. Got carried away there (yeah, and other places...
so?)
Me, I like the reluctant messiahs like Linus Torvalds. He just wants to
keep working and everyone is always asking his opinion. The guy seems to
have some real humility (My humility has been humilitated out of me...)
Life is too short. Enjoy what you find interesting. Be responsible to
those less fortunate. Leave the rest to eternity.
Shoot the messenger! Enjoy the weekend. Go to the beach! (For all those
purists that don't like gotos!)
Cheers!
[2/3] from: joel:neely:fedex at: 26-May-2001 17:19
Hi, Ken,
I enjoy a good ramble on a slow weekend! ;-)
Ken Anthony wrote:
> > I think of a router as a very simple thing that takes
> > data in and sends it out. Perhaps it more complicated
<<quoted lines omitted: 3>>
> someone that better than most understands the power
> inherent in fundamental abstractions.
Or, for another option, it shows someone who is bright enough
to see the fundamental abstraction, but out of touch with the
world that I live in, where simple sounding ideas get much
more complicated when you have to:
- optimize like crazy (literally! ;-) because of really
extreme performance requirements,
- design for extreme fault tolerance/recovery,
- interface with other people's stuff,
- provide a significant level of dynamic configurability, and
- do all of the above at once!
> Another example, printf doesn't seem foundational to me (C
> programmers probably think this sounds weird, especially
> since it can't be written in C because printf does not have
> a fixed number of parameters...
>
Not to be picky, but... well, I guess I am. Take a look at
the documentation of <stdarg.h> for the discussions of va_list,
va_start, va_arg, and va_end (usually implemented as macros,
often in a platform/compiler-specific way). printf and sprintf
are, in fact, writable in C, using variable argument lists.
> OTOH, datatypes are another way of supplying a refinement
> that seems closer to doing things the way they should be
> done. It allows the computer to do the housekeeping that
> computers are really good at and frees the programmer
> to think about the fundamentals of the algorithm they are
> writing.
>
Excellent summary! I may have to quote you!
> Ok, now on to my fundamental objection to CM's elitist
> attitude: Real Programmers Kluge! They patch! They
> connect things together that no one had considered putting
> together. Real programmers maintain the code that elitist
> programmers didn't have time to get right or have to adjust
> because the specification changed.
>
Perfectionists never release anything, because there's always
just one more little tweak
.
Pragmatists try to ensure that it's "good enough" before
release, and then commit to ongoing improvement.
Extremists release multiple times per week (or day), because
shipping one feature at a time helps keep the crosshairs on
the moving target.
I'm glad we have all three kinds, or even the freedom to play
all three roles at different times.
OTOH, slobs compose at the keyboard and put it into production
(or the customer's system) immediately, because they don't
know any better or don't care.
I'm glad that I get publicly embarassed every time I play THAT
particular role!
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[3/3] from: agem:crosswinds at: 27-May-2001 3:43
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 26.05.01, 22:23:42, schrieb "Ken Anthony" <[kenneth--nwinet--com]> zum
Thema [REBOL] Real programmers? or myopic egotists:
> Hi all, been to any good jousts lately?
> (this is a long post and it rambles so for those of you that just want
to
> hit the delete key, I promise not be offended ;-))
> At 16 I could have been the best at something. At 42 I've determined
that I
> have too many interests to become an expert at any one of them. So I
> ramble. Ok, you can call me shallow. ;-) OTOH, I've noticed as have
<<quoted lines omitted: 3>>
> Minneapolis programmer (not a young guy) I once knew that thought
> hexadecimal was much more natural and so regardless of what language
he
> wrote in he always used that representation (even when decimal was the
> natural way to express the number.) ...and this was a guy that worked
with
> computers that used 9 and 36 bit cpu's. Am I alone in thinking this
funny?
Want to mention some high skilled programmers killing projects
by mixing units..
similar in system-programming there is a change to se a number,
think »o pretty« and not realising bad base..
solving that standing with one base everywhere can make sense.
Specially if this is one's prefered personal bug.
(Just speculating ;-)
> > I think of a router as a very simple thing that takes
> > data in and sends it out. Perhaps it more complicated
> > than that. -- C.M.
> There's a paradox here. On one hand it shows a person somewhat out of
> touch, but on the other hand it shows someone that better than most
> understands the power inherent in fundamental abstractions. So he
invents a
> language where all programmers are an island and in the process breaks
the
> heart of those that see the potential inherent in the fundamental
design.
> It makes me wish I were a better programmer or better visionary (or
perhaps
> just a programmer with more time) so I could take elements of his
design and
> build on them to come up with something better. I'm attracted to
Rebol
> because I see some of those elements existing here.
> > >If it succeeds, these people will prefer to look at scripts
<<quoted lines omitted: 8>>
> > including Charles Moore, the inventor of Forth.
> I want to talk more about C.M.'s thoughts on real programmers, but
first...
> It amazes me when someone disparages the 'black box'. I think Joel
pointed
> out that, even machine language represents a black box because as has
been
> mentioned it sits on top of microcode. The abstraction of the black
box is
> always there and is where power (there's that word again) comes from.
(Does
> it stop at Quanta? I don't know, but I suspect not.)
Not really. Having only one root does't mean to have only one
branch. except for the leaf.
At a certain level
the question is which pieces are there, how they interact and
where it is necesary to clumb stuff together in a frozen way
or in a warmer, more agile.
This depends on the number of needed base-elements for a »molecule«.
A while it is better to stay on the warm level (10k for programms?)
for quick rearangements,
after that cooling get benefits because not destroing the complex.
Real ice cold eternal stuff
is needed for root-like stuff.
For the needed-knowledge - and code base for millions.
And this we have, guess? its rebol ;-)
Above it there is some room for warmer stuff
(changeable mutable scripts).
If things gets even larger, there comes a splitting in different
hot pieces
(config-and code-files), and on very hard cases api-freesing
(remote dialects on other servers maybe).
Rebol is designed to have highly combinable »atoms«
reducing heavy the needs for bridging pieces
(declarations of the obvious, castings, creating
extra objects to have the right type of a parameter, ..).
Results in small code.
new pieces are »automatic« higly combinable too,
makes for even smaller code, ..
Well, somewhere here are a little list of stuff which could be on
a standard library.
This stuff is pretty state of the art, it covers
distributed computing servers (rugby), webserver,
»asp«, own wordprocessors
(as the function of a WP is to quick write pretty looking text,
make-spec & etext are word-processor ;-) ,
irc, ..
IIRC there is not much where i see the need to go to a cold level.
SWIS and mysql for auto-updates maybe ? But else?
And that are parts which should be embedded by rebol.com as
central parts if ready for standard, as i argue.
Other scripts are not as hot as writing stuff,
but small enough to understand
the general structure quick and make personal customization.
(<-hot in my sense, not »not hot scripts« ;-)
so additional hardcoded options are not necessary.
A limiting dependency-control is also not needed,
one can easy distibute 3 related files together..
Saves work on both ends.
BTW little contrib for the lib,
killing meta-info in header instead of XML.
Just to show about recombination of basic pieces.
Hm, would you like this in a black-box with some docu instead?
Which options in blackbox? ;-)
[REBOL [title: "kill uhuru-entry in header"
file: %pad.r
date: 27-May-200 author: "Volker Nitsch"
uhuru: [
version: 123 "lots of other stuff"
]
]
old-source: read %pad.r
;adds lots of fields.., handwork?:
set [header source] load/next/header old-source
header: make header [uhuru: none]
;molded-header: mold third header ; no newlines, ugly
molded-header: find mold/only header "[" ; better :)
new-source: join "REBOL" [molded-header source]
;send it down..
;---demo-view
sz: 340x480
inform center-face layout compose [
tabs sz/x + 40
across
tx: text sz/x * 2 wrap {
maybe we should parse the header by hand
to avoid standard fields?
or better keep because they are standard? or?
}
return
title "original" tab title "uhuru-less header" return
area sz old-source
tab
area sz new-source
]
> For me the issue is which black boxes are foundational and which are
> programs themselves rather than tools for programmers (I'm not quite
happy
> with how I expressed this thought, but I'm not sure how to better
express
> it.)
i tried it a bit longer :)
> I have to be careful here because I'm not arguing that a language
should not
> include these 'programs themselves' but that they should be part of a
> library (which then paradoxically makes them a programming tool.)
»languages« are: the stuff all people agree in (a bit forced).
all basic pieces which are needed.
including libs like io, if portability is concerned.
Since agreement has to happen in this field to then.
IMHO
> My thoughts are a little muddy on this issue. For example, I would
not
> classify most visual components like textboxes and such as
foundational to a
> language. Although I would want to be able to easily create new
widgets
> with language elements that are foundational. Others might reasonable
see
> this differently, so perhaps it's just a matter of where you put the
fence.
One can think about faces as »language to the painter«,
Carl(?) compared vid/view once with compiler/machine code.
As far as possibilities are required, multiple sub-languages
are ok.
i would count assembler to be a sub-language of c in this sense.
There's stuff you can't do without it in C's area,
so some c-program cannot be complete without it.
Similar /view is not complete without faces.
hm. i dont like »sub-languages«. »assistant languages«?
> Another example, printf doesn't seem foundational to me (C programmers
> probably think this sounds weird, especially since it can't be written
in C
> because printf does not have a fixed number of parameters (C++ could
> however.) I would say it's not foundational because it includes both
> formatting and output. To me, printf is something a programmer (or
library
> builder) would create for their own use, but not include as a
fundamental
> part of the language. Ok, so it's part of the standard library then,
hey
> guys, cut me some slack. I see printf as a programming kludge, not
well
> thought out (but have no problem with format specifications and escape
> sequences in general ---as opposed to using special symbols--- as in
APL
> keyboards and there ilk.)
OTOH it is complex and important enough to be part of the agreement.
Think that functionality would come in various versions..
> To me, Rebol's use of refinements is very appealing. Although using
> different words may be more concise (print, write, out, send, etc.)
My
> purist heart likes the idea of a single word (copy perhaps) that takes
a
> pointer to a buffer and redirects it to another buffer with some
> preprocessing dependant on a refinement.
> Then I realize that taken to the extreme it becomes ridiculous (say
copy is
> the only language element) and the refinements become the language!
> Copy from the keyboard into a buffer. Copy from a blob to a screen
> location. Copy this range over that range using Xor. Etc. Shades of
turing
> machines!
Shade of the amiga blitter/copper :)
a special processor nowing only this command. ;-)
Makes some stuff very fast.
> OTOH, datatypes are another way of supplying a refinement that seems
closer
> to doing things the way they should be done. It allows the computer
to do
> the housekeeping that computers are really good at and frees the
programmer
> to think about the fundamentals of the algorithm they are writing.
Well, perl-guy says there's more than one way to do it.
Well, with rebol there is often a middle to mix them :)
> Doesn't it strike some with awe that the exact same bits, depending on
how
> they are interpreted can be both data and code, can represent a letter
of
> the alphabit (another freudian? Alphabet,) or a color on a screen, or
the
> address of that color on the screen? There's something fundamental
here
> that is almost a religious experience (hey, and I don't even do drugs!
It's
> a natural high. Ok, aspirin on occassion. Feel free to take a few
> yourself. *** Insert Medical Legal Disclaimer Here *** What a world
we live
> in? I spilled coffee on myself for months at McDonalds and they never
game
> me a million dollars? Incredible huh?)
Well said. That's what fascinates me with meta-progamming, i think.
You touch the right two view-points and suddenly a lot of
extra-instructions go away. It flips suddenly together. Mythical.
> Ok, now on to my fundamental objection to CM's elitist attitude: Real
> Programmers Kluge! They patch! They connect things together that no
one
> had considered putting together. Real programmers maintain the code
that
> elitist programmers didn't have time to get right or have to adjust
because
> the specification changed. I believe in elegant code. I love the
power of
> simplicity. I'm constantly telling the guys I work with that code
that
> doesn't exist doesn't produce an error (Ok, I know that's not exactly
true
> and wish I could find a better way of phrasing the concept.) I'm
often
> reducing 500 lines of code into 100 that does the job better and with
more
> flexibility and that other programmers can understand without having
me
> around to explain it to them. I also know there are other guys that
do that
> better than I do. I don't do it just to be rewriting other's code
(which I
> think is insulting to the original programmer and often unproductive
or
> counter-productive) or because I somehow know better. But in my book,
> maintenance programmers are the unsung hero's that keep things working
after
> the Real Programmers are long gone. Yeah, I'd much rather be doing
> something original and less like housework, but the piles would be
getting
> pretty high if we didn't have these legions of dumb programmers out
there
> doing their job. Occasionally, making things harder for those that
follow,
> but so what? That's just the way it works and no amount of moaning or
> elitism is going to change it any time soon.
Well Chuck is really really great and all that, but you can't deal
with
him like with publicity/success-oriented people.
He remembers me more of a excentric poet (well, english..)
chess-player, Muenchhausen.
I would look if they play with me carefully before trusting.
In a way »what is cisco?« could mean a great compliment like
»(i know them but) its perfect! I never sensed them! No problems!
But this booring interviewer..«.
Depends very on the people.
He may be really that stupid of course, don't know :)
> I find myself both agreeing and disagreeing with both the conservative
and
> radical view's expressed on page xviii of R:TOG. Both start by saying
that
> programs become too large to be completely understood. My view is
that it
> takes a combination of both discipline and mind expansion. The key is
to
> carefully choose the abstractions that are to be considered
fundamental. I
> see this as the craft of a language designer. The use of the word
craft as
> in craftsman is deliberate.
> When a language turns into some obscenity of characters ' -#@$ %" I
think
> something is fundamentally wrong. I think that when indirect memory
> references become a series of pointers to pointers, then something is
> fundamentally wrong. I think that when you have to introduce stack
> manipulation words like pick, rot, dup, drop and swap (my favorite) it
may
> not be wrong, but something isn't quite right either. Actually, why
doesn't
> somebody use Pluck? What? Prejudiced?
Ok, somewhere said this swapping is the forth way of not saying.
»There is a large black tree. The large black tree has green large
leafs.
The green large leafs of the large black tree have..«
but »there is a large black tree. It has green large leafs.
The leafs of it have..«
or »large black tree. green large OVER leafs of-it . DUP have..«
> I hear the arguments regarding stacks vs. registers and think... Why
not
> have the first 16 or 256 elements of the stack map to registers?
Because forth-guys would cry. There was a suggestion
: #1 dup ; : over #2 ; : swap 2#21 ; (two elements change, new order 2
1)
.. \ or simmilar
long ago. Was a teacher, reports better teaching with this.
BTW if you wan't to talk about forth, theres not only Chuck.
Search a bit for Bernd Paysan telling about people
in a german »lowest level« school learning to code in forth
successfully.. about elite ;-)
> ************* you can safely ignore this section (or everything for
that
> matter ;-)) ************************** comments on elitism continue
below...
> This leads to what I admit is an ugly notation but suppose... (and
here a
> better choice of letters or replacing them with actual words sounds
fine to
> me. A shorthand version might also exist in that case.) BTW, I got
this
> wrong which I'm sure you'll all be able to spot.
> R5 would directly address the fifth element on the stack (leaving it
on the
> stack.)
> A5 or @5 might indirectly address memory pointed to by the fifth
element.
> U9 to use it like A9 but also removes it from the stack.
Chuck is really very very silent, it seems.
Since some years he added two register similar to your suggestion,
A, for addresses, and R (top of return stack) has now more features.
Both have increment/decrement, so some swapping is replaced
by having A and R too.
But you know about guys happily breaking code all few years
and community following :)
Of course is Chuck-style, (over-)minimal.
But R9 is very deep, i would limit around R4-R6.
(4 is the number of scratch-pad-registers in Amiga Assembly
conventions.)
Deeper needs names.
Want to mention using the stack helps to have the few currently
needed values »in the hands ready«, which eases focus and
factoring. Hm, theoretically..
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted