World: r3wp

That said, I'll probably use R2 as long as it is working on new platforms 
versions for the existing apps. R2 will always be a very valuable 
tool for prototyping and daily scripting tasks. But I'm now considering 
other choices for my future projects (especially for business projects).

Maarten has moved to Scala

Scala has a lot to offer, especially for server-side. It compares 
very well with others, its main issue is just that it's not REBOL...so 
not easy to wrap a REBOL-addicted mind to it. Besides that, it is 
very promising.

To make things clear for all, I'm still actively working on Cheyenne 
and CureCode. I have a long todo list for both of them (including 
new frameworks for Cheyenne) and intend to continue with it.

Btw, to clarify also other things, "switching to R3" by porting Cheyenne 
(which by itself would took weeks), would put me in difficult position 
where I would have to maintain 2 versions of Cheyenne (R3 version 
and R2 for all my installed personal and business webapps). Making 
a full switch (porting all my web and native apps to R3), would require 
*months* of work. I currently have around 12h a week (7 days) of 
free time for non-business projects. So, "switching" to R3, would 
mean stopping all evolutions on all my products during months, maybe 
a year until I can port everything to R3. This is not an option for 
me.


So, only a "R2 feature-complete" R3 version could make that doable 
in an acceptable time frame (and with much less risks of regressions). 


And all this huge work for what gain? Well, without threading, almost 
none (to be fair, maybe a little bit lighter source code base).

Ok, no business case for porting Cheynne ...

To be completly honest, I didn't decided yet if I'm ready to spend 
another decade with a new closed source Core as my main programming 
tool.

Here here.

Rebol is a mistress.

I'm addicted to the philosophy of "natural language"  cause that's 
what I develop, and how i got started in programming in the first 
place.

I've tried so hard to leave Rebol, but as you see, end up coming 
back.

Actually, I would say that FOREACH works with map! (= hash! traversing) 
and extensions are better than /Library. No host kit required.

Oh.. nOO!  Dock don't abandon us, scala is bad, rebol is good  ;-)

Will: I'm not leaving, I'm still here, at least as long as R2 obsolesence 
prevents it from working. It's just that my future projects will 
be most likely based on a open language with a large community. Not 
every programming language is good for all jobs. Btw, sometimes it's 
good to change your horizon to discover new things. Being in the 
position of a newbie can be funny too. ;-)

I hope you mean "until R2 obsolensence prevents it from working .."

And Scala-made-anything is not applicable to the same use case as 
Cheyenne, if only because of the RAM and disk space overhead.

Graham: right, I've mixed up my fingers while searching how "obsolensence" 
was spelled in english.

Not to say that a Scala-made web server written by Doc wouldn't be 
cool - it should just be called something else.

Graham was saying "as long as" -> "until" :)

Brian: I'm using mainly FIND, NEXT, BACK, SKIP to navigate in hash! 
values. Hash! type is supposed to be a block! (inheriting all series 
navigation capabilities) with fast lookup times, so I've always used 
it like a block!. That's why I feel like I've lost something with 
map!.

Brian: yes, that one too ;-)

It's spelled obsolescence :)

Same as in french, that's why I couldn't find it easily in an english 
context while searching in google (my browser has french as prefered 
language).

Terry: I know the feeling.

Lookup for the map! type is very fast, but there is no inherent persistent 
ordering (in theory). However, code that depends on hash! (or list!) 
will need to be changed to use block! or map!. You might want to 
go over your code to reoptimize it too, since some easy-to-use functions 
were not formerly used because they weren't optimal, and now they 
are.

Extensions are better than /Library

  True, Extension are more powerfull, but for simple DLL mappings needs, 
  it's overkill and too costly in maintenance (you have to code and 
  maintain C code for each platform instead of a unique REBOL code 
  base). Again, I can't understant why /Library code cannot be ported 
  to R3 and why we're loosing a valuable feature.

I can't comment on that; I never found /Library to be valuable, it 
was too limited for me to use.

actually, we can build a /library extension in about an hour.

on windows, at least.

Brian, do you have any application code out there with a user base?

brianH, /library is absolutely required for ANY real REBOL application.

I mean something that actually has to be used in the field with a 
moderate amount of seamlessness.

It was never good enough for my purposes. My purposes aren't typical, 
so "I can't comment on that".

I've never need to wrap a C library, but I have to wrap libraries 
written in other languages all the time. Languages without C interfaces.

So, real world developers have different requirements

Yup.

Brian: I can't see how my code would be more optimized with map than 
hash (but I'm not a map! expert). For example, mime types lookups 
are made using a 1<=> N flat structure stored in a hash!.

make hash! [
	image/bmp	bmp
	image/gif	gif
	image/ief	ief
	image/jpeg	jpeg jpg jpe
	image/png       png
	image/tiff	tiff tif
	...
]

How can map! handle this easier than hash!? (looking up a mime-type 
based on a given extension)

I agree with BrianH, that /Library was kind of limited. Extensions 
are better, although more difficult for novice to use. Somene (Ladislav?) 
proposed to make kind of /Library interface as an extension for R3. 
And IIRC, Max worked on some automatition ...

Different from each other too, as I am also a real world developer.

Brian, what kind of software do you build? just curious 8-)

Mostly development tools and server-side apps.

Were you salaried?

Max: that would be good (with support for UNIX / OS X too), unless 
it requires to wrap a big 3rd party library?

server-side stuff for huge traffic sites? I thought you were in the 
qtask team

In theory it would by possible to make an extension that could implement 
the /Library dialect, or a better version of it.

Salaried: Yes, on occasion. In the Qtask team: Not since mid-May.

doc, on windows, its easy because we can load and map functions on 
demand.  the only complexity is to build a proper structure dialect.

This is way off topic - switching somewhere better.

I was looking at using some of the windows speech recognition stuff 
via /library  earlier today. Accept voice prompts, and push to a 
web page via sockets.

Playing with PowerShell for the first time as well.  Has some promise.
The speech recognition in Windows 7 is world class.

R3 as an academic white paper is great. But I've learned that building 
stuff nobody wants is a waste of life. (Paul Graham agrees)

Without R3 being completely open source, in this day and age, is 
soo 1984. And if the 'killer app' is a webserver, and that web server 
doesn't plan on using R3, then it's not much more than a hobby.
But hey, nothing wrong with having a hobby.