Wednesday, August 23
HTML::Embperl
Perl is a powerful language. And it can be terribly concise. I believe there are competitions that award prizes for the most concise (and most illegible, of course) Perl programs.
Perl also fits a niche. If you are a sysadmin-type scripting sort of person, it is the tool for you. The core language has powerful text-processing facilities; and packages exist for everything else such as database access, XML parsing, whathaveyou.
But if you thinking of programming-in-the-large, forget about it. Object oriented support is available from Perl 5, but the syntax is clumsy and looks tacked on as an afterthought. CGI programming? You are probably better off with PHP.
But I digress.
I recently saw and played with HTML::Embperl, which is a Perl package that lets you insert Perl code snippets in your HTML. Think JSP, but with Perl instead of Java. On the surface, seems like a good thing. The power of Perl directly from your Web pages, without having to worry about having to explicitly program to a CGI interface. But "the surface" often misleads.
Quite frankly, the philosophy (not to mention the syntax) of Embperl made me cringe. Over the years, I have come to appreciate the good things that happen when you separate concerns. Embperl--not unlike carelessly programmed JSP--throws seperation of concerns out the window.
Frameworks are often derided. Frameworks like Struts or Wicket try to separate concerns and this leads to a steep and complex learning curve. Embperl goes in the opposite direction and this makes it tempting for some, especially for smaller projects. But if there is one thing that I have learned, it is this: There *are* no small projects. Even the smallest project has a way of growing and bloating past its original intent.
I would personally put my money on the frameworks.
Perl also fits a niche. If you are a sysadmin-type scripting sort of person, it is the tool for you. The core language has powerful text-processing facilities; and packages exist for everything else such as database access, XML parsing, whathaveyou.
But if you thinking of programming-in-the-large, forget about it. Object oriented support is available from Perl 5, but the syntax is clumsy and looks tacked on as an afterthought. CGI programming? You are probably better off with PHP.
But I digress.
I recently saw and played with HTML::Embperl, which is a Perl package that lets you insert Perl code snippets in your HTML. Think JSP, but with Perl instead of Java. On the surface, seems like a good thing. The power of Perl directly from your Web pages, without having to worry about having to explicitly program to a CGI interface. But "the surface" often misleads.
Quite frankly, the philosophy (not to mention the syntax) of Embperl made me cringe. Over the years, I have come to appreciate the good things that happen when you separate concerns. Embperl--not unlike carelessly programmed JSP--throws seperation of concerns out the window.
Frameworks are often derided. Frameworks like Struts or Wicket try to separate concerns and this leads to a steep and complex learning curve. Embperl goes in the opposite direction and this makes it tempting for some, especially for smaller projects. But if there is one thing that I have learned, it is this: There *are* no small projects. Even the smallest project has a way of growing and bloating past its original intent.
I would personally put my money on the frameworks.
# posted by Sougata : Wednesday, August 23, 2006
Subscribe to Posts [Atom]