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

[REBOL] Re: object funnies

From: joel:neely:fedex at: 19-Oct-2001 7:36

Hi, Andrew, Andrew Martin wrote:
> I wonder if it would be a smart idea to make a scanner function > that looks inside nested blocks for a object! spec and adds any > set-word! to the start of the object's block... >
It sounds like an interesting group experiment, but see below... I'd personally prefer an object checker that simply takes an object and identifies those cases when out-of-context words are set. The proliferation of cases where we have multiple ways to do the same (or worse, slightly different) things makes me just a bit paranoid for a couple of reasons: 1) The more we hide (from newbies or ourselves) the areas in which RDIOT (REBOL Does Its Own Thing), the more we increase the likelihood that its unique behaviors will take even more time to figure out when they do emerge. 2) The more we have proliferations of slight variations (if you'll pardon the alliteration ;-) the more details and exceptions we have to remember to get our code right. I'm not sure that the marginal value added by make function! [][][] vs. function [][][] vs. func [ ][] vs. does [] (just to give one example, I'm sure everyone can immediately think of other cases) is really all that much compared to the value of tidying up some of the needless inconsistencies. Frankly, this all reminds me of a statement I heard years ago: "FORTH is not a programming language; FORTH is a programming language construction kit!" Perhaps there's a reason why radically extensible programming languages have never made it to the mainstream (especially when used in the most radically-extensible style) -- it becomes all too easy for the code for each application to become in effect its own private language. In the long term this poses risks to the safety and stability of maintenance efforts. To be fair, I recall the "shoebox" quotation in which Carl described REBOL as a language for "programming in the small". If we expect to use REBOL only for relatively short, throw-away scripts, then this isn't an issue. If that's NOT how someone wants to use REBOL, then there seem to be a few choices that have to be made: 1) Excercise self-discipline and avoid radical use of extensibility, so that any REBOL programmer (including the original author after at least one nap or long coffee break ;-) can pick up a piece of code and understand it quickly and maintain it safely. 2) Have some widely-used means of creating re-usable units of code (components/modules/packages/...), whether delivered by RT or created by the community, so that semi-standard extensions can be widely (and consistently and conveniently) deployed and used. 3) Have more docs and examples of the cases where RDIOT and how the conceptual model of REBOL differs from more "familiar" languages. (I'm working on some ideas here and hope to provide some results in the near future.) I'm not suggesting that REBOL "should" look more like any particular other language, but simply making a practical observation -- most of the high-skill/high-performance programmers of my acquaintance are quite comfortable with multiple languages and the use of multiple languages as specialized tools within a single task. They tend not to be willing to: 1) devote themselves to a single language for everything, nor to 2) spend lots of time experimenting and trying things out and running into dead ends and solving syntactic or semantic puzzles just to develop proficiency in a new language (at least not unless there's some REALLY big payoff). This brings me full-circle to your suggestion above and my first response. The open-source community thrives on competitive evolution of ideas. People try things out and, over time, the more useful, reusable, learnable, (etc.) ideas tend to become the norm within that subculture. In such a context, your suggestion regarding a variation on the process of object-making would get debated, tried out, praised, criticized, etc... until the community converged on a way to address the issue in a consistent way. We don't seem to have such a mechanism here. For example, we've been intermittently talking about MAP for almost a year and a half on this list (at least, that's how far back escribe can find references). Several of us have (re)invented variations on that theme, yet once the discussion dies down, it's forgotten. We have no way to get this into any forum where we understand its progress (or lack thereof) into the language or a "standard library". The same could be said of many other specific proposals/discussions. Soooo... In the absence of such mechanisms, I tend to be fairly conservative and minimalist in terms of what I have time and attention span to think about or experiment with. PLEASE let me emphasize that I'm not being negative or critical of your suggestion, but just trying to raise what I perceive as some practical limitations to our ability to experiment with REBOL... Thanks for listening to the rant! ;-) -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;