You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jens Klöcker <je...@kloecker.org> on 2001/03/02 08:26:00 UTC
Introduction
Hi,
here is my introduction: my name is Jens Klöcker. I'm currently
working as the principal system architect and configuration manager
for an e-learling company in Mannheim, Germany.
My interest in version control software comes from my job _and_ from
my personal interests. Up to now I'm using CVS, but I've also used
PRCS for some smaller projects. Additionally, I had a closer look at
Perforce, but rejected it because of it's license model.
I have a background in designing and implementing SGML/XML processing
software and Web-based user interfaces. My programming language
knowledge includes Perl, ML (Ocaml), C and some (X)Emacs-Lisp. In the
Subversion project I would like to be involved when it comes to
writing a Perl interface to the libraries, integrate Perl into the
server or designing and implementing a Web-interface (e.g., like
cvsweb). I can also help in writing an (X)Emacs client.
For the first time, I would like to mainly join your discussions to
get a feeling on what's going on here. But I don't like to only
discuss---I like to help this impressive project to become succesful
and will hopefully soon be able to contribute code.
Cheers,
--
Jens Klöcker <je...@kloecker.org> | Co-existence or no existence.
Re: Introduction
Posted by Jens Klöcker <je...@kloecker.org>.
A last message from me on this thread.
I don't expected to cause such a discussion with just an
introductionary posting. I'm not a Perl "evangelist" or anything
similar---my real programming language love is OCaml---but I thought,
that a Perl interface to the client and server libraries would be a
great thing and very helpful in writing higher level code based on
that.
However, I'm not discouraged! Once I understand all the details of the
library interface, I'll try to set up a Perl binding and I would
welcome any help in doing so.
--
Jens Klöcker <je...@kloecker.org> | Co-existence or no existence.
Re: Introduction
Posted by John P Cavanaugh <ca...@soco.agilent.com>.
On Fri, Mar 02, 2001 at 03:49:58AM -0500, Eric S. Raymond wrote:
> Jens Kl�cker <je...@kloecker.org>:
> > I would like to be involved when it comes to
> > writing a Perl interface to the libraries, integrate Perl into the
> > server or designing and implementing a Web-interface (e.g., like
> > cvsweb). I can also help in writing an (X)Emacs client.
>
> I am not a member of the project core team; I just wandered in a few
> days ago myself and have yet to do any work. So please don't
> over-interpret my opinions, I am speaking for myself and from my own
> experience only.
>
> I get a little nervous when I hear "Perl" in a context like this.
> I used to write a lot of Perl, but have almost completely abondoned
> the language. The problem I have is that Perl is a maintainability
> disaster, very nearly a write-only language at program sizes over
> a few hundred lines.
Geez, give the guy a break. We all have language preferences and since
its his time and effort, which will most likely result in some tangible
benefit to him & others. I dont see why we would want to discourage his
involvement in any way.
I know several people that would welcome a perl interface to the
subversion libraries.
Personally I know myself and a few others that would like the ability to
develop subversion server side "triggers" to enforce development policy.
-----------------------------------------------------------------------
John Cavanaugh Agilent Technologies
R&D Program Manager 1400 Fountaingrove Pkwy
CAD Data Store Santa Rosa, CA 95403-1799
Email: cavanaug@soco.agilent.com Phone: 707-577-4780
707-577-3948 (Fax)
-----------------------------------------------------------------------
As I grow older, I pay less attention to what men say. I
just watch what they do.
-- Andrew Carnegie
-----------------------------------------------------------------------
Re: Introduction
Posted by Alan Shutko <at...@acm.org>.
"Eric S. Raymond" <es...@thyrsus.com> writes:
> Would you consider writing a Subversion back-end for Emacs VC mode?
Yes, but don't do it till Emacs 21 comes out, with the VC overhaul.
It'll be easier to do it with the new interface, and you won't have to
redo it later.
--
Alan Shutko <at...@acm.org> - In a variety of flavors!
I may be getting older, but I refuse to grow up!
Re: Introduction
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Jens Kl�cker <je...@kloecker.org>:
> IMHO, VC is only good for handling _one_ file at a time (and for
> _that_ purpose it's incomparable practical). But when it comes to
> commit a bunch of changes or to just get an overview of the working
> tree, I usually prefer pcl-cvs.
Interesting. I gather then, that you aren't aware of the special mark
feature in vc-dired mode? You can mark a bunch of files, do Ctl-X v v,
enter a single change comment, and they will all be committed with that
same comment.
Given a back end with a concept of changesets, it wouldn't take a lot of
work to make this an atomic changeset operation.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Idealism is the noble toga that political gentlemen drape over their
will to power.
-- Aldous Huxley
Re: Introduction
Posted by Daniel Rall <dl...@collab.net>.
jens@kloecker.org (Jens Kl�cker) writes:
> IMHO, VC is only good for handling _one_ file at a time (and for
> _that_ purpose it's incomparable practical). But when it comes to
> commit a bunch of changes or to just get an overview of the working
> tree, I usually prefer pcl-cvs. It would be very nice to have both
> tools for SVN. I don't know if they are already in work by someone,
> but this an area where I'm interested in and where I would like to
> help.
I would also like to help with this.
--
Daniel Rall <dl...@collab.net>
Re: Introduction
Posted by Jens Klöcker <je...@kloecker.org>.
========> Today, Eric S Raymond <Eric> wrote:
Eric> I get a little nervous when I hear "Perl" in a context like
Eric> this. I used to write a lot of Perl, but have almost
Eric> completely abondoned the language. The problem I have is
Eric> that Perl is a maintainability disaster, very nearly a
Eric> write-only language at program sizes over a few hundred
Eric> lines.
The following are also strictly my opinions.
The projects I was involved have shown, that you _can_ write such
unmaintanable code in Perl. But when you design (rather than just go
on and start hacking) a Perl application, using the build in OO
mechanisms and package concepts, you can write very modular and clear
code. I think that this holds for most programming languages.
Eric> Again, strictly my opinion...but if you think you could do a
Eric> cvsweb equivalent, I'd sure rather see you do that first.
The working areas I mentioned are just ideas where I could help. I
don't claim for me to be able to sit down and write such a program in
an evening ;-)
Eric> Finally (and the real reason I spoke up), Emacs already
Eric> includes a generic version-control client with an interface
Eric> many people have in their fingers. Would you consider
Eric> writing a Subversion back-end for Emacs VC mode?
IMHO, VC is only good for handling _one_ file at a time (and for
_that_ purpose it's incomparable practical). But when it comes to
commit a bunch of changes or to just get an overview of the working
tree, I usually prefer pcl-cvs. It would be very nice to have both
tools for SVN. I don't know if they are already in work by someone,
but this an area where I'm interested in and where I would like to
help.
--
Jens Klöcker <je...@kloecker.org> | Co-existence or no existence.
Java bindings (was: Re: Language Advocacy)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 02, 2001 at 09:48:43AM -0800, Bruce Atherton wrote:
>...
> At 10:16 AM 02/03/2001 -0600, pohl wrote:
> >While we're on the subject of language bindings, I'd like to ask if
> >anybody here has considered how one would write a client class library
> >in Java? Would it require maintaining separate implementations in
> >Java of both Neon and libsvn_ra_dav of one didn't want to go the
> >less-portable JNI route?
>
> I think it depends on which libraries you are talking about.
>
> Regarding the FS libraries, I believe that JNI is required in order to get
> at the Berkeley DB libraries. The bindings are created as part of the
> standard build from Sleepycat. Furthermore, given the portability goals of
> Apache and Subversion, I'm not sure how much more portability a pure Java
> solution would give you.
I'd see the use of Java as a preference in this case; portability may not be
required. I know that I write much of my own stuff to always run on Linux; I
use Python primarily, but not so that it'll run on a Palm Pilot.
>...
> If you want to avoid JNI you will need a library that talks DeltaV. For
> ease of understanding and reuse, it would probably be helpful if
> libsvn_ra_dav was reimplemented in Java as well, although there is no
> reason it would have to be. The Java client could just as easily call
> directly into the DeltaV library.
Right. Our use of WebDAV was intended to facilitate the use of standard
libraries and tools. While we will provide client-side libraries to
bootstrap peoples' code, they may still choose to "go to the metal" and use
DeltaV libraries to directly interface with the SVN server. Great for them;
it is part of our design. (no custom protocol requiring custom development)
> There are a number of projects that are developing WebDAV libraries in
> Java, such as Jakarta Slide http://jakarta.apache.org/slide/index.html,
> Websphere DAV4J http://www.alphaworks.ibm.com/aw.nsf/techmain/DAV4J, and
> WebDAV Explorer http://www.ics.uci.edu/~webdav/. Jakarta Slide even
> specifically mentions their intention to include DeltaV client support.
> None of them currently support DeltaV that I could find, though.
SkunkDAV at SourceForge is (apparently) a very good WebDAV client library.
Last I checked/heard on these: Slide is a framework, and doesn't have a
complete implementation; DAV4J has had some problems (dunno what; I should
learn more); WebDAV Explorer doesn't have a separable library. SkunkDAV is
intended to be a separable library plus a GUI app.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
[OT] the Perl thing (was: Re: Introduction)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 02, 2001 at 11:33:11AM -0500, Eric S. Raymond wrote:
> cmpilato@collab.net <cm...@collab.net>:
> > I've heard/read this statement on more than a few occasions, and each
> > time I seem to have failed to understand the basis for the statement.
> > In my experience, the maintainability of a piece of software is tied
> > far less to the language of choice or the size of the program, but
> > instead is directly proportional to how that language was weilded, and
> > how thoroughly that code was documented.
>
> Of course. A poor programmer will write bad code in any language.
>
> This issue is whether your language of choice makes it easy to write
> clean, maintainable code or difficult to do it. Clean code can be
> done in Perl, but requires more work than it ought to. I'm lazy and
> don't like to work that hard :-).
Eric hit it on the head. It is easy to write crap in Perl. You have to be
very experienced to avoid that. Other languages make it more difficult to do
so.
I spent several hours once *trying* to write obfuscated Python. It was quite
difficult.
So, Mike: in an ideal world, what you say is true: everybody will write nice
Perl. But most people simply don't because they don't have the necessary
capability to do so.
---------------
All that said, I'll reiterate my earlier comment: I *hope* Jens writes the
Perl bindings. I won't use them, but I want them available for others.
I have no problem with Perl or people who use Perl. I just avoid it whenever
I can (sometimes unsuccessfully :-( which is why I've learned to dislike
the thing).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Introduction
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Karl Fogel <kf...@galois.ch.collab.net>:
> Respectfully suggest creation of a new mailing list for this thread,
> if people wish to continue it.
I apologize and will shut up now.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
.. a government and its agents are under no general duty to
provide public services, such as police protection, to any
particular individual citizen...
-- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181)
Re: Introduction
Posted by Karl Fogel <kf...@galois.collab.net>.
Respectfully suggest creation of a new mailing list for this thread,
if people wish to continue it.
Thank you,
-K
"Eric S. Raymond" <es...@thyrsus.com> writes:
> cmpilato@collab.net <cm...@collab.net>:
> > I've heard/read this statement on more than a few occasions, and each
> > time I seem to have failed to understand the basis for the statement.
> > In my experience, the maintainability of a piece of software is tied
> > far less to the language of choice or the size of the program, but
> > instead is directly proportional to how that language was weilded, and
> > how thoroughly that code was documented.
>
> Of course. A poor programmer will write bad code in any language.
>
> This issue is whether your language of choice makes it easy to write
> clean, maintainable code or difficult to do it. Clean code can be
> done in Perl, but requires more work than it ought to. I'm lazy and
> don't like to work that hard :-).
>
> (These days I like Python and Java on this scale.)
> --
> <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>
> You need only reflect that one of the best ways to get yourself
> a reputation as a dangerous citizen these days is to go about
> repeating the very phrases which our founding fathers used in the
> great struggle for independence.
> -- Attributed to Charles Austin Beard (1874-1948)
Re: Introduction
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
cmpilato@collab.net <cm...@collab.net>:
> I've heard/read this statement on more than a few occasions, and each
> time I seem to have failed to understand the basis for the statement.
> In my experience, the maintainability of a piece of software is tied
> far less to the language of choice or the size of the program, but
> instead is directly proportional to how that language was weilded, and
> how thoroughly that code was documented.
Of course. A poor programmer will write bad code in any language.
This issue is whether your language of choice makes it easy to write
clean, maintainable code or difficult to do it. Clean code can be
done in Perl, but requires more work than it ought to. I'm lazy and
don't like to work that hard :-).
(These days I like Python and Java on this scale.)
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
You need only reflect that one of the best ways to get yourself
a reputation as a dangerous citizen these days is to go about
repeating the very phrases which our founding fathers used in the
great struggle for independence.
-- Attributed to Charles Austin Beard (1874-1948)
Re: Language Advocacy
Posted by Bruce Atherton <br...@flair.law.ubc.ca>.
At 06:35 PM 02/03/2001 -0500, Jim Blandy wrote:
>Not sure what you mean here. Code that uses the Subversion filesystem
>library need never make a single Berkeley DB call --- svn_fs.h
>provides a complete covering for Berkeley DB. So I don't see why the
>fact that the FS uses Berkeley DB internally affects how one must
>write Java bindings for it.
What I meant was that if you wanted to write a client that interacted with
the Subversion file system rather than through network calls, you could not
do it in pure Java but require JNI bindings. That is true even if you
recreate all the FS code in Java, because the Berkeley DB code requires JNI
bindings (as I understand it). Of course, you could try to recreate
Berkeley DB in Java as well, but that would be no small undertaking.
Re: Language Advocacy
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
Bruce Atherton <br...@hagbard.flair.law.ubc.ca> writes:
> Regarding the FS libraries, I believe that JNI is required in order to get
> at the Berkeley DB libraries. The bindings are created as part of the
> standard build from Sleepycat. Furthermore, given the portability goals of
> Apache and Subversion, I'm not sure how much more portability a pure Java
> solution would give you.
Not sure what you mean here. Code that uses the Subversion filesystem
library need never make a single Berkeley DB call --- svn_fs.h
provides a complete covering for Berkeley DB. So I don't see why the
fact that the FS uses Berkeley DB internally affects how one must
write Java bindings for it.
Language Advocacy
Posted by Bruce Atherton <br...@flair.law.ubc.ca>.
I wonder if we could drop the language advocacy on the list. I think most
of us understand the following:
- TMTOWTDI = ease of expression
- TMTOWTDI = maintenance nightmare, since other peoples' idioms will not
be your own (Perl is the PL/I of the modern world in this respect)
- No part of Subversion itself should be written in Perl
- There is a need for Perl bindings to the Subversion library.
Now that we are all agreed, let's move on.
At 10:16 AM 02/03/2001 -0600, pohl wrote:
>While we're on the subject of language bindings, I'd like to ask if
>anybody here has considered how one would write a client class library
>in Java? Would it require maintaining separate implementations in
>Java of both Neon and libsvn_ra_dav of one didn't want to go the
>less-portable JNI route?
I think it depends on which libraries you are talking about.
Regarding the FS libraries, I believe that JNI is required in order to get
at the Berkeley DB libraries. The bindings are created as part of the
standard build from Sleepycat. Furthermore, given the portability goals of
Apache and Subversion, I'm not sure how much more portability a pure Java
solution would give you.
If your concern is for clients using the network layer, you probably don't
want to require them to do any kind of compilation so you have to deliver
Java bytecode and possibly (if using JNI) compiled binaries for each
platform. So there is a real advantage to avoiding JNI on the client, in
that you don't have to provide many different binaries.
If you want to avoid JNI you will need a library that talks DeltaV. For
ease of understanding and reuse, it would probably be helpful if
libsvn_ra_dav was reimplemented in Java as well, although there is no
reason it would have to be. The Java client could just as easily call
directly into the DeltaV library.
There are a number of projects that are developing WebDAV libraries in
Java, such as Jakarta Slide http://jakarta.apache.org/slide/index.html,
Websphere DAV4J http://www.alphaworks.ibm.com/aw.nsf/techmain/DAV4J, and
WebDAV Explorer http://www.ics.uci.edu/~webdav/. Jakarta Slide even
specifically mentions their intention to include DeltaV client support.
None of them currently support DeltaV that I could find, though.
That is my take on it, anyway.
Re: Introduction
Posted by pohl <po...@screaming.org>.
cmpilato@collab.net wrote:
>
> I've heard/read this statement on more than a few occasions, and each
> time I seem to have failed to understand the basis for the statement.
> In my experience, the maintainability of a piece of software is tied
> far less to the language of choice or the size of the program, but
> instead is directly proportional to how that language was weilded, and
> how thoroughly that code was documented.
> ...
> I'd love to hear some more in-depth reasons why people oppose Perl
> *outside* of suffering through situations as described above.
I'm not a very skilled programmer in any language, but I do know that
I have a more difficult time going back over my own code when it was
written in perl. Your observation about how one wields the language
is astute, but I also think that the effort to wield perl correctly is
far more herculean than for other languages. That's my failing, though,
and I respect anybody who doesn't feel the larger burden of discipline.
While we're on the subject of language bindings, I'd like to ask if
anybody here has considered how one would write a client class library
in Java? Would it require maintaining separate implementations in
Java of both Neon and libsvn_ra_dav of one didn't want to go the
less-portable JNI route?
I'm thinking about something along the lines of jcvs.
http://www.jcvs.org/
----
pohl@screaming.org
Re: Introduction
Posted by cm...@collab.net.
"Eric S. Raymond" <es...@thyrsus.com> writes:
> I used to write a lot of Perl, but have almost completely abondoned
> the language. The problem I have is that Perl is a maintainability
> disaster, very nearly a write-only language at program sizes over
> a few hundred lines.
I've heard/read this statement on more than a few occasions, and each
time I seem to have failed to understand the basis for the statement.
In my experience, the maintainability of a piece of software is tied
far less to the language of choice or the size of the program, but
instead is directly proportional to how that language was weilded, and
how thoroughly that code was documented.
In any language with somewhat lax type-enforcing, the opportunity
arises for an advanced programmer to exploit this to do amazing things
in a really obscure fashion -- such programmers fail the Community by
not taking the time (and a few lines of textfile real estate) to
comment about the little tricks they're using to do Big Things. They
bypass the opportunity to share their knowledge with others, perhaps
out of laziness, perhaps out of pride, perhaps out of some twisted
attachment to being mystical.
I'd love to hear some more in-depth reasons why people oppose Perl
*outside* of suffering through situations as described above. Note
that I don't have any type of love affair with the language--it does
what I need it to do, and since I'm not an advanced Perl demigod, I
never return to my code and say, "What the *hell* was I doing here!?"
(although there've been plenty of times where 'the morning after' a
long night of coding brings the phrase, "What the hell was I *trying*
to do" to my lips...)
Triggers (was: Re: perl (was Re: Introduction))
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 02, 2001 at 02:59:31PM -0500, Greg Hudson wrote:
> I know Karl would dearly love this thread to die on this list, but
> really, all of what I'm going to say is very directly tied to
> Subversion, although it's all post-1.0 stuff.
Bah. He's got a "d" key :-)
> There are two issues to consider. First, language bindings. This
> isn't really a question. If Subversion becomes popular, someone will
> do language bindings in perl. We can host them in our CVS tree or
> not; it doesn't matter especially much. Very low commitment on our
> part.
Exactly.
[ I'd prefer they were in our tree. ]
> Second, server triggers. We have a high-commitment option with regard
> to server triggers,
Agreed.
> which is linking the perl interpreter into the
> server as a compile-time option, and making perl code a form of server
> trigger.
Oof. The Perl interpreter can be a bit clunky when threading is present.
Doable, certainly, but I pity da foo' who to code this :-)
Ideally, it would be best if we could spawn a program and pipe the necessary
bits over to it, then let it talk to the repository via libsvn_fs. That will
keep the server more robust, and we won't have to link big chunks into the
server.
Of course, the performance isn't ideal, so we'll just have to see.
>...
> It may be enough to just let people call out to perl scripts via the
> shell, or it may not. Aside from performance, linking perl into the
> server has the advantages that (a) getting at interesting Subversion
> values can be made more direct, via perl global variables, instead of
> having to pass them through arguments to the script, and (b) people
> can more easily keep state between trigger calls. Or so I would
> guess; I'm not actually too familiar with the perl interpreter
> interface.
(a) is very true. I don't think (b) is going to be very possible, though.
Recall that we're in a multi-process, multi-thread environment. I believe
the Perl interpreter (because of threading) is going to require a Perl
interpreter for each thread/process. IIRC, values cannot easily be shared
between interpreters (and IIRC they *can* with some heavy lifting).
IOW, I'm with Greg. Keep Perl, Python, Guile, Tcl, whatever out of our
implementation, but allow them for triggers. Possibly as spawned programs,
possibly linked directly in.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Bindings (was: Introduction)
Posted by Yoshiki Hayashi <yo...@xemacs.org>.
Greg Stein <gs...@lyra.org> writes:
> On Sat, Mar 03, 2001 at 02:34:11AM -0800, Julian Fitzell wrote:
> > On 02/03/01 at 2:56 AM Greg Stein wrote:
> >
> > >If Jens does Perl, and Lefty and I do Python, and Jim does Guile, then we're
> > >pretty well set. I'm sure that somebody will also have an interest in Tcl
> > >or Ruby bindings, but nobody has mentioned it yet.
> >
> > A friend and I will happily undertake the Ruby bindings when it becomes appropriate.
>
> Cool!
>
> I've noted this along with a bunch of other bindings in the TASKS file.
You can expect XEmacs Lisp binding.
--
Yoshiki Hayashi
Re: Bindings (was: Introduction)
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Mar 03, 2001 at 02:34:11AM -0800, Julian Fitzell wrote:
> On 02/03/01 at 2:56 AM Greg Stein wrote:
>
> >If Jens does Perl, and Lefty and I do Python, and Jim does Guile, then we're
> >pretty well set. I'm sure that somebody will also have an interest in Tcl
> >or Ruby bindings, but nobody has mentioned it yet.
>
> A friend and I will happily undertake the Ruby bindings when it becomes appropriate.
Cool!
I've noted this along with a bunch of other bindings in the TASKS file.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Bindings (was: Introduction)
Posted by Julian Fitzell <ju...@beta4.com>.
On 02/03/01 at 2:56 AM Greg Stein wrote:
>If Jens does Perl, and Lefty and I do Python, and Jim does Guile, then we're
>pretty well set. I'm sure that somebody will also have an interest in Tcl
>or Ruby bindings, but nobody has mentioned it yet.
A friend and I will happily undertake the Ruby bindings when it becomes appropriate.
Julian
Re: Introduction
Posted by Mo DeJong <md...@cygnus.com>.
On 2 Mar 2001, Ben Collins-Sussman wrote:
> Greg Stein <gs...@lyra.org> writes:
>
> > If Jens does Perl, and Lefty and I do Python, and Jim does Guile, then we're
> > pretty well set. I'm sure that somebody will also have an interest in Tcl or
> > Ruby bindings, but nobody has mentioned it yet.
I was planning on doing a Tcl interface.
Mo DeJong
Red Hat Inc
Re: Introduction
Posted by Ben Collins-Sussman <su...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> If Jens does Perl, and Lefty and I do Python, and Jim does Guile, then we're
> pretty well set. I'm sure that somebody will also have an interest in Tcl or
> Ruby bindings, but nobody has mentioned it yet.
Heh, if anyone ever asks: "why was subversion written in C, instead
of some high-level language?"... the paragraph above reminds me how
useful and neutral C is. :)
Re: Introduction
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 02, 2001 at 10:00:20AM +0100, Daniel Stenberg wrote:
> On Fri, 2 Mar 2001, Eric S. Raymond wrote:
> > I get a little nervous when I hear "Perl" in a context like this. I used
> > to write a lot of Perl, but have almost completely abondoned the
> > language. The problem I have is that Perl is a maintainability disaster,
> > very nearly a write-only language at program sizes over a few hundred
> > lines.
>
> I feel lot of anti-perl movements in the open source/free software
> communities these days.
But that is not a problem in-and-of-itself. I'm anti-perl based on
experience with it. Same for Eric. If you get somebody who is simply
rejecting it without actual experience... you're absolutely right. But I'd
say "too bad for them" rathern than consider it a problem.
> I think it is sad, and I do believe perl has a place in every hacker's
> library of tools. To judge anything based on the selected language is not a
> very encouraging attitude.
Perl has a place, and I'd agree with Eric. If the thing stays under a
hundred lines, then you have a chance to maintain it. Or hell, to understand
it a few months later.
You're right, though... Eric shouldn't be pre-judging, but he does make it
clear that is just his preference/opinion.
> I say let everyone do anything using their language of choice. If it isn't
> good enough, and if we can't join in and improve it at that point, then let's
> make a competing tool that is better and that is written in my language of
> choice.
Exactly. And speaking of cvsweb, that is exactly what happened to me. I had
some changes that I wanted to make. After spending a couple hours trying to
deal with the cvsweb source, I simply gave up. It isn't simply that it was
written in Perl, but that it was horribly written.
I wrote a cvsweb equivalent (basically, a port) in Python. It's called
ViewCVS (http://www.lyra.org/viewcvs/). It is now well beyond cvsweb's
capabilities, and has been dramatically cleaned up. None that global
variable crap found in cvsweb.
And yes, I intend to expand ViewCVS to operate against SVN. I'm fine with
competing efforts and don't want to "stake out territory", but people can
rest assured that we'll have web-based browsing of an SVN repository.
> IMHO: We should not make any script language mandatory for extensions, we
> should encourage and support all languages people want to use.
I hope that Jens follows through on his desire to write Perl bindings. While
I won't use them myself, I am pragmatic enough to recognize that others
*will* and that it will lend to the success of Subversion.
[ you should see how long I was bitching about the lack of a client-side DAV
library for Perl; I pleaded for well over a year before somebody finally
sat down to write one ]
If Jens does Perl, and Lefty and I do Python, and Jim does Guile, then we're
pretty well set. I'm sure that somebody will also have an interest in Tcl or
Ruby bindings, but nobody has mentioned it yet.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Introduction
Posted by Daniel Stenberg <da...@haxx.se>.
On Fri, 2 Mar 2001, Eric S. Raymond wrote:
> I get a little nervous when I hear "Perl" in a context like this. I used
> to write a lot of Perl, but have almost completely abondoned the
> language. The problem I have is that Perl is a maintainability disaster,
> very nearly a write-only language at program sizes over a few hundred
> lines.
I feel lot of anti-perl movements in the open source/free software
communities these days.
I think it is sad, and I do believe perl has a place in every hacker's
library of tools. To judge anything based on the selected language is not a
very encouraging attitude.
I say let everyone do anything using their language of choice. If it isn't
good enough, and if we can't join in and improve it at that point, then let's
make a competing tool that is better and that is written in my language of
choice.
IMHO: We should not make any script language mandatory for extensions, we
should encourage and support all languages people want to use.
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: Introduction
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Jens Kl�cker <je...@kloecker.org>:
> I would like to be involved when it comes to
> writing a Perl interface to the libraries, integrate Perl into the
> server or designing and implementing a Web-interface (e.g., like
> cvsweb). I can also help in writing an (X)Emacs client.
I am not a member of the project core team; I just wandered in a few
days ago myself and have yet to do any work. So please don't
over-interpret my opinions, I am speaking for myself and from my own
experience only.
I get a little nervous when I hear "Perl" in a context like this.
I used to write a lot of Perl, but have almost completely abondoned
the language. The problem I have is that Perl is a maintainability
disaster, very nearly a write-only language at program sizes over
a few hundred lines.
Again, strictly my opinion...but if you think you could do a cvsweb
equivalent, I'd sure rather see you do that first.
Finally (and the real reason I spoke up), Emacs already includes a
generic version-control client with an interface many people have
in their fingers. Would you consider writing a Subversion back-end
for Emacs VC mode?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
All governments are more or less combinations against the
people. . .and as rulers have no more virtue than the ruled. . .
the power of government can only be kept within its constituted
bounds by the display of a power equal to itself, the collected
sentiment of the people.
-- Benjamin Franklin Bache, in a Phildelphia Aurora editorial 1794
Re: Introduction
Posted by Lee Burgess <le...@red-bean.com>.
I think it is fair to say that this post falls under the category of
"Perl Advocacy", which is fine in and of itself. However, as such, it
does not belong on the Subversion development mailing list, especially
since it does not address Subversion in any way.
If this thread must continue, please continue it elsewhere, unless it
bears some specific relevance to Subversion development, as was
previously asked.
Deven T. Corzine writes:
> On Sat, 3 Mar 2001, Greg Stein wrote:
>
> > Your defensiveness of the language is not required. Every response that I've
> > seen has recognized Perl as a "force", although people dislike it
> > personally. Those people will recognize that it has utility. Case studies in
> > its success are not required. Even if every response was that people hate
> > it, it still does not discount that it was useful in certain environments.
>
> I love Perl. I've programmed in many languages for many years, but none
> have approached the power and expressiveness of Perl. Sure, the language
> can be abused, but what language can't? (How many years has the IOCCC been
> running now?) It's easy to write bad Perl OR to write good Perl.
>
> > Personally, I think Perl is great for short text transform applications.
> > Once you need data structures, though, it really breaks down, and I'll
> > absolutely recommend Python. For myself, I know Python and its libraries
> > well enough to do text transforms efficiently and effectively in Python. I
> > don't expect that of others, so Perl is typically recommended.
>
> This was true for Perl 4. Perl 4's lack of references made it very hard
> (though not impossible) to implement a large application. Perl 5, on the
> other hand, is quite adept at manipulating data structures of arbitrary
> complexity; this is one of Perl's strengths, not a weakness.
>
> Perl is excellent at text transformations, of course. But to suggest that
> covers the applicable domain of the language is as inaccurate as suggesting
> that Emacs is only good for basic text editing. Yes, it's good for that,
> but it's only the tip of the iceberg.
>
> I don't know where all this hostility toward Perl is coming from here; the
> complaints about "Other People's Perl" are a poor way to evaluate the value
> of the language -- a bad programmer will write bad code, regardless of the
> language used. I've seen bad code in every language I've used. You can't
> force bad programmers to write good code, after all...
>
> Deven
>
--
Lee P. W. Burgess <<!>> Manipulate eternity. Power is a symphony:
Programmer <<!>> elaborate, enormous, essential.
Red Bean Software <<!>> Dream the moment with a fiddle in summer
lefty@red-bean.com <<!>> and a knife in winter.
Re: Introduction
Posted by "Deven T. Corzine" <de...@ties.org>.
On Sat, 3 Mar 2001, Greg Stein wrote:
> Your defensiveness of the language is not required. Every response that I've
> seen has recognized Perl as a "force", although people dislike it
> personally. Those people will recognize that it has utility. Case studies in
> its success are not required. Even if every response was that people hate
> it, it still does not discount that it was useful in certain environments.
I love Perl. I've programmed in many languages for many years, but none
have approached the power and expressiveness of Perl. Sure, the language
can be abused, but what language can't? (How many years has the IOCCC been
running now?) It's easy to write bad Perl OR to write good Perl.
> Personally, I think Perl is great for short text transform applications.
> Once you need data structures, though, it really breaks down, and I'll
> absolutely recommend Python. For myself, I know Python and its libraries
> well enough to do text transforms efficiently and effectively in Python. I
> don't expect that of others, so Perl is typically recommended.
This was true for Perl 4. Perl 4's lack of references made it very hard
(though not impossible) to implement a large application. Perl 5, on the
other hand, is quite adept at manipulating data structures of arbitrary
complexity; this is one of Perl's strengths, not a weakness.
Perl is excellent at text transformations, of course. But to suggest that
covers the applicable domain of the language is as inaccurate as suggesting
that Emacs is only good for basic text editing. Yes, it's good for that,
but it's only the tip of the iceberg.
I don't know where all this hostility toward Perl is coming from here; the
complaints about "Other People's Perl" are a poor way to evaluate the value
of the language -- a bad programmer will write bad code, regardless of the
language used. I've seen bad code in every language I've used. You can't
force bad programmers to write good code, after all...
Deven
Re: Introduction
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Mar 03, 2001 at 12:07:22AM -0500, Matthew O. Persico wrote:
>...
> Really? Give me five minutes. Read on...
>
> [ ... Perl used successfully in an environment ... ]
Um. So what? Great... it worked in your problem space. I can name any number
of other times that it worked. And the point would be... ??
"Big transactions" "lots of money changing hands" "much input" Feh. Any
language can do any job. Just becuase it works it a case doesn't mean that
it works in all cases.
Your defensiveness of the language is not required. Every response that I've
seen has recognized Perl as a "force", although people dislike it
personally. Those people will recognize that it has utility. Case studies in
its success are not required. Even if every response was that people hate
it, it still does not discount that it was useful in certain environments.
Personally, I think Perl is great for short text transform applications.
Once you need data structures, though, it really breaks down, and I'll
absolutely recommend Python. For myself, I know Python and its libraries
well enough to do text transforms efficiently and effectively in Python. I
don't expect that of others, so Perl is typically recommended.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Introduction
Posted by "Matthew O. Persico" <pe...@acedsl.com>.
Lee Burgess wrote:
> In my opinion, Perl is a glue language;
This is more than your opinion, it is pretty much accepted fact. This is
its primary utility. It is not, however, its only one.
> it is a disposable scripting language.
Another useful talent. Easy enough to write one-offs when necessary so
that you don't feel you are wasting time or effort in doing so.
> I have taken way too much Excedrin Migraine for headaches
> caused by maintaining OPP (Other People's Perl).
Ok, I'm sorry that this has been your personal experience and I
sympathize with you.
> Perl should not be used for anything really important.
Really? Give me five minutes. Read on...
In May of 1998, I changed jobs. After 11 years as a 'C' and C++ jock, I
ended up at a small, boutique asset management firm in New York City.
$75 billion US in assets under management. Yes, that's small - see
Merrill Lynch. But I think it's still important, yes?
Anyway, a conversion was underway when I got there. The commercially
bought asset management software was being upgraded from version 2.0 to
version 4.0. The biggest difference is that 4.0 brought the ability to
queue up jobs in a database batch table. In 2.0, you had to open up a
pipe to the curses-based client and send keystrokes down the pipe to
implement batch processing.
The existing 5000 line 'C' code was a mess. And mostly irrelevant with
the new software. So, I bet my brand new job and a significant portion
of the company's ability to process client statements on designing a
brand new process in a language I BARELY KNEW - Perl. Why? Because the
'C' was a mess and the process was basically :
1) read data from the database
2) queue up the jobs
3) fire off the client via backticks.
In short, "glue-time". Guess what? That system is humming along today
with minimal problems. In addition to running the asset management
client, the system also handles the coordination of calculation of
rollup data, generation of client statements using that data, and the
archival of those reports in our document management system that allows
our clients to access their reports via the web.
To be fair, the rollup and generation programs are C-based binaries.
However the archival stuff is pure Perl. This demonstrates one of Perl's
strengths, pulling disparate processes together into a cohesive unit.
As far as readability goes, I've had two other people maintain it with
me. I have formal namespaces for all the modules. I use h2xs to build my
module frameworks. I use OO where it makes sense (and sometimes when it
doesn't!)
Another set of colleagues (three to be exact) has designed and built a
security master database system in Perl. It grabs input files from
providers like Bloomberg and regurgitates the inputs into our central
database. The multiple phases are controlled by rules stored in a
database. Which, are themselves coded in Perl and eval'ed as needed. How
many projects have been derailed at the point where a "description
language" had to be written to complete the project? Not this one.
Perl is being used for 'important' things. Using it properly may take
more effort than using Java properly and it can be abused more than most
langages in terms of line-noise resemblance. These are its weaknesses.
In my opinion, the weaknesses are compensated by the flexibility and
speed of implementation as compared to 'C' for example (because my java
experience is limited, I won't make a comparison to java.)
If it is not your experience, I am really sorry. Like anything else,
Perl has its weaknesses and strengths. We can even disagree as to what
those weaknesses and strengths are.
But don't say that "Perl should not be used for anything really
important." Because it is being used that way.
> As an aside, my solution to OPP hell is this: people just need to be
> educated to be better programmers. They need to be taught that
> TIMTOWTDI is an evil trap and an excuse for putting up with clever or
> crappy code. The Real mantra should be The Right Tool For The Job.
I almost agree. It's not that T7I is evil in itself, it's that T7I is
not treated as the means to an end, the end being the code most balanced
between efficiency/maintainability, but rather as the end itself, i.e.,
being cool. People don't put up with T7I, they embrace it. THAT'S the
problem. T7I should be used until you find the best way, for some
definition of 'best way', then move on.
> They need to understand what Larry Wall was *really* talking about
> when he defined laziness, impatience and hubris. They need to
> understand that simplicity, clarity and generality take precedence.
And if speed/efficiency lead away from these goals, there's always ## or
=pod.
Case in point: I had a section of code that was causing a bottleneck.
After stepping back and redesigning, I got improvements. As I understood
better how perl works, I started to optimize small sections at a time.
The coup de grace was classic five-line Schwarzian (spelling?) transform
that replaced a number of slower loops and copying statements.
Now, a ST for a newbie is like Sanskrit. And for me six months later, it
may have been too. But, I put a full paragraph comment in the code (ten
lines, fifteen words per line) before the transform that explained what
was going on line by line and why. Voila. Speed and effiency and clarity
for maintainability. Sometimes you can have it all. :-)
It's not hard. It just takes work. And I think the effort expended pays
off in cycles down the road. Both processing and maintenance cycles.
>
> Okay, I'm done.
>
Hopefully I am too, cause answering this delayed me in dialing into work
and completing my latest project!
--
Matthew O. Persico
http://www.acecape.com/dsl
AceDSL:The best ADSL in Verizon area
ViewCVS/cvsweb and SVN (was: Re: Introduction)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 02, 2001 at 11:38:32AM -0800, Brian Behlendorf wrote:
> On Fri, 2 Mar 2001, Lee Burgess wrote:
> > Lastly, It was my impression that a new and separate cvsweb-like
> > interface will be largely unnecessary in Subversion. The reason for
> > this being that access to a Subversion respository is over HTTP and
> > via mod_dav (mod_dav_svn), allowing repository trees to be examined in
> > a web browser.
>
> Er, not exactly. It'll only duplicate all the value of cvsweb or viewcvs
> if it's got a nearly as rich interface to versioning. Most web browser
> can't even speak basic DAV, let alone show something as nice as what those
> tools do. So, it'll still be needed, until all web browser are DAV
> versioning tools too. =)
Oh, you're thinking too small Brian :-)
There is no reason that mod_dav_svn cannot return web pages for URLs within
its space. If you request a directory, it can generate a page just like
ViewCVS, with links to each of the files within it. Go there, and get a log
of each revision. etc.
Theoretically, of course. I'm not about to generate web pages from C. Too
much pain, and too inflexible.
Now... mod_dav_svn *will* provide a way to navigate the repository in a
simple fashion using your web browser. You'll be able to navigate through
the "head" of the tree, and (probably) have a way to link over to a specific
revision (and navigate thru that). It will be missing diffs, annotation, log
comments, etc, which ViewCVS provides.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Introduction
Posted by Brian Behlendorf <br...@collab.net>.
On Fri, 2 Mar 2001, Lee Burgess wrote:
> Lastly, It was my impression that a new and separate cvsweb-like
> interface will be largely unnecessary in Subversion. The reason for
> this being that access to a Subversion respository is over HTTP and
> via mod_dav (mod_dav_svn), allowing repository trees to be examined in
> a web browser.
Er, not exactly. It'll only duplicate all the value of cvsweb or viewcvs
if it's got a nearly as rich interface to versioning. Most web browser
can't even speak basic DAV, let alone show something as nice as what those
tools do. So, it'll still be needed, until all web browser are DAV
versioning tools too. =)
Brian
Introduction
Posted by Lee Burgess <le...@red-bean.com>.
Jens =?iso-8859-1?Q?Kl=F6cker?= writes:
> I have a background in designing and implementing SGML/XML processing
> software and Web-based user interfaces. My programming language
> knowledge includes Perl, ML (Ocaml), C and some (X)Emacs-Lisp. In the
> Subversion project I would like to be involved when it comes to
> writing a Perl interface to the libraries, integrate Perl into the
> server or designing and implementing a Web-interface (e.g., like
> cvsweb). I can also help in writing an (X)Emacs client.
In my opinion, Perl is a glue language; it is a disposable scripting
language. I have taken way too much Excedrin Migraine for headaches
caused by maintaining OPP (Other People's Perl). Perl should not be
used for anything really important. Therefore, I think integrating
Perl into the server is a Bad Idea. It's already being written in C
for portability; why muck things up with Perl (or any scripting
language for that matter)?
Regarding library interfaces, as much as I would like to dis Perl
again, I think we should consider writing these. After all, if we
don't, someone will. And it is not like they will not be useful. As
aweful as Perl can be, it is still a popular and powerful Free
Software and Open Source Software programming tool.
Lastly, It was my impression that a new and separate cvsweb-like
interface will be largely unnecessary in Subversion. The reason for
this being that access to a Subversion respository is over HTTP and
via mod_dav (mod_dav_svn), allowing repository trees to be examined in
a web browser.
As an aside, my solution to OPP hell is this: people just need to be
educated to be better programmers. They need to be taught that
TIMTOWTDI is an evil trap and an excuse for putting up with clever or
crappy code. The Real mantra should be The Right Tool For The Job.
They need to understand what Larry Wall was *really* talking about
when he defined laziness, impatience and hubris. They need to
understand that simplicity, clarity and generality take precedence.
Okay, I'm done.
--
Lee P. W. Burgess <<!>> Manipulate eternity. Power is a symphony:
Programmer <<!>> elaborate, enormous, essential.
Red Bean Software <<!>> Dream the moment with a fiddle in summer
lefty@red-bean.com <<!>> and a knife in winter.
Re: Introduction
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
jens@kloecker.org (Jens Kl�cker) writes:
> I have a background in designing and implementing SGML/XML processing
> software and Web-based user interfaces. My programming language
> knowledge includes Perl, ML (Ocaml), C and some (X)Emacs-Lisp. In the
> Subversion project I would like to be involved when it comes to
> writing a Perl interface to the libraries, integrate Perl into the
> server or designing and implementing a Web-interface (e.g., like
> cvsweb). I can also help in writing an (X)Emacs client.
I'd love to see interfaces to the Subversion libraries for every
scripting language people find useful. One of the reasons we
structured Subversion as a bunch of libraries was to facilitate that
kind of thing.