[6616] in Perl-Users-Digest
Perl-Users Digest, Issue: 241 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Apr 6 03:07:19 1997
Date: Sat, 5 Apr 97 23:00:17 -0800
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 5 Apr 1997 Volume: 8 Number: 241
Today's topics:
Re: @array as input symbol in <@array> <tchrist@mox.perl.com>
Re: [Perl HTML manual](perlfunc problem) <tchrist@mox.perl.com>
Re: Establishing Distances??? <spp@psisa.com>
How Do You Get User Input? <bradenb@ibm.net>
Is the Penguin dead? (James A. Robinson)
Re: Is the Penguin dead? (Nathan V. Patwardhan)
Re: Is the Penguin dead? (James A. Robinson)
Re: opendir-readdir problem on IIS 3.0 (Nathan V. Patwardhan)
Re: Ousterhout and Tcl lost the plot with latest paper (John Ousterhout)
Re: perl for winNT and visual basic <jong@mrc-lmb.cam.ac.uk>
Perl Variable Passing Help Needed (Frank Fisher)
Re: Perl vs. C/C++ <ajs@ajs.com>
Re: Perl vs. C/C++ <tchrist@mox.perl.com>
Re: Simple array question by newbie... <lauriem@cstr.ed.ac.uk>
Re: Trouble t with a 2D array! <tchrist@mox.perl.com>
Re: Writing a routine the works like 'open' <ajs@ajs.com>
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 6 Apr 1997 06:27:20 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: @array as input symbol in <@array>
Message-Id: <5i7fo8$kpk$1@csnews.cs.colorado.edu>
Keywords: Hoffman, depreciable, emanate, levulose
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc, mjd@plover.com (Mark-Jason Dominus) writes:
: while (<@array>) {
: print $_, "\n";
: }
It's a fileglob. Consider
print <@INC>;
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
Real Programmers don't write in PL/I. PL/I is for programmers who
can't decide whether to write in COBOL or FORTRAN.
------------------------------
Date: 6 Apr 1997 05:03:51 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: [Perl HTML manual](perlfunc problem)
Message-Id: <5i7arn$gl0$3@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
Sanjay Vohra <sanjay@cis.ohio-state.edu> writes:
:i downloaded a copy of the HTML documentation from the Perl Language
:Home Page, unzipped and 'detarred' it
:
:the individual function descriptions in perfunc directory seem to be
:missing
:
:has anybody come across this problem? maybe i messed up somewhere, any
:help would be appreciated
No, I missed them in the tar file. I'll try to get it fixed soonishly.
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
Fungus doesn't take a vacation. --Rob Pike
------------------------------
Date: 04 Apr 1997 08:57:41 -0600
From: Stephen Potter <spp@psisa.com>
Subject: Re: Establishing Distances???
Message-Id: <uuafnehm3e.fsf@psisa.com>
[I despise people who put fake addresses in their headers, makes it damned
difficult to respond]
[There is rarely any reason to crosspost to more than one of the
comp.lang.perl.* groups. Followups redirected to .misc]
"Jonathan S Hardiman" <none@nowhere.new> writes:
> I have written a script which processes a purchase order. It's main
> function is to tell the user how far from the nearest office he/she is, and
> thus how much the shipping costs would be. Can this be done without the 92
> page subroutine I have at the moment.
This is entirely dependent upon the granularity you want (nearest mile? 10
mile? foot?), and the information you have available (address, lat/long,
GPS), and the route taken (crow fly, roads, etc). Try telling us what
information you have, and what you are doing currently, then maybe we can
make suggestions.
-spp
PS: If you have a "92 page subroutine", this falls out of the realm of what
you will find people in the newsgroups can/will help you with for free.
You'll likely find you need to pay someone to do your programming for you.
------------------------------
Date: 6 Apr 97 03:28:33 GMT
From: "Jerome Bradenbaugh" <bradenb@ibm.net>
Subject: How Do You Get User Input?
Message-Id: <01bc423a$64942ca0$c8c32581@default>
How do you get user input by calling a dialog box after clicking a link?
How can you use it once you have it?
Regards,
--
Jerry Bradenbaugh
HotSyte Webmaster
bradenb@ibm.net
The Connection to that which is JavaScript
http://www.serve.com/hotsyte
------------------------------
Date: 5 Apr 1997 20:10:31 -0800
From: jimr@aubrey.stanford.edu (James A. Robinson)
Subject: Is the Penguin dead?
Message-Id: <5i77nn$rjb@aubrey.stanford.edu>
I've been reading some stuff about the Penguin perl modules, but I
can't seem to locate any up-to-date information resources for it. The
web pages at http://www.eden.com/~fsg/penguin and at what appears to
be the original development site coriolan.amicus.com is also empty. :(
Anyone know if the Penguin is dead?
Jim
--
Jim Robinson <jim.robinson@stanford.edu> - http://highwire.stanford.edu/~jimr/
HighWire Press -- Stanford University
------------------------------
Date: 6 Apr 1997 05:06:51 GMT
From: nvp@shore.net (Nathan V. Patwardhan)
Subject: Re: Is the Penguin dead?
Message-Id: <5i7b1b$k5i@fridge-nf0.shore.net>
James A. Robinson (jimr@aubrey.stanford.edu) wrote:
: I've been reading some stuff about the Penguin perl modules, but I
: can't seem to locate any up-to-date information resources for it. The
: web pages at http://www.eden.com/~fsg/penguin and at what appears to
: be the original development site coriolan.amicus.com is also empty. :(
I was also thinking the Penguin was dead, but I turned up some old
webpages via Yahoo. The author said the release would be in March/April,
but I think that was last year. :-( I've also been searching for the
"patched/upgraded" Safe libs but can't find those, either.
Penguin looked pretty neat; too bad I never got it working.
--
Nathan V. Patwardhan
nvp@shore.net
------------------------------
Date: 5 Apr 1997 21:43:16 -0800
From: jimr@aubrey.stanford.edu (James A. Robinson)
Subject: Re: Is the Penguin dead?
Message-Id: <5i7d5k$sap@aubrey.stanford.edu>
In article <5i7b1b$k5i@fridge-nf0.shore.net>,
Nathan V. Patwardhan <nvp@shore.net> wrote:
>
> I was also thinking the Penguin was dead, but I turned up some old
> webpages via Yahoo. The author said the release would be in March/April,
> but I think that was last year. :-( I've also been searching for the
> "patched/upgraded" Safe libs but can't find those, either.
Yes, the April/March thing seems to be from 1996.
I've got it partially working now (I happen to be running the beta
perl dist, which you can get on any CPAN site). I had to make some
modifications to the Penguin TCP Client and Server modules, and one
modification to the Compartment module in order to get it to run.
Right now it manages to get and execute some code on the server
properly. It looks like the Compartment module might need to be
revamped to work with the newer Safe.pm, but I'm not sure of this.
I've got a problem with Safe not really accepting the shared functions
that are passed with Penguin's Compartment::register method. :( I
don't want to rip it out and redo it because I don't really have a
good understanding of Safe.
In any case I would like to find out if development of Penguin has
stopped because of lack of time or something, or if there is an
underlying problem with the entire architecture...
Felix, are you out there? :-)
Jim
P.S. The mods I made to get it to partially work:
Compartment.pm:
$self->{'compartment'}->share('%{$self->shares}');
to
$self->{'compartment'}->share(%{ $self->{shares} });
Channel/TCP/Client.pm:
Changed the socket creation to:
$self->{'Socket'} = new IO::Socket::INET(PeerAddr => $self->{'Peer'},
PeerPort => $self->{'Port'},
Proto => 'tcp');
/Channel/TCP/Server.pm:
Added this line just above "my $bindport ...":
my $hostname = ($args{'Host'} or 'localhost'); # standard Penguin host
changed the Master Socket creation to:
$self->{'Master Socket'} = new IO::Socket::INET(LocalAddr => $hostname,
LocalPort => $bindport,
Listen => $listeners,
Proto => 'tcp');
--
Jim Robinson <jim.robinson@stanford.edu> - http://highwire.stanford.edu/~jimr/
HighWire Press -- Stanford University
------------------------------
Date: 6 Apr 1997 05:03:15 GMT
From: nvp@shore.net (Nathan V. Patwardhan)
Subject: Re: opendir-readdir problem on IIS 3.0
Message-Id: <5i7aqj$k5i@fridge-nf0.shore.net>
Mikhail Blazer (blazer@mail.nevalink.ru) wrote:
: My script that was OK on Win32 FolkWEB server (Win95) and NetBSD now fails
: on IIS 3.0. Look at this:
: $sc_log_file_directory = "../Store/Admin_files";
Two things:
(1) Use the absolute path of the directory.
(2) *Always* return errors from an open, whether it be to a file or
directory handle.
--
Nathan V. Patwardhan
nvp@shore.net
------------------------------
Date: 6 Apr 1997 06:13:46 GMT
From: ouster@tcl.eng.sun.com (John Ousterhout)
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Message-Id: <5i7euq$cmg@engnews2.Eng.Sun.COM>
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
intentionally limited the discussion to a few issues such as system
programming vs. scripting, components vs. glue, and strongly typed
vs. untyped. 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.
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...
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.
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 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?
- 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. 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 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. 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. 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.
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.
- 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? 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.
- 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.
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.
By the time I found out about the discussion on comp.lang.scheme my news
server had already flushed some of the earlier articles, so I've missed
some of the arguments. I trolled the articles that were left for
comments to discuss, but didn't find a lot. Most of the articles seemed
to be discussing my motives and ancestors more than the ideas in the
paper; I'm not sure how to respond to a comment such as "he obviously
doesn't have a clue" except by saying "Hmmm, let me see... wait ...
here's one in my wallet! Whew..." You guys seem to have more
ad-hominem arguments than we do on comp.lang.tcl.
However, I did find a few comments that I'd like to respond to; here
they are (indented), along with my responses:
> I have only skimmed the article so far, but one thing struck me
> immediately. At one point he gives an "anecdotal" table where
> something is programmed originally in C or C++, at enormous expense
> in programmer hours, and then re-implemented in Tcl/Perl/whatever
> in ten or fifteen minutes. It would be interesting to see if the
> same skew existed for programs that were written in scripting
> languages (or for that matter, Lisp or Scheme or Python) first,
> and then re-implemented in C or C++. It's hard to believe the ratios
> would be as large.
Look carefully at the "Comments" column in the table: some of the
applications were written in C/C++ first, while others were written in
Tcl/Perl first. Indeed, scripting appears to have less benefit in the
cases where the scripting implementation was first. I believe the
caption in the table mentions this, and the 5-10x advantage I claimed
for scripting is the middle range of the table to try to compensate
for learning effects in the second implementation.
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.
He also gets confused when he talks about object oriented programming
being a failure. He attributes the short comings of one implementation
(C++) to the whole approach, much like people who reject Lisp/Scheme
because of one particular implementation.
Time will tell on this issue. Personally I think that the problems with
OO programming go beyond just C++.
>The button example requires about 25 lines of code in three procedures
>when implemented in C++ with Microsoft Foundation Classes. Just
>setting the font requires 7 lines of code:
>
>LOGFONT lf;
>
>memset(&lf, 0, sizeof(lf));
>
>lf.lfHeight = -16;
>
>strcpy(lf.lfFaceName, "Times New Roman");
>
>CFont *fontPtr = new CFont();
>
>fontPtr->CreateFontIndirect(&lf);
>
>buttonPtr->SetFont(fontPtr);
Come on! All this shows is the inconveniece of using the MFC
classes. An interface exactly the same as the Tcl one could easily be
written in C++.
I invite anyone who believes this to try to do it, and post the results.
I've had this argument before, and when people do this, one of two things
happens: either they eventually concede that this is hard to do in C++, or
they define new C++ APIs that are essentially untyped (e.g. they use
strings for everything). This just supports my arguments that types get
in the way of gluing. You can build untyped APIs in strongly typed
languages, but they tend to be clumsy because the languages are designed
to encourage strong typing. If you need an untyped approach, you might
as well use a language designed for that.
> >The button example requires about 25 lines of code in three procedures
> >when implemented in C++ with Microsoft Foundation Classes. Just
> >setting the font requires 7 lines of code:
> >
> >LOGFONT lf;
> >
> >memset(&lf, 0, sizeof(lf));
> >
> >lf.lfHeight = -16;
> >
> >strcpy(lf.lfFaceName, "Times New Roman");
> >
> >CFont *fontPtr = new CFont();
> >
> >fontPtr->CreateFontIndirect(&lf);
> >
> >buttonPtr->SetFont(fontPtr);
CButton* button1;
CButton* button2;
button1 = new CButton();
button1->Create("Push me", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON, r, this,
101)
button2 = new CButton();
button2->Create("Pull you", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON, r, this,
102)
font = new CFont;
font->CreateFont(16,0,0,0,700,0,0,0,ANSI_CHARSET,OUT_DEFAULT_PRECIS,CLIP_DEFAULT_PRECIS,
DEFAULT_QUALITY,DEFAULT_PITCH|FF_DONTCARE,"times");
button1->SetFont(font)
button2->SetFont(font)
Basically 3 lines to create a font (reusable assuming you only
what a few types of fonts, set up a function to handle size changes
if it's the same, you can also create a simple function to handle
defaults for everything but the size and type.
3 lines to create a Button.
I don't know where Oesterhout's reference on MFC comes from
(I'm just looking at Brain & Lovette's book).
I'm not an MFC expert, so I asked someone else, whom I consider to be
a good Windows programmer, to write this for me. Perhaps there is a
shorter way than the code I included. However, the 6 lines above
don't seem to be equivalent to the Tcl script. For example, there is
no code to respond to the button press, and I believe additional code is
needed to free resources when the button is deleted. Suppose that the
MFC code I used is off by a factor of two, and that it really only takes
12 lines of C++ to duplicate the functionality of one line of Tcl. Doesn't
that still illustrate my point?
------------------------------
Date: Sun, 06 Apr 1997 06:29:11 +0100
From: "Park J. H." <jong@mrc-lmb.cam.ac.uk>
To: John Nielsen <jnielsen@chemistry.mps.ohio-state.edu>
Subject: Re: perl for winNT and visual basic
Message-Id: <334734A7.794B@mrc-lmb.cam.ac.uk>
John Nielsen wrote:
>
> We are going to be doing some programming for Windows NT and having to use and
> support perl on the unix side, it would be cool to use perl on the Windows
> side.
>
> How does perl compare to visual basic for windows for getting quick programming
> jobs done? Also, can one setup a graphical interface w/perl as one can
> do with visual basic.
I do not know much about VBasic, but I know Basic and
some opinions on VB.
Perl can not be compared with any langs created so far
for its quick problem solution. So, in general, it
is out of question, you try Perl. For graphics, perl
community is failing to make a good one for Windows.
It is a pity. If you do need a GUI, I think you
should go for VB.
> What are the advantages of using perl for win32 versus visual basic/c++.
Perl has much higher productivity and ease of maintenance than
others. While it lacks GUI for Win. VB is fairly productive
while VC seems to be more demanding. I found MFC is a very
neat one, but C++ in general asks too much for me. If you
use UNIX as well, Perl will be excellent, as there is
virtually nothing you need to change unless you use some
rare functions which are not supported by Win32 Perl.
Jong
> Thanks for any info . . . .
>
> john
--
I support Perl, Linux ...
With OVER SIX MILLION USERS, up from only ten or so a very few years
ago, Linux has taken it's place as the world's #3 computer operating
system overall. And Linux is breathing down the neck of #2 for very good
reasons. If growth rate to date continues, Linux will be the #1 computer
operating system by late '98 or '99. Are YOU ready?
) Linux Newsletter
http://www.smli.com/people/john.ousterhout/scripting.html
------------------------------
Date: Sun, 06 Apr 1997 00:02:07 GMT
From: frank@primemail.com (Frank Fisher)
Subject: Perl Variable Passing Help Needed
Message-Id: <3346e7c7.474590@nntp.a001.sprintmail.com>
I'm having trouble passing a perl variable to a javascript variable.
I'm trying to initialize a radio button at form load time from data in
a file (like a customer fetching their data and then making edits to
it). I can initialize a text box using the value= but radio and check
boxes are different - there are multiple definations of those - so
which one gets set?
The key variables in this code snippet are $plimit (the perl variable)
and jlimit (the javascript variable). $plimit is fetched from an
ascii file and that works. In the <BODY onLoad= I'm trying to pass
the $plimit variable as an argument to the javascripit function
init(). I get a syntax error msg around the init( call.
There must be a way to pass a perl variable $plimit to a javascript
function???
The following is a snippet of the code that attempts to do this.
Thanks for any help...
Here's the code snippet:
#!/usr/bin/perl -w
open (CUST, "cust.txt");
@buffer = <CUST>;
$plimit = $buffer[0];#fetch data into perl variable
close(CUST);
print <<"ending_print_tag";
Content-type: text/html\n\n
<HTML><HEAD>
<TITLE>Edit PrimeMail Account</TITLE>
<SCRIPT LANGUAGE="JavaScript">
<!-- Hide javascript code
var jlimit = 0;
function init(jlimit)
{
if (jlimit == 100)
{
document.limitform.limit[0].checked = true;
}
if (jlimit == 200)
{
document.limitform.limit[1].checked = true;
}
if (jlimit == 300)
{
document.limitform.limit[2].checked = true;
}
return true;
}
// stop hiding javascript -->
</SCRIPT>
</HEAD>
<BODY onLoad="init($plimit);"> <----problem area here!!!
<FORM METHOD=POST NAME="limitform">
100<INPUT TYPE="radio" name="limit" VALUE="100">
200<INPUT TYPE="radio" name="limit" VALUE="200">
300<INPUT TYPE="radio" name="limit" VALUE="300">
</FORM>
</BODY>
</HTML>
------------------------------
Date: Sat, 05 Apr 1997 23:05:49 -0500
From: Aaron Sherman <ajs@ajs.com>
Subject: Re: Perl vs. C/C++
Message-Id: <3347211D.3D87@ajs.com>
Jason C Austin wrote:
>
>>> You're still rewriting C memory management routines by the
>>> same point in time you'd be finished in perl.
>
> Which doesn't matter in a project of any size. Almost all
> your resources in a full blown application go to design, bug fixing,
> and improvements. Coding is the easy part and the time it takes is
> negligible. C++ is far superior when it comes to large scale
> projects.
Excuse me, but that's a joke, right? Since when is "bug fixing"
and "improvements" not "coding".
If your programmers don't spend at least 60% of their time coding,
perhaps you should be looking for new programmers....
> As far as extremely fast, I've done a lot of testing, and the
> perl programs commonly took 200 times longer to run an exact
> translation of the C code. Even if you could get that down to twice
> as long, I'm not going spend a million on a computer and get the same
> performance as a competitor that spent $500,000.
Yep, a C++ to perl translator would sure be a bad idea ;-)
Seriously, though, most code that I use these days (this includes
a lot of large non-GUI systems that you would think spend its
time crunching data) doesn't sit on the system spinning in a
tight loop. In perl, when you run into the exception that
does need to do that (and I do from time to time), you drop down
into C using the XS interface.
Certainly for any project that requires threading, perl is (currently)
not useable (unless you are using an embedded perl as a single
thread in your multi-threaded C/C++ application).
Speed of development is key, and in perl it's ungodly fast. I
regularly stun people with how fast I can crank out a piece of
code that does something quite complex (though I'll admit until
recently I was stunning semi-programmers and admins).
On the other hand, with the RIGHT libraries, and a limited number
of platforms to port to, I would go with C/C++. With a user base
under MS windows and UNIX and a very high-level application with no
performance constraints, I'd go with Java. Everything else is perl.
> I do still use C when reliability
> is important since perl is much more bug prone due to its lack of
> strict data typing and function prototypes.
As of 5.002, perl has a form of prototyping (really only for parameter
count checking and context assignment). Strict typing is overrated,
and the first thing that C++ programmers try to do is eliminate it
by making their C++ classes pretend there is no such thing.
Perl has strict type checking. It ALWAYS knows what your data it.
The problem that people have is that perl the procedes to
happily convert your data to whatever it thinks makes sense in
the current situation. You ment type restriction, but because
languages like C/C++ aren't semantically powerfull enough to make
that distinction everyone forgets that there is one to be made.
> People have tried to tell
> me perl is more reliable since it won't crash on memory handling
> errors, but I would much rather have a program crash then to happily
> run for days producing completely wrong answers.
Oh, now that's just silly. Come, come. The only thing that you're
saying here is that you wouldn't use perl because, given bad code,
it does bad things, as opposed to C which, given bad code does a
wider variety of bad things, many of which involve an end to the
execution of the program. One word: debug. "Segemntation
Violation: core dumped" is not a debugging feature ;-)
> => : 2) How well does it handle files and strings?
> =>
> We are talking about C++ and the STL has these data structures
> along with the automatic memory handling. Even if you don't have a
> template library, it doesn't take long to write it once and never
> think about it again. If you ever tried to do highly advanced data
> structures in perl (beyond simple lists of lists, strings, etc),
> you'll end up pulling you hair out at the pile of nasty syntax.
Gee, I never thought of $stuff->[77]->{"Uber mensch"} as a "pile
of nasty syntax". Are you, perhaps used to using perl 4? BTW: as
a side point, I'd take libperl.a over any C/C++ data structure
library any day. Though, in C++ I might write some wrapper
classes, because it's just begging to be turned into an SV object,
AV object and HV object (etc, etc....)
>> => Perl handles files better than C does, because it allows you to
> => read the entire file into an array with one fell swoop, and process
> => the array. (You don't even have to explicitly define the array! :))
>
> That's hardly a difference. You can read an entire file into
> memory in any language if you so desire.
Um, no. Some C-derived languages (e.g. TCL) fail to provide a way
to deal with binary data at all. But, the key here was language support
for complex file operations in very small amounts of code. e.g.:
print OUTFILE map { s{(\d+)}{$1 + 88}eg } <INFILE>;
Which reads in an entire file and increments every number in it
by 88, printing it out on the filehandle OUTFILE, which may or
may not be an actuall file (e.g. it could be a socket or a
process). Please demonstrate the one-liner for this in C/C++/Java/
VB/sh/awk/etc/etc/etc.... Heck, you could even through in a sort
there, with the overhead of 5 more characters.
> =>
> => : 3) What about support and documentation?
> =>
> => Perl actually works, which makes support less relevant than it
> => would be for other things. Also, you have the source code, so you
> => can fix it when it doesn't. (People who use perl tend to be
> => people who could do that, and the time savings are enormous.)
> => Perl is copiously documented both online and through the
> => Camel book.
>
> So, are you saying C doesn't work? A pointless comment since
> perl and the OS is written in C.
Yes, that was a pointless response. The correct response would have
been that most C compilers come with a LOT less documentation then
perl does. Perl arrives with a book-length set of documentation that
introduces you to everything from command-line switches to how to
take advantage of the object-oriented features of the language.
There are also a wealth of books (of which the O'Reilly books
are at the top of the list), and many advanced topics are already
covered in books that relate to other languages (e.g. graphics,
OS interaction, databases, etc). While it would be nice if there
were a perl version of each of these books, it is certainly not
a requisite.
Support is a stickier problem. I'm not sure if Cygnus supports perl
yet, but if they do, there it is. If not, I guess that's the one
chink in the armor. My take, though, is that there are so many
people out there, beating on each release, that it's just not
going to affect your life that dramatically. The last time I
discovered a perl bug it was in the XS library (external code
interface) which would not have been discovered unless you
really worked at it (and I did). This was fixed within 2 months
(in the next rev), but I had long since worked around it.
------------------------------
Date: 6 Apr 1997 04:46:47 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Perl vs. C/C++
Message-Id: <5i79rn$gl0$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
austin@visi.net writes:
: As far as extremely fast, I've done a lot of testing, and the
:perl programs commonly took 200 times longer to run an exact
:translation of the C code.
You've got something very seriously wrong. Even matrix multiply
isn't that bad.
:I can throw a quick script together that
:would take a couple of hours in C.
I can write a Perl script in hours that would take you weeks to
write in C. And in those weeks, I've written dozens more. You'll
never catch up.
:I do still use C when reliability
:is important since perl is much more bug prone due to its lack of
:strict data typing and function prototypes.
Perl has as strict data typing as you want, which in nearly all cases,
is none at all. What, you want strigs of length 5 and those of length
10 to be of fundamentally different types. Blech.
As for prototypes, well, we've got them, although not to a super-anal
granularity. You ever tried to call push() with a hash argument?
:People have tried to tell
:me perl is more reliable since it won't crash on memory handling
:errors, but I would much rather have a program crash then to happily
:run for days producing completely wrong answers.
If it gets wrong answers, whose fault is that? :-)
Memory management is purely insane. And destructors being
calls too early is fundamentally flawed.
:If you ever tried to do highly advanced data
:structures in perl (beyond simple lists of lists, strings, etc),
:you'll end up pulling you hair out at the pile of nasty syntax.
Funny, I never had that problem.
: That's hardly a difference. You can read an entire file into
:memory in any language if you so desire.
Bah. You're dodging the issue.
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
if (*name == '+' && len > 1 && name[len-1] != '|') { /* scary */
--Larry Wall, from doio.c in the v5.0 perl distribution
------------------------------
Date: Fri, 04 Apr 1997 17:48:01 +0100
From: Laurence Molloy <lauriem@cstr.ed.ac.uk>
Subject: Re: Simple array question by newbie...
Message-Id: <334530C1.749C@cstr.ed.ac.uk>
Alan Weiner wrote:
>
> <SNIP>
>
> $nxtMonth=getNxtMonth("Mar");
> print "$nxtMonth";
>
> sub getNxtMonth {
>
> <SNIP>
>
The problem is a missing "&".
In perl, to call a subroutine you must prefix the name of the subroutine
with an ampersand thus
$nxtMonth=&getNxtMonth("Mar");
is what you want.
Laurence.
------------------------------
Date: 6 Apr 1997 05:02:13 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Trouble t with a 2D array!
Message-Id: <5i7aol$gl0$2@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
Tom Phoenix <rootbeer@teleport.com> writes:
:> I've been going crazy trying to make this 2D test array work as it
:> should,
:
:That's okay. Perl doesn't have 2D arrays.
Pretty please cut that out; you're hanging out with Randal too much. :-)
Perl certainly *does* have two-dimensional arrays. Larry stated as
much the last time this came up. It's not right to claim they don't.
Please don't say that. One just has to be aware of their implementation
for many applications. Perl *does* have 2D arrays; they just happen
to implemented with references. To claim otherwise rings of Sophistry.
--tom
--
Tom Christiansen tchrist@jhereg.perl.com
A woman needs a little more weird today than normal. --Andrew Hume
------------------------------
Date: Sat, 05 Apr 1997 23:09:36 -0500
From: Aaron Sherman <ajs@ajs.com>
Subject: Re: Writing a routine the works like 'open'
Message-Id: <33472200.5E60@ajs.com>
Roderick Schertler wrote:
>
> On Tue, 01 Apr 1997 23:05:05 GMT, bernie@rev.net (Bernard Cosell) said:
> >
> > [...] how you can write subroutines which take 'filehandles' as
> > arguments and can do the right thing with the argument [e.g., leaving
> > the 'filehandle' open in the context of the caller so that the caller
> > can then read the file, etc.]
>
> If the calling and called subroutines are in the same package there is
> nothing special you have to do, just put the filehandle argument in a
> scalar and use the scalar where you normally would a filehandle.
>
> If the caller might be in a different package then you have to qualify
> bareword filehandles with the name of the calling package (otherwise
> Perl will put them in your package). Use Symbol::qualify for this.
Also, you can always accept a glob or glob-ref (e.g. *FILE or \*FILE).
sub x {
my $fh = shift;
if (ref(\$fh) eq 'GLOB' || ref($fh) eq 'GLOB') {
# Do something with the FH.
} else {
die "$0: Glob or glob ref required.\n";
}
}
On the other hand, see the IO library for what you really SHOULD be
doing...
-AJS
------------------------------
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 241
*************************************
