Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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