World: r4wp

(I will file a bug report for Brian's head ;-)

I met them on one festival where we were playing together and from 
that day I just can't stand Boron.

John needs World to become popular, because his business model is 
to sell a book about it. Karl specifically didn't mean Thune to become 
popular, probably not even ORCA. Boron was meant for a wide audience 
again, but he does not depend on it, because he's simply developing 
it for his work

I was fine with Orca.

That's cool, Rebolek :-)

Having only been exposed (mentally, not physically) to the element 
Boron, I have no prejudice against it's name. And I have a coffee 
cup with an orca on it :)

I know it's pretty stupid but I can't help myself :) That's why I 
was very glad for Red(/System). That and BSD vs. GPL.

ONE MORE TIME: IT'S NOT GPL!

Ah, I didn't know about the book. He only mentioned wanting to use 
it for his projects, which I could only guess at because of its semantic 
model. I mostly knew about it because the World features he was promoting 
the most, beyond the 256-bit value slots, I recognized as being rejected 
R3 tickets.

That's why I said that incompatibility with R3 was part of the point 
to World. He went out of his way to talk about the deliberately incompatible 
features. The only thing left to distinguish it semantically from 
being something in the same category as R2, R3 and Boron was the 
256-bit value slots. Otherwise it was pretty much the same language 
model.

Red is a different language model, of course.

OK, I understand your point

The iOS theory is reversed, though. World is aimed at science, and 
then the iOS apps came just to make money for World development

That makes sense.

Kaj: LGPL? Sorry, I'm not expert at licensing.

Yes, very different

Unfortunately, we are forced to be experts at licensing

Boron is basically like R2, but with a Lua/R3-like library model 
with a different FFI from either, at least in terms of its major 
semantic model. Syntactically Boron has gone out of its way to adopt 
more C-like features here and there. The LGPL argument is more a 
personal and social thing as far as I am concerned, it's not the 
reason for the language design choices. You can tell the reason for 
the language design choices just be seeing which choices were made 
(assuming a reasonably intelligent person).

Still, there must be some factor at play that makes Boron unatractive 
to people. I just don't know what it is.

(people - most of current Rebol users)

Copyleft, even the minimal copyleft of LGPL, is a bit off-putting 
for a development tool of a Rebol-like semantic model. For reasons 
that only became apparent later, so I'm not knocking the choice in 
hindsight because of the results.

It's mostly a mystery to me too, but my best guess is the divide 
between free software culture and the old REBOL/Amiga culture of 
mostly American business

I liked the library idea though, it was cool. The C-like stuff was 
also off-putting for me, but I can see why you'd want it to appeal 
as a scripting language to a crowd of Posix users.

So you're also put off by REBOL?

One more personal experience - I never had the same fun playing with 
Boron that I have with R3 or Red/System (practically haven't use 
Red yet).

In general I'm not put off by Rebol-like languages, but the mix of 
Rebol-like and C-like stuff usually doesn't work. Even supporting 
C-like comments conflicts with Rebol syntax in ugly ways. C is better 
in C-like languages.

You have to develop R3 in C now

The only "C-like stuff" I can think of in Boron are 'c' for character 
syntax and comment delimiters. Not exactly earth shattering

Like I said, keep the C stuff in C-like languages. C isn't bad itself, 
necessarily, it has its place. But C syntax and Rebol syntax don't 
mix well. Putting C-like syntax, particularly their comments, in 
a Rebol-like language leads to ugly syntax conflicts.

Sure, but it's hardly used in Boron

It was enough for me to reevaluate using the language. It's implementation 
stuff was cool though.

You can easily define your own COMMENT function and not use /* */

It doesn't matter now. I'll use Boron when I have to though, it's 
still part of the family :)

I just never got very far with Boron.  I donated to it when I thought 
it could be a viable open source alternative to R2, but it's feature 
set never evolved enough to be useful for work, like R2.  That's 
been the problem with ALL REBOL related language tools for the past 
6 years or so.  That's what made/makes R2 attractive.  A full stack 
of usable tools for creating applications.  If the Saphirion guys 
and Doc build usable tool sets with mature GUI, sound, database, 
3D, etc. APIs, then people will begin to use those languages.  Boron 
never had any of those features implemented in a user friendly way.

