Fellow monks,

Several last months I've been busy with "management" work much more than "real" work and my black thoughts took anvantage of it and sneaked out of dark places of my mind. They whipered all the time "What if you made wrong decision? What if Perl is not the right platform for you?" ... Brrrrrrr

And just when these toughts did thier work, coleague of mine started to talk about Java. I have put aside Java long ago as "too cumbersome" for a skilled programmer, too unfinished, too binding ... I considered Java only to be anohther "right thing to do this year". I'm realy fiery evangelist of object-oriented programming, but Java looked to me that it took object orientation by the wrong end.

... but ...

Now, as I browse through all the ugly Java API acronyms, I've realized that some of these will be quite handy in Perl. Yes, yes, I hear you all, we have CPAN. But, look at the CPAN. Plethora of different modules, different APIs, different ways how to do one single thing. Yes, I still hear you, TIMTOWTDI you say. But, on the other hand, try to imagine a perl newbie that wants to write a simple WWW application. Simple web shop, let's say. First thing that he gets upon is CGI.pm. What kind of good, clean and simple application can one write using CGI.pm except for "hello world"? And still he has many thinks to decide yet. He has to find some session module, some templating system, etc. He starts to modify his ugly application to suit these and make it even uglier. Then he founds his ugly app unmaintanable and starts over, maybe using some other language ...

Look at Java now. First thing a WWW-oriented newbe is pushed to is JSP. Quite nice looking embeded language. He soon learns how to use Java Beans, if he wants to use a directory, he has JNDI, if he wants to process XML he has JAX* APIs. He is keeps his nose pointed in the right direction.

Hey, hey, stop beating me! I'm not telling that everyone here has to covert to Java instantly and to preach Java relegion!
I'm just trying to tell that some definition of Perl APIs and frameworks will be great help for Perl community. For example I would like to see some standard Perl-like way of XML processing. Or some kind of standard Web Application Framework. Or object persistece layer. Note that I do not want to see standard implementation but standard API for which several implementations may exist.

Two years ago there was nothing like object persistence attempts in Perl, so I started to write my own. There was nothing like fine-looking XML-based Web Application Framework. Now I have my own. But this path leads to the binary hell, no one can write its own API for general use. It should be the community work to do.

I suppose that Perl community should start (re)design first, review second and to code last. Some order in the Perl chaos will be welcome, at leas by such a humble monk as me.

Replies are listed 'Best First'.
Re: Order in Perl chaos?
by suaveant (Parson) on Apr 18, 2002 at 17:36 UTC
    While you are pointing out strengths of java... I see flaws. As you list ways to do things in Java, I see but one for each application. In Perl I see many. Things like LWP are an encompassing package that keeps a decent standard within itself, but if I don't like LWP, there are other fish in the sea. I prefer to go with a package because it suits my needs, rather than, "everyone else uses it, and nothing else comes close". Granted if you want to switch later on, it is not always easy, but with good engineering there is always the possiblility of making an application tier to interface with these modules. Since it is perl, it should be easy to do and rapid to develop.

    From my experience with java, I never thought the words 'easy', or 'rapid'... :)

    But then, to each their own, if it weren't for diversification and differing opinions we'd all be programming in something really awful right now :)

                    - Ant
                    - Some of my best work - (1 2 3)

[reply]
      I give you a yes and a no. :)

      From my experience with java, I never thought the words 'easy', or 'rapid'... :)

      Easy? Oh yes. Doing things in java is indeed easy, and as the original poster pointed out, Sun has already written almost anything you need already, and it works on all platforms it is supposed to do. Compare that to the things on CPAN. :) Straightforward syntax, clean interfaces, logical structure, and everything an object. This is easy. You know what you have, and what it can do. Plus the docs for the java api are the best ones ever. Perldoc is close though.

      Rapid? No, you are right. Java is in no way as rapid as perl. Perl is extremely rapid to work in, because it is a scripting language, you just write a few lines of code that says what you want done, and it has a functional interface, where lots of stuff is built in in function calls and even operators. Java is built around the foundation that everything is an object. That is all well and sound for some, but it doesn't make for rapidness when developing. On the other hand, you might win it back when it comes to maintenance and enhancements. Maybe.

      So what do I mainly use? Perl. Always perl. Except when I need to do something complex, or socket/server stuff, or something multithreaded. Then I still turn to java. When those things work well and are easy to use in perl as well... what can I say? Perl is just so much more fun! :)

      You have moved into a dark place.
      It is pitch black. You are likely to be eaten by a grue.
