[REBOL] Columbus would have loved REBOL [was Re: What language am I looking for?
From: joel::neely::fedex::com at: 15-May-2001 9:14
Hi, Ken,
Ken Anthony wrote:
> When a language is put into the class of 'scripting language' it's
> use is assumed to be only for very small projects. Why is that?
>
I'd suggest that it's because many of the early "scripting"
languages
(e.g., sh and tcl) were implemented without ...
1) ... attention to brute-force performance; therefore don't handle
mass amounts of bit-crunching as rapidly as most conventional
programming language implementations,
2) ... commonly-known scalability features; therefore are much more
amenable to one-person, get-your-head-around-the-whole-program
tasks, instead of multi-person, long-lifetime, coordinated-
project, large-scale tasks,
... and that was OK. There are lots of tasks that can be
effectively
addressed with a little bit of "glue" to tie together the useful
behavior of other independently-written utilities, especially in the
do-one-thing-well-at-a-time Un*x world. When you're optimizing the
design and/or implementation of a notation for rapid-turnaround
plug-this-into-that-and-kick-it-off tasks, there are some kinds of
overhead you may choose to live without.
> Is there some intrisic reason a language must be so limited?
>
Intrinsic to a specific language? If you design/implement it that
way. Somehow intrinsic to the fundamental notion of "language"?
Not really, but I truly believe there are tradeoffs in how our
heads work -- see the sig below.
> I think of languages of having only two intrinsic levels, machine
> and virtual machine. Everything else seems to me to be an artificial
> limitation. I'm not speaking here of the limitations of languages,
> but rather, our own limitation in our perception of them.
>
To me, even THAT ("machine" vs. "virtual machine") is artificial and
arbitrary. If you write some ...
- XML processing specifications, fed to
- an application-specific dialect, on top of
- conventional REBOL, that is supported by
- an interpreter written in C, compiled to
- an assembly-language programming model, running on
- a microcoded CPU, implemented in
- circa 2001 microprocessor circuitry, realized by
- quantum mechanics
... which of those is the "real" machine, and which are "virtual"?
I was teaching 15 years ago that the traditional hardware vs.
software vs. data distinctions from the early days of computing
are outdated notions. They are simply relative to the task at
hand.
1) "data" are what want to manipulate,
2) "software" is what I am writing,
3) "hardware" is what I can't change about the environment
or mechanisms for my task.
And if I indulge in metaprogramming in an extensible language,
such as LISP, FORTH, or REBOL, the boundary between (1) and (2)
may be wiggling around during a single act of programming!
Finally, my experience is that most adjectives people use to
describe programming languages are either arbitrary or refer
to a spectrum rather than a binary decision.
> Many scripting languages are typeless for instance. Rebol is not.
>
REBOL has typeless "variables" and (fairly strictly-) typed data.
In my experience, this is fairly common among language designs
intended for interactive interpretation. Or did I misunderstand?
> So what are the barriers that prevent it from being capable of
> major applications?
>
1) Difficulty of "code sharing" in objects -- Every REBOL object
must contain a copy of its own "methods".
2) (Current, at least) limits on interoperability with other
languages -- One can mutually cross-embed e.g. Perl, tcl, and
c within each other, to construct an application using the
strongest features of each.
3) (Current, I fervently hope) level of documentation -- A typical
programmer on a heads-down, mission-critical task needs to be
able to focus on progress toward goal, not figuring out the
subtleties of the language by trial-and-error experimentation.
Remember the early days of Java?
4) Performance -- Possibly less of an issue when (2) goes away.
> Can they be overcome by intelligent (and
> careful) expansion of it's core features?
>
Only to a certain extent. After some point of diminishing returns
I've always found the effort of learning more "features" of an
all-things-to-all-people language more trouble than that required
to learn a new small language tightly focused on the task at hand.
> I want to do everything in one language (a fool no doubt) and
> have my challenges be the barriers I have to overcome outside
> my language, not from within.
>
Not a fool, but certainly an optimist! Look outside of programming
for the experience of other disciplines.
The only absolutely extensible "language" I know of is Mathematics,
where you can make up notation suitable for the task at hand. But
the various sub-branches of Mathematics have evolved their own
local dialects
for the various domains of activity, and haven't
solved the problem of universally-consistent notation.
Physicists, chemists, and biologists are all presumably dealing
with the same external, objective, real universe, but the issues
with which each discipline deals exist on such different scales
and levels that their "languages" for describing what they are
doing are radically different.
If the only thing we ever did with computers was number-crunching,
it would be perfectly OK for every other language to look like
FORTRAN. In the 60's and 70's there was lots of attention given
to "application-specific languages", and our discipline suffered
from several cases of premature spec-freezing. By the time a
newly-specified language could be implemented, our understanding
of the problem domain had matured/changed enough that the ideas
frozen in paper specs were no longer even vaguely optimal.
The promise of extensible languages (such as LISP, FORTH, and
REBOL) lies not in whether they (and their implementations!)
are guaranteed to contain adequate concepts and mechanism for
all programming tasks for all times, but in the fact that they
allow us to conceive of new ways of expressing ourselves. Such
flexibility/extensibility has a cost in notation and/or raw
performance. Once our experiments have converged on a set of
capabilities that are sufficiently well-suited for a sufficiently
widely-perceived area of activity, the result is usually that
the relevant concepts get distilled into a more tightly-focused
language with less (conceptual and implementational) overhead.
If you'll pardon a severely US-centric analogy...
Pioneers went into the primeval forests with axe and flintlock,
and lived for the adventure of seeing things never seen before.
The following waves of settlers cleared fields, planted crops,
and built towns. We, their descendants, now want interstate
highways, gas stations, municipal electrical, water, and sewer
utilities, cable TV, and high-speed Internet connections.
When I'm in scheme-and-dream mode, I *want* an extensible,
expressive language. When I'm in get-the-production-server-up-
-and-query-that-billion-row-database mode, I *need* a language
implementation that is highly performance oriented, for at
least *part* of the task. Pioneer programmers dream up new
territories that are colonized, and then permanently inhabited,
by later generations of applications and users. (And, depending
on the task at hand, I live all along that spectrum.)
Thanks for the stimulating questions!!! I hope my musings in
the vague direction of answers aren't too tedious/boring; they
reflect my attempt to think about where REBOL fits into the
world(s) I live in.
-jn-
--
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
