Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: Re: Re: Re: (OT) Programming as a craft

by simonm (Vicar)
on Dec 16, 2003 at 20:45 UTC ( [id://315135]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Re: (OT) Programming as a craft
in thread (OT) Programming as a craft

What I don't understand is why a Perl editor should be written in Perl itself. You're ultimatly dealing with a stream of bytes, which is as a completly language-agnostic concept as you can find.

But woolfy was specifically describing a Perl-specific code editor, not an arbitrary-stream-of-bytes editor.

Beyond just syntax highlighting, such a tool might be expected to support the features of some advanced Java and Smalltalk code editors, like:

  • symbol name lookup (tab-completion for variable names, when typing a function name show an example of the arguments it takes, etc);
  • refactoring editor (for example, select a few lines of code and invoke the "move to new subroutine" refactoring, and automatically have those lines replaced by a call to a new subroutine with proper argument passing and return value assignment);
  • run-time/debugger integration (interpreting code as you type, setting break points, editing code in a running program and then continuing);
  • documentation support (WHYSIWYG POD editor, fill in some kinds of POD automatically);
  • testing support (automatic running of tests in the background, integrated display of profiling results and code or pod coverage analysis);
  • plugin support (to let others add support for working with Class::MethodMaker, Class::Contract, Aspect, or other specialized approaches to Perl coding).

Even if it only implemented some subset of the above, I think such an editor would be providing real value, beyond the traditional solution of a good text editor with syntax coloring and automatic indenting.

And I don't see how you could really do justice to such a tool without implementing it in Perl, or at least delegating key portions to an embedded Perl instance.

  • Comment on Re: Re: Re: Re: (OT) Programming as a craft

Replies are listed 'Best First'.
Re^5: (OT) Programming as a craft
by hardburn (Abbot) on Dec 16, 2003 at 21:22 UTC

    And I don't see how you could really do justice to such a tool without implementing it in Perl, or at least delegating key portions to an embedded Perl instance.

    For most of the things you list, a Perl implementation isn't required--you just need the ability to parse Perl. In fact, since some of them will probably require hooks into the perl interpreter (or maybe Parrot), it's preferable to do much of it in C. In particular, the run-time debugger and symbol table lookups will probably be best with interpreter hooks.

    Test script support is probably best done by hooking into Test::Harness, unless there is a particularly good reason to come up with something else. It'd also be nice to be able to write plugins in Perl. However, neither of these things make it absolutely required to write entire editor in Perl (as long as proper hooks are in place).

    I'm not saying a editor written in Perl is a bad idea, just that I don't see what benefit it will bring to the user over any other langauge. There are already too many text editors/IDEs out there, and the same people who keep using vi or emacs will probably keep using them.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://315135]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (5)
As of 2024-04-19 23:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found