I just tried two environments (vim and emacs) extended with Perl and felt flat on my face. Clearly these extensions are not maintained/used. Why?

Side note: See below for a more detail story about my exeriences with emacs and vim Perl extensions

In these two cases, the explanation may be simple. Elisp is the accepted extension emacs language . Vim also comes with its own extension language even if it supports many other extension languages. Also you can do a lot by selecting a region and running it thru Perl so Perl as an extension language is unnecessary but for the more ambitious undertakings.

grinder was talking about using Perl and Postgres. Reading the pg doc, I see that Perl can be embedded in pg. Does anyone use it? What does it buy (say, compared to access pg with DBI)?

This led me to general thoughts about Perl as an extension language:

• Is perl5 too complex as an extension language? May be when people learn a tool, they don't want to learn a too complex language to extend it. I am not talking of the complexity of XS here, but about what makes an extension language popular. late addition: Paul Prescod has a point in its otherwise very good page advocating against Perl. He says in substance that the power of a natural-like language is offset by the cost of learning it. I would add that a natural language comes with a nurturing environment (we speak of mother-tongue, do we?) while perl and most open-source languages don't. But IDEs can help here .
• Is there some "physical" law here. Being a full fledged language, has Perl such a mass that it cannot be a satellite but has to be the object around which the satellites move (thanks to DBI, XML::Parser...)?
  
• What do you think that parrot and Perl6 will change in these cosmologic landscape. May be that whole environments will be built around Perl6/parrot instead having it added as an afterthought or gluing to them?
• BTW: What are the successful example of environments empowered by Perl5 as an extension language(gimp?).

For the curious, more about my experiences with Perl extensions of emacs and vim.

I switched a long time ago (circa 90) to emacs from vi because I could do everything in one emacs session (besides editing various files in different buffers, having different shell sessions, debugging using perldb or gdb...) but I always sincerely hate lisp syntax so I dislike very much to have to mess with emacs configuration files. Another PITA: emacs has been extended by so many people with extension following different conventions

Anyway, John Tobey wrote perlmacs so that emacs is extendable using Perl. But it does not work with recent version of emacs even if Mandrake dutifully distributes the emacs-EPL package.

I decided to look back at vi; or more precisely to its vim avatar. Except for the lack a of a decent pager and the ability to run shell or debugger. It seems pretty nifty.

Better, it supports many extensions languages including Perl. It is documented right in the nice hyperlinked system. So I tried it:

: perl  $main::curwin

This is supposed to access the variable for the current window. I got a segmentation fault.

-- stefp

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.