Nick Coghlan <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >> Arich Chanachai <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list