At 08:46 PM 10/23/2001, Rob Nagler wrote:
> > is easier and more standardized, and well documented. But I "feel" like
> > coding front-end web applications is much easier in Perl where the workflow
> > bits change all the time. For this, I like using SOAP on the backend Java
> > server and SOAP on the front-end Perl.
>
>I don't quite understand the difference between worflow in the front-end and
>workflow in the back-end. They both change. The danger of making one part
>of the system easier to change is that people tend to "cheat". They won't
>put the business logic in the back-end if it takes twice as long.
Yes, people can cheat. But generally the workflow that is most likely to
change is the UI based workflow. UI isn't just about templates, it's a lot
about how you go from one screen to the next, or not.
Actually business logic is a bit of a misnomer because there is plenty of
business logic in the front-end from your choice of fields to the
javascript to the UI workflow.
>To me, the major issue in Perl vs Java is dynamic vs static typing. Building
>large scale systems in Perl is much like building them in Smalltalk or Lisp.
>It takes a certain mindset. The lack of compiled interfaces means you need
>much more discipline (e.g. unit testing). The payoff is big with Perl,
>because
>you can refactor more easily and quickly than in Java.
I don't think refactoring in Perl is necessarily faster. Actually, it can
be quite hard to refactor in Perl as well but for the opposite reason.
If you do not have a strongly typed system, then when you break apart and
rebuild another part of the system, Perl may very well not complain when a
subtle bug comes up because of the fact that it is not strongly typed.
Whereas Java will complain quite often and usually early with compile time
checking.
Compile time checking can definitely be a friend of yours especially when
dealing with large systems. But it's also a friend that's judgemental
(strongly typed) so he's a pain to drag along to a party....
In practice, I still think using a good framework, it's about as long to
develop in Perl as it is in Java for a medium sized system. My only beef I
have with Java and I still have it is that the debugging support is simply
atrocious for web apps. Perl has many more debugging utilities and allows
much greater introspection. When I develop in Java, the only reason it
takes me about 20% longer is that I am restarting the server much more
often than I do in Perl.
>The libraries aren't much an issue. A good example is SOAP. SOAP is
>middleware. It is standardized, documented, and the rest of it. You like
>it for connecting Perl to Java, but why can't it be the other way around?
>If it can be the other way around, why aren't Perl and Java equally adapted
>to building middleware applications?
Java's support for multi-threading makes writing servers feel fairly
trivial with no jumping through IPC::Shared memory stuff hoops to get
shared memory caches and the like.. you just synchronize on global data
structures.
Arguably, an overuse of threads has problems in itself, but in general, I
think it is easier. It is also easier to find programmers who know how to
code middleware that do Java and harder to find people who have coded
middleware that are Perl programmers... so maybe the language would support
it, but there is also a personnel issue.
Later,
Gunther
