From: ············@gmail.com
Subject: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <1151703408.592062.30810@m73g2000cwd.googlegroups.com>
Here's a section from the scsh FAQ on the comp.lang.scheme.scsh. I look
at those code examples and I'm very, very charmed by how readable scsh
code is in comparison to the more cryptic scripting languages.


3.7.4 Example script
--------------------

The following code snippets aim to provide an idea of how scsh compares
with other common scripting languages. They all print a list of all the
executables available in the current PATH to the standard output
(improvements to these examples are welcome).

   - `sh'
          #!/bin/sh

          IFS=':'
          for d in $PATH; do
            for f in $d/*; do
              [ -x $f -a ! -d $f ] && echo $f
            done
          done

   - `perl'

          What is the sound of Perl? Is it not the sound of a wall that
          people have stopped banging their head against?
          - _Larry Wall_

          #!/usr/local/bin/perl

          for my $dir (split /:/, $ENV{PATH}) {
             opendir DIR, $dir or die "can't opendir $dir: $!";
             -x "$dir/$_" && !-d _ && print "$_\n" for readdir DIR;
             closedir DIR;
          }

   - `python'
          #!/usr/local/bin/python

          import os, string, stat
          for d in string.split(os.environ['PATH'], ':'):
             for f in os.listdir(d):
                mode = os.lstat(d + '/' + f)[stat.ST_MODE]
                if not stat.S_ISDIR(mode):
                   print f

   - `ruby'
          #!/usr/bin/ruby

          ENV["PATH"].split(/:/).each {|path|
            Dir.foreach(path) {|file|
              puts(file) if File.stat(File.join(path,
file)).executable?
            }
          }

   - `scsh'
          #!/usr/local/bin/scsh -s
          !#

          (define (executables dir)
            (with-cwd dir
               (filter file-executable? (directory-files dir #t))))
          (define (writeln x) (display x) (newline))

          (for-each writeln
             (append-map executables ((infix-splitter ":") (getenv
"PATH"))))

From: William James
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <1151706305.272927.34930@p79g2000cwp.googlegroups.com>
············@gmail.com wrote:
> Here's a section from the scsh FAQ on the comp.lang.scheme.scsh. I look
> at those code examples and I'm very, very charmed by how readable scsh
> code is in comparison to the more cryptic scripting languages.
>
>
> 3.7.4 Example script
> --------------------
>
> The following code snippets aim to provide an idea of how scsh compares
> with other common scripting languages. They all print a list of all the
> executables available in the current PATH to the standard output
> (improvements to these examples are welcome).
>
>    - `sh'
>           #!/bin/sh
>
>           IFS=':'
>           for d in $PATH; do
>             for f in $d/*; do
>               [ -x $f -a ! -d $f ] && echo $f
>             done
>           done
>
>    - `perl'
>
>           What is the sound of Perl? Is it not the sound of a wall that
>           people have stopped banging their head against?
>           - _Larry Wall_
>
>           #!/usr/local/bin/perl
>
>           for my $dir (split /:/, $ENV{PATH}) {
>              opendir DIR, $dir or die "can't opendir $dir: $!";
>              -x "$dir/$_" && !-d _ && print "$_\n" for readdir DIR;
>              closedir DIR;
>           }
>
>    - `python'
>           #!/usr/local/bin/python
>
>           import os, string, stat
>           for d in string.split(os.environ['PATH'], ':'):
>              for f in os.listdir(d):
>                 mode = os.lstat(d + '/' + f)[stat.ST_MODE]
>                 if not stat.S_ISDIR(mode):
>                    print f
>
>    - `ruby'
>           #!/usr/bin/ruby
>
>           ENV["PATH"].split(/:/).each {|path|
>             Dir.foreach(path) {|file|
>               puts(file) if File.stat(File.join(path,
> file)).executable?
>             }
>           }


ENV[ 'PATH' ].
split( File::PATH_SEPARATOR ).
each do |path|
  Dir.foreach( path ) do |file|
    if File.stat( File.join(path, file) ).executable?
      puts file
    end
  end
end


>
>    - `scsh'
>           #!/usr/local/bin/scsh -s
>           !#
>
>           (define (executables dir)
>             (with-cwd dir
>                (filter file-executable? (directory-files dir #t))))
>           (define (writeln x) (display x) (newline))

"writeln" had to be defined?  Incredible.  Not much of a
scripting language.  And can this handle more than one
argument?  In newLISP you can say

(println "The number " x " is the answer.")

>
>           (for-each writeln
>              (append-map executables ((infix-splitter ":") (getenv
> "PATH"))))
From: ··········@gmail.com
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <1151707448.850803.157910@h44g2000cwa.googlegroups.com>
William James wrote:
> ············@gmail.com wrote:
> > Here's a section from the scsh FAQ on the comp.lang.scheme.scsh. I look
> > at those code examples and I'm very, very charmed by how readable scsh
> > code is in comparison to the more cryptic scripting languages.
> >
> >
> > 3.7.4 Example script
> > --------------------
> >
> > The following code snippets aim to provide an idea of how scsh compares
> > with other common scripting languages. They all print a list of all the
> > executables available in the current PATH to the standard output
> > (improvements to these examples are welcome).
> >
> >    - `sh'
> >           #!/bin/sh
> >
> >           IFS=':'
> >           for d in $PATH; do
> >             for f in $d/*; do
> >               [ -x $f -a ! -d $f ] && echo $f
> >             done
> >           done
> >
> >    - `perl'
> >
> >           What is the sound of Perl? Is it not the sound of a wall that
> >           people have stopped banging their head against?
> >           - _Larry Wall_
> >
> >           #!/usr/local/bin/perl
> >
> >           for my $dir (split /:/, $ENV{PATH}) {
> >              opendir DIR, $dir or die "can't opendir $dir: $!";
> >              -x "$dir/$_" && !-d _ && print "$_\n" for readdir DIR;
> >              closedir DIR;
> >           }
> >
> >    - `python'
> >           #!/usr/local/bin/python
> >
> >           import os, string, stat
> >           for d in string.split(os.environ['PATH'], ':'):
> >              for f in os.listdir(d):
> >                 mode = os.lstat(d + '/' + f)[stat.ST_MODE]
> >                 if not stat.S_ISDIR(mode):
> >                    print f
> >
> >    - `ruby'
> >           #!/usr/bin/ruby
> >
> >           ENV["PATH"].split(/:/).each {|path|
> >             Dir.foreach(path) {|file|
> >               puts(file) if File.stat(File.join(path,
> > file)).executable?
> >             }
> >           }
>
>
> ENV[ 'PATH' ].
> split( File::PATH_SEPARATOR ).
> each do |path|
>   Dir.foreach( path ) do |file|
>     if File.stat( File.join(path, file) ).executable?
>       puts file
>     end
>   end
> end
>
>
> >
> >    - `scsh'
> >           #!/usr/local/bin/scsh -s
> >           !#
> >
> >           (define (executables dir)
> >             (with-cwd dir
> >                (filter file-executable? (directory-files dir #t))))
> >           (define (writeln x) (display x) (newline))
>
> "writeln" had to be defined?  Incredible.  Not much of a
> scripting language.  And can this handle more than one
> argument?  In newLISP you can say
>
> (println "The number " x " is the answer.")
>
> >
> >           (for-each writeln
> >              (append-map executables ((infix-splitter ":") (getenv
> > "PATH"))))

newLisp looks really nice.  I have been looking at it for a while now.

I have been using SCBL for a lot of my scripting needs, which has been
cumbersome and Ruby - which I really love.

How many people are using newLisp?
From: Stefan Mandl
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <4glpd1F1n4eveU1@news.dfncis.de>
> "writeln" had to be defined?  Incredible.  Not much of a
> scripting language.  And can this handle more than one
> argument?  In newLISP you can say
> 
> (println "The number " x " is the answer.")
> 

Well, for my part, I really like the minimalistic approach of Scheme.

=> (define (writeln . args)
      (map (lambda (a)
              (display a) (display " "))
           args)
      (newline))

=>  (let ((x 3)) (writeln "the number" x "is the answer"))
the number 3 is the answer

Sure, it has few built in tools, but very powerful abstractions and 
therefore can be turned in anything you need.

I'd like to know, which criteria qualify a programming language as 
scripting language?
From: ncruces
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <1151710542.154512.201040@y41g2000cwy.googlegroups.com>
Stefan Mandl wrote:
> => (define (writeln . args)
>       (map (lambda (a)
>               (display a) (display " "))
>            args)
>       (newline))

You should really use for-each instead of map here.
From: Stefan Mandl
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <4glraaF1nviohU1@news.dfncis.de>
ncruces wrote:
> Stefan Mandl wrote:
>> => (define (writeln . args)
>>       (map (lambda (a)
>>               (display a) (display " "))
>>            args)
>>       (newline))
> 
> You should really use for-each instead of map here.
> 

Pardon me, you are right! My Scheme is quite rusty (6 years since I did 
some Scheme coding).

--
 From Scheme Report:

Unlike `map', `for-each' is guaranteed to call proc on the elements of 
the lists in order from the first element(s) to the last, and the value 
returned by `for-each' is unspecified.

--

Do /you/ know the difference between a scripting language and a normal 
programming language, I actually don't?

regrads,
Stefan
From: Ray Dillinger
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <44a5e79b$0$96935$742ec2ed@news.sonic.net>
Stefan Mandl wrote:

> Do /you/ know the difference between a scripting language and a normal 
> programming language, I actually don't?

Well, I would say that there are things a scripting language /must/
have, which a programming language may fail to specify.  In the instant
case, you have to have a way of getting environment variables, a way
of reading file directories, and a way of writing to the console.

A programming language can take the high road and claim that these
system-dependent functions are not part of the language and must be
defined for each system in libraries.... but a scripting language
absolutely must have a standard way to do them.

So, I would say, scheme is not a scripting language because it lacks
crucial facilities for dealing with a filesystem.  But Mzscheme can
be used as a scripting language because these gaps are remedied.

				Bear
From: funkyj
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <1151740417.611554.236130@v61g2000cwv.googlegroups.com>
Stefan Mandl wrote:

>
> Do /you/ know the difference between a scripting language and a normal
> programming language, I actually don't?

What makes a scripting language a scripting language is the fact that
you rather use it for scripting jobs rather than most other languages.
The reason you'd rather use any scripting language over a non-scripting
language is because the language designer makes your job much easier by
providing lots of language primatives and/or libraries that do the
common heavy lifting of scripting.  As others have pointed out these
are:

* convenient access to the file system (directory listings, file
globbing, etc)
* powerful easy to use string manipulation (regular expressions are
manditory)
* minimal or built in boilerplate (e.g. Python's OptionParse module)
* the ability to easily control text based applications (expect.pm,
pexpect and Expect).


Among popular scripting language (Perl, Python, Tcl) abstracting away
much of the underlying OS is a common theme too.

There is no technical reason a Common Lisp implementation couldn't be
made into a nice scripting language.
From: Rob Warnock
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <vpmdnReI9rZz2TvZnZ2dnUVZ_smdnZ2d@speakeasy.net>
funkyj <······@gmail.com> wrote:
+---------------
| There is no technical reason a Common Lisp implementation
| couldn't be made into a nice scripting language.
+---------------

What do you mean "be made into"?!? I find standard CL to
already be a quite nice scripting language all by itself!!

Sspecifically, of the 379 scripts of various kinds in my personal
"~/bin/" directory, 61 of them are some form of Common Lisp or Scheme:

  31 CL-based:
     28 a /usr/local/bin/cmucl -script script text executable
      2 a /usr/local/bin/cmucl -core /usr script text executable
      4 a /usr/local/bin/clisp script text executable
      1 a /usr/local/bin/clisp -Kfull script text executable

  25 Scheme-based:
     18 a /usr/local/bin/mzscheme -r script text executable
      2 a /usr/local/bin/mzscheme -fm- script text executable
      2 a /usr/local/bin/mzscheme -R/usr/ script text executable
      3 a /usr/local/bin/elk -l script text executable

The only reason that Lisp/Scheme is "only" 16% of the total is
that many of the other 84% were written *decades*[1] before I even
started using Lisp/Scheme. In fact, almost all of the scripting I
do these days is done with Common Lisp [usually CMUCL], so I expect
that 16% to continue to grow over time.


-Rob

[1] The oldest scripts that I still use on a daily basis have
    May 1986 filesystem dates on them, but I know that many of those
    actually date from circa 1981. [I suspect that when moving
    stuff around in May 1986 that I accidentally did a "cp -r"
    instead of "cp -rp"... (*sigh*)]

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: funkyj
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <1151794248.456063.308470@m73g2000cwd.googlegroups.com>
Rob Warnock wrote:
> funkyj <······@gmail.com> wrote:
> +---------------
> | There is no technical reason a Common Lisp implementation
> | couldn't be made into a nice scripting language.
> +---------------
>
> What do you mean "be made into"?!? I find standard CL to
> already be a quite nice scripting language all by itself!!

While I am quite fond of lisp syntax and CL I am still vastly more
productive writing scripts in Python.  Why?  Here are some reasons:

* to date I've invested more time in python than I have in CL.  I think
this is a
  minor factor.

* I spend practically no time wrestling with the installation of Python
or python modules.  When I downloaded pexpect installing it was as
simple as extracting the tarfile and running one command that was
mentioned in the INSTALL file ("python setup.py" I think).  I didn't
have to fetch a 3rd party package system and wrestle with it.

Here is an example of some Common Lisp pain:  I recently decided to
upgrade CLisp from 2.35 to the latest (2.38?) using the cygwin updater.
 The update when fine but when it was done SLIME was broken.  I
wrestled with SLIME for hours and one of the new problems but it is
still broken.  I posted a descrption of my problem to
gmane.lisp.slime.devel over a week ago and I still haven't even heard a
"that is too bad" reply much less something helpful.  I have never had
anything break as a result of upgrading Python from one version to
another.  I've never had to fix pdb (the python debugger) -- it has
always worked.  When I had SLIME working I thought it was great but now
that it is broken I don't have time to figure out why.

* The 'Python Library Reference' PDF kicks CL's ass for scripting.
When I want to figure if a library function exists to do some work for
me it is much easier to find it by searching the PLR than it is
searching the hyperspec.  Part of this is because of the PDF reader's
search capability but the other part is that the PLR is much easier to
read than the CLHS.

* the biggest is probably that Python, Perl and TCL have 'expect'
functionality.  With Perl and Python expect is a 3rd party module but
the module system for these languages is standard and installing the
corresponding expect module is a snap.  Not having 'expect' is a show
stopper for scripting.

* Python (my scripting language of choice) and Perl are ubiquitous.  I
can write a script on my PC under cygwin and then move that script to
the FreeBSD servers at work without having to install Perl or Python
because it is already there.  I have CLlisp (via Cygwin) on my PC and
the FreeBSD servers at work have CMUCL but given the other problems
I've experienced I'm skeptical that moving CL programs from
CLisp+Cygwin to FreeBSD+CMUCL will be as trouble free as moving
Python+Cygwin to FreeBSD+Cygwin.  If we happened to have CLisp on the
FreeBSD servers (or CMUCL on Cygwin) I would be more confident in
moving CL scripts from Cygwin to FreeBSD and vice versa.

* does CL come with something comparable to Python's optparse library
in its standard library?   If not then when I use CL for scripting I
have to waste time implementing optparse myself when it is already
provided in Python.

While I really do prefer the base CL language, it really doesn't
measure up to Python or Perl for scripting for the reasons mentioned
above.  

Cheers,
  --jfc
From: Pascal Bourguignon
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <871wt5yktl.fsf@thalassa.informatimago.com>
Stefan Mandl <············@informatik.uni-erlangen.de> writes:
> Do /you/ know the difference between a scripting language and a normal
> programming language, I actually don't?

Take it as a definition:

if:     

        is this a script?

is data, then it's a script. If it's program, then it's not a script.



For example, in bash, you must quote the code:

    echo `date` Is this a script? `if true ; then echo yes ; else echo no ; fi`

so bash is a scripting language.



But in lisp, you must quote the data:

    (print (list (date) "Is This a Script?" (if t (quote yes) (quote no))))

so lisp is a programming language.


Eg. by this definition, HTML is a scripting language.  You must quote
the PHP programs with <?php? ... ?> quotes.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

THIS IS A 100% MATTER PRODUCT: In the unlikely event that this
merchandise should contact antimatter in any form, a catastrophic
explosion will result.
From: Ari Johnson
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <m2psgp4eq9.fsf@hermes.theari.com>
Pascal Bourguignon <···@informatimago.com> writes:

> Stefan Mandl <············@informatik.uni-erlangen.de> writes:
>> Do /you/ know the difference between a scripting language and a normal
>> programming language, I actually don't?
>
> Take it as a definition:
>
> if:     
>
>         is this a script?
>
> is data, then it's a script. If it's program, then it's not a script.
>
>
>
> For example, in bash, you must quote the code:
>
>     echo `date` Is this a script? `if true ; then echo yes ; else echo no ; fi`
>
> so bash is a scripting language.
>
>
>
> But in lisp, you must quote the data:
>
>     (print (list (date) "Is This a Script?" (if t (quote yes) (quote no))))
>
> so lisp is a programming language.
>
>
> Eg. by this definition, HTML is a scripting language.  You must quote
> the PHP programs with <?php? ... ?> quotes.

I would consider that to be the distinction between a template
language and a programming language.  In bash, you aren't quoting all
of the code; rather, you are quoting calls to external programs in
order to get at their output.

I instead consider the difference between "scripting" and
"programming" to be the amount of interaction with external software
and its external environment.  A script tells other programs what to
do; a program does its own thing.  What this also means is that every
language is usable as a scripting language at some level, but some are
more tailored to scripting than others.

For instance, consider the amount of work needed to do in C or in Lisp
to run an external program with a socket connected to its input and
output streams, and then compare to doing the same in Perl.

That's the difference between a scripting language and a programming
language.  You can do programming in Perl and you can do scripting in
Lisp, and any program or script will likely be at least partially into
the gray area between the two, but the features of the language tend
to make one easier than the other.
From: Stefan Mandl
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <4goaamF1o4fh0U1@news.dfncis.de>
> I instead consider the difference between "scripting" and
> "programming" to be the amount of interaction with external software
> and its external environment.  A script tells other programs what to
> do; a program does its own thing.  What this also means is that every
> language is usable as a scripting language at some level, but some are
> more tailored to scripting than others.

So script language = glue language ... the Gnome project advocated 
(still?) scheme interpreter as glue language.

Let me try to find yet another definition maybe one that unites the two 
views:

Asking http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=script
for the meaning of script gives the following:

1 a : something written : TEXT b : an original or principal instrument 
or document c (1) : MANUSCRIPT 1 (2) : the written text of a stage play, 
screenplay, or broadcast; specifically : the one used in production or 
performance
2 a : a style of printed letters that resembles handwriting b : written 
characters : HANDWRITING c : ALPHABET
3 : a plan of action

ok, let's forget about the first (1a), that's just obvious.
(2a) is irrelevant.
(3) seems to make sense in the context of computer languages.

I stick with 3 from now on.
First, it's clear, that writing scripts is similar to programming.
What does "plan of action" imply for the kind of programming.

1) A certain focus: don't talk *about* the entities in the programs. I 
think, the lack of declarations in scripting languages fits this well

2) Actions are central: you call scripts to *do* something like changing 
files, putting stuff on servers and so on. Running for 2 hours and then 
answering "yes" or "no" maybe no typical script task.

3) Specialization for certain tasks. When we assume that actions are 
central, we could actually exclude the ability to define new 
functionality (functional abstraction) from the necessary features of 
scripting languages (of course none of the mature ones does). Then it is 
clear that all necessary actions have to be predefined and the language 
is restricted to certain kinds of tasks.

Taking that back to Pascal's previous definition, it becomes clear why 
Bash-Syntax is the way it is: Bash-language is a language focusing on 
calling programs, doing some minor processing and redirecting to other 
programs, all done with strings as strings are the common Unix data 
type. Hence the ability to mix strings and outputs quite nicely.

For Perl: The focus is on doing more processing in the language, hence a 
lot of special syntax to transform strings.

Tcl and PHP also were created for certain problem domains.

Ok, you get the idea.

So my conclusion is that scripting languages are languages that were 
initially created for certain specialized tasks and only later were 
transformed into full-featured programming languages.

If that is right, nearly all useful languages made their start as 
scripting languages and over time have been transformed into domain 
independent programming languages. An exception are those 
committee-designed languages.

So maybe we consider a language as scripting language, if it is quite 
new and still has to prove its usefulness for certain domains.

So, if we were back in 1960 now, we'd consider Lisp as scripting 
language (if that term would make any sense there).

On the other hand, given the number of different applications that have 
already been done in Python, I think only needs a good compiler to 
compute native code in order to allow us to consider Python a 
full-featured programming language.

regards,
Stefan
From: Ari Johnson
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <m2veqgwnn1.fsf@hermes.theari.com>
Stefan Mandl <············@informatik.uni-erlangen.de> writes:

> 2) Actions are central: you call scripts to *do* something like
> changing files, putting stuff on servers and so on. Running for 2
> hours and then answering "yes" or "no" maybe no typical script task.

This is right in line with what I was trying to say.  Programs do
something inherent to themselves and produce a result.  Usually that
means running for a while and then returning an answer.  Scripts do
their work by calling external programs to do individual pieces of the
work.

It's obvious that, no matter which definitions a person uses, there is
a vast gray area here.
From: Tim X
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <8764igzbfr.fsf@tiger.rapttech.com.au>
Ari Johnson <·········@gmail.com> writes:

> Stefan Mandl <············@informatik.uni-erlangen.de> writes:
>
>> 2) Actions are central: you call scripts to *do* something like
>> changing files, putting stuff on servers and so on. Running for 2
>> hours and then answering "yes" or "no" maybe no typical script task.
>
> This is right in line with what I was trying to say.  Programs do
> something inherent to themselves and produce a result.  Usually that
> means running for a while and then returning an answer.  Scripts do
> their work by calling external programs to do individual pieces of the
> work.
>
> It's obvious that, no matter which definitions a person uses, there is
> a vast gray area here.

Yes. I'm not sure the scripting language/programming language
distinction really buys us much anymore. Originally, they fulfilled
two fairly distinct roles and had clear advantages and disadvantages
in certain domains. However, the basis of these distinctions are
diminishing. for example -

- Scripting Language => interpreted 
  Programming language => compiled
  While this was an important distinction 20 years ago, increases in
  speed make the difference less relevant and many languages which use
  to be interpreted now have compilers and we have a greater use of
  languages based on byte codes and virtual machines.

- Programming Language => rich set of data abstractions
  Script Language => only basic support for data
  abstraction/structures
  This doesn't seem to be true anymore. Even bash and other shells
  have a more sophisticated framework for data structures and
  abstraction than the early Bourne, Korne etc shells. Languages like
  Perl, Python, Tcl etc all provide a good selection of data
  structures and abstraction facilities. 

- Programming Language => low level access to system and services 
  Scripting language => usually restricted to using utility programs
  written in a "programming" language to access low level system calls
  and services. 
  Again, not as true any more. Perl, Python etc all provide access to
  services which were difficult to access with traditional scripts -
  consider trying to use sockets from a scripting language 20 years
  ago. 

- Scripting Language => high level abstracted but less flexible access
  Programming Language => powerful, but low level access
  write a script/program which will recursively descend a
  directory tree and compress all the files over a ceertain size. You
  can do this in C and you can do it in bash, perl or python etc.
  However, which would take longer to write and which one are yo more
  likely to be able to move to any of your Linux/Unix boxes without
  change? (of course, if you have a C library of routines especially
  designed for this sort of task, the differences may be very small).

for me, the difference between a scripting language and programming
language is somewhat artificial these days as those languages which
would have once been called scripting languages have become a lot more
powerful and traditional programming languages seem to have become
more standardised. 

I wouldn't call scheme or common lisp a scripting language as I don't
believe their respective standards include the high level abstractions
which allow you to do basic interaction with the environment very
easily. However, due to the add-ons of various implementations, it
would/could be reasonable to argue that specific implementations of
these languages are a scripting language (i.e. guile, scsh, lush and
even cmucl). 

It may be more profitable to look at the software and decide if it is
a script or a program. If its a script, then the language it is
written in must be a scripting language and if its considered a
program, then its language is a programming language - but what
defines a script compared to a program? 

Maybe there is no real benefit in making a distinction at all? Does it
actually give us anything apart for the source of arguements as to
whether X is a scripting language or a programming language? 

Tim





-- 
tcross (at) rapttech dot com dot au
From: Thomas F. Burdick
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <xcvfyhk72fq.fsf@conquest.OCF.Berkeley.EDU>
Ari Johnson <·········@gmail.com> writes:

> I instead consider the difference between "scripting" and
> "programming" to be the amount of interaction with external software
> and its external environment.  A script tells other programs what to
> do; a program does its own thing.  What this also means is that every
> language is usable as a scripting language at some level, but some are
> more tailored to scripting than others.
> 
> For instance, consider the amount of work needed to do in C or in Lisp
> to run an external program with a socket connected to its input and
> output streams, and then compare to doing the same in Perl.

(I assume you mean pipes, not a socket because as far as I'm aware,
doing this with a socket isn't particularly easier in Perl than other
languages.)

Okay, let's consider them.  Perl:

  open CAT, "| cat |";
  print CAT "one\ntwo\nthree\n";
  close CAT;         
  foreach my $line (<CAT>) {
    print $line;
  }
  
Lisp (specifically SBCL):

  (let ((cat (run-program "cat" nil :input :stream :output :stream
                          :search t :wait nil)))
    (format (process-input cat) "one~%two~%three~%")
    (close (process-input cat))
    (loop for line = (read-line (process-output cat) nil nil)
          while line do (write-line line)))

The lisp version is more verbose, but not particularly more difficult.
From: Ari Johnson
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <m2y7vbhpw5.fsf@hermes.theari.com>
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> (I assume you mean pipes, not a socket because as far as I'm aware,
> doing this with a socket isn't particularly easier in Perl than other
> languages.)

My understanding is that pipe(2) is to SVr4 as socketpair(2) is to
BSD.  I may be wrong in that understanding. :)

> Okay, let's consider them.  Perl:
>
>   open CAT, "| cat |";
>   print CAT "one\ntwo\nthree\n";
>   close CAT;         
>   foreach my $line (<CAT>) {
>     print $line;
>   }
>   
> Lisp (specifically SBCL):
>
>   (let ((cat (run-program "cat" nil :input :stream :output :stream
>                           :search t :wait nil)))
>     (format (process-input cat) "one~%two~%three~%")
>     (close (process-input cat))
>     (loop for line = (read-line (process-output cat) nil nil)
>           while line do (write-line line)))
>
> The lisp version is more verbose, but not particularly more difficult.

This proves, depending on how you approach the discussion, one of the
following things:

1. Lisp is a scripting language
 -or-
2. There is no real difference between a scripting language and a
   programming language
From: Thomas F. Burdick
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <xcvbqs57q5x.fsf@conquest.OCF.Berkeley.EDU>
Ari Johnson <·········@gmail.com> writes:

> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> 
> > (I assume you mean pipes, not a socket because as far as I'm aware,
> > doing this with a socket isn't particularly easier in Perl than other
> > languages.)
> 
> My understanding is that pipe(2) is to SVr4 as socketpair(2) is to
> BSD.  I may be wrong in that understanding. :)

socketpair is more capable than pipe, although some systems implement
the latter in terms of the former.  I don't know the history, but I
can't imagine how Unix could work without one of the two, so I assumed
pipe is the ancient (pre System V) interface.

> This proves, depending on how you approach the discussion, one of the
> following things:
> 
> 1. Lisp is a scripting language
>  -or-
> 2. There is no real difference between a scripting language and a
>    programming language

My take on it is (3) yuck, all that line noise buys you verry little.
From: Stefan Mandl
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <4gn9e5F1o42j1U1@news.dfncis.de>
> Take it as a definition:
> 
> if:     
> 
>         is this a script?
> 
> is data, then it's a script. If it's program, then it's not a script.
> 
> 
> 
> For example, in bash, you must quote the code:
> 
>     echo `date` Is this a script? `if true ; then echo yes ; else echo no ; fi`
> 
> so bash is a scripting language.

Pascal, thanks for this definition, it's very interesting, as it 
describes a programming style independent of the language.

Let me expand on this a little:

Def.: *Script-style programming* = write the program's output literally 
inside the program.

Given that definition, any language contains some script-language 
aspects, as any language (that comes to my mind right now) let's you 
specify certain parts of the output literally.

Could we say that the language of FORMAT as included in CL is a 
script-language embedded in CL?

Guess we could use some combination of reader and compiler macros to get 
a script-mode in CL, like:

...

(script-mode
   Ok, this is some stupid script coded with
      embedded computation: `(sqrt 3)`
   )
...

Would you consider the commonly used HTML-generating macros scripting 
features?

--
regards,
Stefan
From: Pascal Bourguignon
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <87veqhwhqy.fsf@thalassa.informatimago.com>
Stefan Mandl <············@informatik.uni-erlangen.de> writes:

>> Take it as a definition:
>> if:             is this a script?
>> is data, then it's a script. If it's program, then it's not a
>> script.
>> For example, in bash, you must quote the code:
>>     echo `date` Is this a script? `if true ; then echo yes ; else
>> echo no ; fi`
>> so bash is a scripting language.
>
> Pascal, thanks for this definition, it's very interesting, as it
> describes a programming style independent of the language.
>
> Let me expand on this a little:
>
> Def.: *Script-style programming* = write the program's output
> literally inside the program.
>
> Given that definition, any language contains some script-language
> aspects, as any language (that comes to my mind right now) let's you
> specify certain parts of the output literally.
>
> Could we say that the language of FORMAT as included in CL is a
> script-language embedded in CL?
>
> Guess we could use some combination of reader and compiler macros to
> get a script-mode in CL, like:
>
> ...
>
> (script-mode
>   Ok, this is some stupid script coded with
>      embedded computation: `(sqrt 3)`
>   )
> ...
>
> Would you consider the commonly used HTML-generating macros scripting
> features?

Well, of course, CL is good at everything:

(print
  `(Ok, this is some stupid script coded with
    some embedded computation: ,(sqrt 3)))

That is, if we wrote a REPL that'd put an implicit quasiquote, we
could just write:

   (Ok, this is some stupid script coded with
     some embedded computation: ,(sqrt 3))

and we'd just have to prefix a comma before any command:

   ,(print (+ 1 2))
   


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

"You can tell the Lisp programmers.  They have pockets full of punch
 cards with close parentheses on them." --> http://tinyurl.com/8ubpf
From: Rob Warnock
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <l_idnXw0YrSNHjrZnZ2dnUVZ_vOdnZ2d@speakeasy.net>
Pascal Bourguignon  <···@informatimago.com> wrote:
+---------------
| That is, if we wrote a REPL that'd put an implicit quasiquote...
+---------------

Oh, you mean Scsh!  ;-}  ;-}

    http://www.scsh.net/
    http://sourceforge.net/projects/scsh/


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Ludovic Courtès
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <87odw54knr.fsf@laas.fr>
Hi,

Pascal Bourguignon <···@informatimago.com> writes:

> Well, of course, CL is good at everything:
>
> (print
>   `(Ok, this is some stupid script coded with
>     some embedded computation: ,(sqrt 3)))

Interestingly, document formatting (programming) languages have interest
in making it easy to mix "data" and programs.  Skribe [0], which derives
from Scheme, provides an extended syntax allowing for this:


  (p [This is text that is ,(emph [mixed]) with ,(bold [function
      calls]).])

is equivalent to this:

  (p "This is text that is " (emph "mixed") " with "
     (bold "function calls") ".")

Lout [1], OTOH, takes a more radical approach: every token is "text",
unless the interpreter recognizes it as a previously-defined symbol:

  This is text that is @I { mixed } with @B { function calls }.

From this example, one can hardly identify function calls.  Well, of
course, ·@I' and ·@B' are easily recognizable as such.  But the word
"is", for instance, could very well have been defined earlier as a
function:

  def "is" right word   { @I { "is" } @B { word } }

Still, I would not call any of these languages a "scripting language".

Thanks,
Ludovic.

[0] http://www-sop.inria.fr/mimosa/fp/Skribe/
[1] http://lout.sf.net/
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <8764idcxff.fsf@qrnik.zagroda>
···············@laas.fr (Ludovic Court�s) writes:

> Lout [1], OTOH, takes a more radical approach: every token is "text",
> unless the interpreter recognizes it as a previously-defined symbol:

This is evil.

-- 
   __("<         Marcin Kowalczyk
   \__/       ······@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/
From: Robert Uhl
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <m38xn8dkju.fsf@NOSPAMgmail.com>
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
>
>> Lout [1], OTOH, takes a more radical approach: every token is "text",
>> unless the interpreter recognizes it as a previously-defined symbol:
>
> This is evil.

Not necessarily.  In a text markup language, it makes sense for the
actual text to be the default, since markup typically consists of large
amounts of text and small amount of code.  This is in contrast to most
programs, which are typically large amounts of code and small amounts of
text.  Different domains call for different approaches.

-- 
Robert Uhl <http://public.xdi.org/=ruhl>
She [Ingrid Newkirk] has one of those faces that you wouldn't tire 
of testing new cosmetic products on.                      --Tanuki
From: Christian Haselbach
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <e85ihv$2dj$1@online.de>
> Do /you/ know the difference between a scripting language and a normal 
> programming language, I actually don't?

Shakespeare is the only scripting language I know of ;-)
http://shakespearelang.sourceforge.net/
http://www.99-bottles-of-beer.net/language-shakespeare-664.html

Romeo:
	Speak your mind.

Regards,
Christian
From: William James
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <1151717114.338592.194400@p79g2000cwp.googlegroups.com>
Stefan Mandl wrote:
> > "writeln" had to be defined?  Incredible.  Not much of a
> > scripting language.  And can this handle more than one
> > argument?  In newLISP you can say
> >
> > (println "The number " x " is the answer.")
> >
>
> Well, for my part, I really like the minimalistic approach of Scheme.
>
> => (define (writeln . args)
>       (map (lambda (a)
>               (display a) (display " "))
>            args)
>       (newline))
>
> =>  (let ((x 3)) (writeln "the number" x "is the answer"))
> the number 3 is the answer

This seems the natural way in newLISP:

(define (writeln)
  (println (join (map string (args)) " ")))

(writeln "The number" 8 "is the answer.")

The number 8 is the answer.
From: William James
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <1151716491.627881.201500@b68g2000cwa.googlegroups.com>
············@gmail.com wrote:
> Here's a section from the scsh FAQ on the comp.lang.scheme.scsh. I look
> at those code examples and I'm very, very charmed by how readable scsh
> code is in comparison to the more cryptic scripting languages.
>
>
> 3.7.4 Example script
> --------------------
>
> The following code snippets aim to provide an idea of how scsh compares
> with other common scripting languages. They all print a list of all the
> executables available in the current PATH to the standard output
> (improvements to these examples are welcome).

>    - `scsh'
>           #!/usr/local/bin/scsh -s
>           !#
>
>           (define (executables dir)
>             (with-cwd dir
>                (filter file-executable? (directory-files dir #t))))
>           (define (writeln x) (display x) (newline))
>
>           (for-each writeln
>              (append-map executables ((infix-splitter ":") (getenv
> "PATH"))))

In newLISP.  (For windoze' sake, I'm using a bizarre method
of determining if a file is executable.)

(define (exec? f)
  (regex {\.(exe|com|bat)$} (lower-case f)))

(define (executables dir)
  (filter exec? (directory dir)))

(map println (flat
  (map executables (parse (env "PATH") ";"))))

----
Another way:

(dolist (dir (parse (env "PATH") ";"))
  (dolist (file (directory dir))
    (if (exec? file) (println file))))
From: Stefan Mandl
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <4gm125F1oegrhU1@news.dfncis.de>
 > [] I'm using a bizarre method
> of determining if a file is executable.)
> 
> (define (exec? f)
>   (regex {\.(exe|com|bat)$} (lower-case f)))

bizarre?

Pragmatic!


regards,
Stefan
From: Darren New
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <cHTpg.5538$MF6.2954@tornado.socal.rr.com>
Stefan Mandl wrote:
> bizarre?
> Pragmatic!

And incorrect. The PATHEXT variable is what you're looking for. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Native Americans used every part
     of the buffalo, including the wings.
From: Chris Barts
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <pan.2006.07.05.07.11.48.571475@tznvy.pbz>
On Sat, 01 Jul 2006 03:22:14 +0200, Stefan Mandl wrote:

>  > [] I'm using a bizarre method
>> of determining if a file is executable.)
>> 
>> (define (exec? f)
>>   (regex {\.(exe|com|bat)$} (lower-case f)))
> 
> bizarre?
> 
> Pragmatic!

And not always correct. There are other extensions commonly used for
executable files (.scr comes to mind, and I'm sure others might too), and
there is no general Right Way to solve the problem because I don't think
you can detect any local changes.

It's an 80% solution, in other words, and it's as good as we can get.

-- 
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
From: Darren New
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <FhRqg.12352$MF6.4368@tornado.socal.rr.com>
Chris Barts wrote:
> there is no general Right Way to solve the problem because I don't think
> you can detect any local changes.

Yes. The PATHEXT environment variable lists all the extensions you 
should try to execute as a command on the command-line.

> It's an 80% solution, in other words, and it's as good as we can get.

No wonder Windows software sucks so often. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Native Americans used every part
     of the buffalo, including the wings.
From: Rob Thorpe
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <1152028294.395812.67110@a14g2000cwb.googlegroups.com>
············@gmail.com wrote:
> Here's a section from the scsh FAQ on the comp.lang.scheme.scsh. I look
> at those code examples and I'm very, very charmed by how readable scsh
> code is in comparison to the more cryptic scripting languages.
>
>    - `scsh'
>           #!/usr/local/bin/scsh -s
>           !#
>
>           (define (executables dir)
>             (with-cwd dir
>                (filter file-executable? (directory-files dir #t))))
>           (define (writeln x) (display x) (newline))
>
>           (for-each writeln
>              (append-map executables ((infix-splitter ":") (getenv
> "PATH"))))

It's quite a nice demonstration.  In some ways though clarity is down
to how the language is used.  If I were writing this in Perl I would
not write the way given here.  I would write:

#!/usr/local/bin/perl

my $dir, $path = $ENV{path}

for $dir (split /:/, $path) {
  opendir DIR, $dir or die "can't opendir $dir: $!";
  for readdir DIR {
    -x "$dir/$_" && # Check exists and executable
    !-d _ && # Check not a directory
    print "$_\n"
  }
  closedir DIR;
}

Many Perl programmer would say this is unidiomatic. I would agree but
say that it is clearer to break complex lines apart a little.

The other examples also show how modern languages are relatively
difficult to read.  Older imperative languages like Pascal are easier.


Note that in the Scheme code there are some genuine problems for those
who do not use intelligent editors.  At the end it says:-

>           (for-each writeln
>              (append-map executables ((infix-splitter ":") (getenv
> "PATH"))))

How does the programmer know to type 4 closing parentheses?  If they
are not using a good editor it is hard to tell how many to type.
Obviously one is needed to match the "(for-each" but after that the
programmer must count parens from left to right across the second line.
 This is easy with Emacs which matches parens, and OK with Vi if you
know about the "[]" keys.  You can do it with a simple editor too if
you format it like this, for example:-

(for-each writeln
  (append-map executables
    ((infix-splitter ":") (getenv "PATH"))
  )
)

The programmer I know who hate lisp seem to hate it because they were
never taught how to edit it and spent hours at university in front of
notepad counting parens.

Many editors are reasonably good these days, so this shouldn't really
be a problem.  People often make it a problem for themselves by
insisting on using very basic editors though.
From: Robert Sedlacek
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <44aa956a$0$29127$9b4e6d93@newsread4.arcor-online.net>
In comp.lang.scheme Rob Thorpe <·············@antenova.com> wrote

>   for readdir DIR {
>     -x "$dir/$_" && # Check exists and executable
>     !-d _ && # Check not a directory
>     print "$_\n"
>   }

for readdir doesn't look like valid Perl, tho :) I guess I'd do it kind
of like this, but change this little part to

  while ( my $entry = readdir $dir ) {
      next if not -x "$dir/$entry"
           or not -d _;
      print "$_\n";
  }

> Many Perl programmer would say this is unidiomatic. I would agree but
> say that it is clearer to break complex lines apart a little.

The problem I see is that there's Perl and there's Perl. You can make
amazingly useful scripts with not much code, but some things are just
"quick hacks" and not suited for development with more than one person,
unless they're enough documented. But it get's a bit messy when people
judge a whole language and it's programmers based on some quick hacks
they've seen :)


p

-- 
There's a storm on the horizon. It's gonna be everywhere.
                        -- Michael Moynihan
From: Kaz Kylheku
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <1152039519.155943.240650@75g2000cwc.googlegroups.com>
Here is the code snippet from implementation of the "create" command in
Meta-CVS which walks the directory and classifies the files. This uses
the FOR-EACH-FILE-INFO macro from code/dirwalk.lisp.

          (for-each-file-info (fi ".")
            (cond
              ((regular-p fi)
                 (let* ((path (canonicalize-path (file-name fi)))
                        (suffix (suffix (file-name fi)))
                        (file (mapping-generate-id :suffix suffix)))
                   (chatter-info "~a <- ~a~%" file path)
                   (push (make-mapping-entry :kind :file
                                             :id file
                                             :path path
                                             :executable (executable-p
                                                           fi))
                         filemap)
                   (when suffix
                     (setf types (adjoin (list suffix :default)
                                         types :test #'equal)))))
              ((symlink-p fi)
                 (let ((path (canonicalize-path (file-name fi)))
                       (id (mapping-generate-id :prefix "S-" :no-dir
t)))
                   (chatter-info "~a <- ~a~%" id path)
                   (push (make-mapping-entry :kind :symlink
                                             :id id
                                             :path path
                                             :target (readlink path))
                         filemap)))))

This actually builds up the mapping document which is printed to a file
and put under version control: the key to the directory structure
versioning.

The big decision here is to pick apart symbolic links and regular
files, because these have to be treated somewhat differently.

Some highlights:

MAKE-MAPPING-ENTRY is a constructor which creates a mapping entry
structure. These structures are serialized to a list form when written
out to the MAP file, but in memory, we use a structure representation.
(That was not originally the case; in true Lisp spirit of evolving
product from prototype, the early versions just used lists).

The directory walking is done by the FOR-EACH-FILE-INFO, which
recursively crawls the directory structure. It's quite sophisticated
under the hood. When errors are encountered, there are restarts at
every directory level.

For instance, suppose you encounter a directory where you don't have
permissions. A condition will be raised, and there will be restarts
allowing you to continue the walk at different levels. And of course,
no matter how the macro terminates, it will restore the current
directory properly. At the various nesting levels, it actually keeps
open file decriptors, which locate the current directory there. A
fchdir() system call is executed on these descriptors during unwinding.

Oh and by the way, do you want that in preorder or postorder (depth or
breadth first?) There is a keyword argument for that:

  (for-each-file-info (fi "." :postorder t) ...)

Now the directory entries, including subdirectories, are processed
before each directory.

Do you want to suppress recursion and just do the directory?

  (for-each-file-info (fi "." :norecurse t) ...)

Oh, and within the block scope created by FOR-EACH-FILE-INFO you can
call the lexical function (SKIP).   What this does is abort the
processing of the current directory, and goes on to the next directory.
For instance, this is used to skip CVS/ directories.

      (for-each-file-info (fi ".")
        (when (and (directory-p fi)
                   (path-equal (basename (file-name fi)) "CVS"))
          (skip))
        ... process it ...)

That's the nice thing about having a programmable programming language.
You roll your own syntax.

So how about the "identify all executables in the $PATH" task? Using
just the libraries in the Meta-CVS image, it could be done like this:

  (in-package 'mcvs) ;; of course

  (dolist (path-element (split-fields (ext:getenv "PATH") ":"))
    (for-each-file-info (fi path-element :norecurse t)
      (when (and (regular-p fi) (executable-p fi))
        (format t "~a is executable~%" (file-name fi)))))

Shorter and more comprehensible than the shell script version.
EXT:GETENV is a CLISP extension.

The executable-p does not hide the unixism that directory search
permissions are the same as execute permissions, so we need the test
for a regular file.
From: Tin Gherdanarra
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <4h578vF1q2kn9U1@individual.net>
············@gmail.com wrote:
> 
> Here's a section from the scsh FAQ on the comp.lang.scheme.scsh. I look
> at those code examples and I'm very, very charmed by how readable scsh
> code is in comparison to the more cryptic scripting languages.

Do you mean this in a challenging, polemic fashion? I
think tcsh compares quite well. tcsh's snippet has more characters, but
not more logic. I think larger examples would compare even better.

> 
> 
> 3.7.4 Example script
> --------------------
> 
> The following code snippets aim to provide an idea of how scsh compares
> with other common scripting languages. They all print a list of all the
> executables available in the current PATH to the standard output
> (improvements to these examples are welcome).
> 
>    - `sh'
>           #!/bin/sh
> 
>           IFS=':'
>           for d in $PATH; do
>             for f in $d/*; do
>               [ -x $f -a ! -d $f ] && echo $f
>             done
>           done
> 
>    - `perl'
> 
>           What is the sound of Perl? Is it not the sound of a wall that
>           people have stopped banging their head against?
>           - _Larry Wall_
> 
>           #!/usr/local/bin/perl
> 
>           for my $dir (split /:/, $ENV{PATH}) {
>              opendir DIR, $dir or die "can't opendir $dir: $!";
>              -x "$dir/$_" && !-d _ && print "$_\n" for readdir DIR;
>              closedir DIR;
>           }
> 
>    - `python'
>           #!/usr/local/bin/python
> 
>           import os, string, stat
>           for d in string.split(os.environ['PATH'], ':'):
>              for f in os.listdir(d):
>                 mode = os.lstat(d + '/' + f)[stat.ST_MODE]
>                 if not stat.S_ISDIR(mode):
>                    print f
> 
>    - `ruby'
>           #!/usr/bin/ruby
> 
>           ENV["PATH"].split(/:/).each {|path|
>             Dir.foreach(path) {|file|
>               puts(file) if File.stat(File.join(path,
> file)).executable?
>             }
>           }
> 
>    - `scsh'
>           #!/usr/local/bin/scsh -s
>           !#
> 
>           (define (executables dir)
>             (with-cwd dir
>                (filter file-executable? (directory-files dir #t))))
>           (define (writeln x) (display x) (newline))
> 
>           (for-each writeln
>              (append-map executables ((infix-splitter ":") (getenv
> "PATH"))))
> 


-- 
Lisp kann nicht kratzen, denn Lisp ist fluessig
From: Rob Thorpe
Subject: Re: How could they complain about lisp-scheme syntax
Date: 
Message-ID: <1152261975.759224.97270@k73g2000cwa.googlegroups.com>
Tin Gherdanarra wrote:
> ············@gmail.com wrote:
> >
> > Here's a section from the scsh FAQ on the comp.lang.scheme.scsh. I look
> > at those code examples and I'm very, very charmed by how readable scsh
> > code is in comparison to the more cryptic scripting languages.
>
> Do you mean this in a challenging, polemic fashion? I
> think tcsh compares quite well. tcsh's snippet has more characters, but
> not more logic. I think larger examples would compare even better.
>

Just to demonstrate one of the problems with shell I'll ask the
following question:-
What tcsh snippet?


In some ways though I think your right, I've done quite long things in
bash.  When file manipulation is the issue it's often quite appropriate.