Novel Thoughts on Scripting and Languages

[James Huang]

Andrew Dalke <adalke at mindspring.com> wrote in message news:<avj5lr$4jf$1 at slb3.atl.mindspring.net>...
> 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.)

You missed the significant difference in philosophies. -- When needs
arise, sure, it is always possible to add them. Now that you have
given such a detailed use case, and if it is confirmed worth the
hassle, I could add it in in the next version, big deal. It's the idea
to specify your needs rather than programming solutions that makes the
difference. And, of cause, my lead post should be clear enough that
this is all about scripting. My definition of scripting is:

Scripting (in programming sense)
================================
is to do things easily, intuitively, obviously, and accurately, so
much so that when another person (with the same domain knowledge) sees
a chunk of code, he immediately understands it without even a hint of
reasoning (ideally). #

This is the fundamental different. I am relunctant to bring up the
term "4GL" but that is what it is (or even futher).

> 
> 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.

I've expressed my opinions on comparing languages in the reply to your
another message. As for "easier", make sure we are talking about
scripting, to do things rather than make software.

> 
>    - 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".

Repeat, make sure we are talking about scripting.

> 
>    - 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.

Repeat, make sure we are talking about scripting.

> 
>    - 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

You're right about JudoScript and Java, finally. Do Rebol and REXX
have Java ports? If not I'll pass. JudoScript is intended to be
"scripting and shell for Java", and the assumption is Java will have
software for most, if not *all*, of our needs.

>       your lack of experience there makes it harder to believe your
>       other claims.

See below.

> 
>    - 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.

Programming needs? I have been talking about scripting!

> 
> 					Andrew
> 					dalke at dalkescientific.com

You summarized the risks of drawing hard conclusions very well. :)

Cheers,
-James