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

[REBOL] Re: [RSL/UHURU discussion]

From: agem:crosswinds at: 26-May-2001 16:31

>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 26.05.01, 08:15:42, schrieb "Graham Chiu" <[gchiu--compkarori--co--nz]> zum Thema [REBOL] Re: [RSL/UHURU discussion]:
> On Sat, 26 May 2001 06:46:25 GMT > Volker Nitsch <[agem--crosswinds--net]> wrote: > >So it has to keep »simple things simple« for mousers > >with limited time/interest. > >If it succeeds, these people will prefer to look at scripts > >instead of black boxes, because this boxes are highly > >abstract things which can't be touched, only documented. > 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.
No, wrong. I like libraries. But: Blackbox-libraries have some disadvantages about whitebox-libraries. One is, i have to press my wishes through the api. This is a good way if i have to deal with tons of code. But the smaller the code, the more easy it is to change the code compared to pressing through api. And rebol-code is very small.. So customisation compares well to parametrisation. Maybe, let us compare unix-find with rebol. (except rebol can't detect file-links afaik) Unix-find is very strong. But it is not stronger for me than rebol if i have the basics of a subdir-walker. I would have patched it faster for my patterns than finding again these specialities in the man-page. Easy done with going to the part where a new file is handled and inserting some ifs and [x < size? F] and [parse read file[thru »hello« to »world«]] if i had a blackbox instead, i would need a lot of options which would make usage very similar to unix-find: read the manual, learn the options, and - well, why? The blackbox would consist of 20% subdir-walker and 80% [if option]'s. The whitebox could be 5 times smaller. Wasn't there a rule complexity grows »some bad factor« with the size? So i want to have flexible changeable scripts as a base. Contrary The standard library discussion here focuses a lot on definitive places, versioning, fixed apis, magic updates and so on. That will break my patched scripts of course. So i have to decide to go through api for the library (with 80% option-handling) or to change prototype-scripts of 1/5 the size. exxagerating? [help find] (native) shows me 10 options because i can't simply put my check at the right place. And thats only a little find, think what would be needed for a real find/deep .. then look at some 3-liner loops shown the last time for finding stuff in sub-blocks.. 3 lines to 3 + 1/option = 13 .. ok, i choosed an example which favors my point.. ;-) Additionally updates give compatibility problems which aren't really solved AFAIK. Staying backward-compatible is a nice art with a lot effort and self-restriction IMHO simple copying current script will work as good as this frees the developers do what they want for real improvements and give users more flexibility/customisation. As long as scripts are short, many stuff is short living (scripts after all) and there are good instruments to compare new versions to the original and patched versions for scripts that live long enough to incorporate librarie-updates. That means, we need a good diff and a smart searcher and »cross-referencer« in rebol to track changes, instead of smart dependency-tracking around the world. And a good library of course. But off customize-friendly prototypes. Like the old rebol.org - style. With a bit more support for the very small snippets somehow. Not of clever organised »everywhere exactly the same automatic« blackboxes. Except of the carefully designed rebol-exe of course. one update-target to track, and it changes seldom, after lots of discussions. Gives the freedom to mutate on top of that wildly :)
> If so, then that view is shared by some eminent programmers > including Charles Moore, the inventor of Forth.
<snipped Charles a bit(sorry, Chuck :)>
> And everybody has been going along > with it accepting that this is the way things are in > software and that forty mega lines of code is needed to do > anything interesting."
You are citing really chuck here, yes? Sounds like LDC and Carl talking how short and flexible rebol (again) makes code ;-) (well, i snipped chucks rambling:)
> ... > "One of the things that happened, I guess twenty years ago, > was that we had the concept of automatic code generation > otherwise known as a compiler. And this did not let anyone > write code that could have been written before but it did > let less skilled people write code than what people were > used to. So we introduced into the profession a very very > large number of very very unskilled coders. You hardly can > call them programmers. > Now this may just not have hurt a little bit it may have > destroyed our civilization. The same thing is happening in > VLSI design. The silicon compilers are attempting to do the > same thing. Let lesser skilled people do what a small pool > of experienced expensive people used to do. It isn't > cheaper. It isn't better. It's just different. > This is what the bureacrats, the executives want. They want > industrial scale workforces. Ten times as many people > earning one tenth as much. The only justification is > redundancy It is certainly easier to manage a large group of > dumb people than a small group of smart people. You can't > replace the smart people, but you can replace the dumb > people. > What our culture is doing is trying to do is build a > reliable system from a large number of unreliable parts. And > to do that you need a large number of unreliable parts." > Of course, such opinions haven't help popularize Forth!
Chuck must be joking here? He wrote lots of compilers. and i heard he can fly with his vlsi-cad through the chip in realtime 3D, dropping transitors on the way? :) *brooding*
> -- > Graham Chiu
-Volker