[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

   >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. :)
   Well, aside from making fun of the use of the special-small-integers, 
   you have two alternatives.

Dan you misunderstood the point. And the way you chose to respond to
it w/ Lisp further illustrates it -- what if I did not have the
ability to rebind / control :input and :output for the context of my
program written in language X, without understanding the syntax and
semantics of "another" language Y? (JCL, sh, J2EE XML are all
"different" languages :)   

Library API's often impose restrictions that are different from the
language per-se -- see the Swing thread restrictions for example.
Leave problems to a library -- and you increase the chances those
problems will not get solved. Or solved in incompatible ways that
fragments your market.

Personally speaking, I don't care if you call it a language issue or
an API for I/O issue -- IMO, it doesn't matter if language X supports
functions as full-class objects but fails to do so on SMP
hardware. Because another language that does so will win mindshare as
a result -- some things just can't be solved in libraries, or through
container declarations.

O' well.

   First, you could hard-code into your program what the I/.O streams 
   should be opened to, e.g.

   (with-open-file (my-input :input "/usr/dlw/foo")
      (with-open-file (my-output :output "/usr/dlw/bar")
	    <code using my-input and my-output>))

   That's great, no JCL needed, it just works.  But it always uses exactly
   those file names, and you can't do anything about it without editing the
   source code, and maybe recompiling which might be more automatic
   or less automatic.

   Or you can have some level of indirection.  The program could get its
   filenames from reading command line arguments: then you could have
   neglected to include some stupid command line arguments.  Or it could
   use Unix-style environment variables, in which case you could have
   neglected to set some stupid environment variables.  Or you could use
   more elaborate versions of the same general idea as are done in the
   Java 2 Enterprise Edition with its concept of deployment descriptors.
   It's all very analogous.

   I don't think this has much to do with whther I/O is in "libraries" or not.