--- In extremeperl@yahoogroups.com, J Matisse Enzer <matisse@m...> wrote:
>      * Syntax-coloring text editor.
>      * Syntax-checking - catch and display syntax errors as you type.

You realize that this is not possible for Perl, correct?  You can get 90% of the
way there, but there'll always be ways that a "perl editor" will be wrong
compared
to /usr/bin/perl's interpretation of the code.

Well, maybe even 97% of the way.  But that's even more expensive.

For my demonstration of this, see "On Parsing Perl":
http://www.perlmonks.org/index.pl?node_id=44722

On Jun 17, 2005, at 4:25 AM, Randal L. Schwartz wrote:

> --- In extremeperl@yahoogroups.com, J Matisse Enzer <matisse@m...>
> wrote:
>>      * Syntax-coloring text editor.
>>      * Syntax-checking - catch and display syntax errors as you type.
>
> You realize that this is not possible for Perl, correct?  You can get
> 90% of the
> way there, but there'll always be ways that a "perl editor" will be
> wrong compared
> to /usr/bin/perl's interpretation of the code.
>

Yes.

As I have said in this list, 90% is waaaaay better than 0%. I'll take
70% over 0%.
I use a Perl IDE that gives me probably 90% (80%? 70%? I dunno) right
now.


-------------------------------------------------------
Matisse Enzer <matisse@...>
http://www.matisse.net/  - http://www.eigenstate.net/
415-225-6703 (work/cellphone)
415-401-8325 (home)

Randal L. Schwartz writes:
> --- In extremeperl@yahoogroups.com, J Matisse Enzer <matisse@m...> wrote:
> >      * Syntax-coloring text editor.
> >      * Syntax-checking - catch and display syntax errors as you type.
>
> You realize that this is not possible for Perl, correct?  You can get 90% of
the
> way there, but there'll always be ways that a "perl editor" will be wrong
compared
> to /usr/bin/perl's interpretation of the code.
>
> Well, maybe even 97% of the way.  But that's even more expensive.

I find cperl 5.0 gets 99.9% of the way there.  It's fast enough for
me, too.  The only problems I've seen have to do with defects in the
code.  For example, 5.0 seems to have introduced a bug that highlights
builtins in the middle of identifiers, e.g. die_you_gravy_sucking_pig
would have the "die" highlighted.  This bug was not there in earlier
versions.

One of the important parts of XP is the coding style a team agrees on.
The style guide defines what "readable" is to the rest of the team.
While you can write "zany" Perl, it's rarely a good idea, and doesn't
add business value.

Another part of the style guide directly addresses some of the
requests I've been seeing for IDE features.  For example, at bivio, we
ask programmers to code "fast fail".  The net result is that I can't
remember the last time we (junior or senior developers) used the perl
debugger.  Although Emacs has a Perl debugger mode, we don't need it.
The stack trace is good enough, and Emacs brings us right to the line
with the error with its "next-error" command.

Since there seems to be a dearth of Emacs users on this list, I'll
point out what Emacs supports today in Matisse's list of requirements:

J Matisse Enzer writes:
>      * Syntax-coloring text editor.

Yes.

>      * Syntax-checking - catch and display syntax errors as you type.

Sort of.  It does brace checking.  It can't tell you that:

     $x = 1,
     $y = 2;

is incorrect, because it is correct syntax, even if that may not be
the semantics you want.

>      * Version control integration - checkout and compare code using
> CVS, subversion, etc.

Yes.

>      * Excellent refactoring support

I think so.  We have create class, create program (which calls a
specific class' main), rename method, add method, insert special
method (some methods in bOP have known signatures, Emacs will add
those signatures for you), and extract ViewShortcut.  You can add
private refactorings that hook into the standard refactoring shortcut.

>      * Bug/Request tracking tool.
>        Ideally integrated with the source control system:
>        Put a bug number in a check-in note and it automatically
>        creates links in the project web pages (Perforce does this.)

I think this is more of a matter for CVSWeb (which I don't use).  We
don't track bugs with a bug tracking tool, because we release weekly.
If there's a bug, it's fixed in the next release, always.

>      * Support for creating and running unit tests.

Yes.

>      * Code generation, create commonly used stub code.

Yes (see above), I consider this dangerous, though.  One of the
problems with stubbed out code is that it often is a target for
refactoring.  For example, the classic get/set of Java is a
nightmare from OAOO's point of view.  We have a base class that
handles all of that so all you have to do is document the attributes.

>      * Code-assist editor (e.g. get a menu of methods when you type in
> an object reference.)

Not yet. :-)  It's something we'd like to add.

>      * Language-specific help (click on a keyword and the
> language-specific help is available)

Yes.

>      * Managing of dependencies between code files, packages, etc.

Unnecessary in Perl.  I've found the whole dependency to be a red
herring in Perl.  Having lived through it with compiled languages, it
adds no business value.  Either all the code is there, or you forgot
to check something in.  Your acceptance tests (this is the XP list
after all :-) will detect that missing bit of code or they aren't very
good acceptance tests, and the customer will find the missing bit of
code, or the missing bit of code is simply not necessary. :-)

>      * Debugger - run your code under a debugger with real-time display
> of results

Yes.

>      * Automatic reformatting of code.

Yes.

>      * Automatically build and test.

Yes.

>      * Performance profiler.

Not sure what this has to do with the IDE, because you have to run it,
and see the results (best in a spreadsheet program imiho).  Anyway,
you can run this in a subshell in Emacs, and it will work fine.

>      * Some kind of networked, shared note-taking (e.g. a Wiki)

There is Wiki-mode for Emacs, but I would just use the Wiki.
Personally, I find Wikis less useful than checking in what little
documentation you have in CVS.  Indeed, the code and tests should
speak for themselves, if this is "true" XP, and you don't need a Wiki.

>      * Ability to choose tabbed or floating display of resource windows.

Yes.  (Not tabbed, but "windows" or floating "frames".)

>      * "Tree" view of source files and resources.

We get this from pod2html.

>      * Automatic email notice when other people commit code to the
> repository.

Part of CVS, if you like.  If you are on an XP project, you really
don't want this.  We commit LOTS of files daily, and it would
overwhelm even the most competent email user.  Better to have the
developer summarize the changes in an email -- even that overwhelms
most developers. :-)

Here's what I do to develop:

     * Edit a unit or acceptance test
     * Run it (C-c C-m)
     * Fix the module to make the test work
     * (Possibly) restart server web server (C-c h)
     * Run the unit test (C-c C-m)
     * Find next error (C-c C-e)
     * Repeat :-)
     * Register with CVS and/or check in (C-x v v <type comment> C-c C-c)
     * Release (b-release build && b-release install)
     * Email team (C-c m m <type away> C-c C-c)

BTW, all of the above can be done in vim, but I only use vim casually
so I can't tell you how to do it.

The nice thing about using Emacs is that I get to pull up previous
comments (M-p) easily.  Cut and paste text from the code to my email
msgs.  And so on.  All without using the mouse.  That means ultimate
efficiency.  The physical movement of my hand to the mouse is at least
ten keystrokes for me, searching in an analog space is at least
another ten keystrokes, and then clicking (5-10 keystrokes).

While it is great for an IDE to have GUI, it's not what an expert
programmer uses.  It's simply too much work to use the mouse to do
stuff.  You learn how to use the keyboard shortcuts.  That's where GUI
IDEs fall apart imiho.

