Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Embperl Abandonment Issues

by Stegalex (Chaplain)
on Sep 05, 2008 at 14:16 UTC ( #709282=perlquestion: print w/replies, xml ) Need Help??

Stegalex has asked for the wisdom of the Perl Monks concerning the following question:

It now seems abundantly clear that Embperl development/discussion has become very dormant. Perhaps it has been abandoned. I don't wish to criticize Gerald for abandoning this project, rather, I would like to thank him for his fine work. I have been using Embperl professionally since the beginning and am very grateful to him.

Now I am at a crossroads of sorts - I have to choose between continuing to develop in Embperl or migrating my code (lots of it) to another product that is actively supported. I think it's hard for me to justify continuing Embperl development to my client given that the product lacks:
  • support
  • ample documentation
  • an active community (a la PHP) (and no, I do not like or advocate PHP)
So my question to the community is this: which language/product should I use instead of Embperl/Embperl Object? Here are my priorities:
  • Camelness: I would prefer to stay under the Perl umbrella if possible. I am not unwilling to learn other languages if necessary but Perl rocks!
  • Power: Properly implemented, Embperl/Embperl Object is VERY powerful and productive. I don't want to downgrade to an inferior product
  • Open Source: of course
  • Continuity: I need to choose a product that is not on it's way to retirement
  • Documentation: Something well documented (perhaps supported by an O'Reilly book).
  • Community: There should be an active community with active discussion boards and more than one person enhancing/maintaining the product
  • Linux: Microsoft is out of the question.

Replies are listed 'Best First'.
Re: Embperl Abandonment Issues
by moritz (Cardinal) on Sep 05, 2008 at 14:26 UTC
    I'm not all the familiar with Embperl or Mason, so please take this with a grain of salt, but I think that Mason might be worth looking.

    It seems to meet your criteria, and there's even a book.

Re: Embperl Abandonment Issues
by perrin (Chancellor) on Sep 05, 2008 at 14:32 UTC
    If you want to stay with the inline-perl approach of Embperl, your best bet is Mason. It's good enough for Amazon.com and has a large base of users.
      I may be gazing at my navel a little too closely, but you used the term "inline-perl approach". Besides CGI, what would be some examples of approaches that are not "inline-perl approaches"?

      I am truly seeking the wisest choice of an Apache handler to use for the next 5 years.

      Thanks so much for your help!
        It's a question of how you organize things. See my templating article for a discussion about the options.
        Besides CGI, what would be some examples of approaches that are not "inline-perl approaches"?
        Unless I misunderstood perrin, I think s/he may have just meant that not all templating approaches use Perl for their 'embedded' languages. Template::Toolkit, for example, has its own little language. (I couldn't tell, because I'm not familiar enough with Embperl, whether you're looking for a templating solution or something else, but the suggestion of Mason makes me think that at least what you want to do is within TT's bailiwick.)
      Seriously? Amazon is Mason? The whole thing or just a couple of bits? Wow!

        According to the Mason wiki everything (at least as of about a year ago).

        And seconded the recommendation for Mason as an alternative. You might also look into Catalyst which I believe supports Mason and TT as view engines (still just starting to look into it myself).

        The cake is a lie.
        The cake is a lie.
        The cake is a lie.

        The front-end web stuff is all Mason.
        I've started reading the O'Reilly book on Mason & wondered about the whole Amazon/Mason thing. So go to http://www.amazon.com/jobs and search for Mason! (Spoiler: it is definitely there!)
      I can confirm that (almost) all frontend amazon is mason.
Re: Embperl Abandonment Issues
by derby (Abbot) on Sep 05, 2008 at 15:44 UTC

    I'm currently at the same crossroads but my priorities are a bit different. I definitely do not want something as powerful as Embperl (or Mason or Template Toolkit) because I found it way too easy to break MVC principles. Not that it's always bad to break MVC but I still prefer my templates to be just HTML. At the moment, HTML::Template is filling the bill rather nicely (but then again it should since I prefer CGI::Application).

    -derby
      I definitely do not want something as powerful as Embperl (or Mason or Template Toolkit) because I found it way too easy to break MVC principles.
      I agree. I have used HTML::Mason extensively over the last 4 years, and I really like the power and flexibility it provides. But these strengths can also become weaknesses, and it can be very easy for inexperienced developers to break MVC principles without even knowing it.
      --
      No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]

      I personally believe you won't be interested at all since it is by definition even more poweful and complex, but since nobody seems to have mentioned it yet, there's also Template::Alloy, (I've never used it, but ever since I heard of it for the first time, I liked the idea!) by a fellow monk of ours, whose PM handle unfortunately I can't remember ATM: it gives convenient access to several templating systems mini-languages, so one can just choose the one she likes best for any particular task, being allowed to mix them freely.

      (Sorry for replying so late!)

      --
      If you can't understand the incipit, then please check the IPB Campaign.
Re: Embperl Abandonment Issues
by talexb (Chancellor) on Sep 05, 2008 at 19:54 UTC

    I'm a fan of Template Toolkit -- very powerful, decent documentation, still actively under development.

    But it always depends on what your comfort level is with all of the bits. I quite like CGI::Application and have developed web apps with it, but there are lots of other options -- Maypole, Catalyst, and so forth. Just using Template Toolkit by itself doesn't tie you into an MVC framework -- you can just use a bunch of CGIs with TT2 and that works fine.

    For each choice you look at, find out what other underlying technologies you'll have to get familiar with -- I hacked away at one of the frameworks but because I couldn't get the hang of one of the underlying bits, I abandoned it.

    Yeah, and do stick with Perl -- I think this language has legs. ;)

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: Embperl Abandonment Issues
by aufflick (Deacon) on Sep 06, 2008 at 02:15 UTC
    I second (or third) Mason - it's awesome. However it is tricky to use outside a web context if you currently do things like pre-building static html trees. That sort of thing is easy with template toolkit.

    I dislike Template Toolkit in general because I dislike having to use a new language (the TT2 templating language) when a perfectly good one (Perl) is available and is more powerful. You can break out to Perl in TT2, but then what's the point?

    Your other option is to keep using embperl. If it does what you want, why change? If you need a particular new feature, I'm sure the CPAN masters will be more than happy to grant you joint custodianship of the modules.

Re: Embperl Abandonment Issues
by CountZero (Bishop) on Sep 06, 2008 at 06:35 UTC
    When browsing CPAN, I found Apache::ASP and that module allows you to embed Perl code in your webpage, but it runs only on Apache-servers. I'm not using it (strictly Catalyst and Template::Toolkit here) so I cannot vouch for its quality, but it doesn't look bad.

    If you only need to execute Perl-code in your webpage, Template::Toolkit allows this through its "PERL" and "RAWPERL" directives.

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Re: Embperl Abandonment Issues
by Anonymous Monk on Sep 06, 2008 at 10:22 UTC
    Have you considered taking over development of Embperl?
      That would be bad for Embperl. I am not as smart as Gerald Richter.
        Stegalex:

        Modesty doesn't become you ... it looks like you need to brush up on your perl skills--after all, isn't hubris one of our core virtues?

        </joke>

        ...roboticus
Re: Embperl Abandonment Issues
by Anonymous Monk on Sep 06, 2008 at 10:16 UTC
Re: Embperl Abandonment Issues
by waswas-fng (Curate) on Sep 08, 2008 at 23:08 UTC
    I would take a look at Catalyst. It supports both TT and Mason, is MVC, has a very large user group, active dev, and is on its way to get Moosified.


    -Waswas
      UPDATE: Someone got a hold of Gerald (by phone). He claims that there are some product updates in the works. Here's the start of the thread: http://www2.ecos.de/~mailarc/embperl/2008-09/msg00000.html. IMHO even it the product hasn't been "abandoned", I don't think I can continue to depend on Embperl unless there is more than just one person maintaining it. Perhaps Gerald should take the approach Larry Wall has taken with Perl - he delegates some of the work and retains God-like veto power.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://709282]
Approved by Arunbear
Front-paged by grinder
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (4)
As of 2022-12-09 03:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?