World: r3wp

Rebol does require a different mindset if you want to get the most 
out of it


It's what I call the Zen of Rebol. I think it explains why it's taken 
me years to really "get it". I'm still learning of course. In a way, 
I wish I'd not had a backgound in procedural languages before Rebol.

I find myself changing the mindset with REBOL every few years, because 
for a long time I was afraid of for example, using PARSE. PARSE is 
so central and important that it can change the way you work with 
REBOL, if you have stayed away from it. I had the same experience 
when starting to use the SDK and when starting to do networking stuff 
in REBOL to let scripts communicate with eachother.


It's not just a new set of ideas that turn up that lets me add to 
existing scripts, but doing the same scripts in entirely different 
ways. I feel I know about 30-40% of REBOL. :-) It's so damn deep.

I'm still afraid of ports and the event system. :-)

Yes, I can only swim so deep before I run out of air :-)


I read a snippet of code related to the system object and think, 
Wow! I didn't even know that existed.

As you say, Parse itself is such a powerful thing. What I find inspirational 
is to sit down in front of the console and just explore ideas.

REBOL is like a little, magic and very deep lake high up in the mountains. 
It doesn't look much on the surface, but you'll be surprised, again 
and again.


It's a good exercise (maybe not for the totally newbie) to read some 
of the scripts, Carl has produced. They can be found e.g. in the 
Library. You find things like this one, that I trampled over in his 
color-code.r script:

set [value new] load/next str

load/next ... !!?? cute! :-)

to not speak only in superlatives, there are also some darker corners 
though. One of them being REBOL's isolation. There is nearly none 
linkage to external technologies. The reason is, that so far /library 
interface is imo "weak", and commercial. While with most other languages 
you will find links to things like non-odbc, direct db drivers, via 
libraries, or wrappers to some other libraries, such things are nearly 
non-existant with REBOL, not to mention stuff like ActiveX (COM) 
integration etc.

Thanks everyone for your prompt and honest comments.


Why did I join this community? The primary reason is to be part of 
a small, smart and passionate group who think differently, which 
when combined with REBOL is a very powerful combination. Therefore 
it would seem that focusing the resources of the community on a "killer" 
application leveraging REBOL3 would increase the chance of REBOL 
becoming main stream, and as a side effect possibly allow part time 
REBOL developers to become full time REBOL developers. As an example, 
think what Ruby on Rails did for Ruby. Wouldn't it be nice to get 
paid to do what you love!


IMO/E I believe it's very important for the application vendors to 
have very close and strong ties with the platform vendor so architectures 
and features can be designed and exist at the correct layer. Also, 
if something needs to be implemented in the application but really 
belongs in the platform, it can be done in a way that enables that 
feature to be migrated in the future with minimal impact and extra 
work. This seems to fit with REBOL's history of improving based on 
experience.


I'd like to think it's possible to build great applications in 3 
months, with new releases every three months as required based on 
requirements, so I don't have the time (and maybe not even the ability) 
to spend years learning REBOL. I'd also argue that for a company 
to be successful, it needs a small team to have a number of diverse 
skills which is focused on delivering the product. I mentioned when 
I first signed on that I would be interested to meet REBOL gurus 
who are in Northern California and see what happens when interesting 
(or not) people get together. Sorry for the length of this post and 
thanks for listening.

About dialects: You may not know what it is, so I'll give a brief 
real example of what I did, when adding a dialect to my database 
system. It does 3 different database operations, the details don't 
matter, but here goes:

lock-state: db/release locker-id current-object
set [lock-state current-object] db/add-object locker-id
if all ['locked-by-me = lock-state object? current-object] [
  current-object: db/advance locker-id current-object
]


This is RPC based, which means I call specific functions in the database 
over the network, pass parameters, get stuff back in return and maintain 
database environment variables. This is how you do it traditionally.

Now with a dialect, you can say something like this:

do-database [release add advance]


As you can see, it's an incredible code reduction. Same 3 operations. 
A part of it is of course that database environment variables are 
maintained internally and are not really a part of the dialect, which 
further reduces code. But I consider it a side effect of dialecting 
and makes it easier to design a uniform way of talking to the database.

Now which method would you expose to a third party developer? :-)

Henrik - in traditional environment, you could cover it with functions 
db_release(), db_add(), db_advance() :-)

Pekr, the functions would have specific and different input parameters. 
That's not required here. For example above, the 'add word, adds 
an object to the database. The 'advance word advances the same object 
to the next stage (hard to explain), but I don't have to pass the 
object again, since the dialect parser is not finished with parsing 
and keeps the variables in the air automatically.


Besides, do-database is only 1 network operation. The traditional 
one requires 3.

Why did I join this community? The primary reason is to be part of 
a small, smart and passionate group who think differently,
 -- Then you're in the right place. :-)


