Re: Re: Re: How would you fix Java?

[IlyaM]

Ability to mix easily procedural, OO and functional styles of programming.

How important is this to you and are you looking for something like Python's approach to this? Do you think it offers that much more usability than just throwing everything in a class?

Frankly I'm Python ignorant (I have only walked through Python tutorial once and it was very long time ago so I forgot everything anyway :( ). Can you tell how it compares with Perl in this aspect?

Obviously a library of reusable compontents like CPAN.

Is it just the more specialized modules you find lacking from Java (the Finance::Quote type modules), or is it problems with included libraries (including lack of api choices)?

I like that fact that there is central repository of reusable tested Perl components which are easy to install. In other languages you are either stuck with core libraries or you have to hunt for other libraries over all Internet. This discourages code reuse (how many times have you heard "I don't want to use this library but rather reinvent it myself so my users are not forced to deal with many external dependanices"). One negative side is that I think in other language communities programmers contribute less in reusable libraries. Another is that you see a lot of code going in core (think PHP, think Java) making it bloated.

--
Ilya Martynov, [e-mail]
CTO IPonWEB (UK) Ltd
Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
Personal website - http://martynov.org

[arturo]

I'm not sure what you mean by talking about stuff going into the core with Java as "bloat," unless you're referring to raw download size of the JRE. It's by no means the same situation as with PHP, because Java has packages, while PHP does not. It can be quite maddening for quite a long time to figure out how one accesses one's preferred database in PHP, for example, since mysql_* and pg_* are both in the core (well, if you compile them in, they are).

You can write a reasonably functional (if verbose) program in Java without using anything outside of the java.lang package (although, heh, you can't process a file ...); OTOH, if you need to process XML and you have JDK 1.4 or later, or you want to serialize some expensive-to-construct objects in Java, you can do it without having to download anything new. Yes, the base API documentation is huge, but you can do a heck of a lot with it. It's kinda like shipping a lot of CPAN in the distribution.

It's by no means an official central Java repository of modules, and it's also by no means as comprehensive as CPAN, but the Apache Jakarta project has been developing reusable components, some of which are quite nice. I still prefer CPAN, but my point is that the Java picture is not as bleak as it is sometimes made out to be. Of course, for most textual processing, I still prefer to use Perl, but my view of Java is not as jaundiced as it used to be.

If not P, what? Q maybe?
"Sidney Morgenbesser"

[IlyaM]

I probably should not use word "bloat", I'd better say lack of modularization (on the other hand don't they come together often?). It irritates me as hell that when, say, I need a certain feature of Postgres API I have to upgrade to a new version of PHP. I must admit I'm not doing Java programming for quite long time but your phrase if you need to process XML and you have JDK 1.4 or later, or you want to serialize some expensive-to-construct objects in Java, you can do it without having to download anything new sounds like indication of same problem.

CPAN frees me from dependancy on core libs. I don't have to wait for a new release of Perl to get new features and/or bug fixes, I don't have to upgrade to a new release of Perl to use features and/or bug fixes. CPAN makes me free from release schedule for Perl.

--
Ilya Martynov, [e-mail]
CTO IPonWEB (UK) Ltd
Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
Personal website - http://martynov.org

[oylee]

It appears to my clouded lens that Perl's lack of strong typing and contract enforcement has allowed it to be as backwards-compatible as it is (arguably moreso than Java), although it seems you hold Java to a double standard since there are quite a few modules out there that require, for whatever reasons, versions of Perl more recent than Perl 1.0 (if it ever existed) - CPAN, great as it is, doesn't solve the difficulty of adding new language features and having new libraries dependent on those new language features be backwards compatible. Are you going to make all your programs Perl 4 compliant? How about Perl 3?

One of the things that's seemed to be an everpresent problem in CS is that designing for the future is hard. You just can't foresee all the problems that might crop up. YouArentGonnaNeedIt and YouAreGonnaNeedIt are always ridin up and down that seesaw of long-term planning, and I think it's unreasonable to expect to that language specifications shouldn't also evolve with the programmers using those specifications. It'd be great for them to get it right the first time, but how often does that happen? Why do notions like refactoring have books written about them?

I'd argue that writing programs in a 'foolproof' way is hard to do in Perl, just as it is in Java or any other language. However, the addition of type safety is sometimes a GoodThing, since it mitigates the risk of client code (code using any given API) screwing up by having arbitrary functions executing arbitrary things. I want to idiot-proof my code, not because I think other people are idiots, but because I know I _am_ an idiot, and I'll screw things up every chance I can get.

