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

[REBOL] Re: What language am I looking for?

From: rishioswal:y:ahoo at: 14-May-2001 1:44

I like the fact that rebol seems to be optimized for the most frequently done cases while making unfrequently done things possible. Many language use a general approach. Take Java for example. As a programming language, Java's core concept is pretty clear and concise. But it doesn't seem to have any bias. Everything in java seems to be equally hard to do. While this makes complicated things comprehensible, it also has the side effect of making simple things ridiculously complicated. Serialization is one example. Serialization, in java, is basically a fancy name for saving data from your program (like preferences) in a file so the next time you run the program, you can load that file and start up the program based on data in the file. There are many steps involved to do this in java...and every time you need to do it, you forget how you did it previously and end up looking at the docs and figuring it out. I was blown away in rebol when serialization was basically all done with two simple functions: load and save. You basically save any data to a file by using save, and you can load that data up in a format rebol can use using the load function. It's really easy...and is something i use all the time. This is just one example...but rebol is filled with many of these examples...from parse, no operator precedence (really makes sense!), prototype based objects, vid, different kind of loops such as foreach and forall (very cute and surprisingly hand!),series (this is the best!), etc... Basically, in rebol, common things are generally simple to do, and uncommon things are usually possible, but require thought. It's kind of like evolution...animals, for instance, evolve not based on general principals...but based on the most frequently done task. regarding your questions on rewriting words...first off: 1) you can protect all system words (and user defined words) with a single line of code. 2) this also bothered me in beginning...but i've never run into an instance where this has become a problem.In my opinion, it is ok to overwrite words. Infact, if you overwrite a word with your own word, chances are that you don't need that particular word in your program..otherwise you wouldn't have overwritten it! 3) Once you become proficent with rebol, there are many ways to prevent this such as using simple objects. Regarding having to declare local variables: At first i would have agreed with you...variables within a function should be declared local...However, after using rebol, i feel that the way it is currently implemented is a better choice. By putting all defined variables in global namespace, it makes it easy for beginners to get into the language. Once you are proficient, it's a no-brainer to make variables know better.. This brings me to my next point...rebol is really designed nicely in terms of being a really simple language for beginners, but providing all the features for growth as skills increase. It has a really nice growing curve. This has yet another benefit (in my opinion): Rebol is one of the easiest languages to pick up after you haven't used it in a while! With java, c, c++ and many other languages, their are all these little details that, after a break from the language, you forget. You have to go back to the manuals each time you want program again after a period of time. Rebol has very little syntax, no really special variable declaration features, no confusing/complicated headers, no unnecessary parenthesis or semicolons, no required oo programming or function to can just start off and go...i love that. and above favorite thing about rebol is that it is hands down the most fun language i've ever used. Sorry for the longwinded english...would have made it shorter if i had time! rishi --- Ken Anthony <[kenneth--nwinet--com]> wrote:
> Great response all (GS Jones, Porter Woodward, Petr > Krenzelok), thanks. > > Scott Jones said: > > my case the emphasis is on providing the most > > productivity for the least investment of grief, > time and money. > > Absolutely!!! > > Porter Woodward said: > >I would refer you to the following article > concerning language selection: > > > > Good article, but in my mind it has a fundamental > flaw. It's conclusions > are true only if you accept it's definition of > power. What they describe as > power, I think in terms of abstraction and leverage. > In my mind the term > power is somewhat ambiguous and leads to some > confusion. > > There the author uses power in the context of > leveraging programming > productivity, in which case power equals > abstraction. Getting the most from > those 10 lines per day that research keeps telling > us we are capable of > (personally, I've had days where I've added a > thousand lines of code and > other days where I only modified one word. I > couldn't guess what my average > is) I would define as productivity, which I admit > isn't as sexy as the term > power, but I think more explicit. > > Perhaps I'm just old school, but I have always used > the term power with > regard to computer languages to mean both its > ability to manipulate every > bit in the hardware and to do it at the very fastest > speed. So when the > article says... > > >Few would dispute, at least, that high level > languages are more powerful > than machine language. > > My hand goes up. Now if you replace the work > powerful with productive then > my hand goes back to my side. > > From the article: > >"I ll begin with a shockingly controversial > statement: programming > >languages vary in power. > > Again, translating his term power for productivity; > I say, what controversy? > (I think the author was setting up a straw man.) > > >The basic argument made by the author is that you > should always > >use the most powerful language that you have > available to program in... > > I agree (on both levels); however, my contention is > that one small language > (assuming an abstraction level to deal with machine > dependancies that only > machine language or it's equivalent can bridge) can > be that most powerful > language in most if not all cases. This is my > central argument, so if I'm > wrong here, everything else falls apart. > > From what I understand, Rebol takes from other > languages, which I believe is > exactly the right approach. Which is why I also > applaud the creation of new > languages, because they give us new ways of looking > at things. I however, > do not want to use or even become conversant in > every new language out > there. I'd rather stand on the shoulders of others > that have that desire. > All, I want is that the best of these things be > folded back into the > language I use in a way that isn't disruptive to the > use of that language. > > Scott Jones said: > > I think you've already touched on one of the most > important issues that > > can affect a project of any significant size: > scope and namespace. > > Joel Neely's posts have been one's I've read with > considerable interest. A > work-around is a flaw, IMHO. Giving more thought to > local variables in > functions and I find that the syntax... > > g: func [a b /local c] [] > > wonderful. However, I also find what I've > read about scope a bit > disconcerting. I apologize for shooting from the > hip here. I usually > prefer not to comment on things I don't really > understand. Perhaps after > I've played with it a little more I'll have > something constructive to > contribute. > > Scott Jones said: > > However, let me urge some caution in what I > believe you understand that > > the runtime versions will allow. I do not speak > from authority, but > > since others have not addressed this issue, I'll > at least throw in my > > understanding. The runtime license allows for the > creation of a single, > > executable binary file that will hide your code, > but I do not believe > > that it is compiled in the sense of creating a > binary of machine code > > nor pseudo-code. If I understand correctly, it is > merely a form of > > obfuscation, likely through compression, in the > same way that one cannot > > see the large quantities of mezzanine-level REBOL > code by viewing the > > REBOL executable file directly (one of the reasons > that 500 kb of code > > can do so much). I suspect that there is no true > performance benefit in > > creating a runtime. I would ask RT directly about > that issue. > > Hey, if it quacks like a duck... Thanks, the > enlightenment is appreciated. > To me, Rebol shows a lot of Forth heritage. Forth > had the ability to > produce headless code and I suspect the same could > be done with Rebol. I > agree that performance might not improve, but that > was third on my list. As > long as the language is capable of it, it becomes > the programmers task to > wring the performance out of it. [ok, Petr > clarified this issue - see > below] > > >In terms of Rapid Application Development of a > > GUI, it is hard to beat VisualBASIC or Delphi's > approach, in my opinion. > > I agree (which is probably why I have both.) I > think a rebol RAD/IDE is > probably essential for it's long term success. But > it can wait until the > language has matured some. > > > The one other area that might become a gotcha for > you is shifting to > > REBOL's method of parsing, as opposed to the > variations of regular > > expression matching found in other languages. > > This is another area where Rebol is dead on target. > I love the way they've > implemented the parser. I think regular expressions > were developed by guys > that should go through detox. Step back and > beautiful things happen. Rebol > parser is a beautiful thing. > > > My only advice (unasked for, I know) is to > actually implement a small or > > medium-sized personal project in REBOL before you > consider tossing it > > into the bit bin. > > Hey Scott, your advise is always welcome. The fact > is, Rebol is no where > near the bit bin (or I'd stop spending money on it > or following this list.) > As far as vision, where would we all be without it? > > Petr Krenzelok said: > >Hmm, maybe it was done so to keep things "easy"? > Simply - if you want to > >define your word local, you have to state it. > > You're right Petr, after rethinking I came to the > same conclusion. The > syntax is fine, it's the scope question that still > nags
=== message truncated ===