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?).
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::curwinThis is supposed to access the variable for the current window. I got a segmentation fault.
-- stefp