Don't get me wrong, I really like perl a lot (and am still learning!), I was raised on Scheme and C/C++, but I also respect Java's place in the PL hierarchy (although they should have at least handled recursive tail calls properly... that's a different story though ;). It's just that having non-static typing means that you can't make as strong a guarantee of what you can or can't do with a symbolic name. It means that my subroutine can return an integer half the time, or another subroutine as a first class value the other half of the time. It means that if in my program, if I accidentally re-assign my $shared variable somewhere (even with lexical scoping), $shared might be a hash reference instead of an array reference. Of course, I can add a check at runtime using ref(), but sometimes it's nicer to have that check made for me at compile-time so I don't have to wait and write a unit test to realize that I'm bungling something. Perl is great for flexibility, brevity, expressiveness-in-shortest-number-of-lines, and, in general, becoming a very 'natural' and idiomatic language to speak in, but but it also provides a lot of ways for me or the person coding to my framework to screw up by localizing the wrong symbolic name at the wrong time or whatever.
To me, one of the biggest strengths of Java is its ability to enforce contract-based programming. You can ensure that implementors and client-developers follow the contract that you lay down to some stronger degree than most other languages... for instance, (example shamelessly lifted from the way JUnit does things, basically an example of the Template Method from the GoF):

public abstract class Goo implements Gooable {
   protected abstract void doSomethingThatRequiresSetup();

   public void doSomething() {
      setUp();
      doSomethingThatRequiresSetup();
      tearDown();
   }


   public void setUp() {
      ... initialize network connections and blah blah blah
   }

   public void tearDown() {
      ... close network connections and any open files
   }
}

Granted, this contract is still a little weak, since we have no guarantees as to what doSomethingThatRequiresSetup() does, but we can guarantee that the initialization and finalization steps occur, if J. Random Implementor does decide to extend the Goo class and implement the doSomethingThatRequiresSetup() method. Of course, it is still possible to screw this guarantee up by spuriously subclassing the Goo class and overriding the behavior of doSomething(), or directly invoking doSomethingThatRequiresSetup(). As always, one should always favor composition and delegation to inheritance, but that's just part of the lingo. It's like getting slapped here for not use strict; or to turn warnings off or to not untaint user input that's going to be inserted into invocations of system() or exec() (or even sending user input to system or exec commands for that matter).

Besides, no language holds a candle up to Scheme ;). Where else can you smash your brains out with the power of hygienic macros and call/cc? Not until continuations become first class values in Perl 6 at least :).

wow, that's a lotta blathering. apologies for the rambling - flames/corrections/thinly-veiled insults are welcome!

Allen

[arturo]

I'm replying here at IlyaM's request (we've had a /msg discussion going for a while). I think the charge of lack of modularity in Java is way off the mark, and he thought I should put my thoughts into a post.

Extending the functionality of Java is as simple as getting the relevant .jar file and putting it on your application's classpath. If you want to make certain functionality available to all your applications (à la default @INC in Perl) you can have that, too, by putting the relevant jars in the system's extension directory, although the mechanism doesn't lay out directories à la @INC. In the most recent versions of the JDK, you can even override some of the packages in the java.* and javax.* hierarchies simply by putting jars in the appropriate directory. And, of course, you can set your classpath and other system properties however you want when you execute java, so all this stuff is flexible.

Combined with Java's (mostly) OO roots (AOL keyword: "code reuse"), in particular the ability to define interface classes and different implementations thereof, this makes for mad modularity and upgradeability, even extending in some cases to classes in the core of the language. I'm not saying that Perl doesn't have these features (you can fake the ones that aren't there by default), but that to say Java doesn't have them is based on a serious misconception.

My earlier comment merely referred to the fact that JDK 1.4 implements the JAXP specification ( standardized API for XML processing ) "out of the box", but you had that with earlier versions of the JDK simply by downloading the relevant jars and placing them on your classpath¹. Java is, and has since the introduction of jars, been highly modular and upgradeable, outside of the core classes. There is still no CPAN equivalent.

¹ JDK 1.4 also makes regexps available out of the box. Wow, it only took about 6 years after Perl5 =)

If not P, what? Q maybe?
"Sidney Morgenbesser"

[Anonymous Monk]

Frankly I'm Python ignorant

I'm fairly Perl-OO ignorant, (that's why I used Python as an example ;-) but I'm pretty sure they perform identically in respect to your comment. What I meant by the Python approach was that, in addition to the OO module approach, you can also just have a file with a bunch of subroutines and import them directly from that.

I strongly agree with your last paragraph as well, especially about causing unnecessary bloat in the core.