Columbus would have loved REBOL [was Re: What language am I looking for?
[1/1] 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