Layered Plan - Exploration into a KOSH Scripting Language

Author: Kristan Slack
Date Started: 10/1/99

What is a Scripting Language?
Why do we need a Scripting Language & The KOSH SL User
What do you (the user) want?
Current Scripting Languages and their Advantages/Disadvantages


First, before looking at the different aspects, benefits and disadvantages of scripting languages, we must detail a little of why one is needed at all, and what (in brief) would be needed in particular in a KOSH scripting language (SL).

From there we can proceed to examine (in part at least) what we, as a KOSH Kommunity, would hope to get out of this SL. In summary we can look at existing SL’s and their respective positives and negatives, hoping to glean off the benefits and learn from the mistakes.

What is a Scripting Language?

What indeed? Of all the descriptions I have read whilst researching this topic, most seem to point to an SL’s speed of development and ease of use. But I see much more. I see both power and flexibility. I see a sense of total control of the Operating System (at least I see these NOW I know about the object sea - I’ve been deep ocean diving, you could say).

I see this and it excites me.

So, you could ask, what makes an SL different from a Systems Programming Language? Good question and it is this question that I will endeavour to partially answer in the following paragraphs.

A language, by definition (Macquarie Dictionary), is any set or system of chosen symbols allowing people to communicate with those others who are familiar with the system OR a form or manner of expression. I see the KOSH SL as somewhere between these two definitions. Perhaps a manner of expression to communicate with those objects which exist in the KOSH object sea.

But then, the KOSH SL should also be something more. It should be an easy to learn language, perhaps where the user "can type sentences in and get responses back in an interactive conversational style" [Fleecy Moss, 1999].

A systems programming language, in general, is a much lower level instrument, usually allowing the user - who is usually an experienced programmer or someone with more than a layman’s understanding of the underlying system - to "totally" control the system at a hardware level or just above.

Instead, our KOSH SL would NOT interface with hardware (we have HAL instead). It would be the object sea interface - the water itself if you will - which suspends or buries all the objects in the sea. Scripting Languages have often been called the glue that keeps all the user applications together, but we have an object sea, so I prefer the water analogy.

Without taking the object sea analogies too far, nor getting carried away in under-detailed but over- described explanations, let’s get down to business.

Why do we need a Scripting Language & The KOSH SL User

When we explain tasks in real life to people we use phrases such as ‘move that book over near the table’, ‘pick that paper up off the floor’. In other words in real life we used object-sea centred descriptions without even knowing it. Actions between objects - it’s all about interaction between the objects in our world. Positional, action/reaction explanations are how we think, so why shouldn’t it be how we tell our computers what to do as well?

As such, our Scripting Language should be totally intuitive (this word seems to crop up an awful lot in my document). It should also be all encompassing.

But ‘Why do we need a Scripting Language?’. Well, why not? After all, we shouldn’t have to perform tasks repeatedly day after day when the computer can do them for us. Having a computer should always mean it reduces our workload somewhat, NOT increases. Having a script to send “data” between objects, open up objects, move from one area in the sea to another (a bit vague I know) would make life so much easier.

One question that is usually asked about a language by a ‘newbie’ is "how hard is it to learn"? Now, there are plenty of books that claim you can learn C in 24 hours, or Java in 21 days - but it begs to be asked, how much of a thorough understanding is necessary before you can actually do something useful in a particular language?

Well, this is where a scripting language has generally provided the user with a quicker (but usually dirtier) way of getting what he/she wants done with the minimum of exposure to formal programming methods. So, we see then that the KOSH SL user should be anyone who uses KOSH at all: KOSH for play or work!

You want to create a tutorial for people to see just how easy it is to use your new program - then code it in the scripting language. Intuitive and with total control of the interface - indeed perhaps the interface.

Or, you work in technical support and a user can’t work out how to perform a certain task, you can write a visible tutorial for them, guiding them through the steps by moving the pointer around the screen opening menus, selecting items etc. The list goes on and on.

Or perhaps you just want a little script to tell the computer to log you on at a certain time, download your mail, archive certain web sites to disk and send a "I am not really here" message to anyone who pings you - then do it in the KOSH SL.

A script could be used to put objects together, to index them, to start up a particular 'program' with the user’s individual settings (see Fleecy’s VIP lists).

These examples may seem limited and boring, but that is largely because of my lack of imagination. I know for a fact though that scripting languages can be (as ours WILL be) extremely powerful yet easy to use.

You’ll also have to pardon my use of non - object-sea centred explanations, I have been living in the staid and un-original computer world of this sort for so long it colours the way I speak (menus, files, mouse pointer - it could all be different, its all up to you).

What do you (the user) want?

I have put out a public survey to the KOSH kommunity as it exists on what they would like from a KOSH Scripting Language - but there has already been a certain amount of discussion pertaining to the KOSH interface and even scripting (directly and indirectly).

