:-> In comp.lang.tcl, bevan@cs.man.ac.uk (Stephen J Bevan) writes:
:In article <CwvHKH.A60@apollo.hp.com>
: sommerfeld@apollo.hp.com (Bill Sommerfeld) writes:
: In article <RSANDERS.94Sep27065835@hrothgar.mindspring.com>,
: Robert Sanders <rsanders@mindspring.com> wrote:
: >To me, Scheme's one fault as an extension language is its weak set of
: >string manipulation primitives. I write many programs in perl that
: >I'd like to write in Scheme.
:
: Actually, I'd say the main failing right now is a lack of standardized
: functionality encompassing that found in the ANSI C library, POSIX.1,
: and BSD sockets. This does not have to be (and shouldn't be) part of
: the base language... but it *should* be a commonly-implemented
: extension. Most, if not all, of this is in perl already.
:
:Can you point to a language which has the facilities you want and for
:which there is more than one implementation of the language (e.g. this
:rules out perl and tcl)? Alternately if you are happy with only ever
:using a single implementation of a language, then why not just add the
:features to -an- implementation of Scheme and forget about
:standardization (it seems to work for perl and tcl!)?
You seem to think this is a bad thing. Let me show you how it isn't.
If you intend to cavalierly disregard any sort of standardization
whatsoever, then it may disappoint you when create programs that you'd
like everyone to use, but they can't be bothered because you can no longer
distribute your software as is and hope someone's going to be able to use
them without a lot of fuss.
Do not assume that because there is One Version of perl and tcl that these
are somehow non-standard. They are, as SJB pointed out earlier, de facto
standards. This is not necessarily a bad thing. In fact, in these cases,
I'd argue it's a good thing. Thing of the problems people have in porting
C, C++, or even awk programs due to the multiplicity of incompatible
implementations out there. When you factor in differences in allegedly
standard libraries, then you have a real nightmare on your hands.
The most frequently heard complaint about Scheme (to my ears) after its
fingernail-clipping syntax is that you just never know *which* implementation
something's written for. This really doesn't seem like a "feature" to me.
perl and tcl avoid this by there being just one implementation. Oh, each
have quite a few library extensions that folks have written, but I don't
really think that counts as an incompatible extension to the base language,
as it doesn't touch the base language. Likewise, if you have a v5.0 perl
program it's not likely to run on a vintage v1.0 perl interpreter, although
I'm pleasantly surprised to add that the reverse does tend to be far more
true than you'd imagine.
It's true that in their most recent revisions, both perl and tcl have
"broken" a few things. That's because their respective authors were
given, in effect, one final opportunity to "do things right" before so
many multitudes were using that they could never "fix" the core language
again. I think it's actually too late for that, in that there are still
going to be too darn many complaints, but at least it's something. As L.
Peter Deutsch stated in his keynote at the USENIX C++ conference in April
(titled "C++: A Better C -- for Whom???"), compatibility with previous
previous versions was incompatible with good language design. [See the
recently arrived October issue of the USENIX ";login:" Newsletter for
summaries of this and many other talks.] I concur that blind obedience
gets in the way and ends of annoying critics who don't like to see the
idiosyncratic historical remnants left lying about, but wanton disregard
for the past makes enemies of your software's real users, rather than
merely its critics.
I suspect that Python was more designed at its inception than either perl
or tcl, given its author's experiences with ABC. I haven't played with it
much, but I get the feeling that despite the brevity of its existence,
it's altered less in syntax and semantics that the other two mentioned.
This may someday become significant.
If you really want to write text munging programs in something other than
perl (or Snobol :-), then you're going to have to work a lot to develop
non-standard library primitives to your pet language, whether it be C++ or
REXX or Scheme or whatnot. Face it, all matters of aesthetics aside
("Blasphemy!" I hear Steve shout) perl's virtually ubiquitous, and unless
you're a visionary with a great following (or Microsoft), your little
hacks aren't likely to catch on. People are going to be much more likely
to run something standard. And in these days of increasingly many de
facto workstation sysadmins, most people simply don't want to mess around
with tedious installations of a myriad little compilers, interpreters, and
whatnot.
Now, I can turn around and say much the same thing about tk with regard
to windowed programming.
Given the mutliplatform support for both of these, I don't see them
being successfully supplanted from their dominating positions in their
respective domains in the immediate future.
On the other hand, it's certainly true that there are plenty of perfectly
valid, special-purpose reasons to write in something else. You might need
to fit your program in a toaster. It might need to be real-time. You
might just *HAVE* to interface with some funky library in something
moderately bizarre language like say tkprolog that won't translate into a
reasonable C or plain ASCII pipe interace. Maybe you need to write this
code for some expert system hidden on a MUD somewhere and driven by a
FORTH compiler. You just might be the only person to ever read, maintain,
and use your program. You might still be using Sunfools.
But I submit to you that these are *not* overwhelmingly common cases.
it's pretty easy now in v5.0 to load in your library modules. These get
dynamically loaded (if your architecture supports such). They may be
written in perl, a foreign language (assume C), or in fact a combination!
You may embed your script in a C or C++ program, and use cc -lperl to use
a shared library. As for POSIX, sockets, and the rest, you don't have to
just come close to having them in perl. You can have the "real things":
use POSIX;
use Sockets;
$fd = POSIX::open("path", O_RDONLY, 0666);
# or import the POSIX::open() into your namespace and just
# call it open() then.
See the posix.t test suite in the perl 5.0 source distribution to see just
how clean and straightforward these can actually be for their users. (You
may not want to see how the POSIX stuff is actually implemented:
bilingually, parts in perl, parts in C.)
:Note I've directed followup's to comp.lang.misc since this issue isn't
[Tom wonder's what S'teve mean't by "followup's" :-]
:Scheme specific.
I'm going to temporarily expand the newsgroups line again, as the
discussion crosses many boundaries, but direct followups back to
comp.lang.misc just in case. If someone picks this up and thinks their
particular response should stick around in one of the listed groups, feel
free to edit the followup lines appropriately.
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker tchrist@mox.perl.com
The only disadvantage I see is that it would force everyone to get Perl.
Horrors. :-)
--Larry Wall in <8854@jpl-devvax.JPL.NASA.GOV>