[REBOL] How can we help REBOL succeed?
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-
