Novel Thoughts on Scripting and Languages

[Andrew Dalke]

James Huang wrote:
> First off, I don't call "sendMail" an API (but that again may fall
> into the meaningless confusion of what exactly is API, scripting,
> ....). For what you described, you are right, you need to fall back to
> API such as Java's javax.mail.* package, which is used by this
> "sendMail" statement.

Perhaps 'PSI' for "People's Scripting interface" (or "Everyone's"?  ;)
But it is indeed an API.  The people who use it write applications,
and they are programming.  Perhaps script programming, but programming
non the less.


> Obviously, you are an expert in mail programming,

No, I am not.  Not by a long shot.  I chose email because you
posted it as an example.  What I know mostly comes from using
Python's 'email' module.


 > and the situations you described are rather involved.

Indeed they are.  I limited it to your example.  My point is that
people's needs, even those of beginners, can become complicated
quickly.  You say it's rather involved, but suppose Nobuki Peréz
is just starting to use your language to send mail in Japanese
to his Japanese maternal grandparents.

Because I am not an mail expert, I don't know if this is
a problem or not.  I again say that I know the Python API
for handling email allows for multiple characters in the headers,
even multiple character sets in the same line, so I am
conjecturing a reason for why that is needed.


 > It all boils down to probability
> when analyzing computer systems -- what are the probabilities of what
> JudoScript-sendMail can handle and what not. Also, how many people can
> use JudoScript-sendMail, how many use mail API(s)?

Speaking personally, last time I programmed a way to send
email was about 5 years ago.  I have used the email module to
read my mail archive (was playing around with a text indexer)
but that was about it.

> You can specify different character-sets for any of these 3:
> "sendMail", "body" and "htmlBody". I've heard Japanese emails may use
> different encodings for differnet parts, as you described.

I did read your documentation about that functionality before
posting, which is why I explicitly gave a case of multiple
character sets used in the header.  You only allow one for
all the headers.

> JudoScript's extremely-easy-to-use features are not designed for
> non-programmers, but rather for potent programmers especially those
> who know Java. I can program javax.mail.*, big deal, but only if I
> have to.

Ahh, I misunderstood.  In that case I don't find the idea of
JudoScript very interesting.  Jython integrates well with Java,
so I can program to those lower-level APIs directly, and I am
(IMO) a rather potent programmer who can write the higher-level
interfaces pretty quickly.  In addition, my knowledge of Python
is transferable to the C implementation of Python so I can used
non-Java based libraries.  (I work with quite a few C libraries
which have no equivalent Java implementation.)

This is very similar to what Sandy Norton said elsewhere in this thread
] Actually, it first reminded me a little bit of rebol which has
] some nifty high level commands like "send person at address.com
] file.txt". My initial reaction to that was "wow, that's cool... let
] me try rebol out". After a few attempts to use the language, I
] got somewhat frustrated with the syntax and semantics and decided
] to write a module called 'rebol.py' instead, implementing the
] functionality I could use on top of the python standard library
] infrastructure. So now I can write
] >>> from rebol import send
] >>> send('person at address.com', 'file.txt')
]
] My approach to your examples would be similar. I would use
] elements of the python standard library and implement my
] 'preferred level' of abstraction.

I see you have not yet replied to that post.

I also note that in your whitepaper you state:
 > Since Jython is fully capable of Java scripting, why would
 > anyone use a Python module if similar functionality exists in Java?

You provide a high-level but limited way to send email, and say that
people can use the lower-level Java modules for more complicated
tasks.  This implies that people need to choose between two different
way to do similar things.  Yet in your white paper you say that
people shouldn't have to choose between two different APIs.

In your whitepaper you say the problems with Jython are that
you must choose between Python's module for something and Java's
module for something.  Isn't that just like real-life where you
need to choose between a half-dozen graphics libraries?  Plus,
you conveniently forget to mention that there are plenty of
libraries in Python which aren't part of the standard Java
distribution.


> It is hard for me to understand why some programmers are so afraid of
> easier ways of doing things (not necessarily you, Andrew, but there is
> an anonymous guy responded to an article on LinuxJournal site). We can
> program does not mean we have to program, unless, perhaps, for job
> security reasons.

Here's some ideas off the top of my head:
   - have you done any testing to show one is easier than the other?
       (for non-trivial, non-contrived tests.  For example, read
        "An empirical comparison of C, C++, Java, Perl, Python, Rezz,
       and Tcl for a search/string-procesing program" at
           http://www.ipd.uka.de/~prechelt/Biblio/#jccpprtTR
     Without such tests, we have little to go on to believe that
     you have an easier way of doing things.

   - perhaps it isn't easier over the spectrum of tasks that are
     needed, and you are under the persuasion that (quoting Terry
     Reedy earlier in the thread) that "My baby is great".

   - A lot of language announcements have the same sort of "this is
      much easier than existing languages" flavor -- and you haven't
      convinced us otherwise.

   - You write a new language but base it only on your knowledge of
      other Java languages, and didn't look at Rebol nor REXX.  Given
      your lack of experience there makes it harder to believe your
      other claims.

   - You misrepresent Python, saying for example that it is weakly-typed
      (which is false) and that the ActiveX interface is another Python
      distribution, rather than simply a Python library.  Again, this
      makes it harder to believe your claims.

   - You misinterpreted other people's posts several times, which means
      you may also misinterpret other's programming needs.

					Andrew
					dalke at dalkescientific.com