I love this community; it reminds me of the old MSBASIC forums on 
CompuServe, before the rise of VB.


I'm in Southwest Idaho, but have a good friend in the Bay area who 
thinks REBOL is cool, though he doesn't use it (yet).


And, yes, there are some dark corners in REBOL, and things I'd like 
to see change. It's hard to complain, though, because *almost* everything 
I'd like to change I *could* change if I really wanted to.

An important aspect of dialects, for me, is that they *don't* look 
like a series of function calls; there is often "implied state" which 
I think is powerful, but messes you up if you think in terms of functional 
programming.

Since REBOL requires a programmer to "think differently", in general 
what type of person, skill set, and/or background is required for 
a person to be a good REBOL programmer?

you must be patient, definitely, particularly when learning PARSE. 
You must be willing to dive into how figuring out how REBOL works

you must accept that it does certain things differently, because 
there is usually a reason to why it does things differently. Some 
people won't accept this, and they won't figure out the true strengths 
of REBOL and go back to other languages.

RayA; I'm of two minds on this one.  I'm attempting to show construction 
site bosses 

how to be 'good' REBOL programmers.  Very simple, data driven code 
sequences.

If you want to be a 'good REBOL' programmer, hang out here and watch 
for posts

from the likes of Anton, Henrik, Gregg, Ashley, well...most of the 
players here.


But a 'good' REBOL programmer can be anyone, in my humble opinion.

Thanks for the feedback. I'm not the "best" programmer (hopefully 
I have other strengths ;-) ), but I'm looking for different and better 
ways to solve problems and build applications. Therefore, would a 
programmer with a computer science background with NON procedural 
languages like Lisp or ML be more likely to "grok" and appreciate 
REBOL? Would it make sense to "hire" a young/new programmer out of 
college and get them involved with REBOL early so they have less 
"bad habits" to unlearn? Are any schools teaching their students 
REBOL? I appreciate the help and opinions of the group.

knowing PHP already did not help me in learning REBOL

I'll pipe up again and say anybody.  Now, if you wanted to hire someone 
that could

write say, a new LIST-VIEW or a dataflow engine, then there may be 
screening

required.  But if you wanted usable applications, I think the sole 
requirement may be
'willingness'.

I got into REBOL from years of conventional languages: assembler 
mainly, plus some COBOL.

Therefore is a persons prior background unimportant, and it's just 
more important that they are "open minded" and willing to try something 
very different and not mainstream, or dare I say it, be a risk taker? 
Also, don't some languages (and the teaching of them) encourage more 
open minded thinking? For example, ime, it's nearly impossible to 
get Java programmers to think outside their language and OO only 
mindset.


So what attracted everyone on this newsgroup to REBOL? And, in general, 
what type of applications are people trying to build?

I was an Amiga user and then anything Carl did, was interesting, 
by default. But I didn't start learning REBOL until trying out the 
View demos and the desktop.

RayA; You pretty much said what I was going to pipe up with again. 
 REBOL

encourages thinking outside the box.  So a good 'good REBOL' programmer 
is 

perhaps a little more rare, but anyone with a desire to simplify 
life is 'in'.

My first commercial app was in support of a volunteer fire department, 
the current

work is going to be 'the next big internet thing'...in a small town 
for a small town.  :)

I think, it is a plus to know functional programming. And if the 
programmer is used to do more than one thing in each line/statement, 
that will help also, when learning REBOL. Things like:

insert back tail serie somefunc + 1


is often seen in REBOL. Experience with scripting languages is probably 
also a plus. I too had a background on the Amiga, staring in 1987 
with an A500. In the 90'ies I started to explore the operating system 
more closely, and then it was natural to check out, what Carl was 
up to. Prior to REBOL, I've programmed in many languages incl. C, 
C++, 6502 ASM, PASCAL, COBOL, LOGO and sh and csh scripting. I develop 
many different things with REBOL from graphical applications, games 
and astronomical applications to tools, languages, databases, xml-stuff, 
word processor, etc. It's very few things, I would choose another 
language than REBOL to do.

The more coding paradigms you know, the better it is. Rebol is great, 
but doesn't preclude you from investing tile in other languages. 
Rebol is one of the highest level language you will find, with maximum 
expressiveness. But learning Lisp is a whole experience, and OO coding 
is kind of vital these days as well (for GUI stuff, for example). 
Anyway, I got to Rebol because Carl sold it very well  to my ears. 
I was a Rexx scripter, coding also in javascript, actionscript, and 
lua. Lua  is great, as well. Compares well in some respect to Rebol. 
Good luck.

I remember, I found it hard at first to read and understand REBOL, 
but after some time I got it. My example above is maybe a good example. 
It is evaluated like:

insert (back (tail serie)) (somefunc + 1)


