in reply to Order in Perl chaos?

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.

Replies are listed 'Best First'.
Re: Re: Order in Perl chaos?
by gildir (Pilgrim) on Apr 19, 2002 at 14:04 UTC
    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]
Re: Re: Order in Perl chaos?
by PodMaster (Abbot) on Aug 24, 2003 at 08:36 UTC
    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]

In Section Meditations