Are there other features you want in your tools? Are there tools that provide all of these features? Do you disagree with the premise? Let's talk about it here.
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 31 of 31.

• Visual SlickEdit has excellent support for Perl
  2006-02-09 05:59:09 zardozcs [Reply]
  
  Best Editor I've ever found. Been using it since it was a DOS program for C++ (1992) Now running it on Linux and Windows. It runs on everything. Has great online help for Perl and every other language, Syntax coloration, Function listing, you name it. Fantastic Visual Differencing and merging in place, Version Control support. v11 is out now! I've got v8 wonder what marvels it does for perl now. http://www.slickedit.com/home.php

• UltraEdit also has nice Perl support
  2006-01-14 21:21:11 W33 [Reply]
  
  I use UltraEdit as my main Perl development tool since years. I did not find better one, which lists functions in such useful way, as UltraEdit does.

  
  It also has bookmarking, code highlighting, autocomplete, project, and several other useful features features.

  
  Furthermore UltraEdit has code folding feature, which makes possible to collect an
  IF ($foo) {
  }
  block into 1 or 2 lines, so you view only the code parts you actually work.

  
  Supports not just Perl language, but also a lot other languages.

  
  UltraEdit is still actively developed and better & better programming.

  
  The strongest reason, why I still use UltraEdit for my Perl developments is the function listing and code folding feature. I can't believe it, how was I able to live without these features earlier...
  I also added some advanced features, with the configuration tool, so I can do Perl syntax check and Perl execution with just a click.

  
  Further extras would be welcomed in UltraEdit for sure, like the mentioned features:
  - "Code-Assist Editor"
  - "Extract Subroutine/Method", "refactoring",
  - "Rename Subroutine/Method",
  - "Rename Variable",
  - "Move Subroutine/Method",
  - "List Global/Local variables",
  - "Tree View and Navigation of Source Files and Resources",
  - "Language-Specific Help"

  
  I hope the UltraEdit developer will take into consideration to include some of these features into his fine software...

  
  W33

  • UltraEdit also has nice Perl support
    2006-01-15 18:59:43 matisse@matisse.net [Reply]
    
    UltraEdit (http://www.ultraedit.com/) seems like another useful tool. It is Windows-only, so won't work on machines running Linux/Solaris/Mac OS X etc. but still the more tools the better.

    
    By the way - the EPIC plugin for Eclipse does have code-folding and function listing (also lists packages - clicking on apackge jumps to the "use Package;" statement.)

• Perl needs better Tools, but not IDEs!
  2005-11-10 11:05:49 orperl [Reply]
  
  I'm developing in Perl since 10 years now. IDEs are of course nice to
  have but I know many programmers - regardless what programming language
  they use - which just use a simple editor, even for complex projects.

  
  Perl got big by the use in web-projects but got out-dated by PHP and
  other languages because there was no further development in this
  direction. Perl would need a stable and reliable mod_perl with a session-
  management. Without that it will fade out ... sad but true.
  

• Unit tests with GTestRunner
  2005-11-08 11:21:17 Guido.Flohr [Reply]
  
  The module Test::Unit::GTestRunner provides a Gtk+ based GUI for running unit tests. It provides a UI similar to JUnit. Compared to the command line and Tk versions that ship with Test::Unit it already offers some improvements, like running multiple test suites, (re-)loading test suites, and running only selected subsets of test suites. Apart from that, GTestRunner is fully internationalized and currently available in English, Bulgarian, and German. You can subscribe to new release on http://freshmeat.net/projects/GTestRunner.

  
  Since I am the author, I leave the decision to you, whether GTestRunner is a better tool or only a tool. ;-)

• Python have a nice IDE
  2005-10-21 08:29:19 explorer [Reply]
  
  Eric3: http://www.die-offenbachs.de/detlev/eric3.html

  
  I suppose that to make a IDE is more easy if the language is not syntax free like Perl...

  
  I use Eclipse + e-p-i-c plugging and joe (last version) for local and remote work, respectly, but I will need a better class' explorer.

  • Python have a nice IDE
    2005-10-21 09:16:51 matisse@matisse.net [Reply]
    
    Eric, can you give a URL for the Python IDE you use?

    
    I completely agree that Perl's flexible syntax makes an IDE much harder, it's one of the main challenges.

    
    Perhaps one approach is to have the IDE assume that the code follows Damian Conway's "Perl Best Practices", http://www.oreilly.com/catalog/perlbp/ - I know of at least one team in a major financial institution that has adopted that book as their in-house development rules.

