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

[REBOL] long read, sorry... RE: Re: Hitting the learning curve

From: maximo::meteorstudios::com at: 5-Nov-2003 11:09

-- pekr -- I wont't quote you, I agree with all. Many people also have different views on how everything should work and do similar tools (RSP and my own remark.r are a good example), that is ok, but then it seems, not many actually wish to use those tools once we share them. That is deeply incrusted within rebol, you like it because you can do anything the way you like it, but then you feel lost, because not many released, rugged, tested, proven, tools exist (in the public eye) on top of which you can do it. THAT is the specific goal I want to achieve with steel. provide a common gateway for all tools to integrate, as though they were all wrought of the same iron. There are many facets in order to acheive this, but hey I can't wait for no one to do it, especially not RT. So I do it, stay focused on the end goal, even if its sometimes quite (read extremely) boring to code. comments on rebol/view: ------- glass was built from the ground up using view. no vid code used anywhere. I had to learn view itself, and although I am now happy I had, cause I've created really advanced faces, it really was a pain to find all the information (some things still are mysterious). team management. ------ If I can make a parallel with steel and RT, I think we suffer from the same problem. a fairly detailed release plan with a good idea of what it -should- be. the plans are large and include many things others are doing or trying to, but which aren't integrated. So if you have limited resources, to the exterior, it looks as if its really all ground to a halt, but its not the case. most suggestions are already in the detailed specs, most can't even fathom the advanced plans I have for steel, glass and liquid, but there is so much to do before, that sometimes I feel like I'll never get to them. I'm sure RT suffers from the same problem. the main difference between me and RT is that I try not be silent (I hope I'm not too loud though). I'm giving as much of what I'm doing so that people can see where its at. I also WANT people to participate... which seems to be contrary to RT's POV. BUT alas, it seems people only want to share efforts if their name is going to be included into RT's credits. Only wishing to work on projects with RT's stamp on it. it tooks years for to get to what it is now, in the sence that I had also started to put effort in trying to get it go back live three years ago... but that never delivered, cause I was completely alone and stopped getting feedback from those who had the site's control. The PROBLEM I HAVE with the community is that many of us sit and wait and hope that either RT or some guru will create the tools they need. I agree that many tools are missing, but we should not wait, we should cooperate, in the end, even RT might use some or our code if its rock-solid. STEEL has always been open source minded, but no one seems to want to DO anything. I mean beyond saying "sounds cool", "I' might", "I think", "I hope". Only one person offered to do real concrete help with steel. and I lost his name in a computer swap which went bad, so I don't know who it is anymore (others than it was a french person, please come forwards again :) There are MANY extremely usefull tools. The real problem is that none share the same api, look and feel, or share some common philosophy. Most distribute their scripts in different forms, many aren't specifically released as code bases which are easy to reuse, or even meant to be linked to. Many scripts expect people to peruse the code and figure out how it works, or how to make it work within your code. Python and perl are success stories, because they did not depend on one holy person to do solve all miracles. They quicly setup a standard way to exchange and link code. They made it so that whoever wants to solve a specific person, can only create a linkable module which solves that specific issue and it gets ALL dumped into one archive, no matter where it came from. That way the author of the language can say, hey, they fixed that, I can work on something else. is probably the one thing that might revive the community spirit, if it lives on. Many people only acknowledge efforts if they are supported for a long time... It is a way of knowing if the effort is genuine or if its just an impulse. no one wants to use a tool that will stop being supported a few weeks after its inception. Working as a team helps a lot, especially to keep motivation. I have something in the oven which will help the community to become more united, but I am scared that it too will be just another "looks nice", "sounds cool" thing, even if it will be only be distributed in a release-level and supported state. IT would mean people adhering to a standard... oooh i said the evil word... standard. Most of us love rebol cause its not standards based (in terms of coding methods), you don't have to adapt your mind to a fixed way of thinking... but if the platform is to become more accessible and stable, this will have to become a serious consideration to those of us who build tools. surprise: ---------- I am working on a tool to help us get united in the way we release tools. I have been hacking away for a few weeks now, on and off. I'll be open to suggestions on how to improve it and will add any code that someone contributes to it, if it makes the system safer, more rugged or easier to use, once the version for peer review is released. I don't want to say more, specifically to reduce the amount of hype and limit expectation in time and features, but I am working solely on this architecture everytime I sit in front of my rebol editor... (which is not nearly as often as I'd like too)... its not the most fun thing to code, but It should help the community unite in a way that it currently is not, as long as the community itself accept the api and takes the time to adhere to it, and improve it. Robert, Gregg, the project's current version is not based on creative metaphors, altough ROCK was the prefered term when I started it, cause it represents a solid and durable material, something akin to a foundation on which you build your stuff. I have since renamed it to something more conservative, specifically due to your observations about liquid's naming making it less obvious to approach. :-P cheers! -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.