World: r4wp

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" ;-)

AdrianS: thank you for the Trello link, after a few minutes playing 
with it, I think I like it as it matches pretty well how I manage 
my own tasks on paper. I will test it further to see if I could use 
it for moving my personal tasks from paper to an online public place.

some problems where having an array  would come in very handy. (So 
I have the allocate sought out but I am not sure of the free, and 
my progress is really slow now). I am generally considered a good 
programmer by colleagues but there are specialities and different 
leagues, I am not playing in. :D 

R3 and Red both need each other to make the best case for both of 
them and attract a real momentum. Both need very much the same best 
solutions, yet there are differences to live with.

First line got dropped somehow: Agreed with NickA here. As much as 
I like to contribute time and random to Red/system, I face

(@Kaj, I know you added bindings for random :) I am doing it as a 
project for me to learn from).

Kaj: you'll have refinement and paths support tonight for the runtime 
lexer. I will add some more interpreter tests tomorrow and prepare 
for a new release (0.3.2) this weekend focused on the addition of 
the interpreter.

Arnold: you'll get your new blog article in a couple of days. ;-)

Also we need additional tests on Linux-ARM platform for regressions 
before the release, anyone?

Ok, got refinements and paths supported now in the runtime lexer, 
but I found some regressions in the interpreter wrt to set-paths 
evaluation.

Kaj, got your tickets fixed, if you have more of the same kind, just 
report them here, not need for a ticket. Like this one:

red>> a: 1 + 1

*** Runtime Error 1: access violation

weird bug indeed :-)

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


Not always. R3 isn't done yet either. Remember, we're still catching 
up with a 2-year backlog of pending design changes. Some of its design 
experiments have turned out to be bad ideas for reasons that weren't 
known at first, or in some cases discovered by Red. So sometimes 
R3 is the one that needs fixing, and much sooner because R3 is going 
to get to 3.0 long before Red's design is set.


There are real advantages for Red and R3 to declare that incompatibility 
in comparable situations should be considered a bug, especially then 
it comes to syntax, and sometimes when it comes to semantics (ie 
indexing). But I don't assume that either R3 or Red in in the right. 
More often these incompatibilities are a sign of things that haven't 
been fully thought through, and once they are it could be R3 or Red 
that needs fixing, or in some cases both.


But, in the scale of history, Red is much earlier on in its design 
process than R3 is. R3 is more towards the end, closer to release. 
So that means that any changes that might break the *core* semantics 
or syntax of user code need to be made very soon, before 3.0 comes 
out and sets the standard. Red can afford to make those changes later 
because it isn't anywhere near the point of standardization. So if 
there are design flaws in R3 that might be comparable to something 
that would affect Red, they need to be fixed earlier in R3 (not by 
the Red people unless they're into that). And it would be useful 
for Red if people would participate in the R3 design discussions 
for stuff that would affect Red too because Red would benefit from 
the discussions regardless of compatibility, and also benefit from 
being compatible with the results.

and btw - R2 and R3 are incompatible already, so why to bother so 
much?
 - see my post in !REBOL2.

Pekr: we don't have much regression tests for the interpreter yet, 
so regressions might have happened during the last set of interpreter 
changes. Also, some edge cases have not been tested yet, we'll probably 
find more of this kind of bugs soon.

I wish I could switch to a more TDD approach asap.

I've been trying TDD out for R3 and it works pretty well. I usually 
have to expand or change the tests afterwards based on stuff learned 
while fixing the problem, but as long as you're OK with that it works 
great.

If you are a TDD purist and insist the the tests not be changed after 
you do the fixes, then the process fails horribly.

I am sure everybody here is really looking forward to that next blogentry!! 
:)

The tests reflect the specification, if the specification changes, 
the tests must follow.

Ah, so you are doing spec-driven development. For TDD the tests are 
the spec.