• Argument similar to who is better - vim or emacs
  2005-10-13 12:55:28 rumcho [Reply]
  
  The article reminds me of the legendary topic of which editor is better - vim or emacs. And since I am a vim guy I need to say I am so used to running my editor on the command line that graphical IDEs are not something I personally would like to deal with.
  Many times one needs to connect to a server that does not have X - in situations like this say bye-bye to your graphical IDE. And who would run or even install X on a server anyway so you could run your GUI IDE and drain the system memory? I work in environments where I have X or there's no X. So what do I need to do in this situation? Run graphical IDE when I can and run vim/emacs when I can't?
  NO! No, no, no!
  Too much hassle. Running the same editor all the time no matter where I am gives me the power to hone my "editor skills" if you like. Maybe for graphical IDE users such term does not exist but guess what?! In vim and emacs there's actually such concept and its implications are very important to the work process. I believe every time I use vim I get better and faster. There's no time for splash screens popping up, there's no time for big-ass memory-guzzling editors loading up for 5 seconds (yes, 5 seconds). My vim loads instantly and I dont' like to wait for 5 seconds every time I fire up my editor.
  Then, do I need to make sure my memory-guzzling editor is installed on all the servers I may be working on and also make sure the system requirements for those servers are met (like 64MB of RAM, 450MHz of CPU and what not)? Yes. Ok, yes, I may be working on a big project so I only need one server/workstation. This is great but how about me actually wanting to do some work from home? Well, let's see. ssh user@blah.com; vim /my/file. That's it, plain and simple. And it's secure - as secure as it will ever get. And how would I do this with one of those editors? I don't have the time to configure this editor from home, add remote projects, etc. I just want to make that little change to this little file out there on the development server. It's too much work, actually so much work that I would be reluctant to go about it because it may take me too long to just get to do the work that I was about to do.
  There is another major problem with graphical programs that I have seen few people mention. It is the use of a mouse. Mice were designed to make work for beginning and intermediate users easier. Once you get on the level of the experienced user the mouse is actually a deterrent. Believe it or not the mouse takes a lot of your precious time developing applications. It probably takes you 2 to 10 seconds reaching for the mouse, pointing it at whatever the hell you want to do, clicking on it and putting your hand back on the keyboard. To some people that may seem like a ridiculous statement but after so many years of using the PC I find it a nuisance any time I have to reach for my mouse because I can't do something with the keyboard. It is true that lots of good editors out there have keyboard shortcuts that would allow me to not use the mouse but how many of them will actually let me change the default shortcuts to whatever the heck I want (I don't like the <CTRL> button).
  I definitely see some good points the author of this article puts out there like popping up possible methods for a class but you know what - I really doubt the time saved is worth all the hassle one could run into dealing with a sophisticated graphical IDE. And while some companies/marketers/"technology experts" would like us to believe the IDE is a very important part of a programming language I and many other developers will not buy into their ignorant sales pitch. Of course, if they can't prove their IDE's superiority to my simple vim how would they otherwise sell the Java technology to all those clueless CEO's out there?
  The author has some good points but I definitely consider them to be far from enough to define a good editor. I must say vim has lots of useful features that I have never seen in any other editor. Like block cut and paste, deleting empty lines, repeating of the last command, history of commands, searching across multiple lines, executing a particular command x times to name a few. How many times have you heard the guy in the next cubicle deleting pieces of code sounding like a galloping horse knocking the same sequence of commands 50 times? Listening to one of those almost put me to sleep once. And then, working with vim is so similar to doing lots of things in perl itself, like search and replace. It's almost like they are a product of the same manufacturers.
  Whatever may happen with the graphical IDE's for perl I would be glad if someone was able to crank out something that the Windows background people would call a "nice IDE". However, all in all, I probably wouldn't use it.
  Roumen Semov.
  • Argument similar to who is better - vim or emacs
    2006-02-09 06:06:37 zardozcs [Reply]
    
    Just an idea here is what I do to get the best of both worlds:

    
    I run my gui editor on my workstation. I develop and use a visual debugger (Devel::ptkdb) my code as much as I can locally. Then I have two shell scripts p.sh which pushes all the changed files onto the remote server. Then I can run the code in the browser or on the remove host over my ssh terminal. I have g.sh which gets any changed files from the server back locally. Both scripts make use of a touched file locally and remotely to find changed files, uses tar to archive and scp to copy the changed files. It works great. No X on any server, massive editor power. Plus when the network is down, I can still do some work
    on my local machine.

