Jim, I rigthfully agree that the HTMLified apporach is a band aid solution however the languages you named in this approach ARE already widely available for FREE and installed on most servers AND / OR clients.
An Symbolic Expression based language like REBOL for me is the best way forward for both client side and server side software and also lots of common programming tasks in general. However for this to happen REBOL we needs to get REBOL onto the clients and servers. Just now all distribution of REBOL can only happen via RT Inc. and they are looking to sell PAID for Interpreters like /Pro and /Command which fully enable the client and server side software. For me the best way would be for RT Inc. to unencumber these products by removing all restrictions on redistribution, ie allow anyone to download and distribute freely for either commercial or non-commercial purposes. This way REBOL can get into everywhere. Now this might interfere with RT Inc. current busines plan and attempts to get revenues but how many people are actually buying and using /Pro & /Command when they can get the same or more functionality & libraries freely from other languages like JAVA, Javascript, Perl, PHP, Python etc. These languages are all available for NO FEE and are entrenched in both the client and server sides. REBOL as a language is superior in a lot of ways. However it is currently a small minority interest and attempting charge for and limit the distribution of runtime executables is not and will not do the language any favours in my opinion. Developers use these other tools because they know they can use and distribute their software with confidence because necessary runtimes are already on the client and server or if they're not then they can be bundled with the software or automatically downloaded FOR NO FEE! With Microsoft.Net slated to become the next major development platform (and also equivalent open source clones) these will most likely be included as part of the operating system and pre-installed and paid for by OEM's , no doubt with the usual typical Microsoft persuasiveness ;-) So this is another runtime - perhaps the CLR wil become the dominant runtime who knows? - that will be extremely widely available on the client / server side so yet even more competition for REBOL. I just don't see how RT's current policy of charging for runtimes with additional features, which is quite standard and typical functionaity available already in these other languages, as well as the restrictions on distributing, commercial / non-commercial etc. is in anyway going to help US to advance the use of REBOL as a technology. Of course this affects RT Inc. as well. As to questions about how do RT In.c make money - well as far as I can see how IOS is a SOLUTION developed on top of the "core" functionalities of REBOL and how they can charge for developing, selling and supporting this "added value". REBOL/Encap is fine as a tool which lets you create "executables" but please lets drop the "per runtime" fees / restrictions. I can see how relatively small one-off fee for the /Encap program is justified as this is not a client or server runtime but a specialist tool which help creates added value for developers, however the fee should be low enough for even for developers who create and distribute "free of charge" executables to afford. I can see how they can make money by selling and developing REBOL/IOS as a valuable and much needed SOLUTION in certain identifiable target markets and they should go for this. However they do themselves, us and REBOL as a technology NO favours at all by the fees and distribution restrictions which currently hinder us all. Iam not advocating "open source" here just the right for us to be able to use and distribute the full funtionality of REBOL freely and without restriction. It is only by this way do we stand any chance of creating the widespread use of REBOL and create a market for OUR skills, and even then the competition is still very tough, more entrenched and better organised and / or financed. REBOL does stand a chance though because it is a great and powerful language tool but we have to remove the barriers which help to stifle it's potential growth. Will any of this happen? probably not! Just me spouting my two pence worth as usual 8-) cheers, Mark Dickson In a message dated Thu, 7 Mar 2002 6:02:54 AM Eastern Standard Time, "Jim Richards" <[EMAIL PROTECTED]> writes: > Thank You All, > > I, as most of you, recognized early on that Rebol has the > potential to be a real champion. At times however, you just > get discouraged at the lack of. In order to achieve real > success Rebol/Command and Rebol/View/Pro needs to be put > into the hands of developers. It is these developers, who > learn the real power of the language, that will sell the > solution to their employer or go on to develop applcations > which they can sell. > > Over the past four years I have worked at two software > development companies whose products were HTMLified. By > HTMLified I mean that the presentation layer is browser > based and under the hood is a mix of tools, python, ruby, > perl, java, javascript and the list goes on. HTMLification > is doomed for failure because it is a bandaid approach which > lacks the cohesive qualities of Rebol. > > As a Unix Systems Admin I cringe when I am asked to install > one of these applications because of the security > implications that surround them. This is where Rebol > shines. It has all of the above presentation, security and > data manipulation. > > So what's the reason for all this babble. Most programmers > or institutions are not going to spend $350. to test drive > something. They would rather spend $1,000. on Visual Basic > because it has a name and it has been tested. > > OK, I've said my piece. I am going back to learning and > coding. I just get frustrated because I see a great market > and need for a product like Rebol. > > Rebol, is the replacement for HTMLification. > > Later, > > Jim Richards > > -- > To unsubscribe from this list, please send an email to > [EMAIL PROTECTED] with "unsubscribe" in the > subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
