WARNING: Potentially controversial opinion essay follows...
daniel_bingamon wrote:
I think that a system with a command line interface OS should be used, languages should be left to the individual and loaded from disk or add-on cartridge. One of these modern serial ROM's could be used to load languages into RAM on startup.
Another possibility is to make the CLI operate in a graphics mode, then it
would be easy to port the OS into a grahpic operating environment. Why walk in the legacy of that huge unmentionable software company.
A few points:
1. Implementing a CLI is, in fact, following in the footsteps of two unmentionable companies: AT&T (Unix) and Microsoft (DOS). Of course, other platforms have had CLIs as well, such as the Amiga (inspired by VMS's shell environment, but implemented almost directly like a Unix clone).
2. A command-line interface must interpret user input. Hence, it itself is a language.
Most CLIs are not Turing complete. To make a Turing complete shell interface, in fact, requires resources that are often in excess of a normal language, specifically because the syntax of the language must work around syntax that is incredibly irregular. BASH, for example, consumes 511400 bytes on my x86 Linux box. On a RISC architecture, multiply that value AT LEAST by two. This value, of course, does not include the host OS resources that it relies upon. Moreover, very little of that code is Linux-specific. The last time I saw a version of BASH for DOS, it consumed over 400K, and *required* a 32-bit DPMI handler to be installed to run it.
Yet, Pygmy Forth on my system consumes only 16KB of 16-bit code (if we were to scale it up to 32-bit, it'd be 32KB), and can invoke external programs just like BASH can, though with additional syntax (e.g.,
" QEDIT myFile.txt" SYSTEM instead of just
QEDIT myFile.txt). But the neat thing comes when I have to pass parameters to commands, and have to iterate over whole directories of files, including sub-directories. Neither COMMAND.COM nor BASH have a "NOT" wildcard character (in fact, neither does VMS, but AmigaOS does!), so while I can INCLUDE files based on certain criteria, I can't EXCLUDE them. With Forth, I can, and I can do it in much less space and overhead. Any Lisp user will probably give you similar success stories.
3. In most CLI environments, commands are implemented as subroutines, with grossly unnatural means of passing parameters and an incredibly restrictive method of returning results back. Most CLI commands accept a pure string input, or an array of strings with each element representing one argument. They only return a single integer for a result code. The sheer difficulty in parsing command line arguments cannot be over-appreciated. Just look at the 5 or so "standard" CLI parameter parsing packages available for Linux alone, not counting the ad hoc approaches most commands take. Look at how many exist for MS-DOS. The only two systems I've seen that had only one standard method of processing commands was AmigaOS and VMS, and even AmigaOS didn't really have it until Kickstart 2.0, where they shipped the "standard argument parser" standard with the OS.
With more rational languages, this doesn't exist. The command is implemented, as far as the language is concerned, as a normal language subroutine. Therefore, parameters are passed as normal language parameters (usually on the stack). This maintains proper structure (and, optionally, encapsulation if the environment is object oriented), and is a critical factor in enabling system-wide garbage collection. Moreover, integers are passed as real integers -- no encoding or decoding functionality is needed inside your application. Same thing with floating-point values. And strings are pre-parsed. Wild-cards can be expanded with the aid of an explicit call to an expander function (see the Scheme example below).
Moreover, returning a result is handled the same way as any other language subroutine. In the case of Forth, this is depositing one or more values on the data stack (or other relavent stacks as necessary, such as floating point or string). Note also that Forth and Lisp can return MULTIPLE values (versus the traditional one) of ANY type (versus the traditional integer). This enables commands like (expand) or MATCH-FILES to perform wild-card expansion
on demand, rather than as an automatic and implicit function of the shell. I cannot TELL you, as a programmer, how many times I've been bitten by this when trying to use 'grep' to find a pattern involving a dot, an asterisk, or square brackets. I've also written my own commands whose interface really would have been greatly simplified for the user if (s)he could pass "*" to the command without having the shell auto-expand it to a list of files (a list, by the way, whose delineation isn't certain).
This structure also encourages capability-based security systems, which to date, have been demonstrated to be superior to ACL-based security systems in every way. Damage from viruses can be contained much more easily with capability systems. A faulty program can trash only the files it's been given
explicit permission to modify by the user. Wide-open e-mail security holes are a thing of the past, while STILL preserving the capabilities (no pun intended) and relative ease of use of packages like Outlook (Express). NONE of this is possible in a traditional, strictly-text based shell environment, specifically because it so harshly breaks encapsulation.
4. This raises another interesting point. You have a language parser and interpreter for the shell itself, and then you have a language parser and interpreter/marshaller for the command line parameters as well. How many more languages do you need to support? Scripting is critical for many people, and that constitutes yet another language. Try as you might to unify the CLI and the script, it can't be done 100%. Even BASH has difficulties in this area, though it rarely presents a problem to the user.
5. I've also very desparately wanted to perform basic arithmetic in the shell as well. By basic arithmetic, I'm talking addition, subtraction, multiplication, and division. Not quite as frequently, I've also wanted to do other algebraic operations, like squares and square-roots, and very rarely, sines and cosines. As it is, neither BASH nor COMMAND.COM permit even simple addition. I have to rely on an external command, usually called expr, to figure this stuff out, but I can't use it to affect filenames, and I can't use it for generic text manipulation. How sad.
Because Forth and Lisp are effectively plug-in based languages, any arbitrary program that is willing to accept the Oberon/Forth/Lisp/whatever ABI, regardless of what language it's actually written in, will be self-consistent with the remainder of the language. Therefore, only ONE interpretter is necessary (Forth also has a built-in compiler, so "scripts" that you write get compiled to a representation that is, if not native code, awfully close to it), for both commands and parameters, and allows easy functional composition between programs without the bizarre and patently arbitrary syntax requirements for things like pipes and file redirection.
But you can't invoke a command as easily in these languages? Sure you can. For example:
Code:
(DOS, CP/M, etc) C:\> xcopy *.* a:\
(Hypothetical Oberon implementation) FileSystem.Copy * a: ~
(Hypothetical Lisp/Scheme) (copy (expand *) A:)
(Hypothetical Forth) 0 ddrive! S" *" match-files copy
The advantages of Forth and Lisp/Scheme is that the shell follows the language's syntax rules precisely, while Oberon and DOS, etc. do not (they need a separate interactive interpreter). Note that Forth isn't strictly garbage collected "as is," but can be made to support explicit garbage collection with relatively little additional code. Also, the structure of the dictionary is highly conducive to frequent space re-use, so even to this day, Forth implementations actually tend NOT to use dynamic memory allocation for most tasks.
The only advantage to the CP/M or Unix derived shell environments that I can see is that it requires less typing on average, and therefore, gives the *false* appearance of being easier to learn. Yet, nearly *ALL* of today's IT professionals grew up on systems that had integrated langauges in them, not shells. *EVERYONE* that I've seen who's grown up on a shell-based environment like the PC has demonstrated measurably inferior computer use capabilities to those who didn't.
In short, the scism between OS and language is demonstrably a false one, and should be eschewed. There is a lot of talk these days of re-unifying the language and the OS, so it's a problem that is recognized widely in the software community. The decision, then, is what language do you choose to implement as the default? I also have to agree, why walk in the legacy of that huge unmentionable software company?