World: r3wp

Programming is not all practical, some of it is art form, and people 
have different ideas of what makes "good art".  One person will like 
the forum chat that is 2KB of source because it is 2KB of source, 
even if they can't select text and then get a right click context 
menu to copy it to the clipboard :)

That doesn't matter to them because of other assessments of elegance. 
 I just feel that my own aesthetics of what is elegant or inelegant 
are being redefined by the likes of Gmail.  I sort of don't care 
how it works when I decide to like t, I use it and notice its nice 
properties.  That gets me to the next question when I assess a new 
development platform, I ask: "how can I make something as good as 
that using your tool?"

If the answer is "you can't make something that good without a lot 
of work, but you can make something else that's not as good rather 
easily!  here's how..."  then my interest wanes, because I am only 
interested in the case of matching the best of breed programs I've 
seen.  Right now those are increasingly web apps.  And I think they're 
winning because of what I referred to vaguely as "leverage".

Too much to read, so the answer to my question might be up there 
somewhere. If it is, just point me to the time of the answer, and 
I'll look it up, but here goes:

Fork, what is in your opinion the benefit of having the application 
inside the browser?

Many things taken care of automatically.  If you like AltME but do 
not like Gmail or say Freebase, you won't agree... http://freebase.com/view/en/carl_sassenrath

Pekr has an aesthetic argument against the idea that the platform 
of the future would have lots of bloated javascript powering its 
behavior.  I am just being more practical, and don't understand why 
I would care about how much javascript is implementing the UI any 
more than I'd care how big the windows GDI DLLs are.  What matters 
is the dialect... the rest is platform I'm willing to ignore how 
it's done.

I've also argued that if I've got a browser loaded anyway (I always 
do) then REBOL having its own layer over the native services for 
REBOL/view might be smaller but it is academic at that point, as 
both are running.

I guess we could talk to Reichart and see how much time went into 
developming AltMe. Then we could find out how much time has gone 
into gMail, along with how many technologies are used in each, for 
both the front and back ends. Obviously the scale of things skews 
direct comparison.

Well Reichart believes what I am saying, hence Qtask... I am looking 
at the source and just pondering why they are solving this instead 
of having it be the general emphasis of the REBOL interactive environment, 
in the basic download people get off the web.

If you view the browser as OS, then you also have to take the bad 
with the good. Both FF and IE shut down a lot more than my OS, bad 
pages cause problems, PDFs opening can hang things, memory consumption 
makes me restrt them, etc.

That's Carl's call, and he has strong ideas about how to do things. 
:-)

Having worked both with VID and with some ajax technologies, I far 
prefer VID despite its shortcomings in Rebol 2. VID3 in Rebol 3 is 
a very different beast though and compares more directly with Cocoa 
or QT. It just doesn't compare with ridiculous javascript based GUIs.

Also, as I understand it, qtask is browser-based for acceptance as 
a product, which is not REBOL's main goal.

keep in mind that VID was largely written by Carl in about 1 week 
with a few additions later on.

As a developer, I prefer REBOL, but I readily admit that REBOL hasn't 
advanced as I hoped in some areas. e.g. the plugin has enough issues 
that a client of mine is having a new UI built in Flash to replace 
the REBOL version we did initially. Of course, the REBOL version 
took very little time, and the Flash version is costing about seven 
times as much.

Many things taken care of automatically.

It's like starting a program with
#include <all.h>
and link it with all.lib.

I see programs running in an OS with dynamic linking etc. being superior 
in every way than running in a browser. I can't think of anything, 
that's better in a browser. It doesn't mean, I dislike browsers. 
I use browsers a lot. They're good with hypertext.

Note I'm not saying that average REBOL programmers would program 
in javascript, any more than they are dealing with HWNDs just because 
REBOL/View talks to windows.

Maybe the problem is, that it's hard to get a good OS with easy access 
to the needed resources, and only those that's needed? So developers 
look for platforms, where it's easy, therefore the browser.

If a REBOL programmer need to produce a lot of javascript, we just 
build a REBOL dialect producing that code! ;-)

Or C#, or SQL, or... :-)

I am not arguing that REBOL/View should not exist.  And in fact though 
I am talking about how I like Gmail I do currently use Apple Mail, 
a native program, to read and send messages via Gmail's IMAP (usually). 
 I'm just saying that the reason people are targeting the browser 
now instead of native code is because browsers have one of the most 
important features--efficient multilingual text layout in a 2D space, 
with inline images and such.  I can't embed a YouTube video here 
in the text box... if I type in a hyperlink it's not clickable... 
right click can't copy text, etc.

That's the basic limitations of VID, not a feature. None of these 
limits will be here in VID3, so if you want to look at it as VID3 
vs. the webbrowser layout engine, VID3 is a far bigger "threat" to 
it.

RE: VID3, I'm open to seeing new things.