Without those features, there's no reason for anyone to take a look 
at REBOLish stuff.  It's just weird syntax, as far as they're concerned. 
 Take a look at http://www.runrev.com/products/livecode/LiveCode/
.  18 pages of feature description.  That's an attractive list, and 
I think should be read by everyone here.  It provides some perspective 
as to how much work is required for Red to become a viable competitor.

Features like that need to be provided, not created by the user base. 
 There's no motivation for anyone to get involved if the feature 
set isn't complete.

That's why, even as a REBOL user, I never messed with Boron.  It 
takes less work to learn other languages and tool sets, than to implement 
a complex fundamental feature set required to complete basic work.

R2 provides enough of a basic feature set to make the language viable, 
but without those features I would never have had any interest in 
the language itself.

Livecode cross-compiles to any platform.  I can build Windows, Mac, 
Linux, Android, and Web apps, and X-code projects, with the click 
of a button *all on my Windows machine (or on a Mac or Linux box, 
if I want).

I still think as a full package, REBOL is better, but R2 is getting 
old an losing support for new, cool features and platforms.  If Cyphre 
is succesful porting R3 GUI to Android, it's got a chance.  If Doc 
gets Red evolved enough to support basic features, it's got a helluva 
chance.

an losing -> and losing

I don't understand the push to make both R3 and Red compatible. Sure, 
if it fits, why not. But if Doc decides, that he wants Red to be 
different in some aspects, then I am not sure it is wise to go on 
compromises. The question is, if we really need to merge those two 
projects.

Pekr: merge is not the point, that is not what we've discussed with 
BrianH, Andreas and Fork. The point is just not driving users crazy 
when loading code in R3/Red because of obscure and arbitrary incompatibilities 
in the syntax. Also often the same logic rules apply to syntactic 
choices in both R3 and Red. The best example are the rules for defining 
a word! (it's not that obvious when you consider Unicode).


Also the same remark applies to some basic semantics like indexing. 
Although the level of compatibility is at our discretion, we can 
diverge when we need to. I want Red to retain the best of R2, but 
fix some of its core design issues. Some solutions found for R3 are 
improvements over R2, there's no reason for Red to ignore them. Hence 
the common work between R3 and Red projects on some parts.

That is understandable, but it almost feels like a push - either 
do it R3 way, or it is your bug :-)

and btw - R2 and R3 are incompatible already, so why to bother so 
much? I would not like for any of the languages to take on some grey 
middle consensus - just do what you think is best ...

NickA: I fully agree with you. A bare Red core has low value and 
not much potential to attract a large crowd. Actually building all 
those user-level features will be the fun part of Red project, I'm 
looking forward with great appetit to the moment I'll be able to 
work on them. Also with a solid Red core, we could provide an even 
better user experience than Livecode, which, e.g. still struggles 
to handle Unicode fully:

http://www.runrev.com/products/livecode/text-and-data-processing/


We should mention that currently it’s perfectly possible to build 
applications that use Unicode in LiveCode, but there are some limitations. 
[...] We’re hard at work adding beautiful, seamless and complete 
Unicode support for a future version so please check back if you’re 
interested in that.

http://lessons.runrev.com/spaces/lessons/buckets/809/lessons/12304-How-do-I-use-Unicode-in-Rev-

In "Using character chunk expressions with unicodeText" section:

    set the unicodeText of field 2 to the unicodeText of field 1


Wow...doesn't look like Livecode scales up very well. In Rebol/View:

    set-face field1 get-face field2

(Sorry should have posted that in Languages group)

Pekr: for the part of the R3 and Red languages that are identical 
or almost identical, it would be counter-productive to introduce 
arbitrary differences (the whole point is in this "arbitrary" word). 
I still of course keep my full autonomy for deciding on Red. Anyway, 
I know I can count on you to shout on me if I take some user-unfriendly 
decision. ;-)

NickA: there are definitely some interesting ideas in the Livecode 
environment to have in Red too. We'll "steal" the best ones. "Good 
Artists Borrow, Great Artists Steal" ;-)