Re: What would your ideal language be like...

[Sundar Narasimhan <address@hidden>]

   On Friday, Feb 21, 2003, at 08:57 US/Pacific, DLWeinreb@attbi.com wrote:
   > I think what you're getting at here is the tradeoff between
   > a language for one domain and a general language.  If you,
   > as a "language consumer", only ever want to work on one
   > particular domain (e.g. "files and strings"),

   This is a little disingenuous.  It's like calling "integers"
   or "functions" a particular domain.  Any language that cannot
   handle such basic tools as files and strings has severe applicability
   problems in the real world.  Any language tutorial or reference
   that fails to at least point to descriptions of these basic tools
   is flawed.

I'd explore that point a bit further actually because 

- I think of needing to deal w/ "files" as an instance of a much
broader issue with I/O in general. For example, keyboards/mice (event
driven programming/threads), monitors-screens (gui), other
users/computers (network i/o support) are all instances of I/O as
well. So, why do languages relegate these to libraries? (I've
complained about this since the first day I had to program, and
someone mentioned that the reason why my first fortran program didn't
work was because I'd neglected to include some stupid JCL card that
defined devices 4, 5 etc. :) But I don't think lack of support is a
"flaw" necessarily - it's just that languages "with" support for such
things from the get go will find gaining widespread adoption an easier
problem. Because.. you guessed it, someone will want to use your
language to do one of those kinds of I/O.  I think by narrowly
interpreting requests for things like files, we risk missing the big
picture.
 
- Strings are interesting as well in that the conventional wisdom is
that strings are perhaps a structured type made up of "characters",
and surely if you have "characters" and "arrays/sequences of such
characters", or an OO system that allows you to define your own
objects .. you shouldn't need a separate type such as String, right?
C++ took that tack (I'm thinking before the ISO/ANSI std efforts), and
look at all the MFC:CString or RWCString -- just to name two popular
but pretty widely differing ideas on how to do strings -- that
resulted :) So where is the boundary between base types that a
language provides out of the box and those that a programmer/library
is supposed to provide?  I could make the same point about dates and
times (some things we have to deal with day in and day out here), or a
handful of other data types such as multi-dimensional arrays. So what
is a "good set of built-in domains"? Is there a consensus of opinion
or even approaches toward determining such a list? (Personally
speaking, I'd say that the evidence seems to be that languages that
retain a lot of degrees-of-freedom at the built-in domain level -- I'm
thinking of languages such as Lisp, Smalltalk etc. have not been very
successful -- is this evidence that extensibility doesn't play well in
the mass market because it sets the bar for writing useful programs
too high?)

   I agree with the rest of your message, about extensibility vs
   built-in domains, but I just think that files and strings are too
   basic to be a good example of this, and that Kevin had a point.

   FWIW, I think Kevin should use Python.

      -- Doug