Additional unexpressed requirements and chapter 5

["Kevin Kelleher" <address@hidden>]

Kurt B. Kaiser said:
>
> I'd be curious to hear from Mr. Kelleher why Python wouldn't be
> suitable for his needs.  (Maybe we'll find additional unexpressed
> requirements.)
>

I do have "additional unexpressed reqiurements" that may not
find much sympathy here, but they are real enough.

Most of the time I work as a consultant and have little say over
my environment.  I get hired to write in a particular language
on a particular OS.  The language and OS may vary, but I
am not the one choosing:  I am a programmer, not a designer
or architect.  In large corporations I don't even have root
access to the machines I use.  Typically I use a number
of computers.

At the same time, I write a lot of programs to automate the
repetitive stuff that I and my co-workers have to do every
day.  And that mostly involves manipulating files, making
database queries, and OS calls and munging the
contents or results.

As to what's usually on the machines:  I can count on
the usual unix utilities (ksh, sed, awk, etc.) and most of the
time Perl.  And there is usually C or Java.  I use them all,
but for a long time I've been tired of them.

And, yes, Perl would be exactly what I'm looking for if I
didn't have any aesthetic requirements.  Another requirement
is that I want to learn something from the new language as well.

Suneido is amazing, but it only runs on Windows.

Python would certainly do; it does have the advantage of
intelligibility; it is certainly more consistent in its design.

Ruby or Scsh (the Scheme Schell) would be even better,
I think.  Lisp is another viable option.  Pike might be worth
trying, but it's too cutting edge (it only runs on the latest
OS versions).

But if I use an interpreted language (or one with a virtual
machine), I need to install the interpreter on all hosts.

I am also not going to ask permission, so it can't be something
so big that it would catch attention.

So, I've realized lately, I want either a small interpreter or
a language that compiles to native code.

Rebol could fill the bill - it's small, functional, full of interesting
features - but you can't make OS calls in the free version.

Clean might be the answer, but it was in fact when I got to
chapter five of the Clean tutorial when I wanted to try something
out and wondered "how do you open a file?"  I looked (yes I
did) in the contents and the index and did not find the answer.
Likewise, I was unable to find how Clean treats strings, and
how one does anything at all to them (aside from printing
their value).  The Clean Language Report (which is the
language standard) was equally unenlightening.

So that was my Chaper Five Experience.  I think that Clean is
a very cool language.  I even like it.  So, not to flog a dead
horse, but I did search the docs and did not find "files" or
"strings" and thought, okay, this is probably not made for
my purposes.  I admit I may be quite wrong.  I did
not bother to ask anyone, but see --

The first time I opened a Perl book, I saw how to open and read
a file.  Why?  Because it's *made* for that.  Now if a language
doesn't even MENTION files and strings in its most visible documentation
(forgetting the chapter five cutoff) one has to assume that files
and strings are not a major concern in this language.

[ They are in fact relegated to libraries, as M. Rideau pointed out.
   And he is correct in saying that I did not think to look there. ]

So where does that leave me?

Right now I'm thinking that Ocaml is the solution for me.  It
runs on just about everything I have to use, can be interpreted
or compile to native code, and does not require advanced
brain power to learn.

AND, after the nostalgia expressed for Snobol, I downloaded that
yesterday -- since text munging is so important to me, I ought to
learn that paradigm as well.

-- 
Kevin Kelleher <kkell@znet.com>