perl and XEmacs
David Bakhash
hey,
I was reading the new O'Reilly book on Perl, "Learning Perl",
and noticed the mention of Perl being embeddable and extensible. It's
these abilities (and the fact that Perl is well-written in C, with the
right type of interface) that makes it embeddable. This allows Perl
to be embedded in vi. If vi has been able to embed Perl into itself,
then why can emacs/XEmacs? I figure that this can be a user option
which takes place during the build. It would make XEmacs extremely
powerful -- and for Perl junkies (like what I'm becomming) it would
solve may problems (like the regexp problem that emacs REs are
unfriendly). I would like to see this happen. There's no doubt that
people would be interested. I recall a thread some months ago that
was probably 100 deep on Perl REs in XEmacs. It even got a package
for converting Perl-style REs to emacs-style (Larsi). So who's
interested. Count me in.
dave
Noah Friedman
> > adding more bloat. (Frankly, my sentiments in that regard go for MIME in
> > Emacs 20 too, but it's too late to cry over spilled milk.)
>
>What are you referring to about this MIME business?
Sorry, I meant MULE. Obviously my mind is too traumatized by the
implications of that acronym to use it properly.
Noah Friedman
David Bakhash <ca...@ll.mit.edu> writes:
> right type of interface) that makes it embeddable. This allows Perl
> to be embedded in vi. If vi has been able to embed Perl into itself,
> then why can emacs/XEmacs? I figure that this can be a user option
> which takes place during the build. It would make XEmacs extremely
> powerful -- and for Perl junkies (like what I'm becomming) it would
> solve may problems (like the regexp problem that emacs REs are
> unfriendly). I would like to see this happen.
I would dearly like to see people fixing the performance problems in
XEmacs---not the least of which is the braindead garbage collector---before
adding more bloat. (Frankly, my sentiments in that regard go for MIME in
Emacs 20 too, but it's too late to cry over spilled milk.)
My advice on perl modules is not to do it. There's not enough to be
gained. And not doing anything at all is better than doing something
bad(ly).
David Bakhash
Noah Friedman writes:
> David Bakhash <ca...@ll.mit.edu> writes:
> > right type of interface) that makes it embeddable. This allows Perl
> > to be embedded in vi. If vi has been able to embed Perl into itself,
> > then why can emacs/XEmacs? I figure that this can be a user option
> > which takes place during the build. It would make XEmacs extremely
> > powerful -- and for Perl junkies (like what I'm becomming) it would
> > solve may problems (like the regexp problem that emacs REs are
> > unfriendly). I would like to see this happen.
>
> I would dearly like to see people fixing the performance problems in
> XEmacs---not the least of which is the braindead garbage collector---before
> adding more bloat. (Frankly, my sentiments in that regard go for MIME in
> Emacs 20 too, but it's too late to cry over spilled milk.)
What are you referring to about this MIME business? can you explain?
I must have missed it when it happened.
I did notice that the GC in XEmacs drags a bit.
> My advice on perl modules is not to do it. There's not enough to be
> gained. And not doing anything at all is better than doing something
> bad(ly).
I agree w/ this too, but will embedding it in XEmacs now vs. later
necessarily make any difference whatsoever? Probably, in which case I
saw that holding off on the Perl interface would be a good thing. But
as long as you and others have an open mind for it in the future. I'm
only 23. I've got time. I can wait a few years I guess, but the more
I have, the more I want. XEmacs is a disease in this regard.
dave
David Bakhash
frie...@splode.com (Noah Friedman) writes:
> > > adding more bloat. (Frankly, my sentiments in that regard go for MIME in
> > > Emacs 20 too, but it's too late to cry over spilled milk.)
> >
> >What are you referring to about this MIME business?
>
> Sorry, I meant MULE. Obviously my mind is too traumatized by the
> implications of that acronym to use it properly.
I love the concept of MULE. I love the ability of one program to do
everything. That's why I want Perl embedded. I wouldn't bother if I
was satisfied with elisp, but frankly I'm not. Ideally (for me) emacs
would have a Common Lisp engine, so it's extension language would be
more powerful. And it would be multi-threaded and lexically scoped, and
be faster. Now that I do a lot of Perl, I see its utility, and believe
that this can benefit emacs, and potentially fix some of its inherent
weaknesses, like relatively poor regexp facilities (IMO). Anyway,
embedding Perl would be an option for whoever was building XEmacs, so
it's not like package writers would be writing code which depended on it.
--dave
Jeff Bauer
>On 06 Aug 1997 17:27:08 -0400, bwa...@cnri.reston.va.us (Barry A. Warsaw) wrote:
>I agree with one thing though, it would be nice to have Perl's regexp
>engine in X/Emacs. The Python StringSIG community is in fact working
>on getting Perl regexp facilities into Python, and any work on
>de-Perl-ifying Perl's regular expression engine would benefit many
>communities, Python, Emacs, (Java?), etc.
>
>-Barry
Pardon me for taking this thread futher off-topic, but there's a
great Perl5 regex package for Java (see below). I'm glad
Python is adding Perl regexp, as it's hard to keep all the
rules straight among the various regex dialects.
-Jeff Bauer
http://www.cs.umd.edu/users/dfs/java/index.html
"05/12/97 OROMatcher(TM) is a commercially supported but
free Java regular expression package that is fully compatible
with Perl 5 (yes Perl 5 not 4) regular expressions, unlike any
other regular expression package for Java. It is free although
NOT public domain. You would be making a big mistake to
pay any amount of money for a Java regular expression
package when this one provides greater functionality,
reliability, and performance than any other available
package. "
David Masterson
David Bakhash <ca...@mit.edu> writes:
> I love the ability of one program to do everything. That's why I
> want Perl embedded. I wouldn't bother if I was satisfied with
> elisp, but frankly I'm not. Ideally (for me) emacs would have a
> Common Lisp engine, so it's extension language would be more
> powerful. And it would be multi-threaded and lexically scoped, and
> be faster. Now that I do a lot of Perl, I see its utility, and
> believe that this can benefit emacs, and potentially fix some of its
> inherent weaknesses, like relatively poor regexp facilities (IMO).
> Anyway, embedding Perl would be an option for whoever was building
> XEmacs, so it's not like package writers would be writing code which
> depended on it.
But where does it end? Elisp yesterday, Perl today, Tcl tomorrow, and
don't forget Python or even just C/C++! Can you imagine the memory
requirements (don't cop out with "memory is cheap")!
Are you sure you wouldn't rather have a tightly integrated suite of
programs that would be smaller and more easily managed by the
operating system? For instance, how would you redesign Emacs if you
were to break it down into components that communicated via a message
bus (CORBA, DCOM, etc.)?
--
David Masterson
da...@batcave.bungi.com
Graham Hughes
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "David" == David Bakhash <ca...@mit.edu> writes:
David> Anyway, embedding Perl would be an option for whoever was
David> building XEmacs, so it's not like package writers would be
David> writing code which depended on it.
Doesn't that defeat the entire purpose of embedding a language?
The reason why MULE is a compile time option is because it breaks
stuff. Badly. Unfortunately, it's farther along than alternatives.
Embedding Perl would be actually *worse*, because now two languages
with vastly different concepts of what the interface should look like
need to coexist and somehow communicate with each other (or were you
proposing that everybody suddenly recode everything in Perl?). What
does a cons cell look like to Perl? What does a file handle look like
to Lisp? What does an alist map to, and how does it do it? What does
a symbol in Lisp mean in Perl? How about subroutines? How does a
Lisp function understand wantarray? How do I add a Perl subroutine
with add-hook? And this is between two languages that are *similar*
in many ways (anonymous functions, closures, lists, etc.)!
You're being shot down because you obviously haven't thought this
thing through. Just being able to call Perl on some text isn't
enough.
You owe the Oracle a clue.
- --
Graham Hughes <ghu...@cs.ucsb.edu> MIME OK, PGP preferred
"One thing they don't tell you about doing experimental physics is
that sometimes you must work under adverse conditions ... like a state
of sheer terror." - W. K. Hartmann
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBM+14DyqNPSINiVE5AQFnEgP+OZQlKL/8K1Fl7XR0QAQ79BQrhl24DOL2
zutk4alvhPlxdNgVxGimjKIASurFxa4IkGPPDrZx9n6Nx92vn0grWG35epTdY3JQ
g1IxHwshOg57g+10XJ1geuRln9hZjwCEpOTOB5qizFzNBOW8zndusZx2x0D8dWY4
hj8sDmVRwic=
=GAmr
-----END PGP SIGNATURE-----
David Bakhash
Graham Hughes <ghu...@cs.ucsb.edu> writes:
> Embedding Perl would be actually *worse*, because now two languages
> with vastly different concepts of what the interface should look like
>
> You're being shot down because you obviously haven't thought this
> thing through. Just being able to call Perl on some text isn't
> enough.
You are right in so many ways. I actually did not think this through
very much. I believe that I should think it through as I am in the
midst of trying it, trying to see what's possible, what's feasible,
and what's simply a bad idea. I also was not clear about my
intentions, so here I go:
I was planning to use perl in the following way. Most of emacs
functions on the notion of buffers, and some buffers have their
associated filenames. This *does* go well with the filehandle concept
in Perl, and so was hoping that elisp could leverage off of Perl by
making use of what's already been done. Suppose I wanted to do a
search-and-replace like the following on a buffer or region:
s/(darn\s+){2,4}/Damn!/
Instead of dealing with it by adding to the elisp interpreter, I was
hoping that the elisp interpreter could somehow pass this off to
Perl. Not so hard, (though a far cry from a good-enogh reason to
embed a few more megs into XEmacs). I don't enjoy Perl programming as
much as elisp, personally, but if elisp can actually make use of the
Perl libraries somehow, then I'm all for it.
What you said implied that I was talking about a much higher lever
effect on the user than you thought. I was not planning to have a
.emacs file that was partly written in Perl; I was, however, planning
for some mid-level DEFUNs in C to make use of the embedded Perl. When
I said "the elisp extension language is not so sufficient" I didn't
mean that it needed to change structurally. Theoretically, these
languages all meet some equivalence somewhere; it's silly to argue
about taste. But there's a big difference between semantics/syntax
(which I *don't* want elisp to change) and functionality (which I *do*
want to see augmented). It was a very smart idea years ago that an
editor make use of a fully-functional computer language as its
extension language. But no doubt that there was laziness there too,
and probably some tentativeness which led to its limitaions. I want a
quick-and-dirty solution to some of the limitations. I accept that I
was too reluctant to think it through and too hasty. I hope you don't
feel that I wasted yours or anyone's time. We're just exploring the
possibilities. I'm still interested in the Perl thing as a personal
venture. The XEmacs source code is public, so it won't hurt anyone.
I do see the drawbacks, may drop this idiocy sooner than later.
dave
Justin Sheehy
David Bakhash <ca...@mit.edu> writes:
> I love the ability of one program to do everything. That's why I
> want Perl embedded.
What is it that emacs can't do that you wish it could?
Is the issue the ability to do more, or just the ability to do things
the perl way? The former is generally a win, but the latter is
questionable.
> I wouldn't bother if I was satisfied with elisp, but frankly I'm
> not. Ideally (for me) emacs would have a Common Lisp engine, so
> it's extension language would be more powerful.
Um.
(require 'cl)
*poof*
Works pretty well for most reasons that one would want CL, as far as I
can see.
> Now that I do a lot of Perl, I see its utility, and believe
> that this can benefit emacs, and potentially fix some of its inherent
> weaknesses, like relatively poor regexp facilities (IMO).
I think that individual packages which augment emacs' functionality,
such as Lars' package to convert perl regexps to elisp, are a good
idea.
However, that is a far cry from embedding another language into emacs,
which I think is a somewhat silly idea as elisp either does or can be
extended to do just about everything.
> Anyway, embedding Perl would be an option for whoever was building
> XEmacs, so it's not like package writers would be writing code which
> depended on it.
This doesn't make much sense.
IMO, you would need to commit one way or the other. If you are going
to embed a whole new fully-featured language into emacs, is it worth
the immense amount of work if developers couldn't count on its
presence?
--
Justin Sheehy
In a cloud bones of steel.
David Bakhash
Justin Sheehy <jus...@linus.mitre.org> writes:
> David Bakhash <ca...@mit.edu> writes:
>
> > I love the ability of one program to do everything. That's why I
> > want Perl embedded.
>
> What is it that emacs can't do that you wish it could?
Mostly regular expression stuff is what prompted me.
> Is the issue the ability to do more, or just the ability to do things
> the perl way? The former is generally a win, but the latter is
> questionable.
just add to what it can do (questionable).
> (require 'cl)
Yes, this is a nice feature.
> I think that individual packages which augment emacs' functionality,
> such as Lars' package to convert perl regexps to elisp, are a good
> idea.
I use it a lot now. It's cool. I like the idea.
> However, that is a far cry from embedding another language into emacs,
> which I think is a somewhat silly idea as elisp either does or can be
> extended to do just about everything.
doing everything can theoretically be done with no more than lambda.
But doing everything *fast* is a different story.
> > Anyway, embedding Perl would be an option for whoever was building
> > XEmacs, so it's not like package writers would be writing code which
> > depended on it.
>
> This doesn't make much sense.
It does if you just wanna play. I wasn't suggesting it as any more than
a fun project. Just as a test. Not a feature that will ever become
part of the distribution.
> IMO, you would need to commit one way or the other. If you are going
> to embed a whole new fully-featured language into emacs, is it worth
> the immense amount of work if developers couldn't count on its
> presence?
I wasn't planning to involve the developers. As I said, the source code
for both Perl and XEmacs is there. Me and whoever was interested could
take a stable XEmacs and try to work with it independently. Just as an
asside. you know -- proof of concept. I think if I did it I'd learn a
lot, which would make it worthwhile in and of itself.
dave
Richard Coleman
Jamie Zawinski <j...@netscape.com> writes:
> You are trying to shoehorn your existing preconceptions of how one
> should program onto a vastly different (and older, and more internally
> consistent) model. I suggest your time would be better spent learning
> and understanding that other model, and learn to use it properly, and
> learn what it can and cannot do, rather than infecting it with this new
> cancer out of ignorance.
>
> The notion that everything is a stream of bytes is utterly braindead.
> The notion that regexps are the solution to all problems is equally
> braindead.
>
> Just like Perl.
Come on Jamie... tell us how you REALLY feel.
:-)
Richard Coleman
col...@math.gatech.edu
Joe Davison
David Bakhash wrote:
>
> I was planning to use perl in the following way. Most of emacs
> functions on the notion of buffers, and some buffers have their
> associated filenames. This *does* go well with the filehandle concept
> in Perl, and so was hoping that elisp could leverage off of Perl by
> making use of what's already been done. Suppose I wanted to do a
> search-and-replace like the following on a buffer or region:
>
> s/(darn\s+){2,4}/Damn!/
Uh, doesn't query-replace-regexp do exactly that? The syntax of the regexp
may be slightly different, but I think the capability is there.
--
Joe Davison jwda...@lucent.com
Sure it doesn't work as well as it used to,
but think of all the money we're saving.
Vladimir Alexiev
In article <33F0C496...@netscape.com> Jamie Zawinski <j...@netscape.com> writes:
> Kelly Murray wrote:
> > Why not make everything a stream of BYTES ?
> > Then we can send one programs output BYTES as input BYTES to another
> > program! It works, you can do a lot of stuff with it -- been around
> > now for 20-30 years. Has a few bugs though. BYTE number 4 causes
> > some confusion. BYTE number 0 too. BYTE numbers > 127 seem to cause
> > some bugs too.
> The notion that everything is a stream of bytes is utterly braindead.
Jamie, you gotta learn to recognize sarcasm when you see some. Unless I'm
completely mistaken and Kelly is an idiot.
> > Hmm, maybe if everything was an OBJECT instead, we might get
> > somewhere??
No, he's just being sarcastic.
> The notion that regexps are the solution to all problems is equally
> braindead.
Agreed, but still, having more powerful regexps in emacs won't be bad.
Of course, embedding perl in emacs for only that reason is ridiculous.
> Just like Perl.
What's wrong with perl? To me perl is the triumph of utalitarianism.
David Masterson
David Bakhash <ca...@mit.edu> writes:
> I was planning to use perl in the following way. Most of emacs
> functions on the notion of buffers, and some buffers have their
> associated filenames. This *does* go well with the filehandle concept
> in Perl, and so was hoping that elisp could leverage off of Perl by
> making use of what's already been done. Suppose I wanted to do a
> search-and-replace like the following on a buffer or region:
>
> s/(darn\s+){2,4}/Damn!/
C-u M-x shell-command-on-region
Just build a small perl filter that takes your substituion command as
an argument and then applies that to the input.
--
David Masterson
da...@batcave.bungi.com
Gary Kline
According to Jamie Zawinski:
[[ ... ]]
> >
> > What's wrong with perl?
>
> It combines all the worst aspects of C and Lisp: a billion different
> sublanguages in one monolithic executable. It combines the power of
> C with the readability of PostScript.
You've hit the nail pretty much on its head,
although people who understand perl find it
acceptable... perl5 has been broken into separate
extension libraries, loaded dynamically.
>
> > To me perl is the triumph of utalitarianism.
>
> So are cockroaches. So is `sendmail'.
>
So you want COBOL?
>
--
Gary D. Kline kl...@tao.thought.org Public service uNix
Jari Aalto
| Jamie Zawinski <j...@netscape.com> writes:
| > What's wrong with perl?
|
| It combines all the worst aspects of C and Lisp: a billion different
| sublanguages in one monolithic executable. It combines the power of
| C with the readability of PostScript.
Well; I can't imagine any other language that would allow me to
to do Newsgroup server scan and looking for specific articles by
just few lines of Perl5 OO code. Hey; i can even do batch Http
search on selected URL pointers with handfull of code.
It's simply amazingly powerfull compared to any other language.
And if you comment your code well, it's not that hard to understand
at all.
Cheers!
jari
Les Schaffer
Jamie Zawinski <j...@netscape.com> writes:
> At any time, at any place, our snipers can drop you. Have a nice day.
gee. is this how the 90's are? you write a famous piece of software,
then get hired by a famous company, and then post obnoxious sigs like
that above? Nice. where do i apply for membership?
Les
Jym Dyer
>> What's wrong with perl?
=o= I would say Bourne shell and Lisp, except not really Lisp,
more like awk, and not in a "worst aspects" way, either.
=o= It corrects my one and only complaint about Emacs Lisp, in
that it uses egrep-style regexps instead of grep-style regexps
(hence, no "backslash-itis").
=o= GUILE would win me back over by doing the same.
<_Jym_>
David Masterson
Les Schaffer <godz...@futuris.net> writes:
Application is Irrelevant. Membership is Irrelevant. Resistance is
Futile. You will be Assimilated...
Oh wait -- maybe that's Microsoft... :-)
--
David Masterson
da...@batcave.bungi.com
Randy J. Ray
>>>>> "Jamie" == Jamie Zawinski <j...@netscape.com>
>>>>> wrote the following on Tue, 12 Aug 1997 13:16:22 -0700
Jamie> The notion that everything is a stream of bytes is utterly
Jamie> braindead. The notion that regexps are the solution to all
Jamie> problems is equally braindead.
Jamie> Just like Perl.
The two points are valid, and I doubt that anyone in the so-called "higher
ranks" of Perl would try to put these ideas forward. A current interview with
Larry Wall (the creator of Perl) in SunWorld OnLine shows that certainly
doesn't buy into the one-universal-tool theory. But on what grounds do you
label Perl "braindead"? I speak from the standpoint of managing the development
of a product that includes over 50,000 lines of Perl code, a system that has
to run identically and cleanly on more than 5 different architectures, a
requirement that Perl meets very smoothly. I have many tools in my box, Perl is
just one, and for the things it is suited to, it is the best tool. XEmacs is
another, as are Lisp in general, C, various symbolic debuggers, etc.
Jamie> Some people, when confronted with a problem, think "I know,
Jamie> I'll use regular expressions." Now they have two problems.
The first of which is assuming that one solution fits universally to the whole
set of problems, yes. My guess is, the second problem is an irrational
resistance to new tools and techniques to solve problems.
Randy
--
===============================================================================
Randy J. Ray -- U S WEST Technologies IAD/CSS/DPDS Phone: (303)595-2869
Denver, CO rj...@uswest.com
"It's not denial. I'm just very selective about the reality I accept." --Calvin
Gary Kline
According to Randy J. Ray:
> >>>>> "Jamie" == Jamie Zawinski <j...@netscape.com>
> >>>>> wrote the following on Tue, 12 Aug 1997 13:16:22 -0700
>
>
> Jamie> Some people, when confronted with a problem, think "I know,
> Jamie> I'll use regular expressions." Now they have two problems.
>
> The first of which is assuming that one solution fits universally to the whole
> set of problems, yes. My guess is, the second problem is an irrational
> resistance to new tools and techniques to solve problems.
>
> Randy
>
Exceptionally well put. When I was in school
we learned that different tools were frequently
better suited for different tasks.
Additionally that, especially in this line, the
flexibility and grit to learn new methodologies
was essential.
Hasn't changed....
gary
Gary Kline
According to David Bakhash:
> frie...@splode.com (Noah Friedman) writes:
>
> > Sorry, I meant MULE. Obviously my mind is too traumatized by the
> > implications of that acronym to use it properly.
>
> I love the concept of MULE.
What is MULE? or, more explicitly, how is it used?
I have the multi-language stuff in my new xemacs-20.2,
but see nothing on its use.
> I love the ability of one program to do
> everything. That's why I want Perl embedded. I wouldn't bother if I
> was satisfied with elisp, but frankly I'm not. Ideally (for me) emacs
> would have a Common Lisp engine, so it's extension language would be
> more powerful. And it would be multi-threaded and lexically scoped, and
> be faster. Now that I do a lot of Perl, I see its utility, and believe
> that this can benefit emacs, and potentially fix some of its inherent
> weaknesses, like relatively poor regexp facilities (IMO). Anyway,
> embedding Perl would be an option for whoever was building XEmacs, so
> it's not like package writers would be writing code which depended on it.
>
I think you're onto something. Now that my lisp is
coming back, I understand more of emacs... But to
honestly _do_ anything useful, perl5 as an alternative
extension language would be a major ++plus.
Barry A. Warsaw
>>>>> "JA" == Jari Aalto <ssj...@uta.fi> writes:
JA> Well; I can't imagine any other language that would allow me
JA> to to do Newsgroup server scan and looking for specific
JA> articles by just few lines of Perl5 OO code. Hey; i can even
JA> do batch Http search on selected URL pointers with handfull of
JA> code.
Check out Python. It can do all this and more. It might be
minimally more verbose than equivalent Perl, but then you might also
have a hope of reading your own code a month later.
David Bakhash
Gary Kline writes:
> I think you're onto something. Now that my lisp is
> coming back, I understand more of emacs... But to
> honestly _do_ anything useful, perl5 as an alternative
> extension language would be a major ++plus.
hey,
I'm on the XEmacs-beta mailing list, and I saw a major patch
from someone who totally upgraded the regex module, now allowing XEmacs
regexps to deal with things like (blah){2,3}, minimal-matching, etc.
that's kinda nice, I think. It's still not posix, but it's half the
reason I wanted Perl embedded. sounds good to me. the Perl thing would
be nice too, but if people are willing to re-invent the wheel in C, then
that's good too.
dave
Spider plant breeding program
I like perl. 8-)
Nick
--
#!perl -wlpi[finger.liv.ac.uk] # If it doesn't work see doio.c line ~256
BEGIN{use Socket;$_="YIN;sockeXPZSOCK_STREAM,~proto'tcp'and\$|=connecXpack'S
na4x8',AZ79,\$;=~host qq$^Ior die\$!;print'/w nickc\r'YOUT;print\$^I";s/X/t
STDIN,/g;s/Y/;select STD/g;s/Z/F_INET,/g;s/~(\w*)/get$1byname/g;eval||die}
Ian Miller
Jamie Zawinski wrote:
>
> Perl's nature encourages the use of regular expressions almost to the
> exclusion of all other techniques; they are far and away the most
> "obvious" (at least, to people who don't know any better) way to get
> from point A to point B.
>
The Pattern Extraction and Reporting Language making extensive use
of regular expressions.... now who would have thought it?
> Maybe Java will save the day, once someone straps a Java front end onto
> the gcc back end.
Perl might be an abomination, but at least it's free.
ian
--
+-------------------------------------+---------------------------------------+
| ian miller; research student; |"Train with both heart and soul with- |
| learning agents and systems group; | out worrying about theory. Very often |
| university of aberdeen, scotland. | a man who lacks the essential quality |
+-------------------------------------+ of deadly seriousness will take |
| imi...@csd.abdn.ac.uk | refuge in theory." |
| http://www.csd.abdn.ac.uk/~imiller/ | -- Funakoshi Gichin |
+-------------------------------------+---------------------------------------+
Kevin Oberman
According to Jamie Zawinski:
[[ ... ]]
> >
>
> sublanguages in one monolithic executable. It combines the power of
> C with the readability of PostScript.
Seems like a message from someone who has not seen Perl for a long
time.
Perl is certainly modular. It is, in fact object oriented. I can
create objects and treat them just as I would in C++. Perl has an
autoloader to dynamically load modules. (To be entirely correct, Perl
is not quite capable of being object oriented as it used initializers
and terminators instead of constructors and destructors, but few
really care about the difference.)
I've written PostScript, Perl and C and Perl is by far the most
readable IF WELL WRITTEN. Code written in most any language may be
either obscure or clear. People who write bad code can write bad code
in Perl. Perl is not the solution every time, but it is a good
solution in many cases. (And, despite being compiled every time it is
executed, Perl can be surprisingly fast.)
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest Orlando Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634
Soren Dayton
Kevin Oberman <obe...@es.net> writes:
> I've written PostScript, Perl and C and Perl is by far the most
> readable IF WELL WRITTEN. Code written in most any language may be
> either obscure or clear. People who write bad code can write bad code
> in Perl. Perl is not the solution every time, but it is a good
> solution in many cases. (And, despite being compiled every time it is
> executed, Perl can be surprisingly fast.)
Sure. People can write good code in any language. That is not the
objection to perl. Realize also that people can write good code in
assembler and it can be understandable.
My objection is that the things that makes perl great for short scripts
and the like (things like while (<>) { .... print; }) are great when
they are great, but a real pain in the ass when they are not. I think
of things like an example in the perl book which confused me a lot:
map chr @list;
which works because `chr' looks at `$_' not `@_'.
So I naively wrote:
map myfunction @list;
and it did not work. Now:
map {myfunction($_)} @list;
works fine. The point is that there is a high degree of irregularity
that exists because perl was written with the `quick and dirty' hack in
mind. Of _course_ it is _nice_ _in the moment_ to be able to write:
map chr @list;
but it is not much more of a pain in the ass to write:
map {chr} @list;
and this would make the language more consistent and easier to learn.
What do I mean by easier to learn? I mean that I often write something
in 5 of C, Bourne Shell, ML, Scheme, elisp and Perl at least once a week
and the perl manual is the only one that I have on my desk. and I use
it nearly every time I ever write code. I think of perl as a lot like
C++: it will be understandable if you use a small set of the features in
the language. So I use functions, closureas (all the time. Thank you!),
prototypes, etc. I always make my use of `$_' explicit except when
doing:
while (<foo>) {
s/sdfsdf/sdfsdf/;
print;
}
or something analogous that is _so_ idiomatic, that there cannot be any
confusion. So part of the problem that I run into is that most people
have a similar idea, but they use different small sets (hell, I work
with someone that makes variable names from strings all over the
place. he thinks that is great! If you understand that about a lot of
his code it makes a lot of sense actually).
I wish that it was smaller because a lot of size (bloat) makes it very
hard to follow some times. And a lot of people that I know started to
learn to program in perl. And that is really bad news because people do
not develope habits that lead to good programming. I guess that my
point is that:
good programmers write good perl
bad programmers write bad perl
bad programmers become good programmers when writing code in haskell,
ml, etc because they are not allowed to be sloppy.
I prefer a language that gives me less options if they are always the
ones that I would pick for myself.
Soren
Kevin Oberman
Soren Dayton <csdayto...@cs.uchicago.edu> writes:
> Sure. People can write good code in any language. That is not the
> objection to perl. Realize also that people can write good code in
> assembler and it can be understandable.
>
> My objection is that the things that makes perl great for short scripts
> and the like (things like while (<>) { .... print; }) are great when
> they are great, but a real pain in the ass when they are not. I think
> of things like an example in the perl book which confused me a lot:
This is not the forum for arguing the merits of lack thereof of
Perl. I pretty much agree with your comments and I tend to avoid the
use of $_ and similar shortcuts. Most languages have them and they can
be a good thing in some cases. But they are often over used. (@_ has
been deprecated in Perl, although it still works.)
I was merely correcting some seriously invalid criticisms of Perl made
by Jamie (who dislikes Perl enough that I'm pretty sure he has not
used it since at LEAST V4).
SL Baur
Jamie Zawinski <j...@netscape.com> writes:
> Kevin Oberman wrote:
>>
>> This is not the forum for arguing the merits of lack thereof of
>> Perl.
> It is when someone proposes building it in to emacs.
(Agreed)
Someone appears to have already done this with a traditional editor.
See <URL:http://www.bostic.com/vi/> for sources.
nvi-1.79/build/README:
# @(#)README 8.26 (Berkeley) 10/19/96
Nvi uses the GNU autoconf program for configuration and compilation. You
should enter:
...
=-=-=-=-=-=-=
NVI'S OPTIONS TO THE CONFIGURE PROGRAM
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
...
--enable-perlinterp Include a Perl interpreter in vi.
...
enable-perlinterp:
If you have the Perl 5 libraries and you want to compile in the
Perl interpreter, enter:
--enable-perlinterp
as an argument to configure. (Note: this is NOT possible with
Perl 4, or even with Perl 5 versions earlier than 5.002.)
...
Randy J. Ray
Jamie> The Jargon File defines "brain dead" as
...
Jamie> and brain-damaged as
...
Jamie> Sounds about right to me.
Sounds like a certain GUI application that pretends to be a web browser cum
mail user agent cum newsreader, that spends most of its time making 49 Meg
core dumps on my HP workstation. But then, I'm not running a Micro$oft box,
so I'm not a real concern.
>> I speak from the standpoint of managing the development of a
>> product that includes over 50,000 lines of Perl code,
Jamie> I'm very, very sorry. It must really suck to be you.
Well, I was going to keep this "debate" fairly civil, but if you wish to
resort to sniping, I'd say working for Netscape and criticising other software
as "brain-dead" must really define "living in a glass house".
Jamie> If Perl gets you through the day, great; more power to you.
Jamie> But as a language, and as an application platform, it still
Jamie> sucks.
Compared to what? C? Is that what you rocket scientists are using to code
Netscape? I have a (supposedly) stable release version of NS 3.01, as my
company has a corporate-wide license agreement with NC. This "stable" released
product last week dumped a core nearly 50 Meg in size. What was it doing at
the time? Sitting on my internal (intranet) webserver's home page, a page with
no cutesy animated gifs or such, and Netscape was iconified. *YOU* may wish
to label Perl as braindead, but it is a considerably more stable piece of
software than anything I've seen come out of your company's domain.
Jamie> That doesn't mean that nobody is in the unfortunate situation
Jamie> where Perl is the best solution available to a given problem
Jamie> -- since we're living in the new dark ages of computing, that
Jamie> can easily happen, it happens every day. But that doesn't
Jamie> mean Perl is any less wrongheaded. Just that, sometimes,
Jamie> it's the only game in town.
You still don't explain why Perl is *wrong*. What is *wrong* about it. You
don't like the syntax? None of C, C++, Java or even Lisp are any more
naturally readable to a person new to the language.
Jamie> Personally, I'd like to be hacking in CLOS in the luxurious
Jamie> bucket seats of a highly tuned Lisp Machine development
Jamie> environment. But I don't think that's bloody likely, as I've
Jamie> been hacking C (it's not just a language, it's a grade) for
Jamie> the last six years.
Well, that's nice if it would make you happy, but what if there are people
and companies out here for which a CLOS/Lisp Machine environment is not the
best approach to the problems at hand to be solved? Or do you think that if
CLOS is your hammer, all the world's problems *really are* just nails?
Jamie> Perl's nature encourages the use of regular expressions
Jamie> almost to the exclusion of all other techniques; they are far
Jamie> and away the most "obvious" (at least, to people who don't
Jamie> know any better) way to get from point A to point B.
Yes, the regex engine is one of the strongest features. I'd much rather do any
form of data processing in Perl than Lisp. Maybe programmers with less
experience take simplistic approaches; that doesn't make a language itself
bad. If so, I'd love to see what havoc a novice Lisp programmer can wreak on
the repuatation of Lisp itself.
Jamie> Perl is not *all* bad; just mostly. In its favor, at least
Jamie> it has automatic storage management, lexical scope, and
Jamie> function pointers. But I'd say the bad parts
Jamie> (metastasization of regexps, excessive use of line-noise-like
Jamie> syntaxes for much, and Algoloid syntax for the rest) far
Jamie> outweigh the good parts.
I have no idea to what extent you have evaluated Perl, or to what other
languages and standards you are comparing it. I wouldn't dream of trying the
tasks I am responsible for in Lisp, and they would be very difficult in C
since one of the requirements is an ability to run on 5 or more different
architectures (none of which is a Lisp Machine). It's really kind of insulting
to listen to someone rave on about how flawed Perl is as a language and
development tool. I expect this sort of I-know-whats-best elitism from someone
like Richard Stallman, but I don't accept it from him, either.
Jamie> Maybe Java will save the day, once someone straps a Java
Jamie> front end onto the gcc back end.
Maybe no one language will ever save the day. Maybe we're doomed to have to
always choose from a variety of tools to select the one most suited to the job.
David Masterson
Jamie Zawinski <j...@netscape.com> writes:
> Maybe someday, the language that practicality makes us settle for will
> also be one that doesn't suck quite so much as the current crop do.
> Maybe we won't be "settling" at all.
>
> I expect this will be about the time we're all buzzing around on jet
> packs, living in automatic houses, and driving nuclear-powered cars.
Or we're all speaking esperanto?
--
David Masterson
da...@batcave.bungi.com
Randy J. Ray
Jamie> I wrote:
>> [ the perl language sucks for these reasons ]
Jamie> Randy J. Ray wrote:
>> [ yeah, well Netscape sucks too! ]
Jamie> You know, that tactic of changing the subject, and trying to
Jamie> direct criticisms away from the area that you like and over
Jamie> into a totally unrelated area that you don't like, is really
Jamie> only marginally better than comparisons to Hitler. (Have I
Jamie> invoked Godwin's Law yet?)
Jamie> What, I ask, has Netscape Navigator got to do with Perl?
It doesn't, and the aspects of perl we are discussing have nothing to do with
any emacsen, either. And yet the thread persists. I've added
comp.lang.perl.misc, and removed alt.religion.emacs. I've left in
comp.emacs.xemacs, since that is where this seems to have started, and where
people following it are likely to look.
Yes, it was wrong to redirect the argument from Perl to Netscape, but the
real argument I was making was more along the lines of the validity of you
painting Perl so negatively, when I've never seen your name on anything in
any of the Perl newsgroups, or any patches or bugreports. Richard Stallman
once shared with the Tcl and Perl newsgroups why he thought those languages
were dead-ends, and what we all *should* be using was a Scheme-based scripting
language that FSF was designing. Well, the validity of any points he might of
made were lost in the negative feedback that resulted. I have no problems
accepting the skill and reputation of developers such as yourself and Stallman.
What I have a problem with is wholesale condemnation of a language or paradigm
without any real concession to possible strengths. Throughout this thread, you
list the same complaints over and over, while people respond that those
features are in fact what they like about Perl, or make Perl useful to them.
Your stock reply to these have been, "You're wrong anyway."
Jamie> I suppose you're making the assumption that because I had
Jamie> something to do with Netscape, I'm obviously incapable of
Jamie> having a reasonable opinion about anything. Guess what,
Jamie> that's not how it works in the real world.
Never made that assumption. What I was implying, however, is that there is
irony in your criticism of Perl as the "wrong" solution to the problem set it
addresses, when there are critics just as vocal who feel the same way towards
Netscape. That invalidates opinions from neither of us.
Jamie> I'm very, very sorry. It must really suck to be you.
>> Well, I was going to keep this "debate" fairly civil, but if you
>> wish to resort to sniping, I'd say working for Netscape and
>> criticising other software as "brain-dead" must really define
>> "living in a glass house".
Jamie> I was not sniping. I think maybe you don't understand what
Jamie> "it must suck to be you" means. It means, "I'm really glad I
Jamie> don't have your job." It means, "your job sounds unpleasant
Jamie> in the extreme." It is no reflection on you. It is about
Jamie> your *task*.
Jamie> For reference, it very often really sucks to be me.
Maybe I don't think that it sucks to be me? Maybe if I'm not 100% satisfied
with what I do, it has less to do with the Perl aspect than some other factor.
In that context, it sounded as if your were being petty. The medium does some-
times fail to transmit subtlety.
Jamie> If Perl gets you through the day, great; more power to you.
Jamie> But as a language, and as an application platform, it still
Jamie> sucks.
>> Compared to what? C?
Jamie> AGAIN, it doesn't have to be compared to *anything*. Just
Jamie> because A is better than B, doesn't mean that A is good.
And again, because *you* don't like it doesn't mean that it really does in
fact suck. There are a lot of people out there besides me writing commercial-
grade code in Perl not because it's the only choice, but because they chose
it out of a pool of several options. That's the point I keep trying to make;
If you don't like Perl for goodness' sake don't use it. Even for the tasks
you admit it is good for, you can surely find an alternative that works
reasonably as well. But your wholesale criticism of Perl in particular and the
Perl programming community in general has no grounding; Your like or dislike
does not make a tool "suck" any more than mine makes it "right". But I'm not
telling you, "No, you're wrong. Read the Perl book again." If you don't like
it, fine.
Jamie> I claimed Perl's syntax is obscure, and encourages bad style.
Jamie> I *will* claim that it is obscure compared to *any* of those
Jamie> languages (and saying that any language is more obscure than
Jamie> C++ is fairly harsh, in my opinion.)
But that is not an attribute of Perl, that's an attribute of poor programming
style. I suppose in terms of clarity, the best language would be COBOL, given
the wordiness of it. There are other languages that force more strict structure
and style, I suppose.
Jamie> I brought that up as an example of why things like Perl and C
Jamie> are *realisitically* the things that one has to use,
Jamie> *regardless* of how unpleasant they are to use and maintain,
Jamie> and *regardless* of the fact that they are inferior on this
Jamie> metric or that.
But the unpleasantness of use, maintainability, and relative inferiority on
any given scale are subjective measures. Personally, I'm a very exacting,
attentive-to-detail sort of person. Usually, my sort is called anal-retentive.
I may not always have the best code solution to a problem, but what I write is
in general damned easy to read and maintain. That's a function of *me*, not
C or Perl or Lisp or COBOL. You can write Perl that reads like human language,
and you can write English that cannot be read. The aspect is not in the
language it is in the person whose hands compose.
Jamie> Practicality and cleanness of design have little to do with
Jamie> each other. In fact, in most cases, they're at odds. This
Jamie> is what "Worse Is Better" is all about.
This line of reasoning crosses over more into Software Engineering than any
particular language or environment. I personally think that they can co-exist,
but this would be a completely different branch of conversation, only
marginally related to the trunk.
>> Yes, the regex engine is one of the strongest features. I'd much
>> rather do any form of data processing in Perl than Lisp.
Jamie> *Any* form? There's that hammer-and-nail thing again.
Jamie> For *most* forms of data processing, I'd much rather use any
Jamie> language with clear syntax, and automatic storage management.
Jamie> And that's about as big a generalization I'd want to make
Jamie> without knowing a lot more particulars about the task in
Jamie> question.
No, between Perl and Lisp only, I'd prefer Perl for any sort of data
processing. With more choices than those two, I'd continue to select the
best tool for the job.
Jamie> Regexps are clear as mud. They have many things to recommend
Jamie> them, but clarity is not one.
Jamie> The heavy use of regexps in Perl is due to them being far and
Jamie> away the most obvious hammer in the box.
Jamie> The heavy use of regexps in Emacs is due almost entirely to
Jamie> performance issues: because of implementation details, Emacs
Jamie> code that uses regexps will almost always run faster than
Jamie> code that uses more traditional control structures.
Jamie> Based solely on how lame the syntax is, and how generally
Jamie> unmaintainable regexp-based code is, Perl would be very close
Jamie> to the bottom of my list of choices for most tasks.
A lot of aspects of programming are clear as mud. CPU timing issues on
multi-user servers, resource race conditions, etc. Lots of things about
home construction are clear as mud, too, if that's your vocation. Regular
expressions have evolved in the field of programming to give a consistent (if
obfuscated) method to approaching a certain problem set. Are regex's hard to
read? Yes. Does Perl improve this? No. Could it? I doubt it, though some
people have experimented with object classes to abstract some of the regex
noise. Perhaps you are associating Perl's syntax too closely with the general
syntax of regular expressions. Any language that has support for regular
expressions is going to be subject to the syntactic challenge associated with
them. Even if you are using re_comp() and re_exec() (or equivalent) in C.
Imagine that a task has no need for regular expressions. What aspect of Perl's
syntax will still be so troublesome as to have you resist using it?
Jamie> Yet, I sometimes write programs in Perl. Why? Because in
Jamie> those situations, issues of portability, speed of
Jamie> development, footprint -- whatever -- outweighed the other
Jamie> issues. Tradeoffs get made. Everything gets popped off of
Jamie> the list until Perl is the best option left. And sometimes
Jamie> it sucks to be me.
And we all continue to use tools that we don't necessarily like, if those are
the best tools for the job. Maybe I should be more vocally critical of the
tools I think are badly designed, but since I don't have the time to write
replacements, I just shrug it off and make do. Which is what it sounds like
you do, as well. But this vehement argument against Perl just doesn't serve
any purpose unless you are also prepared to offer sound alternatives. As I
said before (and this is an analogy, *not* an effort to redirect *sigh*), I
don't like Netscape. But I wouldn't run Internet Explorer even if I were on a
Win32 box. So until I can offer an alternative (preferably someone else's),
I'll limit my criticism of Netscape to bugs that can theoretically be
addressed.
>> Maybe programmers with less experience take simplistic
>> approaches; that doesn't make a language itself bad.
Jamie> Actually, I think it does! A good language encourages good
Jamie> style, readable code, and proper use of tools. A good
Jamie> language helps build good programmers by making common
Jamie> operations easy to understand, and uncommon operations
Jamie> possible.
I disagree. It is not the job of the tool to make the person using it
proficient. It is the responsibility of the person to develop proficiency
with the tool. A car cannot make a bad driver good. Buying the finest quality
paints and brushes will not make a bad artist better. And using a language
with complete clarity of syntax and no room for ambiguity will not make a
bad programmer better. You can see bad LOGO, bad Forth, anything. I have
seen SmallTalk code that was almost obvious in form and function, and I
have seen SmallTalk that made Perl look crystal clear. The language does
not make the programmer.