So far, I have been quite disappointed with the response (4 emails). While I don’t have much of an idea of what a typical user would like, since I have had little feedback I have had to rely largely on my own suggestions.

Many have pointed to AREXX (and REXX) as an example of a good SL. In fact, Dave Haynie mentioned that once Amigans got good at using Arexx for all their scripting needs they stopped using any other 'macros' and alternate SLs distributed with a particular app.

Paula Liebeman mentioned (as have others) that multiple modes of script creation should be allowed. For example, being able to drop pre-set routines into a 'code-flowchart' would enable you to ‘see’ your script. But for components not common, you’d just write your own routine and drop that into the chart. As well as this, being able to jump through the script, skipping to certain sections (for example, in a tutorial script) - but this may depend more on the particular script - of course, it should also be something easily programmed in though.

Luke Guest suggested features much like Paula, but also would like to see an easier to read and learn blocking style so it is much easier to tell where blocks start and end (start switch - end switch for example).

But the KOSH SL should be more intuitive (see, told you) than Arexx - a lot closer to <insert your favourite spoken language>. Perhaps including a bit of database querying as well (largely because this method suits our object sea model, albeit in a rather limited way).

So, since I’m assuming this document will be published into KOSH-general, or at least part of it, I’ll ask the users to please submit to me (in documents no longer than a page) what they would like to see included in the KOSH SL (my email address is available from Greg).

Current Scripting Languages and their Advantages/Disadvantages

Here I’ll err on the side of brevity to keep this short (that way, if I miss anything out, I can pretend it was intended).

A list of current scripting languages would have to (at least initially) include:

  • Unix Shells (bash, csh, ksh, sh, etc)
  • Rexx
  • Perl
  • Tcl
  • Visual Basic
  • JavaScript
  • Arexx

SL’s Brief Overview

Unix shells (sh, csh, ksh, ...)
One of the most unique and powerful aspects of Unix was the ability to write shell scripts that create new applications by composing existing applications; it is perhaps the single most important reason for Unix's popularity as a platform for application developers.

Michael Cowlishaw initially conceived the Rexx language in 1979 to simplify programming tasks on IBM's CMS timesharing system. It became popular as a macro language for arbitrary application programs, and its usage spread to many other platforms, including PCs and Unix.

Created by Larry Wall in the late 1980s as a way to bring together in one place the functions of many popular Unix text processing applications such as sh, sed, and awk, Perl quickly became a favorite tool of system administrators. With the arrival of the World-Wide Web, Perl achieved even greater fame as a convenient way to write CGI scripts for dynamic Web pages.

Created by John Ousterhout in the late 1980s as an embeddable command language for interactive tools. When supplemented with the Tk toolkit, it became popular as the fastest way to build graphical user interfaces on Unix. Tcl and Tk were ported to Windows and the Macintosh in the mid 1990s, producing an outstanding cross-platform development environment. Today Tcl is used for a wide variety of integration applications including Web content generation, financial applications, electronic design automation, automated testing, and system management.

Visual Basic
This Microsoft product lies somewhere between a scripting language and a system programming language. It became popular in the early 1990s as the easiest way to create graphical user interfaces under Windows. The combination of Visual Basic and VBX (later ActiveX) components is probably the most successful component framework in existence, due in large part to the ease of integration provided by Visual Basic.

Created in the mid 1990s by Netscape Corporation to perform scripting functions in Web browsers, such as simple form validation. JavaScript has become the de facto standard for client-side Web scripting, although it doesn't have much to do with Java.

Arexx is the Amiga counterpart of the IBM REXX programming language. It is an interpreted language that uses ASCII file input. By utilising IPC (Inter Process Communication) techniques, Arexx provided the user with a way of having their separate applications interact with each other, exchanging messages and commands.

Advantages/Disadvantages of Current Scripting Languages:

Language Advantages Disadvantage
Unix Shells Powerful string handling functions, small code, fast. Terribly terse, hard to learn and not easy to remember.
REXX Powerful.... ? Not intuitive, ... ?
Tcl ??? ???
Visual Basic Good GUI features, easy to learn. Slow, not powerful, over-simplified.
JavaScript Easy to learn, good for simple web displays, small code. Not much use as an OS SL, slow.
Arexx All-rounder, easy to learn, well-documented, ??, great message passing features (IPC). Not powerful enough, ...?

As you can see, because of my own limited scripting language experience, the tables need a lot of work, and I’d appreciate any further help with this.


In summary, I haven't finished this plan yet. But because I’ve been so long on it, I figured it was only fair to release it to the community and see what develops from there. Any suggestions, comments, criticisms (valid ones only) are most welcome.

So get going with talk about our Scripting Language!