[nSLUG] perl and web sites

Robin Murray nibor.yarrum at gmail.com
Fri Feb 28 00:45:05 AST 2014

I certainly had heard of jruby but had quite forgotten about it. It seems
like a bizarre solution to the ruby performance problem but I guess when
you boil it down it's not unlike .net.

I've been doing a fair amount of java dev on eclipse for an android app, as
well as perl for the web site. Going back and forth over the months has
given me a pretty good perspective on both of them. Like all decisions
around what language or framework to use, there are pros and cons to each,
there is no 'one size fits all', and anyone that tries to insist on that is
just inviting a language flame war, something I grew weary of, and stopped
engaging in, back in the 90s.

I really VERY much appreciate the refactoring tool that eclipse gives me, I
use it all the time and I must say even today I usually smile when I use
it. What a hell of a production booster! However, overall, I find that java
tries so hard to keep you out of your own way that it's more often than not
a battle with the language to get things done quickly, contrasted with
perl's incredibly easy attitude - it's perfectly happy to let you shoot
yourself in your own foot if you want to do so. Autovivification and
data::dumper(::concise!) are incredible production boosters for perl, which
rivals eclipse's refactoring tool. I can create many levels of nested
hashes/arrays in just a few lines of perl code, and can see how it's
structured at a glance. Java is an exercise in frustration trying to
accomplish the same thing, due to the stringent type checking requirements.

I would also submit that oop can be taken to extremes, replacing 10,000
functional calls with 10,000 objects in a complex hierarchy that you need a
gps to navigate through. The java libraries can be very daunting to someone
new. Simply doing stream i/o can drive you nuts in java what with all the
try/catch/finally/try/catch and this stream attaching to that stream, when
all I want to do is read a damn file. I guess apache commons has some good
ways around this, but last time I looked it wasn't available on android.

Overall, I enjoy programming in both languages, but really, I always feel
relief when I get back to perl, I feel more liberated and know that I will
get some real progress without worrying too much about the language itself.
It takes a while to get to that point, but when you do you can crank out
lots of reliable code. Params;:validate helps to somewhat mitigate the lack
of static typing, its more work to implement but becomes automatic once
you've used it enough.

Anyway, my $.02, thanks for everyone's thoughts thus far.

Robin Murray
Hatchet Lake,
Nova Scotia

On Thu, Feb 27, 2014 at 10:54 PM, Oliver Doepner <odoepner at gmail.com> wrote:

> I have developed Rails apps and deployed them to Apache Tomcat Java web
> container.
> The Ruby implementation was JRuby.
> This was for a large Canadian oil&gas corporation who uses this as their
> default framework for in-house web applications.
> The performance of JRuby is quite good and benefits from all the JVM
> performance goodies like JIT compilation and automatic runtime
> optimizations.
> There are also dedicated JRuby/Rails containers that are more optimized
> than Tomcat. See links [1] [2] below.
> However, I would recommend neither Ruby/Rails nor Perl for anything that
> goes beyond a simple CRUD webapp.
> I am a big fan of statically-typed languages that allow powerful and
> reliable tooling, i.e. an IDE with advanced refactoring support, etc.
> I usually use IntelliJ Community Edition and program in pure Java.
> For Java webapps, Eclipse or Netbeans are decent IDEs. There are plenty of
> Java web frameworks available. I would probably go with GWT when its
> client-side heavy and JSF 2.x / PrimeFaces when it's more of a server-side
> application. JPA is the standard Java API for accessing database objects,
> CDI is used for wiring it all up.
> So to me the Perl vs Ruby question is like a wooden bicycle vs plastic
> bicycle choice when you actually need a metal frame. :o)
> No offense.
> Cheers
> Oliver
> [1] http://stackoverflow.com/questions/10252293/jruby-performance
> [2]
> http://rockyj.in/2012/09/09/rails_on_ruby_jruby_a_performance_comparison.html
> On Thu, Feb 27, 2014 at 2:56 PM, George N. White III <gnwiii at gmail.com>wrote:
>> On Thu, Feb 27, 2014 at 11:29 AM, Robin Murray <nibor.yarrum at gmail.com>wrote:
>>> I have a web site written in perl/template toolkit with a custom
>>> designed MVC framework (no dancer/catalyst/mojo). This was a design choice
>>> at the outset by a partner.
>>>  [...]
>> But I'm talking through my hat. I don't have experience with rails. Has
>>> anyone here worked with both perl and rails web sites, and can add some
>>> perspective? I'm just looking for points to consider so I can be a bit more
>>> informed.
>> See <http://www.infoq.com/news/2012/10/Ruby-on-Rails-Node-js-LinkedIn>
>> for some links to views on
>> ruby performance issues.   I gather that internationalization was a big
>> issue for choosing platforms, and
>> also a big resource sink (both for development and runtime overhead,
>> memory leaks, etc.) and that
>> rapid growth resulted in compromises to server interconnects, etc.  (We
>> should all have such
>> problems!).
>>  Also, I was wondering how many perl vs ruby programmers are on this
>>> list or people generally know. Is rails really more popular than perl now?
>>> It is hard to find good perl programmers in Halifax, but are ruby
>>> programmers correspondingly falling out of the woodwork there?
>>> Thanks for any thoughts.
>> Sometimes is better to train programmers in house -- good ones can pick
>> up a new language very quickly.
>> --
>> George N. White III <aa056 at chebucto.ns.ca>
>> Head of St. Margarets Bay, Nova Scotia
>> _______________________________________________
>> nSLUG mailing list
>> nSLUG at nslug.ns.ca
>> http://nslug.ns.ca/mailman/listinfo/nslug
> --
> Oliver Doepner
> http://doepner.net/
> _______________________________________________
> nSLUG mailing list
> nSLUG at nslug.ns.ca
> http://nslug.ns.ca/mailman/listinfo/nslug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nslug.ns.ca/pipermail/nslug/attachments/20140227/f85ab1d0/attachment.html>

More information about the nSLUG mailing list