Front page | perl.perl6.language |
Postings from May 2005
Re: Perl6 and support for Refactoring IDE's
Thread Previous
|
Thread Next
From:
J Matisse Enzer
Date:
May 6, 2005 10:47
Subject:
Re: Perl6 and support for Refactoring IDE's
Message ID:
c312d3ef158b58e0738343907cb06e98@matisse.net
Thanks for your comments - I was afraid I'd get flamed for suggesting
something wasn't perfect about Perl :-)
On May 6, 2005, at 9:31 AM, Fagyal Csongor wrote:
>
> IMHO subversioning does not have too much to do with the language
> itself. Subversioning operates on files. An IDE might integrate some
> interface for this task, but that is a different question.
You are right - it's not a language issue, sorry I left that in.
> Have you considered using the "DONATE" button on
> http://e-p-i-c.sourceforge.net/ ? :)))
Yes :-) I've donated :-)
I contributed some changes to Devel::Refactor (added rename_subroutine
and a test suite) and now I have loaded the Java source for the EPIC
editor into Eclipse and started looking at how to add support for
'rename_subroutine' - but my Java skills are less than minimal :-)
In another post, On May 6, 2005, at 9:26 AM, Luke Palmer wrote:
>
> I think you're absolutely right. Perl should have an IDE with
> Eclipse-like context-sensitivity and refactoring support. However,
> it's hardly in Perl's philosophy or interest to bless one.
and I agree that Perl should not bless any one IDE, and I am *very*
happy to read that Perl6 will make it much easier for good tools to be
created for Perl, as Luke Palmer said:
> One thing is for sure. Perl 6 is providing enough introspection and
> parsing capabilities to make it possible to write a context-sensitive
> IDE, unlike Perl 5 (well, Perl 5 made it *possible*, I suppose, but
> Perl 6 will make it obvious). Perl 6 is exposing its whole grammar at
> the language level, so you can say "give me a syntax tree for this
> chunk of code" and it will. Even if there are modules that change the
> syntax with macros (though your editor might have trouble
> understanding what the macros mean).
So, perhaps that leave me (us) in the following situation:
1) Do what I can do help Perl6 happen faster (not much I can do, the
current types of programming required is beyond my skills)
Maybe I can help evangelize Perl6.
2) Try and improve the tools that do exist for Perl5 - I am doing this
with Devel::Refactor and EPIC, but I don't know if I'll learn
enough
Java to make a difference in EPIC any time soon.
3) Try and keep Perl alive in other ways so it's still around when
Perl6 arrives.
Yesterday I was at an engineering Open House at Google, and I asked one
of the engineers "What can Perl do for Google?", and he basically said
(I'm paraphrasing) "Not much, we are a Java and Python shop. Getting a
real refactoring IDE for Perl 5 is more compelling a story then a
virtual machine (Parrot) that will run multiple dynamically-typed
languages." (they already have Jython)
Now that was just one person's statement, but this fellow (John Brewer,
www.jera.com) is not a Perl hater - he uses Perl, and he's bright,
level headed and was not trying to be hostile. In fact he said these
things to me and to Larry Wall who was listening very politely :-)
Maybe this isn't the right place to keep discussing this, so I'll take
pointers to other places. I'm very worried about the continued
viability of Perl for major projects and am trying connect with other
people and see what can be done about it.
-------------------------------------------------------
Matisse Enzer <matisse@matisse.net>
http://www.matisse.net/ - http://www.eigenstate.net/
Thread Previous
|
Thread Next