>>>>>>>>>>>>>>>>>> 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
> 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?
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
> > >instead of black boxes...
> >
> > If I understand you correctly, you are opposed to libraries
> > as they dumb down users who could potentially be learning to
> > be better programmers by examining scripts and building from
> > examples rather than using a black box.
> >
> > 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.)
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..
