[6669] in Perl-Users-Digest
Perl-Users Digest, Issue: 294 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Apr 13 20:07:45 1997
Date: Sun, 13 Apr 97 17:00:19 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 13 Apr 1997 Volume: 8 Number: 294
Today's topics:
Re: -e command-line option <rra@stanford.edu>
CORBA for perl? (David Tauzell)
Re: Crypt function doesn't appear to work <merlyn@stonehenge.com>
Re: Crypt function doesn't appear to work (Tad McClellan)
Re: getting a single keystroke (root)
Re: How to extract string starting with n characters? (A. Deckers)
Index of items in a list? (Michael Friendly)
Re: Index of items in a list? <fawcett@nynexst.com>
Re: Index of items in a list? (David Alan Black)
Re: lock file necessary? <merlyn@stonehenge.com>
Re: Newbie: Webify A Program? (Tad McClellan)
Opening Files That Match *.TXT Wildcard - How? (Frank Fisher)
Re: Opening Files That Match *.TXT Wildcard - How? <rra@stanford.edu>
Re: Perl Database Question (Tad McClellan)
Re: perl executable by core dump <rra@stanford.edu>
Re: Perl NT problems (Gurusamy Sarathy)
questions about timelocal.pl <philipp@ntex.com>
Re: Reply to Ousterhout's reply (was Re: Ousterhout and (John Ousterhout)
Re: Reply to Ousterhout's reply (was Re: Ousterhout and (Charles Lin)
Re: Reply to Ousterhout's reply (was Re: Ousterhout and (Paul Wilson)
Use of Tcl without Tk (Mike Hopkirk)
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 13 Apr 1997 15:25:50 -0700
From: Russ Allbery <rra@stanford.edu>
To: Chris Andrew <earl@bell.us>
Subject: Re: -e command-line option
Message-Id: <qumlo6mk1ap.fsf@cyclone.stanford.edu>
[ Posted and mailed. ]
Chris Andrew <earl@bell.us> writes:
> Can anyone tell me where to read more about the -e option or where to
> find some examples of *larger* uses of it.
> What I've found in Learning Perl, Software Engineering with Perl or
> Programming Perl (both editions) is simply almost nothing. The largest
> descrition I've found is in Learning Perl page 191 and doesn't tell
> much.
I'm not quite clear what you're looking for here. -e lets you enter a
one-line script (for some definition of "line") on the command line rather
than putting it in a file. I tend to use it for testing things, for doing
simple substitutions and processing in combination with -p, -n, and -i.
> I need larger examples passing parameters.
What sort of parameters are you trying to pass in?
Here are some examples of one-line Perl scripts using -e from the Perl
FAQ (section 3):
Can I write useful perl programs on the command line?
Yes. Read the perlrun manpage for more information. Some
examples follow. (These assume standard Unix shell
quoting rules.)
# sum first and last fields
perl -lane 'print $F[0] + $F[-1]'
# identify text files
perl -le 'for(@ARGV) {print if -f && -T _}' *
# remove comments from C program
perl -0777 -pe 's{/\*.*?\*/}{}gs' foo.c
# make file a month younger than now defeating reaper daemons
perl -e '$X=24*60*60; utime(time(),time() + 30 * $X,@ARGV)' *
# find first unused uid
perl -le '$i++ while getpwuid($i); print $i'
--
Russ Allbery (rra@stanford.edu) <URL:http://www.eyrie.org/~eagle/>
------------------------------
Date: 13 Apr 1997 23:28:22 GMT
From: tauzell@math.umn.edu (David Tauzell)
Subject: CORBA for perl?
Message-Id: <5irq6m$q13@epx.cis.umn.edu>
Does anybody have any interest in writing a CORBA ORB for
Perl, or has anybody seen one? The reason I think that this
would be usefull is that several web servers are going to
be using CORBA and IIOP as a replacement for CGI (something like FASTcgi).
It would be nice for Perl to fit within this realm, too.
--
---
David Tauzell. I like unix.
------------------------------
Date: 13 Apr 1997 14:20:10 -0700
From: Randal Schwartz <merlyn@stonehenge.com>
To: dblack@icarus.shu.edu (David Alan Black)
Subject: Re: Crypt function doesn't appear to work
Message-Id: <8c67xqk4c5.fsf@gadget.cscaper.com>
>>>>> "David" == David Alan Black <dblack@icarus.shu.edu> writes:
David> friedman@medusa.acs.uci.edu (Eric D. Friedman) writes:
>> use subs qw(randalphanum);
David> This one 'l' spelling is really catching on :-)
Would that make me the [Randal] Phanum of the Opera-tor?
print "Just another Perl hacker," # but not what the media calls "hacker!" :-)
## legal fund: $20,495.69 collected, $182,159.85 spent; just 505 more days
## before I go to *prison* for 90 days; email fund@stonehenge.com for details
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn@ora.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me
------------------------------
Date: Sun, 13 Apr 1997 16:15:47 -0500
From: tadmc@flash.net (Tad McClellan)
Subject: Re: Crypt function doesn't appear to work
Message-Id: <3eiri5.tc3.ln@localhost>
Randal Schwartz (merlyn@stonehenge.com) wrote:
: >>>>> "David" == David Alan Black <dblack@icarus.shu.edu> writes:
: David> friedman@medusa.acs.uci.edu (Eric D. Friedman) writes:
: >> use subs qw(randalphanum);
: David> This one 'l' spelling is really catching on :-)
: Would that make me the [Randal] Phanum of the Opera-tor?
Your fame as a punster is well known.
This one is like bleu cheese left out of the refrigerator though... ;-)
--
Tad McClellan SGML Consulting
Tag And Document Consulting Perl programming
tadmc@flash.net
------------------------------
Date: 13 Apr 1997 23:01:28 GMT
From: root@localhost.localdomain (root)
Subject: Re: getting a single keystroke
Message-Id: <5irok8$j4j@ecuador.earthlink.net>
Thanks to all who responded to my question on getting a single character
from the keyboard.
jlerner@panix.com (Joshua Lerner) wrote:
>...Read the perlfunc man page (you'll need Perl 5) a little more closely:
>
> getc Returns the next character from the input file
> attached to FILEHANDLE, or a null string at end of
> file. If FILEHANDLE is omitted, reads from STDIN.
> This is not particularly efficient. It cannot be
> used to get unbuffered single-characters, however.
> For that, try something more like:
>
> if ($BSD_STYLE) {
> system "stty cbreak </dev/tty >/dev/tty 2>&1";
> }
> else {
> system "stty", '-icanon', 'eol', "\001";
> }
>
> $key = getc(STDIN);
>
> if ($BSD_STYLE) {
> system "stty -cbreak </dev/tty >/dev/tty 2>&1";
> }
> else {
> system "stty", 'icanon', 'eol', '^@'; # ascii null
> }
This is too ugly to bear!
David Black (dblack@icarus.shu.edu) gaves the solution I applied
successfully to my own script:
> use Term::ReadKey;
> ReadMode 4; # go into raw mode
> $key = ReadKey 0; #
> ReadMode 0; # go back to normal
This is less ugly and seems to work. But it's still bad -- four
statements doing the work that should be done with a single getkey() and
getting the user too involved in system issues that a high-level language
should handle for him/her.
------------------------------
Date: 13 Apr 1997 21:01:16 GMT
From: Alain.Deckers@man.ac.uk (A. Deckers)
Subject: Re: How to extract string starting with n characters?
Message-Id: <slrn5l2ics.jke.Alain.Deckers@nessie.mcc.ac.uk>
In <5i32e2$4ue@gcsin3.geccs.gecm.com>,
Jim Michael <jim.michael@gecm.com> wrote:
>I am looking for a function for extracting a string starting with a
>specific substring, and ending with a specific character, e.g. all names
>starting with "John", ending with a space (Johnson, Johnstone, Johns,..).
>Does this already exist in Perl? Pointer to appropriate reference
>appreciated. TIA.
Use regular expressions:
if ($string =~ m|^John.* $|) {
do_something_with_it($string);
}
sub do_something_with_it {
my $string = shift;
#...
}
Look at the perlre manual page.
HTH,
Alain
--
Perl information: <URL:http://www.perl.com/perl/>
Perl FAQ: <URL:http://www.perl.com/perl/faq/>
Perl software: <URL:http://www.perl.com/CPAN/>
>>>>>>>>>>>>> NB: comp.lang.perl.misc is NOT a CGI group <<<<<<<<<<<<<<
------------------------------
Date: 13 Apr 1997 20:12:17 GMT
From: friendly@hotspur.psych.yorku.ca (Michael Friendly)
Subject: Index of items in a list?
Message-Id: <5iren1$cqp$1@sunburst.ccs.yorku.ca>
I have an application where I have a list of names (@names), and
another list (@permuted) which contains (??) the same names in
a possibly different order. Eg.,
@names = ('henry', 'lucy', 'snoopy' 'linus');
@permuted = ('snoopy', 'henry', 'lucy', 'mary');
I need to find the position index of each element of @names in
@permuted, i.e., the result should be the list
@indices = ( 3, 1, 2).
There must be a way to improve this brute-force use of two
nested loops (a job for map??)
foreach $v (@permuted) {
foreach $i (0..$#names) {
push(@indices, 1+$i) if ($v =~ /$names[$i]/i);
}
}
Any ideas?
--
Michael Friendly Internet: friendly@hotspur.psych.yorku.ca (NeXTmail OK)
Psychology Dept
York University Voice: 416 736-5118 Fax: 416 736-5814
4700 Keele Street http://www.math.yorku.ca/SCS/friendly.html
Toronto, ONT M3J 1P3 CANADA
------------------------------
Date: 13 Apr 1997 17:37:53 -0400
From: Tom Fawcett <fawcett@nynexst.com>
Subject: Re: Index of items in a list?
Message-Id: <8jk9m6ppse.fsf@nynexst.com>
friendly@hotspur.psych.yorku.ca (Michael Friendly) writes:
> I have an application where I have a list of names (@names), and
> another list (@permuted) which contains (??) the same names in
> a possibly different order. Eg.,
>
> @names = ('henry', 'lucy', 'snoopy' 'linus');
> @permuted = ('snoopy', 'henry', 'lucy', 'mary');
>
> I need to find the position index of each element of @names in
> @permuted, i.e., the result should be the list
> @indices = ( 3, 1, 2).
>
> There must be a way to improve this brute-force use of two
> nested loops (a job for map??)
>
> foreach $v (@permuted) {
> foreach $i (0..$#names) {
> push(@indices, 1+$i) if ($v =~ /$names[$i]/i);
> }
> }
> Any ideas?
@indices{@names} = (0 .. $#names);
@permuted_indices = map($indices{$_}, @permuted);
You might be able to get this to a single line, but I'll leave that
to someone else.
-Tom
------------------------------
Date: 13 Apr 1997 22:43:15 GMT
From: dblack@icarus.shu.edu (David Alan Black)
Subject: Re: Index of items in a list?
Message-Id: <5irni3$g03@pirate.shu.edu>
Hello -
friendly@hotspur.psych.yorku.ca (Michael Friendly) writes:
>I have an application where I have a list of names (@names), and
>another list (@permuted) which contains (??) the same names in
>a possibly different order. Eg.,
>@names = ('henry', 'lucy', 'snoopy' 'linus');
>@permuted = ('snoopy', 'henry', 'lucy', 'mary');
>I need to find the position index of each element of @names in
>@permuted, i.e., the result should be the list
>@indices = ( 3, 1, 2).
>There must be a way to improve this brute-force use of two
>nested loops (a job for map??)
>foreach $v (@permuted) {
> foreach $i (0..$#names) {
> push(@indices, 1+$i) if ($v =~ /$names[$i]/i);
> }
>}
>Any ideas?
Two questions/comments, followed by a (probably extravagantly
inefficient) version using map():
First - Are you sure you want the indices to start at 1 instead
of 0? (I guess you are sure, but it still raises a wee red
flag.)
Second - If @permuted were qw(snoopy mary henry lucy), you'd
get the same @indices - but how would you know that mary
hadn't matched? Perhaps you should create an entry in @indices
for every element of @permuted, making it (say) undef if there's
no match.
%pnhash = map { lc($_), $c++ } @names;
@indices = map { $pnhash{lc($_)} } @permuted;
Obviously, this creates a hash out of the indices and elements
of @names, which may be more memory than you want to use up
(depending on size of lists involved). It also follows the
implicit advice in both of the points about, which you could
circumvent:
$c = 1;
%pnhash = map { lc($_), $c++ } @names;
@indices = grep /./, map { $pnhash{lc($_)} } @permuted;
David Black
dblack@icarus.shu.edu
------------------------------
Date: 13 Apr 1997 14:17:12 -0700
From: Randal Schwartz <merlyn@stonehenge.com>
To: pod@null.net
Subject: Re: lock file necessary?
Message-Id: <8c912mk4h3.fsf@gadget.cscaper.com>
>>>>> "Mariusz" == Mariusz Zydyk <pod@null.net> writes:
Mariusz> ------- I believe that according to some standard, writing to a file
Mariusz> in append mode is atomic. That is why we have a separate mode. The
Mariusz> process actually does not seek to the end of file, the kernel does.
"According to some standard." That's what I like about standards,
there are *so* many of them to chose from. Thus, on some machines,
this standard is *not* followed. And therefore, to be safe, one must
seek() after locking, or you'll get bitten some day.
print "Just another Perl hacker," # but not what the media calls "hacker!" :-)
## legal fund: $20,495.69 collected, $182,159.85 spent; just 505 more days
## before I go to *prison* for 90 days; email fund@stonehenge.com for details
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn@ora.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me
------------------------------
Date: Sun, 13 Apr 1997 16:20:42 -0500
From: tadmc@flash.net (Tad McClellan)
Subject: Re: Newbie: Webify A Program?
Message-Id: <aniri5.tc3.ln@localhost>
Charles F. Ritter (critter@quack.kfu.com) wrote:
: Jeff Oien wrote:
: > 2. Why doesn't this work when I eliminate the spaces
: > in the $ax$b=$c so that it prints 3x2=6 (or whatever)?
Because spaces are one of the ways that perl uses to identify the end
of a variable name.
You _can_ do without the spaces, but then you need to give perl
some other way to decide where the variable name ends. See below.
: > --------------
: > print "I am a multiplication robot.\nPlease type in any number, then
: > press Enter: ";
: > chomp($a = <STDIN>);
: > print "Please type in another number: ";
: > chomp($b = <STDIN>);
: > $c = $a * $b;
: > print "$a x $b = $c\n";
: > print "Yay!";
: What you have here should work, but if you try to print $ax$b=$c perl
: will print the value of $ax: an undefined scalar. Using perl with the
: "-w" option gives better error messages.
print "${a}x$b=$c\n";
--
Tad McClellan SGML Consulting
Tag And Document Consulting Perl programming
tadmc@flash.net
------------------------------
Date: Sun, 13 Apr 1997 22:38:20 GMT
From: frank@primemail.com (Frank Fisher)
Subject: Opening Files That Match *.TXT Wildcard - How?
Message-Id: <33515fe5.6229258@nntp.a001.sprintmail.com>
What can I use to read in all files that match *.txt and then perform
operations on them in a perl script?
$files = <>; reads in all of the files from the command line but it
also reads the contents of each file too. I only want to read in all
of the matching wildcard filenames so I can open each file and perform
some edit operations on them.
For example, if I have the following files
1.txt
2.txt
3.txt
I'd like to start my script like this:
unix prompt> perl modify.pl *.txt
and inside the script:
open 1.txt for read
read into some variables
edit some of those variables
open 1.txt for write
print variables out (update the file)
close file
loop to get next .txt file (2.txt and then 3.txt)
and have the script exit after opening all three .txt files
All I could see in my perl book was the $file = <>;
Thanks for any help...
--frank
------------------------------
Date: 13 Apr 1997 16:35:09 -0700
From: Russ Allbery <rra@stanford.edu>
To: frank@primemail.com
Subject: Re: Opening Files That Match *.TXT Wildcard - How?
Message-Id: <qumafn2jy36.fsf@cyclone.stanford.edu>
[ Posted and mailed. ]
Frank Fisher <frank@primemail.com> writes:
> What can I use to read in all files that match *.txt and then perform
> operations on them in a perl script?
opendir (DIR, ".") or die "cannot open .: $!";
@files = grep { /\.txt$/ } readdir DIR;
closedir DIR;
@files will contain the list of filenames.
--
Russ Allbery (rra@stanford.edu) <URL:http://www.eyrie.org/~eagle/>
------------------------------
Date: Sun, 13 Apr 1997 16:26:53 -0500
From: tadmc@flash.net (Tad McClellan)
Subject: Re: Perl Database Question
Message-Id: <t2jri5.hf3.ln@localhost>
Rob Mangiafico (rmang@lexiconn.com) wrote:
: If I have a text database of say 20,000 one line records, and I want
: to open the file and set the file pointer on say the 15,000 record,
: what is the best way to go about this?
The best way would be to:
1) have fixed length records so that you can calculate the byte
offset into the file and then seek() there.
2) create a cross-reference of line# => file offset
and then seek() to there.
: I am using a text database and
: making it searchable by 50 entries at a time, and if the 51st entry
: is at line # 16,000, then it takes a while to search through the 1st
: 15,999 lines to get to this point. I would like to be able to open
: the file and set the file pointer to line 16,000 to begin getting the
: next xxx records. Basically I want to speed up the searching process
: by setting the file pointer / cursor to a known location in the file
^^^^^^^^^^^^^^
The problem is that with variable length records (lines, in this
case) you don't _have_ a known location, because 'location' for a
file means a byte offset.
: before resuming the search, instead of reading through the first
: gazillion entries that I have already searched through.
: Thanks in advance for any help/redirection of where to find a good
: answer to this.
--
Tad McClellan SGML Consulting
Tag And Document Consulting Perl programming
tadmc@flash.net
------------------------------
Date: 13 Apr 1997 15:31:16 -0700
From: Russ Allbery <rra@stanford.edu>
To: DJ Morgan <dmorgan@nght.demon.co.uk>
Subject: Re: perl executable by core dump
Message-Id: <qumhghak11n.fsf@cyclone.stanford.edu>
[ Posted and mailed. ]
DJ Morgan <dmorgan@nght.demon.co.uk> writes:
> I Understand that under unix you can convert a perl script into a
> executable binary by causing it to core dump and thereby have a compiled
> version.
This hasn't really worked for years, and most new operating systems don't
support it at all. Here is some information from part 3 of the FAQ:
What is undump?
See the next questions.
How can I make my Perl program run faster?
The best way to do this is to come up with a better algorithm. This
can often make a dramatic difference. Chapter 8 in the Camel has some
efficiency tips in it you might want to look at.
Other approaches include autoloading seldom-used Perl code. See the
AutoSplit and AutoLoader modules in the standard distribution for
that. Or you could locate the bottleneck and think about writing just
that part in C, the way we used to take bottlenecks in C code and
write them in assembler. Similar to rewriting in C is the use of
modules that have critical sections written in C (for instance, the
PDL module from CPAN).
In some cases, it may be worth it to use the backend compiler to
produce byte code (saving compilation time) or compile into C, which
will certainly save compilation time and sometimes a small amount (but
not much) execution time. See the question about compiling your Perl
programs.
If you're currently linking your perl executable to a shared libc.so,
you can often gain a 10-25% performance benefit by rebuilding it to
link with a static libc.a instead. This will make a bigger perl
executable, but your Perl programs (and programmers) may thank you for
it. See the INSTALL file in the source distribution for more
information.
Unsubstantiated reports allege that Perl interpreters that use sfio
outperform those that don't (for IO intensive applications). To try
this, see the INSTALL file in the source distribution, especially the
"Selecting File IO mechanisms" section.
The undump program was an old attempt to speed up your Perl program by
storing the already-compiled form to disk. This is no longer a viable
option, as it only worked on a few architectures, and wasn't a good
solution anyway.
How can I make my Perl program take less memory?
When it comes to time-space tradeoffs, Perl nearly always prefers to
throw memory at a problem. Scalars in Perl use more memory than
strings in C, arrays take more that, and hashes use even more. While
there's still a lot to be done, recent releases have been addressing
these issues. For example, as of 5.004, duplicate hash keys are shared
amongst all hashes using them, so require no reallocation.
In some cases, using substr() or vec() to simulate arrays can be
highly beneficial. For example, an array of a thousand booleans will
take at least 20,000 bytes of space, but it can be turned into one
125-byte bit vector for a considerable memory savings. The standard
Tie::SubstrHash module can also help for certain types of data
structure. If you're working with specialist data structures
(matrices, for instance) modules that implement these in C may use
less memory than equivalent Perl modules.
Another thing to try is learning whether your Perl was compiled with
the system malloc or with Perl's built-in malloc. Whichever one it is,
try using the other one and see whether this makes a difference.
Information about malloc is in the INSTALL file in the source
distribution. You can find out whether you are using perl's malloc by
typing `perl -V:usemymalloc'.
--
Russ Allbery (rra@stanford.edu) <URL:http://www.eyrie.org/~eagle/>
------------------------------
Date: 13 Apr 1997 23:46:27 GMT
From: gsar@engin.umich.edu (Gurusamy Sarathy)
Subject: Re: Perl NT problems
Message-Id: <5irr8j$95d$1@news.eecs.umich.edu>
[ mailed and posted ]
In article <3351393A.3A4C@icl.fi>,
Petri =?iso-8859-1?Q?B=E4ckstr=F6m?= <...petri.backstrom@icl.fi> wrote:
>
>Well, actually, you can embed double-quotes on Windows NT by doubling
>them. E.g., as follows:
>
> perl -e "print ""$$"""
>
Sorry, that only works sporadically (at least on the NT3.51 cmd shell).
Try C<perl -e "perl '""""'">, which should print two double quotes, but
only prints one. Using a backslash is more predictable.
C:\> perl -e "print '\"\"'"
""
C:\> perl -e "print \"\\\"\""
"
C:\> _
- Sarathy.
gsar@umich.edu
------------------------------
Date: Sun, 13 Apr 1997 14:52:39 -0700
From: "Philip A. Prindeville" <philipp@ntex.com>
Subject: questions about timelocal.pl
Message-Id: <335155A7.621E@ntex.com>
I have a question about timelocal.pl.
I have a setuid(root) (CGI) script that does a:
require 'timelocal.pl';
in it. I noticed that the script gets past the require, and
executes up to the point where:
$now = time;
@x = localtime($now);
$today = &timelocal(0, 0, 0, $x[3], $x[4], $x[5]);
and then complains about:
Undefined subroutine &main::timelocal called at ./form.cgi line 87.
So, I noticed that this goes away if I change the require to:
require '/usr/local/lib/perl5/timelocal.pl';
or even:
require '/usr/local/lib/perl5/sun4-solaris/5.003/timelocal.pl';
(both files are identical, and the later occurs first in the @INC
order list).
Looking at timelocal.pl, I notice that it doesn't return '1' as
its exit value.
I'm curious as to why it doesn't work if I require the file via
an unqualified path, but if I give an absolute path then it works.
If it can't find the file, then why doesn't the 'require' statement
bomb out then and there?
I understand that "use" is compile time whereas "require" is only
run time, but still... this shouldn't have anything to do with it.
Can someone please explain what's going on? What am I missing here?
Thanks,
-Philip
------------------------------
Date: 13 Apr 1997 20:53:25 GMT
From: ouster@tcl.eng.sun.com (John Ousterhout)
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Message-Id: <5irh45$1ul@engnews2.Eng.Sun.COM>
In article <5imhdo$hvj@Masala.CC.UH.EDU>, cosc19z5@Bayou.UH.EDU (cosc19z5@bayou.uh.edu) writes:
|> Is that also the reason why you didn't bother answering any of the
|> numerous posts that raised very legitimate questions about your
|> motivations, and Tcl in general?
|>
|> I find it very interesting that you ignored all these interesting
|> posts, and when you chose to followup, you chose a followup where
|> you cut everything except one passage that necessitated nothing
|> more than a smug response on your behalf.
|>
|> You know, if I didn't know any better I'd say you were avoiding
|> the other posts. I wonder why?
I would be delighted to debate this topic in a moderated forum where we can
keep the discussion on track, such as a conference panel discussion.
Unfortunately, it isn't really possible to sustain a coherent debate on
a hot topic via unmoderated newsgroups. The discussion very quickly fragments
into dozens of sub-topics that drift off the main thread of discussion. I'm
too swamped to respond to each of the hundreds of arguments that have been
made (many of which do have merit), and if I did, each of those responses
would generate 30 more counter-responses that would be even harder to
respond to. When the topic first arose I tried to collect the most common
arguments, and I've posted a couple of articles that responded to them. After
that, things just got too fragmented for me to respond in a meaningful way.
Witness your message, where you put forth a corporate conspiracy theory
instead of a technical argument, and this message, where we're arguing about
whether I've responded enough, rather than the technical issues. I am reading
all the messages, though, and I'll try to respond to some of the arguments
when I revise the white paper over the next couple of weeks.
Or, look at it this way: if I don't respond then you get the last word :-)
------------------------------
Date: 13 Apr 1997 21:08:07 GMT
From: clin@cs.umd.edu (Charles Lin)
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Message-Id: <5irhvn$gm9@mimsy.cs.umd.edu>
Cyber Surfer (cyber_surfer@gubbish.wildcard.demon.co.uk) wrote:
|| If I had the time, I'd write a "Lisp for Dummies" book. At least, I'd
|| attempt it. The result probably wouldn't get published, as I doubt
|| that I can communicate at that kind of level - not without a dummy to
|| test it on. Still, if I did do it, and failed, I could just put the
|| text in my homepage, where anyone can read it.
Some of these Dummies books are unfortunately, not very good. Some
authors think that if you use "cool" language and sound hip, you are
talking to a dummy, even as they explain a fairly difficult concept.
But the nice thing is that the author writes the book with the dummy
in mind. Take Stroustrup's book on C++. For a long time, I've said
it's not a good book for dummies, but I hadn't seen the book in a long
time, so I had forgotten what kind of things is said. Having reread
just the first few pages recently, he makes comments that only an
experienced programmer would understand.
Winston wrote a book called Common Lisp, and he sort of has a
dummies style of writing. The headings of the individual sections
are often sentences. He keeps his sentences rather short. He
tries to use simple examples. But for all that, it still reads
more complicated than it seems it should. Sort of like someone
trying to explaing thermodynamics to kindergarterners in simple
language, but still being more-or-less technically precise. It's
still a little hard to follow. It shows up more in his book
"On to C++". I happen to like Touretsky's Lisp book better
even though it, too, is fairly elementary. It reads a little
better. Winston's book has more stuff in it overall, however.
--
Charles Lin
clin@cs.umd.edu
------------------------------
Date: 13 Apr 1997 17:20:12 -0500
From: wilson@cs.utexas.edu (Paul Wilson)
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Message-Id: <5irm6s$ith@roar.cs.utexas.edu>
In article <5ip5km$qhh$1@news.utdallas.edu>,
Mark A Harrison <mharriso@utdallas.edu> wrote:
>Henry Baker (hbaker@netcom.com) wrote:
>: You make a good point about the importance of environments. That's precisely
>: the advantage of Lisp. You get a uniform picture of the world -- everything
>: is Lisp. You don't have to know anything about machine language, assemblers,
>: linkers, and all plethora of itty bitty 'tools' with <3-character names.
>: You have the same language for writing macros, the same language for writing
>: system code, the same language for writing scripts, the same language for
>: writing editor extensions, the same language for interacting with windows,
>: etc.
>
>I think this is what was responsible for the diminishing influence
>of Lisp... It's all-or-nothing, violating the principle "interoperate
>or die."
I'm not sure what to make of either of these postings.
I think it's important to separate the notion of Lisp per se from
the associated technologies, implementation strategies, and culture
that have grown up around Lisp.
For the purposes of embeddable scripting languages a la Tcl, Lisp
is a tiny, elegant little language which is extremely powerful
and extensible. (For example, take a look at AutoLisp.)
On the other hand, the evolution of some Lisps into large kitchen-sink
languages (like Common Lisp) with large environments is a very different
thing. I'm not criticizing featureful systems, but Tcl/Perl/Python/etc.
fans are likely to miss a lot of points if we let these issues get run
together.
There are two very different ideas here, with very different implications,
and I think some of the miscommunication about scripting language
design is because it's easy to conflate Lisp with Common Lisp plus emacs
plus a browser etc. etc. etc.
In defending Lisp, it's probably best in this context to focus on the
fact that it can be tiny and very flexible, but also to point out that
you can have a larger Lisp and a cool integrated environment _if_
that's what you want.
(Sort of off the point, it's probably good point out that Lisp
can have a "normal-looking" syntax, like Pop, and early Lisps often
provided this. Conventional syntax pretty much fell by the wayside
because it wasn't standardized and most serious Lisp programmers didn't
feel the need for it. If you're trying to design a scripting langauge
from scratch, as Tcl and Perl were, and you're trying not to alienate the
parenthophobes, you can easily make something with most of the virtues
of Lisp that looks pretty much like anything you want. You can even make
it look like ML :-) )
An earlier poster railed against Lisp hypesters who sell people a bill
of goods, sticking them with huge bloated languages and environments
that don't solve people's real problems. That was unfair. There
was a lot of hype about Common Lisp in the 80's. Some of the hype
was true, and Common Lisp did have many wonderful aspects, but Common
Lisp failed partly for marketing reasons. Some of the hype really was
just hype, and Common Lisp failed partly for technical reasons.
Those "hypesters" are pretty well gone by now. Many of them caught the
OOP wave and disappeared. Many of the Scheme people resisted the
juggernaut of Common Lisp from the start, so it's particularly unfair
to tar them with that brush. (I, for one, only used CL for about six
months, near the end of its hype phase, and never hyped it to anybody.)
Lisp fans in this thread have sometimes been derided as "Lisp bigots"
but I don't see a lot of that. Most of us are just pointing out that
even if you find parentheses scary, or are afraid your customers
will, there are some aspects of Lisp (and especially Scheme) that are
very appealing for scripting languages as well as general purpose
programming. Many of the things that motivate scripting languages
motivated the design of Lisp and Scheme.
I think it's probably best to regard Lisp as a family of languages,
with McCarthy's Lisp as the progenitor of Common Lisp, Scheme, etc.,
in much the same way that Algol-60 was the progenitor of Pascal,
C, etc. Railing agianst Lisp because you don't like Common Lisp
hypesters is like railing against Algol-60 because you don't like C++
hypesters.
You don't have to like Lisp, but any good language designer must
learn from it, as the designers of many languages (e.g., Smalltalk,
ML, Java) have done.
And even if you don't like Common Lisp in particular, you can still learn
from it. For example, it appears that many scripting language advocates
were surprised to learn that Common Lisp has keyword arguments, which
lets you do terse scripting if you pick short identifiers---just like
Tcl, "only better" (in most Lisper's views).
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
------------------------------
Date: 11 Apr 1997 18:22:13 GMT
From: hops@sco.com (Mike Hopkirk)
Subject: Use of Tcl without Tk
Message-Id: <HOPS.97Apr11112213@charmstr.sco.com>
In article <5ilbk6$f85$2@news.du.etx.ericsson.se> rv@erix.ericsson.se (Robert Virding) writes:
>A final question which has long interested me and which seems relevant
>to this whole discussion: who would use Tcl if it DIDN'T have such a
>integrated interface to Tk?
Probably the same subset that are *currently* using Tcl without Tk
Close by examples I can point to (that I know of) are three groups here:
System admin, Software Installation, Network configuration
The uses are mainly around the capability already described
- process+system glue,
- Programmable interfaces to data and object repositories....
--
- hops
Everything disclaimed (including disclaimer)
------< hops@sco.com>--------------------------------------
Mike Hopkirk ( hops ) | Whenever possible steal code.
SCO Inc | Tom Duff. Bell Labs
------------------------------
Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 8 Mar 97)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V8 Issue 294
*************************************
