Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Rebol SDK vs Command

From: henrik::webz::dk at: 16-Sep-2007 17:57

On 16/09/2007, at 1.58, Carl Read wrote:
> On Sunday, 16-September-2007 at 0:46:19 Gabriele Santilli wrote, > >> Carl Read: >> >>> From RT's POV, staying proprietary might look the easiest way to >>> make money >>> from REBOL, >> >> That's not the reason why R3's core is not open source. > > And the reason is? I can think of others, such as it containing > licensed code from sources other than RT, or that RT has made > promises to customers that they wouldn't open-source it. Or that > they're just stubborn on this point. But you didn't say why, so I > guess you're not allowed to. Thus we waste time guessing...
To keep others from meddling with the language. It's that simple. And yes, if it were opened, people WILL meddle with it in directions that could quickly move it into a corner, feature wise, so you can't do this or that with it. You can't avoid forking or design by committee as seen in so many open source programming languages. To be frank, how many coders out there can outsmart Carl Sassenrath and code a better REBOL 3? If people say, they won't use REBOL, because it's not open source, then they will likely not spend time on it anyway in order to understand the way the language is designed, and then just use it as a traditional language; For them, REBOL gives no added value and they might as well turn to Ruby or Python. I've had this conversation with some open source enthusiasts, and it goes exactly like that. They will not accept it as anything but a Ruby/Python alternative and completely ignore the features that make REBOL unique and powerful, not as a language, but as a platform. Same reason, why I was asked why we didn't use GTK+ for the UI rather than write our own VID3. It would be nice if the open source crowd (particularly the GPL crowd) were a potential audience, but they can't be that, unless they are willing to go truly in depth with the language and try to understand it. The commercial opportunities for RT would likely be in products like IOS, not the language itself. I don't know the plans, but I hope and expect that R3 will be much less costly than R2, perhaps completely free. And let me tell you this: R3 builds on the 7-8 years of experience of R2. I've used the R3 alpha since early July, and one of the big differences here between R2 and R3 is that almost anywhere in R2, where you have a limitation or a design flaw, be it ports, async, tasks, file management, error handling, graphics, sound or hardware, those flaws are simply gone in R3 or will disappear over the course of alpha and beta development. Not many shortcuts have been taken. Redesigning the graphics system has made it a breeze to use along with VID3, where you in the old VID constantly bump into limitations and bugs and have to spend hours and hours of hacking to achieve a certain functionality, if it's possible at all to do, due to the hardwired nature of the event and graphics system in R2. We won't get everything with 3.0, but be sure that the limitations are far fewer than with R2. This opens a subject of post-beta development that leaves the argument of open sourcing the core language in the dust: The question of how fast the peripheral capabilities of R3 can be developed. Porting to other OS'es, building drivers, the Wildman project, additional documentation and cookbooks. This is almost only a question of how many smart people you can find and put on these parallel, almost autonomous projects. The pace of integrating R3 into your environment will no longer be decided by RT, but by you. There is going to be a _lot_ of work to do: Easily everyone on this list can have a job to do, and the members of the core R3 team already have their hands full enough that there is going to be need for extra help soon. I'm betting personally that with around 50 people, we can support and maintain the 40 advertised platforms by the end of 2008, plus have better integration into each system, and all of them will have proper documentation. This leaves RT to focus on the core language and their commercial product endeavours. -- Regards, Henrik Mikael Kristensen