Re: Article idea: mod_perl + JSP
* Greg Cope ([EMAIL PROTECTED]) [001213 11:19]: Appologies if I am butting in - but what you apppear to say here is that you are using JAVA because its sex / marketdriods know of it, yet perl would be the quicker (and hence cheaper solution ?). Surley for this reason you should use perl and persuade the PBH of the cost benefit here ? Perl isn't always the quicker solution, and some would argue that in the big scheme of things it might not even be the cheapest solution. (Perl programmers aren't easy to find, although IMO if you get a smart programmer with good experience he/she can pick it up quickly.) Technology doesn't exist in a vacuum. Every decision we make as programmers doesn't just affect us, particularly in companies where technology is a product. The people who sell the product, the people who support the product, among others -- all these folks have no idea what Perl is. They know what Visual Basic is, they know what Java is (or they think they do). I would love to be able to convince each and every one of these people that Perl is better than Java and we should use it for our web-based projects. That's simply not going to happen. Does that mean they're "marketdroids"? Not necessarily -- they just want to do their jobs. In their view, Perl makes that harder because it's a hurdle (of many) they have to jump when selling the product. This has hit on a point - in that may people choose Java over Perl because its sexier, which becomes self forfilling, unless we (the perl community) persaude people that (mod_)perl is sexy Absolutely. I continue to argue for Perl wherever possible -- I'm in charge of building the intranet, which simply has to work, and I'm using mod_perl (among other things) to do the job. And if people ask me how the site works I'll be able to more effectively evangelize for mod_perl -- I'd be coming from a much different position than if I were simply arguing one language (or technology) against another. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Article idea: mod_perl + JSP
* Gunther Birznieks ([EMAIL PROTECTED]) [001213 19:50]: Well, for me we do Java because I know that there are a couple drivers. 1) I do know of situations were Java is a better/easier tool. 2) For us its not about what is sexy, but what will sell. By the time we talk to a company, the debate of Perl vs Java is over and they've already spent the money on Java infrastructure or training their guys on Java. There is very little commercial benefit for us to tout the benefits of Perl. me-tooyep/me-too One of the things I said earlier is that I think that the time it takes a good Java guy to develop something vs a good Perl guy seems to be about equal in terms of our real experiences (with Java being a bit longer). I think a *really* good Perl person can be faster, but that's just a gut instinct. Most of us mortals don't qualify. And then when it comes to maintenance (handover) the IT staff of the places we deal with are already trained in Java. This is huge, and the toughest thing to do anything about. Look how much money (marketing, conferences, magazines, arm-twisting, etc.) it took for Sun to get on the radar at large corporations, away from (or in addition to) various other languages. Not that money is the only thing -- I think Java is a pretty nice language, which helps acceptance -- but it's a HUGE effort. So I guess it's a matter of degree. I simply do love Perl, but I don't hate Java, I just merely really like it. I guess you could say I cheat on my Perl gf all the time. :) But unlike in life, I don't think a monogamous relationship with my language is actually very healthy. LOL! I think Chris' views may be similar. ... Yep, we basically said the same thing -- although mine was a little more disjointed and less complete :-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Article idea: mod_perl + JSP
On Thu, 14 Dec 2000, Chris Winters wrote: I think a *really* good Perl person can be faster, but that's just a gut instinct. Most of us mortals don't qualify. i used to think that, until i watched a set of really good *engineers* move quickly inside and between c++, java and perl. i no longer believe that language experts are the be all and end all. altho it is nice to have experts in particular skills - like wrapping things with xs.
Re: Article idea: mod_perl + JSP
* Gunther Birznieks ([EMAIL PROTECTED]) [001212 23:53]: Of course, we have a toolkit that we use to develop apps in both Perl and Java which helps, but it's still interesting that business logic for people experienced in the language of their choice isn't that bad in terms of delivery time. Of course, maintenance is another issue. me_tooyup./me_too Ah but have you looked at taglibs? We rarely ever put Java processing on the page itself. I have, but they seemed more complex than was necessary -- particularly for explaining what's what to a graphical designer. I will take your experience to heart, however, and give them a second look :-) ... As for logic in a JSP... Well, the above is an example of something where you need code for the display to work well. I just find it annoying that simple things like loops and such are not as easy as they should be -- Perl (and the Template Toolkit) have trained me well :-) This is part of what initially drew me to WebMacro -- that, plus the author's insistence on a forcible separation between presentation and logic. Leaving the door open to executing Java (or Perl for that matter) within a page means that someone will walk through it and start writing mini-programs in the template because it's "easy", leaving (IMO) an unmaintable mess. The downside of taglibs is that they are complex, however taglibs aren't THAT bad. In our framework every JSP page has at least 3 sets of taglibs (more can be added if they are generic and serve a purpose).. Framework level -- These are our utility taglibs. App level -- These are taglibs that represent app information Page level -- Each JSP page, like it or not, has information that it needs to display specific to itself. Sure -- I tend to break things down like this as well. (The OpenInteract framework does this, although the second and the third tend to blend together.) The nice thing is that our web designer just needs a cheatsheet of taglib and what it does and doesn't have to worry about any other syntax. Again, I'll trust your experience. The main bad thing about this is that when we spec out a project, each "view" on the application we spec out as 2 days instead of 1 day of work in the equivalent Perl because coding the taglibs gets to be a pain. This may seem like overall project delivery time is increased, and it is... a bit. But the majority of a webapp is not necessarily the screens. It's the logic underneath, so our timelines don't really end up growing that much in the scheme of a project. Makes sense. But we do get a better maintenance time because the JSPs are really divorced entirely from Java code allowing a web designer to change things at will without having to worry about an artificial . We almost never embed Java inside a JSP. This is everyone's aim, I think. Finding the right balance and applying it for the vast majority of users in the templating language is very difficult -- although there are probably sufficiently many templating languages to suit you depending on the balance you personally would like to strike :-) There are preprocessors that help with this. But of course, you have to always remember to compile step to include the preprocessor. And then you still have the issue of variable interpolation.. Another thing annoying not to have. :) Yep, I don't want to even go there. I agree. It is quite extensible. We racked our heads long and hard last June when we started full-on development of open source Java apps as to which toolkit to use. In the end, WebMacro and the others have really not caught on in a huge way. JSPs are what a lot of developers we interview these days do know. So it was easier for us to go with the "standard". Also another important point, although good programmers can pick up anything -- and a templating language is on the simpler side of things. However, keep in mind that JSPs are one part of a generic web application. There's still authentication, logging, datasource manipulation, session mgmt, resource locking, handling incoming data (form validation, untaint, transformation), having a framework to implement model,view,controller (eg struts project for Servlets/JSP), etc... Oh, yeah, absolutely. ... A well-specified app is always easier to code regardless of Java or Perl. Over the years I've become more of a fan of seeing the benefits of good software engineering than really thinking a particular language is a silver bullet. Yes -- it really comes down to what a company uses already and what it's being used for. My company is developing from scratch a web-based front end to a Visual Basic/SQL Server application. We could certainly do it faster in Perl (that's just because our Perl background is much stronger than our Java background), but having a Java-based solution is sexier and therefore more marketable than a Perl-based solution. (We are in business to make money, after
Re: Article idea: mod_perl + JSP
Chris Winters wrote: * Gunther Birznieks ([EMAIL PROTECTED]) [001212 23:53]: ... A well-specified app is always easier to code regardless of Java or Perl. Over the years I've become more of a fan of seeing the benefits of good software engineering than really thinking a particular language is a silver bullet. Yes -- it really comes down to what a company uses already and what it's being used for. My company is developing from scratch a web-based front end to a Visual Basic/SQL Server application. We could certainly do it faster in Perl (that's just because our Perl background is much stronger than our Java background), but having a Java-based solution is sexier and therefore more marketable than a Perl-based solution. (We are in business to make money, after all.) Is that a legitimate reason? I think so, but it's certainly a grey area. With that said though, I still love Perl. Me too :-) It's frustrating to be doing something in Java that would take a much shorter time in Perl. But then there are things in Java that are simpler than Perl as well. Appologies if I am butting in - but what you apppear to say here is that you are using JAVA because its sex / marketdriods know of it, yet perl would be the quicker (and hence cheaper solution ?). Surley for this reason you should use perl and persuade the PBH of the cost benefit here ? This has hit on a point - in that may people choose Java over Perl because its sexier, which becomes self forfilling, unless we (the perl community) persaude people that (mod_)perl is sexy Greg Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Article idea: mod_perl + JSP
On Thu, 14 Dec 2000, Gunther Birznieks wrote: So I guess it's a matter of degree. I simply do love Perl, but I don't hate Java, I just merely really like it. I guess you could say I cheat on my Perl gf all the time. :) But unlike in life, I don't think a monogamous relationship with my language is actually very healthy. http://www.polyamory.com/
Re: Article idea: mod_perl + JSP
* Nathan Torkington ([EMAIL PROTECTED]) [001212 22:09]: I think the 100% Java idea has had its day. Microsoft's .NET is a tacit admission that in the real world Microsoft will never own 100% of the market, so let's make things work better together. In that vein, I'd love to see an article on mod_perl and JSP cooperating. That is, a website that uses both and admits that each has its place. I know a lot of people don't like Java (I'm one of them), but mentioning JSP is the foot in the door to getting mindshare back from those folks who now think that Java is the only way. Anyone run such an installation? Anyone want to write about their setup and experiences? Nat Kind of off-topic but not really: I've recently moved from a job with 100% Perl to one with 80% Java / 20% Perl. One of the things I miss most is the Template Toolkit. (There are lots of other things too, but this keeps coming up again and again.) TT is just so amazingly useful and simple enough that I can't believe more people aren't using it. As for Java, I find it really hard to believe that JSP has caught on like it has. The syntax is *amazingly* clunky and leads me to believe that most people who write JSP use WYSIWYG editors to generate the code for them. (Not that there's anything wrong with that, but it gets my hackles up that catering to one group of folks raises the barriers for another.) "Clunky syntax" might seem like a trivial concern, but IMO it's not. It goes right to the heart of usability -- JSP does not make easy things easy. Since you can embed Java into the page, hard things are possible, but the wisdom of doing a lot of processing in the page itself is beyond me. (And generating web-interfaces from servlets is sufficiently painful that we don't need to discuss it -- haven't any of these smart Java people ever heard of heredocs?) In fact, entirely separate frameworks -- from the open source world there's WebMacro (www.webmacro.org) and the WebMacro spin-off Velocity project (jakarta.apache.org/velocity/), among others -- have sprung up to address JSP's deficiencies. But JSP has hooks in various editors (notably Dreamweaver) and has big money (Sun, Oracle, IBM...) behind it. Plus it has a published standard and (despite its syntax) is quite extensible. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Article idea: mod_perl + JSP
On Tue, 12 Dec 2000, Nathan Torkington wrote: In that vein, I'd love to see an article on mod_perl and JSP cooperating. That is, a website that uses both and admits that each has its place. I know a lot of people don't like Java (I'm one of them), but mentioning JSP is the foot in the door to getting mindshare back from those folks who now think that Java is the only way. I'd be surprised if many people do this. Companies that have both probably consider one or the other a legacy system or a totally separate project. The only web project I've heard of where Perl and Java were really being used together on the server side was one that Gunther described, with a mod_perl front-end talking SOAP to a server running application logic in Java. Anyway, I think a better approach for getting attention from Java-minded people is to demonstrate that there are well-designed, carefully engineered sites being built in mod_perl. Most of the articles I see about Perl tend to play up the "quick hack" aspect, and ignore things like OO design, maintainability, and scalability. Those things are the stock in trade of Java articles, as a quick look through Java World will show. - Perrin
Re: Article idea: mod_perl + JSP
Perrin Harkins writes: Anyway, I think a better approach for getting attention from Java-minded people is to demonstrate that there are well-designed, carefully engineered sites being built in mod_perl. Most of the articles I see about Perl tend to play up the "quick hack" aspect, and ignore things like OO design, maintainability, and scalability. Those things are the stock in trade of Java articles, as a quick look through Java World will show. That's an offer of an article? :-) Nat
Re: Article idea: mod_perl + JSP
At 11:11 PM 12/12/2000 -0500, Chris Winters wrote: * Nathan Torkington ([EMAIL PROTECTED]) [001212 22:09]: Anyone run such an installation? Anyone want to write about their setup and experiences? There are projects where we use mod_perl handlers for stuff like prototyping auth but then use servlets/JSPs for the app. But I believe that's too shallow for what Nat wants. We're a small shop of primarily fairly senior developers (at least several years experience in the languages we like to use)... and we've actually found that the Java web and the Perl web projects we've delivered on aren't necessarily THAT far off in project delivery time than some Perl people would have you believe. Of course, we have a toolkit that we use to develop apps in both Perl and Java which helps, but it's still interesting that business logic for people experienced in the language of their choice isn't that bad in terms of delivery time. Of course, maintenance is another issue. I'll probably get some flak for the above statement about Perl vs Java delivery time. :) Kind of off-topic but not really: I've recently moved from a job with 100% Perl to one with 80% Java / 20% Perl. One of the things I miss most is the Template Toolkit. (There are lots of other things too, but this keeps coming up again and again.) TT is just so amazingly useful and simple enough that I can't believe more people aren't using it. As for Java, I find it really hard to believe that JSP has caught on like it has. The syntax is *amazingly* clunky and leads me to believe that most people who write JSP use WYSIWYG editors to generate the code for them. (Not that there's anything wrong with that, but it gets my hackles up that catering to one group of folks raises the barriers for another.) "Clunky syntax" might seem like a trivial concern, but IMO it's not. It goes right to the heart of usability -- JSP does not make easy things easy. Since you can embed Java into the page, hard things are possible, but the wisdom of doing a lot of processing in the page itself is beyond me. Ah but have you looked at taglibs? We rarely ever put Java processing on the page itself. In the history of open source java apps we've developed there was only one algorithm that we chose to kludge in as embedded Java code (and we will eventually remove it)... And it was an algorithm to generate event blocks in the day view of a calendar (ala Outlook) so that multiple appointments can be at the same time but also span different hours (so 3pm to 5pm and another from 3:30pm to 4:00pm) etc.. and the calendar knows how to render itself. Believe me that is a HARD algorithm in any language to get right so that the HTML displays nicely in all browsers. As for logic in a JSP... Well, the above is an example of something where you need code for the display to work well. The downside of taglibs is that they are complex, however taglibs aren't THAT bad. In our framework every JSP page has at least 3 sets of taglibs (more can be added if they are generic and serve a purpose).. Framework level -- These are our utility taglibs. App level -- These are taglibs that represent app information Page level -- Each JSP page, like it or not, has information that it needs to display specific to itself. The nice thing is that our web designer just needs a cheatsheet of taglib and what it does and doesn't have to worry about any other syntax. The main bad thing about this is that when we spec out a project, each "view" on the application we spec out as 2 days instead of 1 day of work in the equivalent Perl because coding the taglibs gets to be a pain. This may seem like overall project delivery time is increased, and it is... a bit. But the majority of a webapp is not necessarily the screens. It's the logic underneath, so our timelines don't really end up growing that much in the scheme of a project. But we do get a better maintenance time because the JSPs are really divorced entirely from Java code allowing a web designer to change things at will without having to worry about an artificial . We almost never embed Java inside a JSP. (And generating web-interfaces from servlets is sufficiently painful that we don't need to discuss it -- haven't any of these smart Java people ever heard of heredocs?) There are preprocessors that help with this. But of course, you have to always remember to compile step to include the preprocessor. And then you still have the issue of variable interpolation.. Another thing annoying not to have. :) In fact, entirely separate frameworks -- from the open source world there's WebMacro (www.webmacro.org) and the WebMacro spin-off Velocity project (jakarta.apache.org/velocity/), among others -- have sprung up to address JSP's deficiencies. But JSP has hooks in various editors (notably Dreamweaver) and has big money (Sun, Oracle, IBM...) behind it. Plus it has a published standard and (despite its syntax) is quite extensible. I
