How can we help REBOL succeed?
[1/1] from: joel::neely::fedex::com at: 17-Sep-2000 23:12
SHORT VERSION: Benchmark REBOL vs. other languages on real-world tasks, help publicize what REBOL does well and identify what it doesn't do well (so the geniuses at RT can fix it), help figure out what a "standard library" for REBOL would look like and contribute industrial-strength components to it, help identify application areas for which REBOL has some unique strengths, help identify what's needed for REBOL to become "best-of-breed" in application areas with which you have significant experience, ... and the list goes on. -jn- LONGLONG VERSION: How can we help REBOL succeed? These thoughts are offered in the hope of stimulating some useful discussion on what (else) the (non-RT-employee) members of this list might do as REBOL accomplices. I assume that most of us who have invested time and effort into learning REBOL and would like to: - be able to continue to use and enjoy it, - be able to continue to share that enjoyment with others, - have some potential for long-term return on the above investment of time and effort (e.g., valuable job skill, ability to get work done quickly and well, etc.), or - any combination of the above. What does it mean for a programming language to succeed? It must have an active user community, be worthy of notice by trade press and book publishers, and be the subject of ongoing development and enhancement on current platforms. Both its range of application and user community must be growing, not shrinking nor stagnant. What does it take for a programming language to succeed? I won't pretend to offer a comprehensive game plan here (if I could do that, I'd be applying for a job at RT! ;-) but I think I have picked up a few ideas through 30+ years worth of programming (academic and applied) and programming languages. 1) It must have the performance to handle substantial computing tasks within reasonable time and resource limits. The "resources" include memory, run time, programmer time, license fees, and all the other things that go into total cost of usage. 2) It must have the language features required to scale well, "play well with others", and support state-of- the-art computing concepts. ("structured" programming, OOP, networking, and -- some would argue -- components) 3) There must be a body of resources available to the new user (or potential user) to facilitate rapid evaluation, orientation, learning, and expertise maturation. 4) It must either: 4a) Be demonstrably one of the (few!) best languages for some specialized, but sufficiently important, area of application. or 4b) Be demonstrably a good enough language across a sufficiently wide range of application areas that it is demonstrably one of the (few!) best comprimise languages for general-purpose programming. 5) It must have large enough "share of mind" in one or more decision-making or -influencing communities that can drive wider adoption: 5a) The business community - which cares about TCO, stability, supportability, and respectability (will my investors/board/VC be comfortable with this?). 5b) The academic community - which cares about elegance (for the mathematically- and pure computing-science- oriented), widespread accessibility (for the intro- to-programming- and continuing-education-oriented), widespread commercial adoption (for the university and college departments that have sold their souls and become glorified trade schools), inscrutability (for the university and college departments that look down their noses at anything that people who program for a living could understand), and clarity and orthogonality (for those who are actually trying to teach programming concepts without bogging down in the implementation details of the langue-du-jour). 5c) The software product developer community - which cares about speed of development, breadth of tools, speed of development, performance, speed of development, maintainability, speed of development, source code security, interoperability (across platforms and with other languages/tools), and did I mention speed of development? 5d) The sysadmin / web developer / support staff / one- shot task community - which cares about speed of development, economy of effort, and few specialized features including text processing, process and file management, and network/database connectivity. 5e) The open-source/hacker/hardcore-geek community - which cares about coolness, access to the source, attitude, and inscrutability (for those who look down their noses at anything that people who use a Microsoft O/S could understand). and (neither last nor least, but this has gone on long enough), the holy grail of software development, 5f) Some as-yet undefined community waiting to spring into existence the moment a language provides them with a compelling new concept (or impressive name, overwhelming marketing campaign, etc.) around which to rally. What can we do about all of that stuff? In order, by the numbers above: 1) Until/unless REBOL goes open source, our opportunities mainly consist of providing information to our own communities, and to RT. Benchmark REBOL vs. other widely-used languages. Figure out what works, what doesn't (yet) work, and how using REBOL properly can help performance. (Tell the second to RT, and the first and third to everybody.) Find and document ways that REBOL helps us get useful stuff done. For those things that we (individually) believe can only be addressed by changes or enhancements to the language itself (either notation or implementation), we should document the NEED and bring it to the REBOL community and to RT. For those things that we can address by high-level code libraries, I suggest that we need (with guidance from RT) some standards for how libraries can be structured, maintained, and deployed. Wouldn't it be great if we could come up with ways to manage open-source community development of "standard" libraries similar to those in use within (e.g.) the Perl and Python user communities? 2) Stress-test REBOL (and ourselves as REBOL programmers). Tackle some really big problems, some computationally intensive tasks, and some multi-programmer team efforts. Let RT and the REBOL community know where things hit the wall and where the bottlenecks are. (Also, do all the stuff under #1 above.) 3) Write stuff. Read stuff and give feedback and errata to the authors. Applaud editors. ("Hey, editor, that was a great article about REBOL in your Octembruary issue.") Pester editors. ("Hey, editor, when are you going to have another REBOL article? How about a whole issue on REBOL?") 4) Try REBOL for everything we do, the weirder the better! When it works well, brag on it. When it doesn't work well, tell RT. 5) Ask ourselves the question, "What would I need to say (or need to be ABLE to say) to get my boss / CFO / CIO / CTO / co-worker / teacher / student / kid / webmaster / department chairman / trainee / intern / ISP / local alpha geek / sysadmin / (PC/Mac/Linux/...) user group / project leader / etc. to take a look at REBOL?" -jn-