[Fwd: Re: [Uuu-devel] languages] <-- Why Python

[Mike Meyer]

Nick Coghlan <ncoghlan at iinet.net.au> writes:

> Mike Meyer wrote:
>> Arich Chanachai <macrocosm at fastmail.fm> writes:
>>
>>>Mike Meyer wrote:
>>>
>>>>Whatever the intentions may be, the *act* is one of dictation. Since
>>>>the point of the underlying OS is to increase the interconnections
>>>>between applications (assuming I've found the correct web page and
>>>>interpreted it correctly), the underlying architecture should be
>>>>language-neutral. That allows as many applications as possible to play
>>>>in the environment.
>
> *Allowing* other languages is one thing, but that shouldn't preclude
> having a 'default' language. On other OS's, the default language is
> some form of shell scripting (i.e. Unix shell scripts, or Windows
> batch files). It would be good to have a real language to fill that
> role.

Um - I'd say Unix has no default language. Traditional Eunices come
with a nice selection of languages (sh, awk, sed, C), and modern ones
include more (C++, Perl, Python, Ruby, Lua). Tagging one as the
"default" does a disservice to the other languages, and to the OS as a
whole.

For that matter, I'd say that these days the default on Windows is VB,
unless there are hooks to talk to COM from batch files, since COM is
the standard scripting mechanism on Windows. Note that by providing a
scripting mechanism instead of a scripting language, you can script
applications with Python as or more easily than you can script them
with the MS provided solution of VB.

>> You've missed the point. Allowing a wide array of problem solving
>> choices is a goal, not a means. Instead of concentrating on adding
>> langauges, you should be provding an infrastructure that makes adding
>> langauges simple.  The Plan 9 example does this best, as any language
>> that can do file I/O is supported.
> Still, the builtin shell is going to need *some* form of scripting
> support. And if that looks like IPython's shell mode, so much the
> better.

Scripting support shouldn't "look like" a language, it should look
like a mechanism for hooking languages up to the system being
scripted. Shells are a particularly easy hookup, as they have only
three types of objects to deal with - commands, command results, and
text streams. Any language which lets you invoke commands and
manipulate the results of those commands and text streams is
sufficient for shell scripting.

IPython's pysh seems a little clumsy for interactive use, as it
requires special characters to distinguish between commands to be
passed to the shell and commands to be passed to the scripting
language. This should be contrasted with languages designed for
working in a command environment, like Rexx, sh and rc.

> Anyway, the reason to prefer Python to LISP for something like this,
> is that Python reads much more naturally for most people, whereas LISP
> requires that you write things 'out of order'.

I'll say it again - if you're arguing about which language to use,
you're arguing about the wrong thing.

       <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.