• Funny - I've just come back to the 'fold'
  2005-08-31 08:20:39 DaveWarner [Reply]
  
  I drifted away from Perl in search of a more modern language (and the promise of more job security vis-a-vis Java and, to a lesser extent, Python). The many things that I found lacking and/or inelegant in those languages are intrinsic to Perl: testing frameworks, modular design, and a choice between functional and object-oriented programming. In an time when several top-flight books have been released (Higher-Order Perl, Perl Testing, the second edition of Advanced Perl, and of course, Damian Conway's masterful tome), along with toolsets such as POE and Catalyst, I think there is a resurgence of interest in, and excitement about, Perl.

  
  Would I like a NetBeans or Eclipse-like IDE for Perl? Not especially - I get tired of using up hundreds of Megabytes that can be better used for things other than echoing my typing back to me on the screen. Can I today quickly produce production quality code in Perl? Yes. And, standing on the shoulders of the many, many individuals that have worked hard on Perl, I can fire up a graphical debugger - when I need it, check the syntax of my code - when I need it, store my code in a revision control system (I always need that!).

  
  

  • Funny - I've just come back to the 'fold'
    2005-09-06 10:02:55 matisse@matisse.net [Reply]
    
    > Would I like a NetBeans or Eclipse-like IDE for Perl? Not especially...

    
    That's fair. There are also those of us who do want such a thing.

    
    Even in the Java world, where there are many fancy IDE's to choose from, many programmers use emacs or vi, or other non-GUI text editors. There are many ways to work :-)

  • Funny - I've just come back to the 'fold'
    2005-09-03 00:52:24 Agent [Reply]
    
    Yeah, Visual C++ ever made me love IDE. But before long, Perl made me really hate IDE. For years, I got quite used to working with Perl's command-line tools and a simple source code editor, like EditPlus. I admit the combination of ActivePerl and EditPlus is extremely cool on Win32 platforms. But it is somewhat difficult to persuade other Win32 folks to live without an IDE, especially those with Java or .NET background.

    
    A standardized, cross-platform Perl IDE is still worth considering. I'd like to mention Perl's very motto here: "there's more than one way to do it!"

• Optiperl is a good IDE
  2005-08-30 03:31:01 SimonHaidley [Reply]
  
  I came from a Delphi shop(5 years) into a major perl development project. The first thing I did was look for an IDE of which there were few and the ones I found were very elementary compared to Delphi. This was around Jan 2003. The project is pure perl and gets deployed on either Linux/Windows and Apache/IIS. I checked out all that I could find and ended up using OptiPerl by www.xarka.com. I made it the standard tool within the dev group for perl and now they wonder how they survived without it. To this day I use it on a daily basis and it is the one reason that I haven't switched to using a linux workstation instead of windows because it's windows only. It's reasonably cheap and well worth the money.
  • Optiperl is a good IDE
    2005-09-06 10:13:09 matisse@matisse.net [Reply]
    
    Thanks for that posting - I did not know about OptiPerl and it seems to have some very nice features. The sytanx coloring is very sophisticated, and it has code-completion on objects, etc.
    OptiPerl also has a web-server-debugging environment that seems good as well.
    Windows-only thought, and no refactoring support (yet!)

    
    Thanks again.

• Yeah it is kind of evil but it is good
  2005-08-27 17:47:33 shadox [Reply]
  
  I know, some of you guys would look at me as a part of the dark side, but using the ActiveState Visual Perl for Visual Studio.net 2003 is someting to really cool to work with perl in the windows platform ;)

  
  

• Cloning Java would be the wrong way to do this...
  2005-08-26 08:56:38 AdamKennedy [Reply]
  
  In this move towards better tools, it would be a mistake to look at what Java has and copy feature by feature from them.

  
  The things that work best in Perl are the things that were invented specifically for Perl. I for one like Test::Simple and friends much better than JUnit. And the mindsets are different.

  
  The syntax of Perl also leads itself to replication of various Java features being either very hard or impossible.

  
  But there's lots of things we CAN do that are very Perlish and much more novel. Things like POD autogeneration and munging, or catching all the gotchas that newer Perl programmers make. POD-aware spell checking, automated dependency detection.

  
  Things like Perl::BestPractice, taking Damian Conways great book and making a version that automates the principles in it.

  
  Things like features that work across multiple editors, so that a notional Perl::Editor::Collaborate module would let ALL the Perl editors work with each other in a subethaedit-like way.

  
  Perl and CPAN are far better than most other languages at componentisation in this way. Just look at all the plugins for Template Toolkit.

  
  In summary, lets make sure than in this push for better components, we play to our strength, not Java's

  • Cloning Java would be the wrong way to do this...
    2005-08-26 11:47:10 EdenCardim [Reply]
    
    I think 'cloning' is a very extremist term to use in this case. It's not exactly about cloning, it's about copying useful features from a language culture that's got way too much hype into it. Perl already borrowed lots of things from other languages, why not Java?
    • Cloning Java would be the wrong way to do this...
      2005-08-31 16:54:05 AdamKennedy [Reply]
      
      Yes, perhaps the term "cloning" is a little extremist. But the prevailing tone of the article, and of many people I speak to about "refactoring editors" is "Java IDEs have method completion, we should too", ignoring the fact that it is bloody hard to make that happen in Perl, and that there's other things that Java IDEs _don't_ do that are much more applicable to us.

      
      Consider it a reminder to think about the things that you _personally_ would LOVE to have in an editor, but don't. What would make your job easier on a day to day basis. What are the Perl issues that don't apply to Java that we could solve.

  • Cloning Java would be the wrong way to do this...
    2005-08-26 10:48:41 matisse@matisse.net [Reply]
    
    All very reasonable and practical suggestions!

