Random Perl ... rant

[Johan Lindström]

At 10:15 2008-04-03, Ovid wrote:
>--- Iain Barnett <iainspeed at gmail.com> wrote:
> > I want intellisense
>
>http://search.cpan.org/dist/Devel-PerlySense/
>(still needs more work)

PerlySense doesn't actually do Intellisense/command completion yet. 
When starting out, that was what I was aiming for though, hence the 
name. But it turned out that there was a lot of other things more 
important than that. Lots of itches that needed scratching far more than that.


> > and I want a GUI for debugging,
>
>http://search.cpan.org/dist/Devel-ptkdb/
>http://www.freedownloadscenter.com/Programming/Misc__Programming_Tools/ActiveState_Perl_Debugger.html

Just for the record, Emacs has a unified debugger mode, and the 
perldb blends in beautifully with that. I.e. you step through the 
code in the editor and you have a REPL next to it for inspection and 
all that stuff.


At 14:37 2008-04-03, Paul Makepeace wrote:
> >  > Having a perl runtime co-existing with an IDE that does a 90%ile job
> >  > of autocompleting method & class names, provides high speed access to
> >  > docs, and so on would be a big win, IMO.
> >
> >  You've just described PerlySense.
>
>Thanks, I'll take a look when it's vim'ed.

That's potentially not that far off. There's a bit of cleaning up to 
do in the perly_sense command line script so all features use the 
Elisp/Vim serializer, but then it would be possible to start hacking 
Vim-script or whatever it's called. My team mate Rufus started 
hacking on that on his 10% time and created a proof of concept so 
it's definitely possible to implement the basic features like 
navigation and docs.


At 15:37 2008-04-03, Iain Barnett wrote:
>>Debuggers are too tedious to be useful.  Again, I don't think it's a
>>coincidence that most of the best programmers use "print" instead of
>>single-stepping.
>
>I really can't believe anyone wrote this. That is the slowest and
>most tedious way to debug there is. Completely innefficient, and a
>last resort.

I think the idea is that you get a more thorough understanding of the 
program by actually reading source code and reason about it, and to 
use logs and tracer bullets to instrument it.

For me, sometimes this leads to a better understanding, to let the 
program run its course for awhile and then go C.S.I. on the log 
files. Sometimes the debugger is invaluable to figure out which code 
is actually, in fact, executed. That Perl thing. Dynamic and unpredictable.

So it's a great tool to have when needed. But I've also seen 
programmers be very lazy (in the bad sense, intellectually lazy) when 
trying to solve problems and the debugger is just so easy to bring 
out. I would say that if you rely too much on the debugger to lead 
you around, you run the risk of getting a very shallow and fragmented 
view of the code base you are working on.


At 15:55 2008-04-03, David Cantrell wrote:
>On Thu, Apr 03, 2008 at 03:37:18PM +0100, Iain Barnett wrote:
> > it doesn't do perl
>
>Then what the fuck was the point of mentioning it?

Blub, and avoiding it.


/J