[reply]
Re: Order in Perl chaos?
by andreychek (Parson) on Apr 18, 2002 at 18:57 UTC
    I think that you bring up some very valid points. In fact, there are some others that feel the same way you do :-)

    One such example is a group building P5EE, a Perl 5 Enterprise Environment. They are looking to "promote the development, deployment, and acceptance of Enterprise Systems written in Perl". In doing so, they are attempting to create a "generic" framework for both web and non-web applications. This framework is being designed to have a consistant API, easy to use and install, and powerful. The P5EE slogan is "this is one great way to do it", which perhaps could be considered a subset of TMTOWTDI :-)

    At about the same time P5EE sprung up, and with lachoy's help, I've been working on something called OpenPlugin. It's goal is a bit more specific than P5EE, for better or for worse.

    I work on a web application framework called OpenThought. Compared to other frameworks, it's relatively new, yet it offers a very unique set of features. However, OpenThought still shares many of the needs other application frameworks require. It still utilizes authentication, sessions, datasources (DBI, LDAP, etc), headers, parameters, and so on. With so many modules and frameworks offering full implementations of these already, I thought "why should I go about creating all this again?" Thus was born OpenPlugin. It is designed to have pluggable capabilities. For example, one plugin it offers is a logging facility (appropriatly called "Log" :-). The Log Plugin can't do anything on it's own though, it needs to utilize a driver to tell it how to log. So there are LOG drivers for STDERR, Syslog, and Files. The Param Plugin offers drivers for CGI and Apache. And so on.

    OpenPlugin is being designed as a plugin system any application framework can make use of. This would offer a consistant (or at least similar) interface across application frameworks. Also, instead of each application framework author putting their efforts into an integrated system that only works with their framework, this allows all those authors to work together on one unified system. Or so is my hope :-)

    OpenPlugin, although currently very functional, is still in the early stages of it's existance. And, of course, I'm always looking for a hand :-) OpenPlugin can be downloaded, along with OpenThought, at the OpenThought Website.

    So, to answer your original question, I think that while we continue to enjoy the power of TWTOWTDI, that there are cases where "this is one great way to do it" may very much apply, and we're beginning to see new applications and frameworks looking to make use of consistant API's.
    -Eric
[reply]
Re: Order in Perl chaos?
by perrin (Chancellor) on Apr 18, 2002 at 18:49 UTC
    If you think that there is only one web application framework for Java, you just aren't paying attention. There are hundreds and very little agreement on how the few supposedly standard things (like JSP) should be used. It's really not so different from the Perl side.

    My approach to the problem of "too many ways to do it" has been to write articles covering a common subject that will help newbies find their way to the right CPAN modules.

    By the way, there were several object persistence systems two years ago, and there are tons of them now.

[reply]
Re: Order in Perl chaos?
by dws (Chancellor) on Apr 18, 2002 at 18:20 UTC
    Perl is good for a lot of things, and Java is good for a lot of things. Java is easy to move to from C or C++, and it is a compelling move for anyone who has been burned by C++. Perl doesn't yet have robust application servers, though we're not too far away. But for any application that involves slicing and dicing text, I wouldn't touch Java.

    It's not bad to stick with your core competency if it's working for you. A lot of shops are competent with Java.