So 'insert' take 2 arguments, 1. and 2. outermost parenthesis. 'back' 
take 1 argument, so does 'tail'. 'serie' is a variable. 'somefunc' 
is a function taking no arguments. '+' is an operator connecting 
'somefunc' and '1'. If a programmer can think this way easily, REBOL 
should be no problem.

I first got into REBOL on a complete whim - back then I used to learn 
and make new programming languages for fun.


If you want to understand PARSE, it helps to have some background 
in parser generators, particularly recursive decent ones like Coco 
or Antlr. You can do more with PARSE, but the basic way you structure 
parse rules follows the LL model. Knowing regular expressions will 
not help.

Perhaps a great question to ask is not what is the best language, 
but rather,  but what feels the best to program in.

That's why I'm still here :)

Rebol is...........................fun.

I hang on, because of the enormous potential in it. Something like 
Rebcode and how it's implemented shows that. If Python or Ruby were 
a hand grenade, REBOL would be a nuclear bomb. :-) Not that direct 
comparisons are appropriate.

Forgot, I used to write a lot of mainframe Rexx -- it sort of primes 
you for REBOL.

REBOL is so elegant; but it is more than a toy language designed 
for elegance....It can lift heavy weights too.

I think that REBOL "scales your mind" - that's both very god and 
very confronting.

god -> good

The fact that it's one small yet complete executable and rebol.org 
has scripts for things like XML etc. ... I have seen REBOL scale 
from netowrk management tools to e-bank prototypes to ...

Lisp let's you think thoughts previously not thought possible. REBOL 
makes you use them.

 In a way it may wreck a programmers view of the world because a lot 
 of other technologies may become.... annoying

Rebol may become your most useful asset in your toolbox, because 
it's expressiveness and its ease of use, but it will not help you 
understand computer science, precisely because it is so intuitive. 
Anyone trying to grasp the fundamentals of programming will have 
to delve in other languages and paradigms. Also, Rebol didn't spring 
from the void. It is grounded in what Carl knows and he knows a lot. 
I think the link with Lisp is obvious. Parsing comes from the BNF 
grammar. I greatly benefited from studying S-expressions. Look at 
how Lua implements associative arrays (tables), it is very instructive, 
very powerful, they are better than hashes in Rebol, (Carl has expressed 
interest in his blog to revise them). Another thing Lua got right 
is size, it is smaller than Rebol. Lua can be ported more easily, 
it is available on the palm platform for years now. Rebol still promises 
this. Learn Rebol, but don't stop with Rebol.

The integrated internet protocols in Rebol is a great strenth. S-

S-expressions shows that code is data, and data is code. Blocks are 
conceptually the equivalent in rebol. I don't know if they are on 
par, though. It's an interesting topic.

OO in Rebol is prototype based, like in javascript, actionscript, 
lua. Unlike Smalltalk or Java, which are class based.

The guru in terms of explaining programming concepts in Rebol is 
Ladislav Mecir. His articles are a must.

Carl said in his rebol 3.0 front line blog: In REBOL 3.0, closure 
functions are implemented with the closure! datatype and a new mezzanine 
function called closure. That is significant in terms of programming 
techniques.   Ladislav shows how you can achieve them in Rebol 2. 
http://www.fm.vslib.cz/~ladislav/rebol/contexts.html

The thing is, you don't have to understand advanced concepts in order 
to use Rebol. Anyone with some willingness is ready to roll some 
Rebol code. That is great, and if one continues to learn on the side, 
one wins on all the fronts.

In the preface to Structure and Interpretation of Computer Programs, 
Abelson and Sussman state 

“First, we want to establish the idea that a computer language is 
not just a way of getting a computer to perform operations but rather 
that it is a novel formal medium for expressing ideas about methodology. 
Thus, programs must be written for people to read, and only incidentally 
for machines to execute.”

Lots of the fun with Rebol comes from its readability. To be fair, 
lots of people testify the same with Ruby.

Sorry for my ramblings. I'm done now.

I'm intrigued by Ruby's ability to minimize statements (for example 
here -- http://www.softiesonrails.com/2007/5/22/ruby-101-clear-code
)  There does seem to be cases where Ruby can be more concise/expressive 
than Rebol.

Perhaps that should be concise -- the expressive I guess is the ability 
to set the condition after the action, in a way that is easier for 
our brains to parse.  Of course, the core of Rebol's expressiveness 
is that the language is built on top of a consistent, robust vocubulary 
(datatypes), though it can take time to learn how to construct the 
most expressive statements.  Ruby is not instinctively reflective 
(is this the right term)?  Now I'm rambling...

I still prefere:

shutter_clicked: does [while [camera.on? and camera.memory_available?][capture_image]]

Nice article, shows how modifiers are used in Ruby, a fine language 
by all accounts. I suppose you would resort to the dialecting facilities 
of rebol to achieve similar constructions.