I guess the answer, essentially, to my overall question is: REBOL 
programmers (or at least REBOL/View programmers) don't like Ajax, 
by its intrinsic nature.  Thus they are seeking to leapfrog apps 
that rely on Firefox and web standards by running on a new native 
cross-platform interface.  In the meantime, the bet is that those 
trying to maintain brittle PHP and javascript codebases will be fight 
a losing battl that will drown under its own weight, and REBOL/View 
will step in as the "real" Web 3.0.

And thus, effort is not directed by the core development team on 
browser-targeted development, though it's being pursued by those 
to whom it is of interest who also happen to like REBOL.  (e.g. Qtask)

Fork - I tell you the truth. We would all like to use REBOL for more 
than we can afford in our daily jobs, hence we are very jealeous 
to status-quo technologies, which are not cool, but popular :-)

In general, I don't like AJAX, but with HTML 5 it looks like it might 
become almost acceptable. Still, I would find it easier to generate 
such code from REBOL dialects than to write it directly. That is 
not the reason I don't do browser apps as often though.


The real reason is that most of the applications people use don't 
use web browsers at all. Most of the applications I use work offline, 
and no web interface works offline (though Google, Adobe and the 
Mono project are working on it).

http://localhostworks offline.  :)

Yes, definitely, I am advocating generative approaches... not wishing 
to generally pollute one's mainline code with javascript and HTML.

Sure. Then you can explain to the user why their firewall software 
is complaining about your application.

Or for that matter, why the address book app that used to take a 
few MBs of RAM is now taking hundreds of MBs.

Well, I am wondering how accurately I have summarized the REBOL/View 
point of, er, view above at 9:59:53 AM )

Fork, this is ok, really. I think we understand your point. Simply 
put - browser based apps are rational way to go with nowadays. You 
can run it everywhere, plus other advantages, minus some disadvantages 
...

Hey don't take my summary as a bad thing, ambition is good, I just 
want to understand the philosophical landscape... :)

yes, are ambitions are high - we are web 3.0, let's others play with 
web 2.0 for now, thinking they have something cool at hand. Then 
you see some total jokes as Sun posting their JS based desktop attempt, 
which is 10 times slower than SWISS (7 years ago View attempt without 
any optimisations :-)

and. We have, well, I have, - the name for the browser plug-in product 
- FireSide :-) We will Fire from the Side. And FireAnything is popular 
today ...

There is also no third small technology for browser plug-in, so small 
and agile as View ... so Flash, Silverlight, View .... or do php, 
perl, python, other guys have anything at hand?

So - now you know are very ambitious ambitions ... keep your fingers 
crossed for us :-)

are=our

Ok, I'll cross 'em :)

So what I'd worry about is having REBOL closed source and under control 
of a single authority structure, and then to entertwine the fates 
of the pieces together so tightly.  That could mean REBOL could have 
succeeded as a language and grown in acceptance if it hadn't been 
for REBOL/View having such high ambition for being the delivery vessel 
for apps.  Just my opinion...

REBOL is getting less and less closed source every day, and the authority 
structure is not that different than the developer groups of most 
major open source projects. Completely open acceptance of submissions 
is a nice-sounding idea, but once a project gets large they have 
to rein in the submissions just to keep the project semi-stable and 
reasonably bug-free.

If you want to really know the philosophical landscape here, then 
here are some basics:

- We trust Carl's judgement on language design - otherwise, we'd 
be using a different language.

- Most of the language features in R2 were intentional, even the 
ones that seem weird to people who are used to other languages.

- This is even more the case with R3, as the decisions made there 
have to get through a gauntlet of highly skilled REBOL programmers.

- The language features that were mistakes may not be the ones you 
think were, and most of those are getting fixed in R3.

- We value tight programming: It is not uncommon to replace dozens 
of lines of code with a just a few lines of tight code.

The correlary to that first point is that we accept the closed source 
core of R3 because it gets us a better language. If we have problems, 
we discuss them, and they get fixed. There are code escrows for the 
event of RT going out of business, Carl dying, whatever.

correlary -> corollary

I agree with you that the monolithic closed source of R2 was a problem 
that inhibited adoption. This a problem that is getting fixed in 
R3, and to a certain extent R2 as well starting with 2.7.6.

We could also mention open DevBase - all open-sourced parts are going 
to be uploaded there ...

R3 is the culmination of 8 years of experiencing what's wrong and 
right with R2. It's nature and philosophy is basically the same (small, 
simple, lightweight), but there are improvements in almost every 
aspect of it. I don't expect R3 to be feature and design complete 
probably for another 6-12 months as there are still many things missing. 
R3 is the third attempt at REBOL. The first one was about 30 times 
slower than R2 and ate much more memory, because the design philosophy 
was different (Carl didn't implement R1). With R2 we had the right 
philosophy in place, but the implementation lacks in many areas, 
and it has many bugs. With R3 we're getting much closer to fulfilling 
that philosophy with design from long experience with R2, openness 
and richness without the bloat.

There are code escrows for the event of RT going out of business.

 Isn't that only for big customers that had signed special contracts 
 with RT ? What about us ? In the worst case, will REBOL be open-sourced 
 or will we have to trash all our REBOL apps and go learn a new programming 
 language ?