[reply]
Re: Order in Perl chaos?
by simon.proctor (Vicar) on Apr 19, 2002 at 08:23 UTC
    Sorry but:
    1. where you see java.util.regex I see Perl regex
    2. where you see java.util.hashmap (etc) I see perl hashes and arrays and the nested versions of such.
    3. where you see AWT and Swing I see TK and Win32::GUI
    4. where you see jdbc and java.sql I see DBI and DBD::*
    5. where you see JNI I see XS and Inline::C
    6. where you see jaxp I see XML::Parser, XML::Simple and XML::Dom
    7. where you see java.net or other IO based package I see IO::*
    8. where you see java.text you realise how annoying string handling is in Java
    9. where you see java.rmi I see SOAP and its platform independance
    10. where you see anything relating to network protocols I see Net::*
    Of course I could go on but I won't. Whilst it may sound nice for a standard API for everything and you implement your own particular method, theres a whole array of mines and fox holes in there. Theres nothing wrong with, for example, creating wrapper or interface objects in your program that abstract any implementation from your application. As the project changes or better modules arise you can change the underlying process without the interface. There you go, a standard interface for your programs and your applications that you will use. But if I want something different I can and the underlying modules from CPAN don't impact on that.

    Ok, the set of packages you get with Java are quite nice and handy but they aren't the be all and end all and in some cases they aren't implemented with speed in mind. After all, Sun has a department setup specifically to opimise all code for Java.

    I think your point is more about choosing a module from CPAN and finding that you chose the wrong one and need to recode to use a new one. Well if you use a wrapper or interface module/class then your problems are reduced.

    Don't get me wrong, I program in Java and like it but theres no holy grail lurking in its design or implementation, just as there isn't in other languages. Academics may argue that there is but they were arguing that about SmallTalk only a few years earlier.
[reply]
      Fellow monk,

      I will hate end up comparing Java and Perl, but at least some reactions:

      6.where you see jaxp I see XML::Parser, XML::Simple and XML::Dom
      To use XML::Parser in clean object oriented way is impossible. My heart screams and my mind blows when I must write something using XML::Parser. API is terrible. Implementation could be fine, but still, it is non-validating parser (AFAIK).
      XML::Dom is just that: DOM. DOM is such an unuseable API that it is not used directly even in cumbersome languages like Java. Why use such a beast in elegant Perl? .. and XML::Simple is too simple. It has no deeper design behind it, or it just looks like. I used XML::Grove and was quite confident with it. Nice simple API, but unsupported and unfinished.
      Now you have four APIs for the same thing, but none of them quite useable.

      8.where you see java.text you realise how annoying string handling is in Java
      Yes, you've got it. But ... how often do you need to process text in Java? Look at your best Perl OO code, how frequently do you use patterns?. Modern language needs good pattern library, there is no longer a need for patterns build into a language, when you use structured data all the time.

      9.where you see java.rmi I see SOAP and its platform independance
      Hah. I worked with SOAP::Lite quite a bit. Try to write your own dispatch routine there. Just try it. You end up with hacking the module because there is no other way. SOAP platform independence is fine, but you still need good (and standard!) languge binding for SOAP. And that is still missing in perl. Look at CORBA, example even older that the mere Web Services concept. You need standard languge binding, or you won't be able to switch ORBs. The same is true for SOAP.

      And now, would you be so kind and point out to me any matured Perl API for one of these:

      • XML Transformation
      • Security services
      • Directory access (not LDAP only, but generic)
      • Enterprise messaging systems
      • Web server API (some kind of generic mod_perl)
      • Threading and synchronization (..wait till perl6?)
      • Perl components (for visual programming)
      Of course I could go on but I won't.

      It just seems to me, that Perl development is getting slower. Perl community is more traditional, more conservative and it doesn't like changes. But changes needs to be done.

[reply]
      Here are some additions to the list ;)

      11. where you see org.wxwindows I see Wx.
      12. where you see Log4j I see Log::Log4Perl

      MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
      I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
      ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]

Back to Meditations