I've used my share of GUI IDEs and one of my biggest complaints is
that the keyboard shortcuts are always different.  While you may argue
that Emacs keystrokes are random (and they are), once you know them,
you know them for most modes.  And, it's easy to get a list of them
for any mode (C-h b) when I don't remember.

The point is that an IDE is about "integration" not "graphics".  Emacs
has been an integrated development environment for over 20 years.
It's very mature and robust.  It lets programmers optimize their
keystrokes, which is the whole point of an IDE.  Until you've tried it
(or vim :-), you can't really say that it doesn't meet your needs, and
that it is "behind" other IDEs.

Rob

On Jun 17, 2005, at 11:10 AM, Rob Nagler wrote:

> Here's what I do to develop:
>
>     * Edit a unit or acceptance test
>     * Run it (C-c C-m)
>     * Fix the module to make the test work
>     * (Possibly) restart server web server (C-c h)
>     * Run the unit test (C-c C-m)
>     * Find next error (C-c C-e)
>     * Repeat :-)
>     * Register with CVS and/or check in (C-x v v <type comment> C-c
> C-c)
>     * Release (b-release build && b-release install)
>     * Email team (C-c m m <type away> C-c C-c)

Could you detail what emacs packages you use to get the above? I think
it's the mode-compile package, which I have not configured yet - I just
tried the C-c C-m command and it did nothing for me. I spent some time
yesterday installing several emacs packages (including upgrading to
cperl 5.0), but I'm sure I don't have all the useful perl ones yet.
Much less configured or learned.

Thanks,
Drew

Drew Taylor writes:
> Could you detail what emacs packages you use to get the above?

We bind a few keys, and added a few functions.  I uploaded our latest
source in the files area of this board:

http://groups.yahoo.com/group/extremeperl/files/

bivio-emacs-20050612.tgz

Take a clean emacs, put the files in your ~/emacs, and load-file
~/emacs/site-start.el.

This will give you everything we have.  You can customize site-perl.el
and b-site-perl.el.  b-perl.el contains our extensions cperl.el.
These files work with stock cperl.el 5.0 and some earlier versions.

Rob

Rob,

I really appreciate your point-by-point explanation of how you handle
the various items in the list I posted. As you might know, I'm working
on an article for perl.com about the need/desirability of better
development tools for Perl and I'd like to refer to or mention the ways
you do many of these things. I may include a link to the the Yahoo
group page for this list and mention that the file area has the tools
you mention.

I do have some questions and comments about a few of your notes:

On Jun 17, 2005, at 8:10 AM, Rob Nagler wrote:
>>      * Syntax-checking - catch and display syntax errors as you type.
>
> Sort of.  It does brace checking.

In the code fragment below the syntax checking in the IDE I'm using
will highlight line 2 because of the missing right parenthesis:

1.  my $name = getName();
2.  if ($name eq 'matisse' {
3.     print "Found $name\n";
4.   }

In this case it will show an error on line 5 because of the extra ' on
line 3:
1.  my $name = getName();
2.  if ($name eq 'matisse' {
3.     print '"Found $name\n";
4.   }
5. print "That's all folks!\n";

In the following it shows an error on line 3 if 'use strict;' is in
effect because  $naame  hasn't been declared:
1.  my $name = getName();
2.  if ($name eq 'matisse' {
3.     print "Found $naame\n";
4.   }

Here it catches line 3 if there isn't a  prit()  function:
1.  my $name = getName();
2.  if ($name eq 'matisse' {
3.     prit "Found $name\n";
4.   }

and so on. Basically it catches virtually all compile-time errors. I
think that ability (you can turn it off) should be widely and easily
available to programmers.

>
>>      * Excellent refactoring support
>
> I think so.  We have create class, create program (which calls a
> specific class' main), rename method, add method, insert special
> method (some methods in bOP have known signatures, Emacs will add
> those signatures for you), and extract ViewShortcut.  You can add
> private refactorings that hook into the standard refactoring shortcut.

That's pretty cool. The editor I am using has none of those, although
it does have  extract subroutine. In your case if you do a rename
method does emacs correct or offer to correct the references to the old
method name? and if so in just the file you are in, or in your entire
project?


>
>>      * Code-assist editor (e.g. get a menu of methods when you type in
>> an object reference.)
>
> Not yet. :-)  It's something we'd like to add.

I haven't found any perl editor/tool yet that does this, but having it
in Java has really made me miss it in Perl. I believe that in theory
anyway (dangerous phrase :-) it should be possible to do this 80% 90%
95%?? of the time - perhaps the new PPI module would help? The big
trick of course is that the editor/tool needs to be able to figure out
what is in the scalar - but I think in most cases of non-weird Perl
code that is possible.


>>      * Managing of dependencies between code files, packages, etc.
>
> Unnecessary in Perl.  I've found the whole dependency to be a red
> herring in Perl.  Having lived through it with compiled languages, it
> adds no business value.

You may be right about that - I added that item to the list based on
conversations with others but that one doesn't seem to have the same
weight as some of the other items on the list. The dynamic syntax
checking discussed above should catch things like:
      use Matisse;  # Immeadiate error if editor can't find package
Matisse

>>      * Performance profiler.
>
> Not sure what this has to do with the IDE,

Some people, doing certain kinds of work use profiling a lot, for
example running a suite of tests under Devel::Profile, but I agree that
this item is useful to a fairly small number of people right now,
although, just as a thought experiment, imagine if it were trivially
easy to do, just pretend that your tool magically made it a one-click
operation to run something under a profiler and immeadiatly gave you a
pretty graph or spreadsheet - in that case we might hit the "profile"
key or button pretty often, just like running unit tests often because
it is so easy, and we might learn  more about what's happening in our
code than if it wasn't so easy.

That reminds me of a central point I think in my thesis here - it is
not simply having these features somehow available, it is having them
be really really easy that makes a huge difference. When you have most
of these features, and they are all really easy to do, you do them
more, and that makes developing complex projects considerably easier.

>
>>      * Some kind of networked, shared note-taking (e.g. a Wiki)
>
> Personally, I find Wikis less useful than checking in what little
> documentation you have in CVS.

I have found in my research that people and teams vary widely in how
they handle this. There are many variables (whole team in one room?
different time zones? different languages? personal preferences? email,
talking, instant messaging, wiki, bugzilla, perforce, CVS/subversion,
unit tests, etc.) The only more-or-less constant seems to be that if a
team has some effective way of doing shared note-taking then then do a
better job.


>>      * "Tree" view of source files and resources.
>
> We get this from pod2html.
>

Can you explain how that works for you? Do you have something
dynamically generating HTML and displaying it in a window? So if you
add a new file it shows up right away?


> While it is great for an IDE to have GUI, it's not what an expert
> programmer uses.


I think you have to admit that there are, in fact, expert programmers
who use GUI IDE's, even if you don't.

>
> I've used my share of GUI IDEs and one of my biggest complaints is
> that the keyboard shortcuts are always different.

I think that is a common complaint about GUI's in general among those
who prefer keystrokes. I believe that some GUI IDE's, like Eclipse
support emacs an vim keybinding but I would be surprised if a dedicated
emacs or vim user found that a reasonable substitute.
>
>
> The point is that an IDE is about "integration" not "graphics".  Emacs
> has been an integrated development environment for over 20 years.
...
> Until you've tried it (or vim :-), you can't really say that it
> doesn't meet your needs, and
> that it is "behind" other IDEs.

I agree, and I am not saying emacs is behind other IDE's - although I
might say that at some point :-) What I *am* saying is that taken as a
whole, the tools for Perl *are* behind the tools for other languages.

Let's stipulate for a moment that emacs with your extensions does 90%
of my list, I would then argue that it still needs (and deserves) to be
made much more accessible - it would be great if an individual or team
of intermediate level programmers who *have not used it before* could
install and configure the package and use 75% of those features
productively in less than 8 hours of work, say spread over 2 or 3 days.
That is easily possible for Java with things like IntelliJ, Eclipse.


-------------------------------------------------------
Matisse Enzer <matisse@...>
http://www.matisse.net/  - http://www.eigenstate.net/
415-225-6703 (work/cellphone)
415-401-8325 (home)

J Matisse Enzer writes:
> group page for this list and mention that the file area has the tools
> you mention.

Cool.

I tried your examples out.  Here's my feedback.

> In the code fragment below the syntax checking in the IDE I'm using
> will highlight line 2 because of the missing right parenthesis:
>
> 1.  my $name = getName();
> 2.  if ($name eq 'matisse' {
> 3.     print "Found $name\n";
> 4.   }

How it shows up in cperl is that the auto-indent is off, and when you
try to close the enclosing block (assuming it is in a sub), it will
tell you "Mismatched parenthesis".

> In this case it will show an error on line 5 because of the extra ' on
> line 3:
> 1.  my $name = getName();
> 2.  if ($name eq 'matisse' {
> 3.     print '"Found $name\n";
> 4.   }
> 5. print "That's all folks!\n";

The color is off.  The "That's all folks!\n"; line is highlighted in
mixed colors and the ";" is highlighted as a string.  Also, autoindent
stops working after That's all.., because you are still within a string.

> In the following it shows an error on line 3 if 'use strict;' is in
> effect because  $naame  hasn't been declared:
> 1.  my $name = getName();
> 2.  if ($name eq 'matisse' {
> 3.     print "Found $naame\n";
> 4.   }

Not caught by cperl.  Caught when I type "C-c C-m" on the buffer,
though.  Here's the output:

     perl -w x.pm
     syntax error at x.pm line 5, near "'matisse' {"
     Global symbol "$naame" requires explicit package name at x.pm line 6.
     Execution of x.pm aborted due to compilation errors.

I type C-c C-e and it brings me to line 5.  Type C-c C-e, brings me to
line 6.

The nice thing about Perl is that you can compile any buffer.  Since
we put all code in modules, it means that we can compile any buffer
without fear that it will "do something".  It just checks the syntax.
It's a habit I run into before running the unit or acceptance tests.
Saves a lot of time.

> Here it catches line 3 if there isn't a  prit()  function:
> 1.  my $name = getName();
> 2.  if ($name eq 'matisse' {
> 3.     prit "Found $name\n";
> 4.   }

The non-existence of the prit function is shown, because it isn't
highlighted as a reserve word.  There isn't a "getName", either. :-)

I must say that we don't often have code that looks like your
examples.  Almost all of our calls are method calls.  We don't just
call "print" in the middle of a library, or die, or warn.  We have
libraries that wrap these functions, because in large scale systems,
we need to redirect output, differentiate between internal "planned"
warnings and perl's warnings ("undefined value"), and override various
functionality.

> That's pretty cool. The editor I am using has none of those, although
> it does have  extract subroutine. In your case if you do a rename
> method does emacs correct or offer to correct the references to the old
> method name?

Yes, with "query-replace".  This is an emacs builtin that the
refactoring function calls with the subroutine name.  Since we always
bracket subs with (), it makes it easy to pattern match simply.
Again, with XP, we follow a style guide which not only helps us
communicate, but gives enough hints to make it easy to do replacements
like this.

> and if so in just the file you are in, or in your entire project?

No.  There are a number of reasons why you don't want to do this.
Firstly, you can't know that the following is your "foo".

     $o->foo();

Second, our unit and acceptance tests catch these problems.  For the
most part, our classes have very few entry points.  Most of them are
shared with base classes.  And more importantly, are rarely called
directly by arbitrary classes.  Most business logic is managed by our
Task modules in web apps or ShellUtil in command line apps.  That
means that we don't really have calls outside of the classes.  Search
through the PetShop to see what I mean.

> I haven't found any perl editor/tool yet that does this, but having it
> in Java has really made me miss it in Perl. I believe that in theory
> anyway (dangerous phrase :-) it should be possible to do this 80% 90%
> 95%?? of the time - perhaps the new PPI module would help? The big
> trick of course is that the editor/tool needs to be able to figure out
> what is in the scalar - but I think in most cases of non-weird Perl
> code that is possible.

There is etags:

     etags --lang=perl $(find . -name \*.pm)

I don't use it, but I just tried it.  It's a way of looking at all
subs in a tree, and binding them to entry points.  Here's a
tags-apropos on "autoload":

     Click mouse-2 to follow tags.

     Tags matching regexp `autoload':

     [Delegator.pm]: sub AUTOLOAD
     [Test/Bean.pm]: sub AUTOLOAD
     [Test/Language.pm]: sub AUTOLOAD
     [Test/Language.pm]: sub _check_autoload
     [Type/EnumDelegator.pm]: sub AUTOLOAD
     [UI/ViewLanguage.pm]: sub AUTOLOAD

With this function, you could probably bind it to something more
advanced.  However, since Perl is dynamically typed, it's not clear
that it is all that useful.

> You may be right about that - I added that item to the list based on
> conversations with others but that one doesn't seem to have the same
> weight as some of the other items on the list. The dynamic syntax
> checking discussed above should catch things like:
>      use Matisse;  # Immeadiate error if editor can't find package
> Matisse

Again, we don't even do "use" when we can avoid it.  It's simply
unecessary if you always use qualified references.

> although, just as a thought experiment, imagine if it were trivially
> easy to do, just pretend that your tool magically made it a one-click

The problem with this is you need to know "what" to run.  Profiling is
a tricky business.  First you have to decide what is slow.  What I
find with people who like profiling is that they do it without
having a performance problem.  They do it out of habit, which makes it
not only unnecessary, but also dangerous.  When you improve
performance, it almost always means denormalization, which means
decoupling assumptions.   This leads to hard to detect and fix
defects.

> That reminds me of a central point I think in my thesis here - it is
> not simply having these features somehow available, it is having them
> be really really easy that makes a huge difference. When you have most
> of these features, and they are all really easy to do, you do them
> more, and that makes developing complex projects considerably easier.

I guess that is where we depart.  It is very easy for me to type:

     perl -dDevel::DProf perf.t

It's really just a few keystrokes.  If we actually had a need for this
sort of thing, we'd bind it to C-c C-m, but we don't.  We do bind
*.btest, *.t, and *.pm to C-c C-m.  This is very nice for us.

I agree with Rob K here.  The problem with complex projects is not
"keystrokes", but senior engineers.  You simply can't do them without
senior engineers.  The canonical example is Netscape.  What a mess.

If you have a complex problem to solve, it will take tremendous
discipline and experience to solve it.  Shoot from the hip profiling
is not what you need.  You need shoot from the hip testing and nightly
testing on integration machines.  You need people who know that you
need to solve the configuration, logging, exception, etc. problems
through refactoring (you'll hit these right away), or you're project
will be a mess before you know it.  You need people who know they have
to agree about trivialities like coding styles so they can solve the
hard problems, like problem partitioning.

This is why so few people get XP, and why XP is so important to large
scale projects in Perl or otherwise.

> I have found in my research that people and teams vary widely in how
> they handle this. There are many variables (whole team in one room?
> different time zones? different languages? personal preferences? email,
> talking, instant messaging, wiki, bugzilla, perforce, CVS/subversion,
> unit tests, etc.) The only more-or-less constant seems to be that if a
> team has some effective way of doing shared note-taking then then do a
> better job.

Do you have data on this?  We don't have a shared note-taking system,
and we do a pretty good job imiho.  Our primary focus is getting
along.  We have to agree on the approach.  We all use emacs.  We all
use Perl.  We all use Linux.  We all use b-perl.el.  We all run the
unit tests before checking in (right guys! ;-).  We run acceptance
tests on all apps nightly.  The hard stuff we often disagree on.
That's good.  That's where we should disagree, because there's isn't a
right way.  (Emacs isn't right; it just is an easy decision to pick an
editor, and it's more important to agree than get the "best" editor,
whatever that is.)  Hard problems have hard trade-offs, or they
wouldn't be hard.  They'd be easy, and there'd be a hundred
solutions.  Have you ever wondered why there are so many testing
frameworks out there?  It's because it is a trivial problem to solve,
and by solving it, you avoid the hard problems.

BTW, here are some interesting links on IDEs:

http://www.garybeene.com/perl/prl-ide.htm
http://www-106.ibm.com/developerworks/library/j-emacs/?n-j-5241

> Can you explain how that works for you? Do you have something
> dynamically generating HTML and displaying it in a window? So if you
> add a new file it shows up right away?

Well, we add new files every day.  The last thing I need is for it to
show up in a window.  This is what it looks like:

http://www.bivio.biz/f/bOP/html/index.html

> I think you have to admit that there are, in fact, expert programmers
> who use GUI IDE's, even if you don't.

They may use them, but they probably don't enjoy it. :-)  We are going
to enter in a big gray area here, i.e., who is an expert programmer,
and who determines what an expert is?  I would suggest, however, that
you go down the list of top programmers you know, and see what they
use, and why they like it.

> I agree, and I am not saying emacs is behind other IDE's - although I
> might say that at some point :-) What I *am* saying is that taken as a
> whole, the tools for Perl *are* behind the tools for other languages.

This case has yet to be proven.

> Let's stipulate for a moment that emacs with your extensions does 90%
> of my list, I would then argue that it still needs (and deserves) to be
> made much more accessible

If you'd like.  However, be careful what you wish for.  Most people
don't really want a better programming environment.  It then removes
all impediments to getting the job done. :-)

> - it would be great if an individual or team
> of intermediate level programmers who *have not used it before* could
> install and configure the package and use 75% of those features
> productively in less than 8 hours of work, say spread over 2 or 3 days.
> That is easily possible for Java with things like IntelliJ, Eclipse.

Here's what you do:

     1. Buy a Mac or install Linux on a PC
     2. mkdir emacs
     3. cd emacs
     4. tar xzf b-perl.tgz
     5. emacs foo.pm

It won't take you 8 hours. :-)  It will take you 8 hours to figure out
what the C-c C-r view-to-shortcut does, and why you might need it. :-)

It is pointless to have a team of intermediate level programmers,
because this likely means: team of inexperienced programmers.  What
project would they be working on?  Why would anyone pay them to work
on it?  Why wouldn't there be a senior programmer who would know how
to guide the team towards a successful outcome?

Rob

On Jun 18, 2005, at 12:08 PM, Rob Nagler wrote:
> No.  There are a number of reasons why you don't want to do this.
> Firstly, you can't know that the following is your "foo".
>
>     $o->foo();
>

That's part of the problem with current tools. I want to see tools that
*can* figure out if $o->foo() is "my" foo, in most cases.

> Second, our unit and acceptance tests catch these problems.  For the
> most part, our classes have very few entry points.

You guys have a particular approach that minimizes the problem, which
is good. Maybe the whole world will adopt your approach, or maybe not
:-)

I'm certainly in favor of unit tests, and consistent coding style, in
no small part because they make many things easier, just as you are
experiencing.

> I guess that is where we depart.  It is very easy for me to type:
>
>     perl -dDevel::DProf perf.t
>
> It's really just a few keystrokes.

I think you are actually agreeing that it should be easy to access all
of the features we are discussing (not just running a profiler, or a
refactoring action, but all of them).If I'm correcting grasping your
position it is that it is *already* easy and that you are not motivated
to make these things any easier. I think *that* is where we might stand
differently at present.

Or perhaps were we depart is in the list of things that we feel should
be easier, and/or in our feelings about Perl's adoption by new
programmers and new projects - you might be happy with its adoption
rate and/or feel that the obstacles to Perl's adoption lie elsewhere.

>
> I agree with Rob K here.  The problem with complex projects is not
> "keystrokes", but senior engineers.  You simply can't do them without
> senior engineers.

I agree. People gradually become senior, and expert, and experienced,
and no tool have replace experience. My position is that better tools
are, well, better, and even experts benefit from them, in fact they may
benefit more than novices or intermediate level folks, at least in some
situations.

Tools do not make the job - you can have the best image processing
software in the world, running on the fastest computer with the most
memory and the biggest hard disk, yet it behooves one to recall what
Rembrandt did 700 years ago with burnt wood and paper.

>
> Do you have data on this?  We don't have a shared note-taking system,
> and we do a pretty good job imiho.

My data on this is entirely anecdotal and experiential. That is the
people I have talked to and the projects I have worked on seem to me to
have benefited whenever there was some way for the group to have some
record of decisions, discussions, problems, discoveries etc. I'm
personally not a big wiki fan, but it works well for some groups.
mailing lists work for others, whiteboards for many (that's perhaps the
most common for groups that are physically close)

Are you certain you have no shared note-taking? I would argue that
http://www.bivio.biz/f/bOP/html/index.html is an example - the NAME
entries (and the full perldoc) from each module is in fact a note (it's
not executable code), it is meta-information that your whole team
contributes to.


>  Our primary focus is getting
> along.

That is great - that is the single most important thing in a team, I
think the "plays well with others" factor. It is not the only factor,
but I think if you have that, you can acquire any others.


> Well, we add new files every day.  The last thing I need is for it to
> show up in a window.

I think that's a matter of personal preference. I and many other people
do like having a newly added file show up in a list of files instantly.

>
>> I think you have to admit that there are, in fact, expert programmers
>> who use GUI IDE's, even if you don't.
>
> They may use them, but they probably don't enjoy it. :-)

So you would say that the people who wrote Komodo and EPIC, for
experts, are not experts? or do not enjoy using those tools? What about
Eclipse and IntelliJ?

What is your opinion of Martin Fowler's article "Crossing Refactoring's
Rubicon" http://www.martinfowler.com/articles/refactoringRubicon.html ?


>>  What I *am* saying is that taken as a
>> whole, the tools for Perl *are* behind the tools for other languages.
>
> This case has yet to be proven.
>

Depending on what you mean by "proven" I think I agree with you. What
would you consider as "proof" ?

Personally I don't need a scientific proof to be concerned about this
issue - I am personally going by what I see people and businesses
doing, and by my own and other programmers experiences. Did you read
Adam Kennedy's article about PPI?
http://www.perl.com/pub/a/2005/06/09/ppi.html


>> Let's stipulate for a moment that emacs with your extensions does 90%
>> of my list, I would then argue that it still needs (and deserves) to
>> be
>> made much more accessible
>
> If you'd like.  However, be careful what you wish for.  Most people
> don't really want a better programming environment.  It then removes
> all impediments to getting the job done. :-)

I can live with that :-)

> It won't take you 8 hours. :-)  It will take you 8 hours to figure out
> what the C-c C-r view-to-shortcut does, and why you might need it. :-)

Indeed, and that's part of where I'm coming from - part of what makes a
tool "better" can in some cases be how much easier it is to accomplish
a task, including learning to use the tool (that's not the only
criteria for "better" of course.) Here's a trivial example: In
carpentry, a "speed square" is "better" for many things where we used
to use a "framing square", because in these cases the speed square is
easier to use - it might even be a bit less precise ion those cases,
but it's still a  "better" tool.

    http://images.oldhouseweb.com/stories/bitmaps/13019/speedsquare1.jpg
    http://northhaledonschools.com/framingsquare.jpg  (24" x 16")

>
> It is pointless to have a team of intermediate level programmers,
> because this likely means: team of inexperienced programmers.

Of course you also need senior, more experience people. And why
automatically say that "intermediate" == "inexperienced"?

Few people are experts, and all experts started as non-experts. I am
well aware of many of the values of experience and skill, and I hope
that 20 years from now I have learned even more, I certainly intend to
keep trying.


-------------------------------------------------------
Matisse Enzer <matisse@...>
http://www.matisse.net/  - http://www.eigenstate.net/
415-225-6703 (work/cellphone)
415-401-8325 (home)

On Jun 18, 2005, at 3:41 PM, J Matisse Enzer wrote:

> it behooves one to recall what
> Rembrandt did 700 years ago with burnt wood and paper.

Oops :-) Off by a factor of 2. 350 years ago.
http://www.thebritishmuseum.ac.uk/pd/factsheets/images/
rembrandt_ps227364.jpg

-------------------------------------------------------
Matisse Enzer <matisse@...>
http://www.matisse.net/  - http://www.eigenstate.net/
415-225-6703 (work/cellphone)
415-401-8325 (home)

I'll have to take a closer look at your emacs customizations, since
I'm doing perl XP with a highly tweaked emacs as well.  We've got all
sorts of useful mods including:

- Jump to perl-thing-at-point, whether its a method, module, constant
   subroutine, or filename
- Show the inheritance hierarchy of this module, or the one under
   point
- Add a use line for the class under point
- Deparse a chunk of highlighted perl, adding parens to clarify
   precidence
- Jump from code to test (and vice versa) in one button
- Run the unit test
- Update the test count
- See the current cvs diff for this file or sandbox
- Navigate previous cvs changes for this file
- Show the entire CVS checkin that added a particular line
- Apply/Revert a hunk from a cvs diff file
- Show CVS annotation or log comment for current line
- Jump from a CVS diff file directly to the line in the code
- Insert a random MAC address (for writing unit tests)
- Insert a source filter around the current block so only a portion
   of the unit test is run, so you can focus in on a particular
   test thats failing
- Toggle formatting of lists or hashes that span more than 80 columns
- find all occurances of a string in our code base
- show all methods named X
- Jump to the SUPER method of the one you're overriding
- run 'make' with various useful targets
- make sure the current perl file compiles cleanly
- pull up a perldoc on whatevers under the point
- Insert various useful debugging lines temporarily, i.e. Carp
- toggle pairs of single quotes to double quotes and vice versa
- Fold unnecessarily long copyright chunks into one line
- Tab complete module names based on the .pm files in the filesystem
- Toggle between prefix and postfix versions of if,foreach,while

And thats just from a brief scan through our emacs config files.
There's also a handy shortcut for adding a line to our emacs
wish-list so there is a nice long list of stuff we'd like to add.

-Blake
p.s. I noticed Bivio has offices in San Mateo just down the street
from where I work.... Do you happen to work in San Mateo?


--- In extremeperl@yahoogroups.com, Rob Nagler <nagler@b...> wrote:
> We bind a few keys, and added a few functions.  I uploaded our latest
> source in the files area of this board:

blakemills writes:
> I'll have to take a closer look at your emacs customizations, since
> I'm doing perl XP with a highly tweaked emacs as well.  We've got all
> sorts of useful mods including:

Wow!  Would you mind loading this in the files area?  We could try a
merge, or you could. :-) Are your mods based on cperl, i.e., hook into
cperl-mode-map?

> p.s. I noticed Bivio has offices in San Mateo just down the street
> from where I work.... Do you happen to work in San Mateo?

Different bivio.  They were formerly called Network Robots, and became
bivio Networks <bivio.net> in 2001.  There's also a bivio Restaurant
<bivionyc.com>, and, of course, the village <bivio.ch> I named the
original bivio company <bivio.com> after.   Extreme Perl was written
under the auspices of bivio Software, Inc. <bivio.biz>.   It's a
pretty good name, but brand recognition is a bit difficult. ;-)

However, I do get to the Bay Area every now and then so we could meet
up at some point.  I'm always interested in meeting other companies
using Perl & XP.

Rob

On Jun 19, 2005, at 7:22 AM, Rob Nagler wrote:

>
> Wow!  Would you mind loading this in the files area?  We could try a
> merge, or you could. :-) Are your mods based on cperl, i.e., hook into
> cperl-mode-map?

I gather from your enthusiastic response to blake's list that you do
like better tools - maybe the thing is, you really want them in emacs
(which is fine with me), and perhaps much of the apparent disagreement
between you and I is really about graphical IDE's vs. emacs ?

-------------------------------------------------------
Matisse Enzer <matisse@...>
http://www.matisse.net/  - http://www.eigenstate.net/
415-225-6703 (work/cellphone)
415-401-8325 (home)

At 12:35 2005-06-19, blakemills wrote:
>I'll have to take a closer look at your emacs customizations, since
>I'm doing perl XP with a highly tweaked emacs as well.  We've got all
>sorts of useful mods including:

Wow. With all the talk about this stuff I've started hacking a little on
something like this, and now maybe it already exists :)

Is it available somehwere?


/J

J Matisse Enzer writes:
> I gather from your enthusiastic response to blake's list that you do
> like better tools - maybe the thing is, you really want them in emacs
> (which is fine with me), and perhaps much of the apparent disagreement
> between you and I is really about graphical IDE's vs. emacs ?

I like better tools to problems we encounter. :-) Everything else is
YAGNI.  Performance, tree views, checkin notifications, etc. are not
problems we have.  Note that Blake's list doesn't include these
either.

FYI, here's what we would use from Blake's list:

blakemills writes:
> - Jump from code to test (and vice versa) in one button
> - Jump to perl-thing-at-point, whether its a method, module, constant
>   subroutine, or filename
> - Show the inheritance hierarchy of this module, or the one under
>   point
> - Deparse a chunk of highlighted perl, adding parens to clarify
>   precidence
> - show all methods named X
> - Jump to the SUPER method of the one you're overriding
> - Toggle between prefix and postfix versions of if,foreach,while
> - toggle pairs of single quotes to double quotes and vice versa

We have a longer list than this, too. :-(

### Here's stuff we already have:

> - Run the unit test
> - Tab complete module names based on the .pm files in the filesystem

dabbr works fine for this, and handles any (word, language) tuple.

> - Show the entire CVS checkin that added a particular line
> - Show CVS annotation or log comment for current line
> - See the current cvs diff for this file or sandbox
> - Navigate previous cvs changes for this file
> - Jump from a CVS diff file directly to the line in the code

vc mode does more than I have ever needed.  But others at bivio may
disagree.

> - make sure the current perl file compiles cleanly

### Here's stuff we absolutely no need for and why:

> - Add a use line for the class under point

We do "minimal" use.  In general, we wait to run the unit test to see
if we need any "use" lines.  This makes the code shorter, and since we
always use qualified imports, we don't need use lines at all.

> - Fold unnecessarily long copyright chunks into one line

What I would like is an "add year" when a file is checked in.  When we
release to the public, our packager automatically adds the long
copyright notification.

> - Insert various useful debugging lines temporarily, i.e. Carp

We have a trace facility which allows us to dynamically control trace
points efficiently.  It's an abbrev to add a trace point (t C-x a e
adds: _trace() if $_TRACE;).  All bOP trace points and logging
include line and file numbers (compactly) along with date and pid, if
configured.  "warn" is nice, but conflicts with Perl internal warnings
which generate stack traces (if configured), because they usually
indicate a defect.  We never do "print()", because if we checkin the
code accidently (never happens ;-), we'd have a hard time finding it
without a line/file on the line.

> - find all occurances of a string in our code base

grep -Ir :-)

> - Toggle formatting of lists or hashes that span more than 80 columns

We avoid > 80 char lines.

> - Update the test count

Bivio::Test automatically counts the number of tests, executes tests
in "catch" sections, and generally saves the amount of code you have
to type by at least half.

> - Apply/Revert a hunk from a cvs diff file

Never go back!  :-)  Might see how this would be useful, but I thought
vc mode already had this.

> - Insert a random MAC address (for writing unit tests)

I can't think of case where we would need this.

> - Insert a source filter around the current block so only a portion
>   of the unit test is run, so you can focus in on a particular
>   test thats failing

Possibly important.  Our tests are declarative, but order does matter
in many cases.  We try to be as stateless as possible.  We also try to
make the tests as fast as possible.

> - run 'make' with various useful targets

We don't use make.

> - pull up a perldoc on whatevers under the point

I read the perldoc inline.   Could see how this would be useful for
external code.

Rob

J Matisse Enzer writes:
> That's part of the problem with current tools. I want to see tools that
> *can* figure out if $o->foo() is "my" foo, in most cases.

I don't see how this is possible.  Perl has no "interfaces" like
Java.  We have a convention for interfaces, but before you have the
"foo", you can't know what $o is, if it was passed in, without some
documentation.  We could use our POD to find the $o, but then you know
what $o is, and the method is short so you can see it. :-)

> You guys have a particular approach that minimizes the problem, which
> is good. Maybe the whole world will adopt your approach, or maybe not
> :-)

I don't want the whole world to adopt our approach.  It would be too
boring.  Rather, I'd like to see more people figure out that the
problem isn't tools but policy agreement to make the tools easy to
write.  Our additions to cperl are about 1,000 lines of code including
comments.  This is trivial in comparison to what we do for our
customers.

> I'm certainly in favor of unit tests, and consistent coding style, in
> no small part because they make many things easier, just as you are
> experiencing.

Yes, that's my experience.  Something they don't teach you in school
or in most jobs.

> I think you are actually agreeing that it should be easy to access all
> of the features we are discussing (not just running a profiler, or a
> refactoring action, but all of them).If I'm correcting grasping your
> position it is that it is *already* easy and that you are not motivated
> to make these things any easier. I think *that* is where we might stand
> differently at present.

Yes.  Emacs makes it trivial to add new features.  Here's the code to
fire off the right form of perl based on the file name:

(defun b-compile-command-from-file-name (filename)
   "Returns a string compile-command.  Appends 'env BCONF=...' for test files."
   (labels ((base () (file-name-nondirectory filename))
	    (env () (let ((project (b-perl-which-project filename)))
		      (concat "env BCONF=~/bconf/"
			      (if (null project) "default" (cadr project))
			      ".bconf "))))
     (cond
      ((string-match "\.btest$" filename) (concat (env) "b-test acceptance "
						  (base)))
      ((string-match "\.t$" filename) (concat (env) "perl -w " (base)))
      (t (concat "perl -w " (base))))))

This note is far longer. :-)

> Or perhaps were we depart is in the list of things that we feel should
> be easier, and/or in our feelings about Perl's adoption by new
> programmers and new projects - you might be happy with its adoption
> rate and/or feel that the obstacles to Perl's adoption lie elsewhere.

It's a YAGNI thing.  I add what I need.  You add what you need.  We
don't need the same thing, because our development
approach/team/environment is quite different.

> I agree. People gradually become senior, and expert, and experienced,
> and no tool have replace experience. My position is that better tools
> are, well, better, and even experts benefit from them, in fact they may
> benefit more than novices or intermediate level folks, at least in some
> situations.

Is Word a better tool than LaTeX?  Yes and no.  I use Word for
letters, proposals, and such.  I would never use it for a manual or a
book. :-)  I wrote Extreme Perl in DocBook/XML in Emacs.  I doubt I'd
do that again.  I prefer LaTeX, because it is extensible.  It allows
me to refactor my content.  Here's a good example where DocBook/XML
falls on its face:

<b_include_file file="eg/its-a-smop/example.xml"/>

I have another xml file I'd like to use as source data for my book.  I
want it escaped.  I want it in a separate file so I can use it as test
input.  It's the FITness thing in reverse.  I want the tests to be
separate from the document, because there are syntax collisions, and
I'd rather not escape every & and > in my perl source. :-)

> Rembrandt did 700 years ago with burnt wood and paper.

Indeed.  Or what Paul Graham did with Lisp to produce Yahoo
Stores. $-)

> Are you certain you have no shared note-taking? I would argue that
> http://www.bivio.biz/f/bOP/html/index.html is an example - the NAME
> entries (and the full perldoc) from each module is in fact a note (it's
> not executable code), it is meta-information that your whole team
> contributes to.

Agreed, but this isn't note taking, it's commenting working code.  We
have been having an internal argument about whether this stuff is
really useful or not.  Some people like our method sig documentation,
because Perl is so terse in this regard.  We filled in the DESCRIPTION
and NAME sections in bOP, but rarely do in our apps.

> That is great - that is the single most important thing in a team, I
> think the "plays well with others" factor. It is not the only factor,
> but I think if you have that, you can acquire any others.

Exactly.  That's why IDE discussions in general are besides the
point.  It's an easy topic to grasp, when the other parts of the
problem are so looming.

> I think that's a matter of personal preference. I and many other people
> do like having a newly added file show up in a list of files instantly.

Agreed.  It's YAGNI to me, and a feature you need today.

> So you would say that the people who wrote Komodo and EPIC, for
> experts, are not experts?

Hmmm... Muddy waters.  I have no idea until I see the code.  The folks
at Netscape were definitely NOT experts, or they wouldn't have messed
up so badly.  Firefox is a rewrite of a rewrite of a rewrite.  It's
still got some rather silly bugs, but it is getting better.  IE, OTOH,
was superior to all but Firefox.  Microsoft was able to evolve
faster, because they put experts on the problem.

> or do not enjoy using those tools?

I can't say if they enjoy using these tools.

> What about Eclipse and IntelliJ?

IntelliJ is an oxymoron.  :-)  We don't need IntelliJ or Eclipse.  They
are needed, because most people don't know how to write robust code
quickly.  They don't value refactoring, unit testing, and acceptance
testing.

Java is worse than useless; it's dangerous.  I disagree with Richard
Gabriel.  You don't want to bring hundreds of thousands of bad
programmers over to half-way to Lisp.  You want to leave them on the
Dark Side (C#, C++, whatever you want to call it), and instead, you
want the best programmers to focus on solving real problems in OSS and
earning good salaries.

Take the average large software company.  Get all the programmers to
vote on who the best programmers are.  Fire the bottom 90%.  Throw the
top 10% in the same building.  Make them agree on what's right.  Fire
the programmers that don't willingly participate in the new approach
(even if they were voted the top programmer).  The company's
productivity and software quality will undoubtedly improve.

> What is your opinion of Martin Fowler's article "Crossing Refactoring's
> Rubicon" http://www.martinfowler.com/articles/refactoringRubicon.html ?

I let Martin speak for himself:

     This awesome tool makes refactoring much quicker and more
     pleasurable. The trouble is that it is a Smalltalk tool, and not
     many people are using Smalltalk. Indeed I've hardly ever used the
     Refactoring Browser because most of the work I've done in the last
     few years has been in Java.

What does that say to you?  Does Martin prefer SmallTalk?  Why he
coding in Java

Why is that the original wiki, FIT, etc. were written in Perl?
Because Ward could get the job done faster in Perl than any other
language (and he knows quite a few).  Why did it get rewritten in
Java?

Why was nUnit written first in SmallTalk?  Why was it rewritten in
Java?  Why do all the Perl test infrastructures copy these verbose
testing structures?

> Depending on what you mean by "proven" I think I agree with you. What
> would you consider as "proof" ?

When the people who are writing Java code in whatever tools can
outcode the people who are writing Perl on a man-hour and quality
basis.

> http://www.perl.com/pub/a/2005/06/09/ppi.html

The problem of writing a document parser is done quite well in Emacs.
I am not in the editor business.  I'd rather leverage the 30 years of
work that is known as Emacs than trust someone who thinks he can
create a DOM for Perl.  BTW, that's why I got out of the operating
system and infrastructure business.  It's a done problem to my mind.
All problems now are application specific.

> carpentry, a "speed square" is "better" for many things where we used
> to use a "framing square", because in these cases the speed square is
> easier to use - it might even be a bit less precise ion those cases,
> but it's still a  "better" tool.

Carpenters don't build their own tools, because it is difficult to do
in small quantities.  Building integrated software tools is easy.  The
comparison is therefore irrelevant.

> Of course you also need senior, more experience people. And why
> automatically say that "intermediate" == "inexperienced"?

I didn't.  It's a continuum.  However, you need to know what you don't
know.  If you have a senior person, s/he usually does.  That person
will point out things about what is unknown about the project while
the less experienced folks will be arguing over which IDE to use. ;-)

> Few people are experts, and all experts started as non-experts. I am
> well aware of many of the values of experience and skill, and I hope
> that 20 years from now I have learned even more, I certainly intend to
> keep trying.

We all learn and get better, if that is our goal.  The key thing that
I've learned over the years is how much I want to increase complexity
when indeed I should be decreasing complexity.  That's what it means
to be an expert to me.  I am still a long ways from reaching my goal.
Fortunately, I've got several people in my office who like to nudge me
along.

Rob

On Jun 19, 2005, at 10:45 AM, Rob Nagler wrote:

> J Matisse Enzer writes:
>> That's part of the problem with current tools. I want to see tools
>> that
>> *can* figure out if $o->foo() is "my" foo, in most cases.
>
> I don't see how this is possible.  Perl has no "interfaces" like
> Java.  We have a convention for interfaces, but before you have the
> "foo", you can't know what $o is, if it was passed in, without some
> documentation.

Somehow Rob, I feel that if a client paid yo to figure out a way to do
it, you and your team would find a way :-) I kind of doubt you would
simply say "Can't be done, sorry."

-M

-------------------------------------------------------
Matisse Enzer <matisse@...>
http://www.matisse.net/  - http://www.eigenstate.net/
415-225-6703 (work/cellphone)
415-401-8325 (home)

On Saturday, June 18, 2005, at 05:41 PM, J Matisse Enzer wrote:
> On Jun 18, 2005, at 12:08 PM, Rob Nagler wrote:
>> No.  There are a number of reasons why you don't want to do this.
>> Firstly, you can't know that the following is your "foo".
>>
>>     $o->foo();
>
> That's part of the problem with current tools. I want to see tools that
> *can* figure out if $o->foo() is "my" foo, in most cases.

You can't do this without writing something that will break my code.  I
believe it'll break Rob Kinyon's code even worse, if he uses object
method calls in his dynamic code.

Just because, in your code, $o->foo() is your foo, does not mean that
someone using your module will be using your foo at that point.  If
they're not, the code is broken.  If you make changes like this rename
in a single release, without a period of deprecation, you will get a
reputation among those people who use your modules of releasing
unstable code.

Note that, IMHO, when one deprecates code, one must indicate what to do
instead, in addition to saying the code is deprecated, rather than
simply reporting "don't do this any more, as we're about to break it."
Poorly documented transitions can be nearly as frustrating as
undocumented transitions.

I suppose you could put a 'used downstream' flag in the module; this
rename functionality would then be disabled if it was set to true.
However, that is a very obvious barrier to improving skill, as it's a
tool that only works for beginners - once one transitions into the role
of module provider, it's gone.


Regarding the ubiquitousness of unit and acceptance tests - if you are
not doing these tests, and are not planning on doing these tests in the
future, why are you here?  (I ask, so that I might better understand
your contributions.)  Extreme programming is a set of practices, which
do not necessarily work well apart.

Most specific to this discussion, I have found that refactoring without
unit tests can be very dangerous - sometimes, one thinks one has
changed nothing, but one has, in fact, changed a great deal.  This is
actually the situation I was able to use to convince management to
allow us to spend time on a proof of concept of writing automated
tests.  We had repeated instances of various people on our team
releasing code that had repercussions sufficiently removed from where
they'd made their changes that they hadn't thought to test the
afflicted areas.

I think that we would be better served documenting ways to make full
extreme programming in perl easy than we would be making tools which
facilitate incomplete extreme programming in perl.


Incidentally, I'll reiterate more explicitly a point I made earlier -
unit tests should be written before the code to satisfy the
functionality.  It may seem silly, but it sometimes comes in handy,
such as the times I've found that the functionality already existed.
Normally, its utility is more in pointing out exactly how the code
currently behaves.  Because programmers generally do not think about
exception behavior, the behavior in the uncoded section may be quite
different than the programmer thinks it is.

Ed

On Jun 19, 2005, at 10:52 AM, Ed Grimm wrote:
>
> Regarding the ubiquitousness of unit and acceptance tests - if you are
> not doing these tests, and are not planning on doing these tests in the
> future, why are you here?  (I ask, so that I might better understand
> your contributions.)

I am all in favor of unit tests, and test written before the thing they
test. I don't know what I said that might have given you any other
impression, sorry about that.


-------------------------------------------------------
Matisse Enzer <matisse@...>
http://www.matisse.net/  - http://www.eigenstate.net/
415-225-6703 (work/cellphone)
415-401-8325 (home)

--- In extremeperl@yahoogroups.com, Rob Nagler <nagler@b...> wrote:
> Wow!  Would you mind loading this in the files area?  We could try a
> merge, or you could. :-) Are your mods based on cperl, i.e., hook
> into cperl-mode-map?

I'd love too, but I have to get permission from my company first.  I'd
like to get a lot of the infrastructure we've built inhouse back out
into the community at large, but I haven't ever put enough time into
it to get it out there.  The place I'm working at has been doing perl
and XP for nearly four years, so we've built up a lot of interesting
code that hasn't made its way back out into the community.... That
includes our emacs setup (and yes we use a slightly tweaked cperl to
handle our coding conventions)

> However, I do get to the Bay Area every.....

Cool. Drop me a line next time you're in town.

-Blake

On 6/19/05, Ed Grimm <ed@...> wrote:
>  On Saturday, June 18, 2005, at 05:41 PM, J Matisse Enzer wrote:
>  > On Jun 18, 2005, at 12:08 PM, Rob Nagler wrote:
>  >> No.  There are a number of reasons why you don't want to do this.
>  >> Firstly, you can't know that the following is your "foo".
>  >>
>  >>     $o->foo();
>  >
>  > That's part of the problem with current tools. I want to see tools that
>  > *can* figure out if $o->foo() is "my" foo, in most cases.
>
>  You can't do this without writing something that will break my code.  I
>  believe it'll break Rob Kinyon's code even worse, if he uses object
>  method calls in his dynamic code.

I am a heavy believer in OO methodologies as an important tool in my
toolbox and I leverage them in most code I write. Coming from a
primarily Perl background, I'm very cavalier about how I treat
encapsulation and interfaces. I believe in overloading, judicious use
of "no strict 'refs';", eval as both compiler and try-catch,
hand-build switch statements, and a big mixture of all of those. I
overload isa(), can(), and pretty much anything else I can lay my
grubby hands on, as well as using overload itself. Pretty much the
only thing I pause before using is AUTOLOAD, but I'll use it when the
time is right.

When you see $o->foo() in my code, you have the following guarantees:
1) $o is a blessed reference.
2) ref($foo) is (almost always) in a separate file somewhere.
3) ref($foo) is (almost always) the package that has promised to implement foo()

That's about it. As for the "almost always" ...

     - I try to keep my classes in their own packages, except where it
makes sense to generate them on the fly. (I use Class::DBI::Loader
which might generate classes for me.)
     - I wrote Class::LazyLoad. It will redispatch to the class that's
lazyloaded, but ref($foo) may not be what it will be once you do
something to it.

>  Just because, in your code, $o->foo() is your foo, does not mean that
>  someone using your module will be using your foo at that point.  If
>  they're not, the code is broken.  If you make changes like this rename
>  in a single release, without a period of deprecation, you will get a
>  reputation among those people who use your modules of releasing
>  unstable code.

Let's just put it this way - if you make me downgrade your module to
make it work with my stuff because you changed API and it wasn't a
major release, I just ripped your module out of my code. End. Of.
Story.

>  Note that, IMHO, when one deprecates code, one must indicate what to do
>  instead, in addition to saying the code is deprecated, rather than
>  simply reporting "don't do this any more, as we're about to break it."
>  Poorly documented transitions can be nearly as frustrating as
>  undocumented transitions.

Poorly documented ones are worse than undocumented ones. If it's
undocumented, I know that I have to go sourcediving. If it's poorly
documented, I don't know how poorly, so I don't know how much or where
I need to sourcedive.

Rob

J Matisse Enzer writes:
> Somehow Rob, I feel that if a client paid yo to figure out a way to do
> it, you and your team would find a way :-) I kind of doubt you would
> simply say "Can't be done, sorry."

We always say: "No problem is too complex".   We also say:

     Scope = f(Risk, Time, Resources)

When our customers argue about this equation, we explain the situation
politely.  If they still don't get it, we tell them politely we can't
help them.

Rob

Johan Lindström writes:
> Is it available somehwere?

We uploaded our cperl extensions to the files area of this group.
Blake needs approval.

Rob

blakemills writes:
> I'd love too, but I have to get permission from my company first.  I'd
> like to get a lot of the infrastructure we've built inhouse back out
> into the community at large, but I haven't ever put enough time into
> it to get it out there.

It took us about a year or more to get bOP into enough shape to
release.  In hindsight it was really worth it.  The primary business
value is that it allowed us to build apps quickly, which allowed us to
grow on our success.  A secondary business value is that we have a
simple app (PetShop) written with bOP that is now a valuable
acceptance test infrastructure.  At the time, however, it was a big
risk, because we only had one customer who wanted bOP.

> The place I'm working at has been doing perl
> and XP for nearly four years, so we've built up a lot of interesting
> code that hasn't made its way back out into the community....

I bet.

> Cool. Drop me a line next time you're in town.

Will do.

Rob

On Jun 19, 2005, at 8:05 PM, Rob Nagler wrote:

> We always say: "No problem is too complex".

Now that's more like it :-)

-------------------------------------------------------
Matisse Enzer <matisse@...>
http://www.matisse.net/  - http://www.eigenstate.net/
415-225-6703 (work/cellphone)
415-401-8325 (home)

I'm wondering if someone on this list is interested in a paying gig
improving the Language::Guess module so that it is much, much faster,
say 50-100 times faster, even when dealing with utf8 data.

For the right result and price I'd pay for the work to be done. The
module is licensed under the GNU GPL, 2.0 so any work would be under
that same license.

Send me email if you are interested.

-M

-------------------------------------------------------
Matisse Enzer <matisse@...>
http://www.matisse.net/  - http://www.eigenstate.net/
415-225-6703 (work/cellphone)
415-401-8325 (home)

J Matisse Enzer writes:
> I'm wondering if someone on this list is interested in a paying gig
> improving the Language::Guess module so that it is much, much faster,
> say 50-100 times faster, even when dealing with utf8 data.

Do you have a performance benchmark for this improvement?

Thanks,
Rob

Our list seems to be growing all of a sudden.  Is there a upswing in
the use of Perl around the world or XP?

Cheers,
Rob

On 8/26/05, Rob Nagler <nagler@...> wrote:
>  Our list seems to be growing all of a sudden.  Is there a upswing in
>  the use of Perl around the world or XP?

I think it's more that there's an upsurge in understand that XP applies to Perl.

Rob

I can't speak for anyone else, but I recently joined the list. I began
my professional career in 1998 writing Perl programs for the web. Then,
in late 2001, the company I was working for decided to standardize on
Java. I have long since moved on, but I've had my ass firmly planted in
J2EE-land ever since. For the last couple of years I've had the pleasure
of doing full blown XP in a Java environment.

Recently, I've been doing freelance consulting, and I've been hired to
write some native code in C/C++. I knew that I was going to test drive
it, but I was unfamiliar with the test frameworks available. I gave
several a try (CppUnit, CxxUnit, TUX, ...at least one other...) but they
all sucked royally. Then it occured to me that I could test my native
code from Perl. So, I started writing tests first in Perl. Most of the
time I'd use Inline::* or I might black-box with exec() depending on the
granularity of the test. Then I could implement the C/C++/Assembly code
to pass the test.

It also occured to me right away that I hate writing make files, but I
could use Perl to configure and build (Rather than Ant or NAnt, which I
am used to, but they are unwieldy when all you are doing is calling
shell commands.)

Anyway, when I found myself doing XP practices with Perl it seemed like
a natural thing to look for others who were doing the same so I found
this list.

...

Another thought: OReilly just published "Perl Testing" (Which,
ironically, talks about testing C code with Inline:* even though I did
it before I read the book) recently. That might have sparked some
additional interest.

Thanks,
Adam

Rob Nagler wrote:

>Our list seems to be growing all of a sudden.  Is there a upswing in
>the use of Perl around the world or XP?
>
>Cheers,
>Rob
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>.
>
>
>

Rob Kinyon wrote:
> On 8/26/05, Rob Nagler <nagler@...> wrote:
>
>> Our list seems to be growing all of a sudden.  Is there a upswing in
>> the use of Perl around the world or XP?
>
> I think it's more that there's an upsurge in understand that XP applies to
Perl.

Of course, it might just be that you were linked to from this week's new
perl.com article.

Dave...