scsh-users
[Top] [All Lists]

Re: Scsh (a Unix Scheme shell) FAQ

To: scsh-news@zurich.ai.mit.edu
Subject: Re: Scsh (a Unix Scheme shell) FAQ
From: Michel Schinz <Michel.Schinz@epfl.ch>
Date: Wed, 15 Jan 2003 08:50:06 +0100
Organization: EPFL
Yoann Padioleau <padiolea@cripure.irisa.fr> writes:

[...]

> How does scsh compare to other scripting languages, like Perl?
> ==============================================================

Yes, that means "how does it compare to others, Perl being one of the
others". At least that's what it's supposed to mean. I'm not a native
english speaker and I might be wrong here.

But I can make things more explicit, for sure, since the current
wording is apparently confusing to you at least.

>> tries to compare scsh to other scripting languages, Perl being only
>> one of them. Other examples include sh/tcsh, Python, Ruby, etc. I
>
> putting in the same bag sh and perl/python/ruby is
> like putting together C and scheme.
> They are totally different langage.

Sure. They are not put together because they are similar languages,
but because people *usually* use them for the same kind of stuff,
namely scripting.

[...]

>> Could you please elaborate?
>> 
>> Here are the names of some functions in scsh and Perl which should
>> illustrate my point:
>> 
>>   scsh           | Perl
>>   ---------------+--------
>>   delete-file    | unlink
>>   file-readable? | -r
>>   file-info      | stat
>>   process-group  | getpgrp
>>   ... and so on
>> 
> I have to agree.
> But in that case, if you compare scsh to ruby on this point u will
> be disappointed as ruby tried to choose good name.

Right. What I should do is see whether, in the case of Ruby, they went
beyond simply fixing the names and also fixed the behaviour of some
standard Unix functions, which scsh certainly did.

I have some examples in mind but they concern Perl, and they date back
from my last exposure to Perl, which means they are old. So I'll first
check whether they still apply with the current version of Perl, then
see what is done in Python and Ruby. And then rewrite this part of the
FAQ.

> You just cant compare scsh with "the existing scripting langages"
> and say that scsh is better.

No you cannot, and therefore I did not.

> The only advantage i see in scheme over other langages, is its
> powerful macro system. That's all. You should try to argument on
> this point, but not on the other features of scsh which are already
> present in many scripting langages.

Macros are certainly not the only difference I see between scsh and
other scripting languages. The regular-expressions expressed as
s-expressions is one feature I do not find in any other
regular-expression package, for example.

> In fact the word scripting langage is just a non-sense,
> perl/ruby/python are no more used only for administrative quick and
> dirty task.

Of course Perl/Ruby/Python are used for other things than writing
scripts. But the same apply to Scheme, and scsh *is* Scheme (with one
minor exception), so.

What I (and it's not just me) classify as scripting languages are
languages which have specific features whose aim is to facilitate
scripting. With Unix, that usually means facilities to deal with text
files easily, for example through regular expressions, to access many
features of the operating system, like the user database, the
file-system, and so on, as well as networking support. And I certainly
forget tons of other things.

But of course that's a rough classification, just like the
classification of languages as "object-oriented" or "functional" is.
You can do object-oriented or functional programming in all languages,
they are all Turing equivalent and can express the same things.

Now doing functional programming in C is a huge pain, because you have
to do everything yourself. But you can do it. So what people call
"functional languages" are not languages in which you can do
functional programming, because that could mean all languages. Rather,
functional languages are languages which facilitate a functional
programming style, and that typically means those with support for
automatic garbage collection, closures, anonymous functions, etc.

Likewise, you can do scripting in any language. But that's a pain when
the language (or some libraries) does not include some explicit
support for it. So what people call scripting languages are not
languages in which you can do scripting, or even languages in which
you can only do scripting, but rather languages (or, once again,
libraries) which make it easy. And that includes Perl, scsh, Tcl,
Ruby and others.

Michel.

<Prev in Thread] Current Thread [Next in Thread>