[6621] in Perl-Users-Digest
Perl-Users Digest, Issue: 246 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Apr 7 07:07:22 1997
Date: Mon, 7 Apr 97 04:00:16 -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 Mon, 7 Apr 1997 Volume: 8 Number: 246
Today's topics:
Re: Help regarding Microsoft's Personal Web Server CGI (Benson Trinh)
How can I get the weekday of first day of some month in <fliu@ccl.itri.org.tw>
Modem access with Perl (Chris Adams)
Re: No GUI environment for Perl? <lpa@sysdeco.no>
Re: Objective C is cool. (Re: Who makes more $$..) (Gordon Van Huizen)
OO-Perl corrupts parameters! <ceklof@vt.edu>
Re: Ousterhout and Tcl lost the plot with latest paper (Steffen Beyer)
Reply to Ousterhout's reply (was Re: Ousterhout and Tcl (Paul Wilson)
Re: Unix and ease of use (IS who can waffle most ...) (Luke Brennan)
web visitor info!? <LGR96JAL@lustudat.student.lu.se>
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 7 Apr 1997 00:23:02 -0700
From: benson@primenet.com (Benson Trinh)
Subject: Re: Help regarding Microsoft's Personal Web Server CGI configuration
Message-Id: <33489aa1.11446457@news.primenet.com>
Your approach to this is incorrect. First, you need to create an
association with .cgi or .pl in Explorer. Then you need to add the
.pl or .cgi mapping in the registry. If you need further details,
e-mail me. I've done this but currently the problem I have is that I
need to create one directory or each perl script. However, others
have added perl with this method and it has worked for them.
Benson
On Wed, 26 Mar 1997 01:25:12 -0800, Gunraj Singh
<Gunraj.Singh@atsys.com> wrote:
>Hi
>
>I am facing a problem regarding MicroSoft's Personal Web Server. I am
>using this server on Win 95 system and I'am trying to run some cgi
>scripts written in Perl in the cgi-bin directory, which also contains
>the Perl for Win32 executable file. What happens is that
>
>1) If I am using MS Internet Explorer then it gives error:
> 500 Server Error for files with .cgi extension
> but opens files with .pl extension.
>
>2) If I am using Netscape 3.0 then it gives the same error for file
> with .cgi extension i.e. 500 Server Error but opens .pl file
> as Save as to disk. I changed the Option for x-perl application to
>run the perl.exe file on win95 but it stills open as save as.
>
>
>Both Netscape and IE opens cgi scripts if they are running on some other
>servers. Certainly it has something to do with Microsoft's PWS.
>
>Is there any way to configure PWS so that cgi scripts run successfully
>on both IE and NEtscape and I don't get the above errors. If so, can
>anybody help me in that ?
>
>I would greatly appreciate any help.
>
>
>Gunraj Singh
------------------------------
Date: Mon, 07 Apr 1997 16:43:16 +0800
From: Fu-Chin <fliu@ccl.itri.org.tw>
Subject: How can I get the weekday of first day of some month in perl ?
Message-Id: <3348B3A4.985@ccl.itri.org.tw>
As subject above.
------------------------------
Date: 6 Apr 1997 20:49:49 -0500
From: cadams@sh1.ro.com (Chris Adams)
Subject: Modem access with Perl
Message-Id: <5i9jrt$bra@sh1.ro.com>
Okay, I am trying to access a modem in Perl. I wrote the following, but
it does not work. From inserting extra sleeps, as soon as I do the
syswrite (I also tried print, but I thought that might be screwing up
mixing buffered output with unbuffered input), the modem send and
receive lights come on solid (external modem). Also, I get garbage
reading back - "at" followed by 4 newlines, "OK", some junk, "at" again,
etc. until I hit ^C.
I am trying to run this under Perl 5.003 on RedHat Linux 4.1/x86.
---cut
#!/usr/bin/perl
use Fcntl;
use POSIX qw(:termios_h);
$MOD_DEV = "/dev/cua1";
# Open the modem in nonblocking mode and set it to autoflush
sysopen (MODEM, $MOD_DEV, O_RDWR | O_NONBLOCK | O_NOCTTY) or die "open:$!\n";
select ((select (MODEM), $| = 1)[0]);
# Set up the modem device
$termios = POSIX::Termios->new;
$termios->getattr (fileno (MODEM));
$termios->setcflag (&POSIX::CS8 | &POSIX::HUPCL);
$termios->setispeed (&POSIX::B38400);
$termios->setospeed (&POSIX::B38400);
$termios->setattr (fileno (MODEM), TCSANOW);
$rin = "";
vec ($rin, fileno (MODEM), 1) = 1;
if (syswrite (MODEM, "at\n", 3) != 3) {
print STDERR "didn't write enough\n";
exit;
}
while (1) {
$found = select ($rout = $rin, undef, undef, 3);
if ($found > 0) {
$res = "";
$nbytes = sysread (MODEM, $res, 32);
print STDOUT "$nbytes: $res";
}
elsif ($found == 0) {
close (MODEM);
exit;
}
else {
die "select:$!\n";
}
}
---cut
--
Chris Adams - cadams@ro.com
System Administrator - Renaissance Internet Services
I don't speak for anybody but myself - that's enough trouble.
------------------------------
Date: Mon, 07 Apr 1997 11:08:07 +0200
From: Luca Passani <lpa@sysdeco.no>
Subject: Re: No GUI environment for Perl?
Message-Id: <3348B977.44B@sysdeco.no>
blueox@mail.cyberhighway.com wrote:
>
> Is there any gui environment for programming available? I don't mind
> working with text files made in dos, but a gui wouldn't hurt.
Even though I'm not the best to answer your question, I have a few
considerations which are raised by a recent joky thread about Visual
Perl++ and some marketing crap I've read today.
The marketing crap was about a product which, through the use of some
proprietary tools and languages, would allow to create HTML forms and
CGI (in their basic-like language).
What I found unfair in the article was the claim that Perl (along with
C, C++ and Java) was unsuitable for the web since it leads very quickly
to "spaghetti code".
I guess that the average clpm reader will agree with me that this is a
bunch of marketing crap (if you are not convinced, I will provide my
reasons at the end of this posting).
The only "advantage" of a commercial package like the one I'm talking
about (probably I should say the name: WebSpeed by Progress Software) is
"the nice box" in which it's delivered and the idea that you can get
better support for a product where users cannot get in contact with one
another.
If Perl was delivered with a nice GUI interface (both on Unix and PCs),
it would gain much more appeal to the novices which are scared by a
learning curve they will have to climb anyway.
Perl is already a development environment. Building a graphical
interface on top of it should result relatively simple:
-code editor (xemacs already does a good job on UNIX)
-list of "includable" modules and/or classes and methods (with some cool
drag&drop feature)
-debugger window with a list of variables and the possibility
to navigate class hierarchies and analyse objects
-an HTML form editor interfacible with PERL scripts that
simplifies debugging of CGI scripts.
-on line hypertextual help.
The Perl compiler might also be bundled in, of course.
I hope someone agrees with me.
BTW: Why is that marketing stuff crap?
1) they miss the point that web development is first about protocols
which allow heterogenous components to communicate, not about a
particular language. Commiting oneself to their proprietary language
means losing the possibility to use a whole wealth of existing and
future modules freely available on the Internet.
2) It does not need to be "spaghetti code" as they claim, as long as the
architecture of the application is clear. This is true for programming
in general, I guess. In this particular case, Perl offers a whole lot of
reusable modules thus speeding up development and simplifying
maintenance.
3) I have not been able to understand if their product works on UNIX
servers (I don't think so, since they should port their interpreters and
compilers to the various flavours of UNIX, furthermore they omitted to
mention UNIX. Someone correct me if this is wrong).
If this is the case, many of the advantages that intrinsically open
web-technology offers, would be lost.
4) Avoiding the learning curve in this area is virtually impossible. As
soon as a comma is missing somewhere, you need a knowledgeable person to
understand and fix things.
5) If a company wants to use the Internet or an Intranet for real, they
need a webmaster anyway.
6) I'm sure you could add more.
Luca
--
======================================================================
Luca Passani. | Sysdeco Innovation AS, http://www.sysdeco.no
Email: lpa@sysdeco.no | Trondheimsveien 184, 0570 Oslo, Norway
Tel: (+47) 22 09 66 06 | Fax: (+47) 22 09 65 03
======================================================================
------------------------------
Date: Sun, 06 Apr 1997 13:50:37 -0700
From: gvh@solutionhouse.com (Gordon Van Huizen)
Subject: Re: Objective C is cool. (Re: Who makes more $$..)
Message-Id: <gvh-0604971350370001@emerson.digasylum.com>
In article <333C4861.2965@ccnet.com>, wjhunt@ccnet.com wrote:
> Da Borg wrote:
> > ...
> > Objective-C was indeed developed by Next people but since it was
> based on GNU code, it was released after a FSF letter to NextStep
> lawyers.
>
> Objective C was developed a long time ago by a small company called
> Stepstome. Brad Cox, the guy behind it wrote lots of articles and at
> least one book about software ICs.
>
> Next adopted it as a better choice than C++ but they didn't develop it.
> (I think they eventually bought Stepstone since they were by then the
> principal remaining user of Objective C.
NeXT also continued the development of Objective C by adding extensions to
the language. Neither the Cox, nor Pinson/Weiner ObjC books cover things
like categories and prototypes, as NeXT added these a few years ago.
Gordon
----
Gordon Van Huizen
Digital Asylum
gvh@digasylum.com [NeXTmail, MIME ok]
http://www.digasylum.com
------------------------------
Date: Sun, 06 Apr 1997 16:44:44 -0300
From: Carl <ceklof@vt.edu>
Subject: OO-Perl corrupts parameters!
Message-Id: <3347FD2C.6B3B@vt.edu>
I am adding/converting some of my perl code to be immplement the OOP
extentions. Has anyone done this?
All of the routines that I've made into object methods no longer receive
their parameters correctly! For single '$' parameters, everything has
been shifted up one in the array of parameters
eg.
package foo;
sub test{
$firstVar = $_[0];
print $firstVar;
}
is now:
sub test{
$firstVar = $_[1];
print $firstVar;
}
AND THEN, MY HASHES ARE REVERSED, KEY->VALUE, VALUE->KEY!!! Needless to
say, this is bad!
If anyone has any experience with this, I'd really love to hear about
it!
I have:
Perl for Win32 Build 110
Built Aug 13 1996@08:18:50
Thanks in advance,
-Carl
------------------------------
Date: 7 Apr 1997 07:57:43 GMT
From: sb@en.muc.de (Steffen Beyer)
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Message-Id: <5ia9dn$scj$1@en1.engelschall.com>
In comp.lang.perl.misc John Ousterhout <ouster@tcl.eng.sun.com> wrote:
> That said, I still suspect that as scripting applications grow it makes
> more and more sense to implement parts of them in a system programming
> language. The great thing about scripting languages is that this is
> easy to do. You can take the performance-critical kernel of a Tcl
> application and implement it in C or C++; ditto for any complicated data
> structures or algorithms. The simple, non-performance-critical parts
> can be left in Tcl. I knew when I started on Tcl that it wouldn't be
> appropriate for all problems, so I designed it to work smoothly with
> other languages. In contrast, most languages are egotistical: they
> expect you to do *everything* in that language and make it very hard to
> split the functionality of an application between multiple languages.
> For example, I've been involved with several attempts to make C and Lisp
> work together, and they all failed.
Perl is very good at this; you can easily embed C code in Perl and vice-
versa (!!), Perl code in C.
If I'm not mistaken, FORTRAN libraries have also been linked in already.
And you can even compile Perl into plain C code.
> - It is possible to make languages with execution speeds like C or C++,
> that use dynamic typing successfully, whilst being high-level enough
> in the creation of abstractions to "glue" things together quite
> nicely and easily.
> Can you point to a specific language and identify a large community of
> users who agree with this assessment?
Yes: Perl.
> Many people have made claims like
> this to me, but no one has been able to point to a good real-world
> example. The white paper argues that you can't have a jack-of-all-trades
> language. Either you have a strongly typed language, which gives high
> speed and manageability but makes gluing hard, or you have a weakly
> typed language with the opposite properties.
IMHO, "tertium non datur" doesn't hold for Perl...
Because the philosophy of Perl is quite distinct from all other programming
languages (see the interview of Larry Wall and Tom Christiansen in WebWeek -
a link to the article can be found by following links down from www.ora.com),
it combines high speed, manageability and maintainability (if so written,
that is), *and* easy gluing (see "How Perl saved the human genome project" in
"The Perl Journal", for instance).
And Perl actually *is* sort of a "jack-of-all-trades" language...
It's not for pure fun alone that Perl is also nicknamed "PERL = Pathologically
*Eclectic* Rubbish Lister"... :-)
^^^^^^^^
Yours sincerely,
--
|s |d &|m | Steffen Beyer <sb@sdm.de> (+49 89) 63812-244 fax -150
| | | | software design & management GmbH & Co. KG
| | | | Thomas-Dehler-Str. 27, 81737 Munich, Germany.
"There is enough for the need of everyone in this world,
but not for the greed of everyone." - Mahatma Gandhi
------------------------------
Date: 7 Apr 1997 04:47:45 -0500
From: wilson@cs.utexas.edu (Paul Wilson)
Subject: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Message-Id: <5iafs1$fh4@roar.cs.utexas.edu>
In article <5i7euq$cmg@engnews2.Eng.Sun.COM>,
John Ousterhout <ouster@tcl.eng.sun.com> wrote:
>Wow, there's been quite a party going on over here on comp.lang.scheme!
>I'd like to respond to a few of the comments about my white paper on
>scripting, but first a couple of introductory remarks:
>
>1. The paper is not intended to be a complete taxonomy of all programming
> languages nor is it intended to discuss every factor that contributes
> to the usefulness of a language. The paper has a very narrow focus,
> namely to explain what scripting is and why it's important.
I suggest saying this right up front in the paper. You could say that
you're using Tcl as an example, but that many other languages, wit
minor modifications, might be comparably suitable for scripting,
or even more so. As it stands, it gives the impression that you're either
very ignorant of programming languages, despite having designed a popular
one, or just speciously hyping Tcl at the expense of languages that developed
many of the same concepts decades ago (and in my opinion, generally did them
better).
I'll grant that this wasn't your intention, but it is the way it comes
across.
This is partly due to the way you give a history of programming languages,
without even having mentioned the most directly relevant early programming
language---Lisp. Lisp has been around longer than any other noticeably
living language except FORTRAN.
(The lack of reasonable discussion of prior work is particularly striking
for a former Distinguished Professor of CS from Berkeley. Maybe it's not
fair because you're in industry now, but a lot of people respect your
technical opinions because they know something of your track record.
And you and Sun don't hide your academic credentials.)
> I intentionally limited the discussion to a few issues such as system
> programming vs. scripting, components vs. glue, and strongly typed
> vs. untyped.
These dichotomies have something to them, but the paper makes it sound like
the issues are very simple and clear-cut. They're not. For example,
Lisp- and Smalltalk-style dynamic typing have big advantages over
"untyped" conversions back and forth through a uniform string representation.
For common cases where you want coercions, you could code them into
the primitive operations. For uncommon cases, it's probably better to signal
type mismatches, so that bugs are easier to track down. Avoiding
continual coercions could also help keep a language from being dog slow.
> Of course there are other issues in programming language
> design. At the same time, I think that the issues in the paper explain
> a lot about what's going on in real-world programming.
Perhaps. But for sophisticated audiences, there's little that's new,
and much that's grating and seems wrong. For unsophisticated audiences,
it's heavily biased---given your fame, Joe Programmer may take this
kind of thing a little too seriously, and come up with the wrong
impressions.
>2. Many people objected to the fact that their favorite programming
> was left out of the white paper. Yes, I have heard of Scheme,
> Smalltalk, ML, etc. I left these languages out because they
> didn't seem particularly relevant for the discussion. No offense
> intended...
Of course they're relevant, and you probably should know that by now.
(Surely people have complained about this kind of thing before. I
know *I* have heard it before, so I assume you have too.)
For example, a simple Scheme-like language might make a much better
scripting language, with a few minor changes. (E.g., terser names
for built-in procedures and special forms, some important automatic
coercions, and a foreign function interface.)
>3. It's very hard to settle arguments about programming languages
> because it's hard to produce meaningful quantitative evidence about
> things like programmer productivity. I tried to illustrate my points
> with historical examples and a few quantitative anecdotes, but I
> admit that these are soft. I'd be delighted to see better
> quantitative evidence either supporting or contradicting my
> arguments. For example, if you know of any quantitative measurements
> of productivity improvements caused by object-oriented programming,
> please let me know.
I can't help here.
>When Alaric Williams told me about the flame-fest on comp.lang.scheme,
>he proposed a set of counter-arguments for me to respond to. Here
>they are, along with my responses.
>
> - Typlessness, as evident in TCL, is not necessarily the best solution.
> Dynamic typing is generally agreed to be far more powerful and safe.
>
>Actually, I think Tcl is dynamically typed: everything is checked
>at runtime for at least syntactic validity.
I think it's somewhere in between untyped and dynamically typed.
With dynamic types, every value has a well-defined type, rather than
just "string" or whatever. Put in enough automatic (and unsaafe) coercions,
though, and the difference gets blurry.
>I used a slightly offbeat
>definition of "typing" in the paper: by my definition, "typing" means
>declaring the nature of something in advance in order to restrict its
>usage. You would probably call this "static typing", no?
Probably. But in a dynamically typed language, you do associate types with
values. By creating an object that's a general array, or one that's
a string of characters, you may restrict the ways that object can be used
later, without explicit coercions. This is often a good thing, amking
the code clearer.
> - TCL does not scale well to large systems; it is fine for small
> "glueing" applications, but in the "real world", such applications
> are expected to grow with time, and soon proper typing becomes
> necessary, more efficiency becomes necessary, etc.
>
>When I started on Tcl I thought this would be true, but in fact many
>people have built surprisingly large programs in Tcl.
I know some people who have scores of thousands of lines of Tcl in
their applications, but their code is a mess. Tcl simply doesn't
have good abstractions for programming in the large, or even in the
medium. Of course you can do it, given enough patience and care,
but I don't think it proves much in terms of the actual language design.
I'd bet that if those programs were written in a well-designed
general-purpose language, they'd be easier to maintain, and tons
faster to boot. (No, I don't have proof. But I don't think that
large Tcl programs are good evidence for the points you're making.
Often they're evidence against some of your points.)
The main benefits that the Tcl hackers I know get form Tcl are an
interactive command loop, and a standard way of gluing together code
in other languages, and a standard, fairly functional graphics toolkit.
Those are great things, and you're to be applauded for realizing they're
crucial for writing glue code before most other people did! (It certainly
should embarrass the hell out of the programming languages community, of
which I'm a part.)
An interactive command loop is incredibly valuable for increasing
productivity over the usual compile-link-run-crash cycle. What's
sad is how many Tcl programmers there are now who've never used
any other interactive language, and think Tcl is great because it
has that huge advantage over C++.
Other aspects of the language seem poorly motivated. The syntax is
bizarre, the type system (such as it is) is weak and kludgey, and
the idiomatic use of a general evaluator seems like a big mistake.
(You hardly ever need a general evaluator except at the top-level
command loop. Having normal code use it inhibits the ability to
compile to good code, and is error-prone. You're generally better
off using macros for most things that people try to do with eval
If you have hygienic macros a la Scheme, it's much safer, and
macros don't incur runtime overhead in compiled code.)
The lack of real data structures and garbage collection seems
like an equally big mistake.
You these are lessons that Lisp people learned a long time ago, and
many language designers have built on those lessons.
>For example,
>there is a real-time Tcl application containing several hundred thousand
>lines of code that controls a $5 billion oil well platform and (much to
>my shock) it seems to be quite maintainable. Sybase has something like
>a million lines of Tcl code in their test suite.
I pity them. :-)
>I think it depends a lot on the application. The oil well application
>actually subdivides into a whole bunch of small tasks, so it's really
>more like 500 smaller programs.
I find this hard to believe. Maybe the oil well people are incredibly
lucky and their application decomposes wonderfully, but I've never seen
and interesting large application that did that. You generally need
some abstraction mechanisms to manage large programs, whether they're
provided by the language, or hand-kludged for the app.
I suspect that this app is divided into too many too-short Tcl scripts,
with too much flattening of data structures into strings and reconstructing
the structures later. Or worse, it doesn't use interesting data structures,
and is either much kludgier or vastly slower (or both) than it would be if
it did.
And speed is important. I believe that you point out in the intro to
your book that most Tcl programs, contrary to your expectations, are
coded entirely in Tcl. My understand is that interactive program
development is so much easier (and so much more fun) than using batch
languages that people get addicted to it---they're often willing to
sacrifice a lot of performance and important code- and data-structuring
facilities to be able to do it.
>Also, if the application is
>fundamentally gluing (i.e. the complexity is in the interconnections)
>then switching to a more strongly typed language will just make things
>worse.
Maybe yes, maybe no. At the very least, true dynamic typing makes
communicating between modules much less error-prone---you'll usually
get a clear error message sooner than if you're just passing garbled
strings around.
And have a look at ML. Its polymorphic type system LOOKS dynamically
typed, but actually infers types automatically, and type-checks the
program automatically. Pretty spiffy. Most of the advantages of
static typing and most of the advantages of dynamic typing, too.
>One final argument: suppose that Tcl code is harder to maintain,
>line for line, than code in a more strongly typed language (I suspect
>this is true). But if a Tcl application has only 1/5 or 1/10 the lines
>of code of the equivalent program in a strongly typed language, it may
>still be easier to maintain overall.
I think that you're oversimplifying here. Many of us will grant
that scripting languages are good to have, and many of us will
grant that something like dynamic typing is nice, at least compared
to having to declare everything all the time. But there's no reason
why a scripting language can't be a reasonable subset of a general-purpose
language (e.g., Scheme with objects), so that you can just COMPILE
your code to make it run pretty fast, rather than having to REWRITE it
in a different language.
There's no reason why a straightforward Scheme-style interpreter
for a Tcl-sized subset of Scheme can't have a similarly small footprint
and run much faster. And certainly you can compile it to vastly
faster code.
>That said, I still suspect that as scripting applications grow it makes
>more and more sense to implement parts of them in a system programming
>language. The great thing about scripting languages is that this is
>easy to do.
Why not just write it in a good all-around interactive, compiler-friendly
language in the first place?
>You can take the performance-critical kernel of a Tcl
>application and implement it in C or C++; ditto for any complicated data
>structures or algorithms. The simple, non-performance-critical parts
>can be left in Tcl.
I think you're really pushing a false dichotomy here. There's big difference
between simple and non-performance-critical, and each of those is a spectrum.
Tcl is not good for non-simple OR for performance-critical programming.
It's so incredibly slow that you're forced to write many simple things
in a different language to get decent performance. It's so incredibly
limited (e.g., in its datatypes) that it's awkward to write code which
may be somewhat sophisticated, e.g, using sophisticated data structures,
but is not time-critical.
> I knew when I started on Tcl that it wouldn't be
>appropriate for all problems, so I designed it to work smoothly with
>other languages.
This is incredibly reasonable, but the scope of things for which Tcl
is good is way, way smaller than it needs to be. You originally thought
that Tcl scripts would be a few lines, or tens of lines, and designed
the language accordingly. But now people are writing things orders of
magnitude larger than that. Either you made a mistake early on, or
they're making them now.
>In contrast, most languages are egotistical: they
>expect you to do *everything* in that language and make it very hard to
>split the functionality of an application between multiple languages.
>For example, I've been involved with several attempts to make C and Lisp
>work together, and they all failed.
>
> - It is possible to make languages with execution speeds like C or C++,
> that use dynamic typing successfully, whilst being high-level enough
> in the creation of abstractions to "glue" things together quite
> nicely and easily.
>
>Can you point to a specific language and identify a large community of
>users who agree with this assessment?
Depends on exactly what you're asking. I'm not saying there's a single
implementation that gives you everyting you want for Tcl-style apps,
but there's NOTHING hard about it.
Consider SIOD, George Carette's small interpretive implementation of most
of Scheme, which is is embeddable as a scripting language. You can
keep the footprint small by running the GC at a high rate, which will
slow things down a bit, but it'll still be a lot faster than Tcl.
You can write portable Scheme code using the SIOD interpreter, and then
run it through the Marc Feeley's Gambit compiler to get fast code.
Maybe not as fast as C on average, but sometimes faster, and generally
within spitting distance.
Similarly, if you want more scripting and process-control features,
you can use scsh, the Scheme shell. (Unfortunately, scsh is currently
a bit of a pig, because it's built on a fat implementation of Scheme,
but it doesn't have to be---somebody could extend SIOD a little
and port scsh to it, and you'd get the benefits of both. scsh
would run more slowly than it does now, but again, way faster than Tcl.)
>Many people have made claims like
>this to me, but no one has been able to point to a good real-world
>example. The white paper argues that you can't have a jack-of-all-trades
>language. Either you have a strongly typed language, which gives high
>speed and manageability but makes gluing hard, or you have a weakly
>typed language with the opposite properties.
I guess you haven't read the literature on Lisp and Scheme.
Don't be misled by the big-bag-of-features that Common Lisp became,
or the pigginess of the implementations of it. Lisp itself has
always been amenable to tiny implementations, if you care more about
footprint and startup times than running speed.
And even a small Lisp or Scheme is powerful enough to let you implement
an object system or a module system from within the language. You just
need a macro facility, which isn't much code.
> - Do you really think that object orientation has failed? C++ is a bad
> OO
> language, indeed, but what about Self, Java, and other such OO success
> stories from... Sun Labs? Do I detect interdepartmental rivalry?
>
>I overstated the arguments against OO programming in the paper and I'll
>probably soften them a bit in the next draft. I actually think that
>there are some good aspects of OO programming, and I use them myself
>even when I'm not programming in an OO language. But I stand by the two
>main points in the paper, which are that (a) OO programming hasn't
>increased productivity dramatically because it doesn't raise the level of
>programming significantly (it may improve things 20-30%, but I doubt
>there's even a factor of 2, let alone 10) and (b) implementation
>inheritance really truly is a bad idea that tends to reduce reuse and
>productivity. I think you'll see substantial support for the second
>claim even among OO enthusiasts.
I don't think most of us would put it that way. Implementation inheritance
CAN be a truly bad idea if you use it for the wrong things, but it's often
a good thing if you know what you're doing and don't confuse interfaces
with implementations.
>As for Java, it's hard not to be envious of its success (aren't you
>guys a bit envious too?), but Tcl is really symbiotic with Java, just
>as Tcl is symbiotic with C. I look on Java as a better system
>programming language that's particularly well-suited for creating
>portable Internet components. Tcl is moving to the Internet itself,
>and C isn't a good component language in that domain, so I'm delighted
>to have Java around for implementing Internet components that Tcl
>can then glue together.
One of the saddest things about Java is that it screams for an
interactive implementation, rather than batch compilation. (Unlike
C++, it's got enough checking by default to build an uncrashable
interaction environment.)
Once there are interactive implementations, the dichotomy between
scripting and systems languages will be less obvious.
(And if you made type declarations optional in scripts, that
would go much further.)
> [ ... ]
>
> His arguments on "typeless" languages is useless.
> You don't need a "scripting language" to
> get usable abstractions without the need
> to deal with low-level issues.
>
> button .b -text Hello! -font {Times 16} -command {puts hello}
>
> In Macintosh Common Lisp I'll write this as:
>
> (make-instance 'button-dialog-item
> :dialog-item-text "Hello"
> :view-font '("Times" 16)
> :dialog-item-action (lambda (item) (print "hello")))
>
>I think this example supports my claim that scripting languages are a
>lot easier to use when you need to mix and match lots of things of
>different types. The MCL example is a lot more verbose and complicated
>than the Tcl example.
The MCL example is mostly more verbose because MCL uses longer identifiers.
If MCL were intended as a scripting language, the identifers could be changed
and some of them could be made more intuitive for non-Lispers. You
could also trivially define the instance-making macro (which I'll call new)
to coerce a font name string into whatever representation it uses for a
font spec.:
(new button :text "Hello" :font "Times 16" :cmd (proc (item) (print "Hello")))
There's nothing about Lisp that makes this much more verbose than
the Tcl version. It's just that MCL isn't mainly designed as a scripting
language, and Lispers usually like to write readable code. This verbosity
has little to do with anything deep about the language.
The nice thing about Lisp is that you can have your cake and eat it too.
You can define the things that are frequently used in scripts so that
they're terse, and the other things so that they're clear. (You can
do this from within the langauge, by defining procedures and macros
that are really just aliases for standard things, using abbreviated
names.
--
| 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: 4 Apr 1997 07:47:25 GMT
From: L.Brennan@isu%.usyd%.edu%.au% (Luke Brennan)
Subject: Re: Unix and ease of use (IS who can waffle most ...)
Message-Id: <5i2bmd$ptl@metro.usyd.edu.au>
Keywords: UNIX waffle LINUX waffle
In article <Pine.SUN.3.96.970403221856.29535B-100000@access2.digex.net>
REX BALLARD <rballard@access2.digex.net> wrote:
> The question isn't whether, but when. Microsoft has spent $4 Billion/year
> in publicity and advertizing, along with $2 Billion/year for the last 5
> years to keep UNIX from doing to Microsoft Windows what it did to RT-11,
> RSTS, RSX-11, EDX, VMS, MVS, VRTX, and about 20 other lesser known
> attempts at an operating system.
In your dreams...
it all comes down to COSTS. People ignore *quality* and go with words
like CHEAP/EASY/MARKETING/PEER PRESSURE/NEW TOY/.
Stupidity vs long-term vision.
Perhaps you'd better include UNIX into 'attempts at an operating system'...
Luke
------------------------------
Date: Mon, 07 Apr 1997 09:12:32 +0200
From: Jane Lilja <LGR96JAL@lustudat.student.lu.se>
Subject: web visitor info!?
Message-Id: <33489E60.7AFC@lustudat.student.lu.se>
Hi!
Anyone who knows how to retreive the full name and e-mail address of a
visitor to a website whitout the need for the user to fill in this kind
of information in a form and then trace the user via a cookie in
subsequent visits?
I know I can get the visitors machine address, both IP and name, but
there can be muliple users in case of a ISP, or the machinename can be
temporary in case of for example ppp-connection to an ISP. I want to be
able to uniquely identify the user, not the machine.
I want to present a personal greeting when visitors are viewing a
homepage of mine. I have seen this kind of funktionallity somewhere out
there... :-)
The webserver is Apache, and the operating system is either Sun Unix, or
Linux (two different places).
Please e-mail me an answer, as well as post it here.
Thanks in advance!
------------------------------
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 246
*************************************
