Random Perl ... rant
johanl at DarSerMan.com
Thu Apr 3 23:28:23 BST 2008
At 10:15 2008-04-03, Ovid wrote:
>--- Iain Barnett <iainspeed at gmail.com> wrote:
> > I want intellisense
>(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,
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
>I really can't believe anyone wrote this. That is the slowest and
>most tedious way to debug there is. Completely innefficient, and a
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.
More information about the london.pm