• Modeling
  2005-08-26 07:11:54 EdenCardim [Reply]
  
  A tool that doesn't provide Modelling and automated code generation (and documentation) based on models wouldn't be acceptable for the 21st century. Java programmers can't live without them and I'd go as far as saying that the modeling tools available for Java (and other languages) is one of the major reasons why (lazy) new-comers to programming choose it. It's very awkward that this feature hasn't been provided for perl yet (or maybe I'm wrong), because it's community has a tight bond with 'laziness', one of the major programmer virtues. Combined with refactoring tools, one could get automated code and then 'perlize' it to his heart's desire.
  • Modeling
    2005-08-26 07:17:47 matisse@matisse.net [Reply]
    
    Hopefully this article and the discussions around it will help move things in the "right" direction.

    
    For example, see the new Sprog Perl editor project:
    http://sprog.sourceforge.net/

• You might be right, you might be wrong
  2005-08-26 03:40:29 Oyku [Reply]
  
  I have been developing serious perl applications (none of them are web sites) for so long that I cannot remember since when. I see your point, but I think that you are missing the more important ones. Fading of perl is not because other langugages have better IDE and tools. Perl itself is a flexible tool, but flexibility comes with a price. Anyone coded perl for two moths will tend to write "less" code because perl allows them to. Somtimes code gets so short that yyou cannot even figure out what it does even after 3 months pass. Worse, this is encouraged. you earn geek points if you write your code in a perlish way. I have not seen a single perl book telling to write clean code apart from variable naming conventions. This is where the real problem arises. If half of prroject development is coding and delivering it the other half is maintenance. Perl sometimes becomes impossible to maintain

  
  Another issue is that perl community is resilent to what businesses demand. You can easily find articles leveraging how important it is to seperate view and business logic in java word but hardly in perl. Perl geeks (inc. me) do not tend to have a sensitivity on this issue, rather you'll find how mod_perl performs better if configured like .....

  
  One other issue. People have waited for too long for parrot to become real. This opens a window for developers to peek at other methods and langguages. Community process is slow and it takes time to understand. e.g. what is onion?

  
  Aside from those, perl has its own stregths. Nothing on earth can come closer to CPAN. Virtually there are zillions of stable and readily available modules in a very structured way. I go nuts when search.cpan.org site is unreachable. It's my right hand. cpan install Acme::Something will satisfy all dependencies in a fraction of time. Nothing close to that period. For instance perl developers take connecting and accessing to any database for granted, because there is always a DBI driver available.

  
  Another issue is switchers. I find this less of importance. Perl had its time for being used for everything. This will eventually change. Maybe C CGIs were replaced with Perl and now Perl maybe being replaced with java centric frameworks such as Struts. But my friends believe me Struts will be replaced too. The honetmoon period will end sooner or later. There are already alternatives and loud crys for XML situps. Look at Ruby on Rails for instance. Isn't it directly targets struts? It's very perlish both in the sense that it simply rejects app server and endorses a FastCGI method, and hey, it has regex built into the syntax.

  
  To cut the long story short, every language had its peeks so did perl. What is important remains how perl community will proceed in this time of maturity. Come on admit that not a lot of perl developers are writing CGI guestbooks. Template engines are more useful for creating invoices and exporting them to PDF for instance, or generating daily newspaper static web sites that run on web farms.

  • You might be right, you might be wrong
    2005-08-27 05:18:12 DarrenTarbard [Reply]
    
    Perl will fade without nice IDEs, it is sad but true.
    Without new blood the perl developer community will fade somewhat. Imagine a developer fresh out of university - they have got used to not having to worry about spelling method names properly, remembering which methods a given class has, real time error checking (again mainly for those typos), not to mention the powerful refactoring tools as mentioned in this article.
    It must seem to these people that coding in Perl is a backwards step and as such they are much less likely to try it out.

    
    I am a bit concerned if this issue can ever be addressed, I have seen the Perl 6 discussion stating it might not be possible to parse Perl 6 code without actually executing it. Will IDEs with features mentioned in this articles ever be possible to create for Perl? Java's rigid syntax makes things like getting a list of methods simple, but in Perl it is already impossible (e.g use of AUTOLOAD).

    • You might be right, you might be wrong
      2005-08-27 08:14:00 matisse@matisse.net [Reply]
      
      > Will IDEs with features mentioned in this articles ever be possible to create for Perl?
      I believe that yes, they will be. Many are possible right now - if we accept "good enough" -- for example, the EPIC plugin for Eclipse can oftne (not always!) figure out which methods are available on an object, and I think that "guessing" could be improved.

      
      The Perl community is always inventive -- I am hoping we invent our way to better tools!

  • You might be right, you might be wrong
    2005-08-26 11:25:39 matisse@matisse.net [Reply]
    
    By the way - Damian Conway's new book, "Perl Best Practices" is another small step in perhaps improving the maintainability of Perl code:

    
    http://www.oreilly.com/catalog/perlbp/index.html?CMP=ILL-4GV796923290

  • You might be right, you might be wrong
    2005-08-26 07:11:38 matisse@matisse.net [Reply]
    
    I agree with a great deal of what you've written.

    
    Perhaps you can put my article in the category of Perl stuff that doies in fact argue for easier-to-understand code, etc. In my own development work that is certainly something I strive for - not the "coolest code" but the best combnation of effective and maintainable.

    
    The cultural factors you mentin are probably among the most important factors in how Perl has and will develop. Of course this conversation is part of Perl culture too, so maybe we will help shift things just a lttle.

    • You might be right, you might be wrong
      2005-08-28 05:46:20 Oyku [Reply]
      
      Thanks. I'd like to share my experience. I've already made my developers read the article. Their reaction is mixed. Some reacted that IDE and Perl won't come together even so how am I expected to debug a portion of a complex app on a poor GPRS connection when all I have is vi on my Zaurus. Some didn't even react but got EPIC and eclipse installed on their machine and started to ask questions on troubleshooting epic, which I already gave up on my powerbook running Tiger when I could not get debugger to start at all.

      
      My point is, being able to *hack* with perl is one of the input for the process of making money out of the computer. It is an inherent property of Perl and the community itself. Also I have to admit that te phrase "debugger? what's a debugger" is numb. If you are pro, you have to be able to manage one thing. Time. Debugger saves time and make me earn more in less. One sidenote for that. I had to hack and debug every single perl debugger I have used.

      
      It's a common experience for me to see it in the face of senior salesmen after presenting their ultra-super-dooper application server, and getting the response that "thanks but no thanks. we already are doing the stuff you mentioned on Linux with Perl and guess what, we are doing more than that on a far less number of servers you can image". Hidden mesage is "Go do your homework and get your software's feet wet before coming to tell us on efficieency, portability and managability. Reading the internal marketing documents is not enough"

      
      

      
      

      
      
      

      • You might be right, you might be wrong
        2005-09-06 10:00:55 matisse@matisse.net [Reply]
        
        I have used thge debugger in EPIC, but so far only in Panther - I will try it in Tiger within the next week or two. Havce you posted a bug report?
      • You might be right, you might be wrong
        2005-08-29 09:27:38 tooper [Reply]
        
        Just have a look et Eric3 (http://www.die-offenbachs.de/detlev/eric3.html) for Python...
        

• Re: Perl Needs Better Tools
  2005-08-25 23:50:20 ejain [Reply]
  
  Part of the problem is that the "flexible, forgiving, malleable, and dynamic" nature of Perl makes it hard to create the kind of tools you are calling for. Content assist for a typed language such as Java is straightforward. With Perl, not only do you need to guess the methods that might be available on an object passed into a subroutine, but some methods may even only be generated at run time! It is easy to do syntax highlighting for Java, which has a (relatively) simple grammar. There are few editors that manage to parse Perl code correctly...
  • Re: Perl Needs Better Tools
    2005-08-26 07:15:43 matisse@matisse.net [Reply]
    
    Everything you said is true, I think.

    
    It is because of the issue you describe that I find a lot of value in solutions like EPIC and the PPI module (see http://www.perl.com/pub/a/2005/06/09/ppi.html)

    
    ((By the way - I am going to be offline for over a week starting Saturday, so my silence during that time should not be taken as a lack of desire to respond to people here, just a cooincidence of timing with when the article was published. --ME))