I don't really view this as a negative point. All code, up to and maybe even including one-liners, should be stored in a reusable, maintainable form. Also consider what percentage of your code is written in such a short form. Is adding a few extra straightforward lines of code really a huge inconvenience?

The thing is that in Perl it can be both less lines for same thing and it can still be a maintainable code. I recall I read a study that in average number of bugs in programs is proportional to a number of lines and the coefficient doesn't depend too much on language. So less lines means easier to maintain.

Please add your comments as to what you think about Java could be improved.

1. Obviously a library of reusable compontents like CPAN (this is one of reasons why in Perl you can write less code).
2. Ability to mix easily procedural, OO and functional styles of programming (though I doubt it will ever happen).
3. Make it more dynamic language (think runtime generation of code, symbol tables manipulations, very flexiable OO without artficial restrictions like single inheritance, remove static typing - again I doubt it will ever happen as it will be completly different language :).

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

Excellent comments, thank you for your reply :)

A couple questions:

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?

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)?

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, ilya@iponweb.net
CTO IPonWEB (UK) Ltd
Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
Personal website - http://martynov.org

I think the point about CPAN is that there is no single place where you can load up on Java packages. I'm sure with enough time on Google, you could probably find Java equivilents to many popular CPAN modules. In some cases, CPAN modules were even directly inspired by Java packages (Log::Log4perl, for instance). But it's spread all over the Internet instead of one easy-to-search place. And there is no Java equivilent for saying "perl -MCPAN -e 'install Foo::Bar'".

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

I forgot one question, how do you feel about optional static typing? Thanks.

Both thumps up. It is very perlish to support many styles of programming :) I just don't like when I'm forced to program in one specific style. BTW I think we've been promised to have optional static typing in Perl 6.

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

• Early binding for objects is better than late binding
• Objects are universally better than non-objects
• Explicit is better than implicit
• Corporate-control cathedral is better than open-source bazaar (bizarre? {grin})

Any one of these points is a religious argument. Yes, I happen to think the opposite of every one of these. But if you think differently, feel free to use Java in its current form. I won't mind. (I'll still get more done at the end of the day than you do, but that's another story. {grin})

It's not a matter of "fixing" Java, as the thread implies. I think "to each his own". Java is optimized to support the paradigms listed above. And that's perfectly within the right of the developers.

I've shared a panel with James Gosling a few years back, and got to have lunch with him mid-day. He's a nice, well-intentioned guy. (Well, I think writing an Emacs program messed him up for life, but that's another story.) He's created a language that meets his goals, and apparently also strikes a chord in a lot of others. Sound familiar?

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

but if you want to prefer Java over Perl, you must buy into the following paradigms:
...
Objects are universally better than non-objects

I'll disagree with this one. I'd say that in Java you're required to use objects, but that does not mean you're required to like them better. For some the requirement is completely acceptable, others it's a small tradeoff, and others it's a major annoyance. However, you do not have to agree with every design issue to use a language. What you're saying is tantamount to saying that anyone who uses python has to like whitespace restrictions, which I know is false :)

Well, I think writing an Emacs program messed him up for life

Wouldn't you be? I know I would ;-)

I don't know where you read "like". I didn't say you had to like these preferences, just that you buy into them. I don't like the notion of paying taxes, but I understand its purpose, and buy into it.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

I learned Java before i learned Perl. I even got one of those fancy certifications. I thought Java was quite fun and exciting. Then i discovered Perl ...

For the record, i am OO programmer. I was very fortunate to take an OOP class in college which use the GoF book as the textbook. I am not the best OO programmer, but i know me some OO! One of the first projects i bestowed on myself was to port Design Patterns over to Perl. Not only did i find that other folks shared the same idea ... i also found out that Perl doesn't really need them ... and maybe even Design Patterns Aren't!

Hey ... you know what? It does take too many lines to code something simple in Java. That's why you really need an expressive IDE to go along with Java. Those Java programmers who claim they need only vi/emacs probably either type at 90+ wpm or love to waste their time typing. (and for those who hate having to write all of that code just to get some objects up and running ... check out Class::MethodMaker.)

Listen ... Java vs. Perl ... whatever. It's all about mindsets, and unless you learn both, you can't make up your mind which kind of programmer you are. If folks don't like you for chosing one, so be it. And like i said before, noboby says you can't do both ... i tried ... what can i say? Perl spoiled me! :)

besides ... aren't we comparing oranges and apples?

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Thanks for the reply :)

At this point, i really don't think Java can be improved - it's too late

I don't work for Sun, and I doubt they would be interested in what I'd have to say anyways. This isn't really about improving Java. This is an attempt on my behalf to learn more about what are some major complaints about the Java language, and what people feel would be adequate solutions to these perceived problems. I'm not asking this so I can send a few patches to Sun with a get well soon card. I'm asking so I can learn more about the topic. Hope I cleared that up.

besides ... aren't we comparing oranges and apples?

Ah, but the only things I'm trying to compare here are Java, as it exists today, and Java, as it could theoretically exist tomorrow with the improvements people suggest.

You are most welcome. I wouldn't mind Java so much if there were some kind of CJAN. My biggest beef with Java is that programmers end up reinventing wheels that they shouldn't have to. The existing Java classes are only 50% complete - you have to come up with the other half. A good CPAN module, on the other hand, is 90% of your work already written. Java needs a comprehensive archive, but i think that the red tape of bureaucracy is Java/Sun's biggest hurdle.

For example, consider this post from JavaJunkies. Java has a class called StringTokenizer that does a durn good job of tokenizing strings. But why should i have to reinvent a wheel to use that class to parse a CSV file? Why should i have to search the web for a solution that someone else has coded for themselves? Java needs a CJAN. Bad. Either that or they need to hook up with Parrot - then (hopefully) one could simply utilize the power of Perl's CPAN within their Java programs.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

I don't know if it's been pointed out already (too many links to check), but if you haven't seen this post, Re: Re: Perl falls victim to shifting trends(Opinions/Comments From The Other Side) is beyond well worth a read. You will probably also enjoy Perl Functionality in Java.

"It takes too many lines just to write a simple program."

I don't really view this as a negative point.

If I had a nickel for every time I've written "for (i = 0; i < N; i++)" in C I'd be a millionaire.

— Mike Vanier

The real problem is when a considerable portion of your code consists of red tape. Why muddy the clarity of an algorithm with things that the machine can keep track of for itself? Sure, efficiency is occasionally a valid concern to do that - but far less frequently than most people (probably) think.

Verbosity doesn't equate to maintainability. Actually, I find that brevity does far more so; the sad truth is that most people simply can't express themselves both briefly and concisely, so the typical snippet of brief code is much less clear than it could be. This is what the quote Make it possible for programmers to write in English and you will find the programmers cannot write in English refers to.

I guess verbose languages give folks a sense of productivity - "I'm writing a lot of code, so I must be getting a lot of work done, right?". Well, I go to great pains to make my code brief, concise, readable, and maintainable, all at the same time, and in terms of LoC (lines of code) per hour, I'm pretty slow as a result. But I've also found that the resultant code is usually very flexible, without arbitrary limitations (simply because Perl itself does not place any of them - memory size is the limit, is just the most obvious example), and most of the time can be extended in crazy ways very easily.

Esp if you figure in the killer application that is CPAN, the latter point can grow to aweing dimensions.

Personally, I would like to have had first hand experience with Java - both to know what I'm talking about, but also because it's such a highly markettable skill. Well, I got deep into Perl first, which sealed the fate of Java with me. I attacked several Java books trying to get with the swing of things, but I simply never get further than halfway through because it's so boring and longwinded to do even the simplest things. I just can't be bothered dealing with the red tape. It's mindless drone work; I want to concentrate on my algorithm, or generally speaking the task at hand - not the logistics required to make it happen.

Makeshifts last the longest.

I guess verbose languages give folks a sense of productivity - "I'm writing a lot of code, so I must be getting a lot of work done, right?"

I remember a friend telling me about his dismay when learning about the definition of 'work' in physics. I forget the formula he used but it's a measure of how much is accomplished and not the effort expended to accomplish it. If you bring effort into the equations, you're measuring efficiency.

90% of every Perl application is already written. ⇒

dragonchild

It's W = F * d, force multiplied by distance. (Actually, that should be x, a vectorial multiplication, because force has a direction, but whether that is necessary depends on what you are trying to calculate.) You have a point, strictly speaking, but I'm using the term as it's used colloquially.

Makeshifts last the longest.

Asking how one would fix Java is akin to asking how one would fix Perl: you're going to get a lot of opinion, much of it based on personal beliefs (rather than realities) and personal circumstances.

To me, the major difference between the two is scaling of productivity vis-a-vis programmer performance. In Java, it can be easier to get a large team of mid-level programmers to build large systems due to a variety of language features that many in Perl object to:

• Compile-time enforcement of exceptions (which are sometimes stubbed out, negating that benefit)
• Strong typing which alleviates certain classes of errors (adding apples and oranges, for example).
• Cleaner separation of class and instance data and methods
• Signature-based method overloading
• Easy to enforce data encapsulation
• Easy to enforce private methods

All of the above can be handled in Perl, but not as cleanly or easily. Since Perl allows one to play fast and loose with terser code, you can have a smaller team enjoy much greater productivity, but you have to have a higher caliber of programmer who has a more ingrained understanding of why the above might be beneficial.

One problem with Java really is the length of programs. To build those larger systems, you have a need for a larger group of programmers. This means more management, more communication, more strain on resources, etc. As a result, you hit the problem of diminishing marginal productivity much faster.

That's not a clean win for Perl, though. Theoretically, having a smaller number of programmers with the same level of productivity means fewer opportunities for miscommunication, lower strain on resources and rapid development. While this can dramatically reduce costs, how do you identify a Perl programmer who has the necessary ability to be productive in a large team? Simply knowing everything about the language isn't enough. You have to know how to design systems and how to play well with others. These are not trivial tasks and many managers, while great at managing technical people, may not be great at evaluating technical people. One bad Perl programmer can churn out a lot of awful code which can be very expensive to fix, thus negating the benefits of going with Perl.

Many of these issues may be dealt with when Perl 6 is widespread, but we still need to build products now. This means that for a management team investigating alternatives, Java may not be a bad choice. Personally, I don't care for the language, but that's because I work differently.

And some gripes about Java (feel free to correct me as it's been a long time since I used Java):

• Immutable strings limits its suitability for intensive text munging due to the need to repeatedly copy strings and eat up memory.
• Give me print formats, or give me Perl!
• Primitive types were poorly designed and shouldn't have been put into the language in their current incarnations.
• Libraries keep getting moved into the core which are not always fully backwards-compatible.
• I don't need a nine-megabyte "hello world" executable.
• Arrays are too simplistic and force awkward work-arounds (and collections cannot contain primitives!).

Mind you, I can easily come up with a similar list for Perl, but I know Perl's limitations, so they don't bug me as much. Naturally, that should not be taken as a "Perl is better than Java" statement :)

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

Thanks for the reply.

In Java, it can be easier to get a large team of mid-level programmers to build large systems due to a variety of language features that many in Perl object to:

I've noticed this often stated as a positive and as a negative. Does anyone know of a practical application of some sort of middle-ground? What I'm thinking of is basically expanding the choice in areas such as optional typing to a language-wide basis. Maybe throwing a 'use enterpriseDev' (or lemmingDev depending on your opinion) which would enforce some of the points in your first list.

Mind you, I think the lack of oxygen means I've just gone in over my head. Time for a little more research. Thanks for all the excellent responses :)

Java's biggest strength is that its object system is probably the best of any commonly used language (i.e., one that is actually used, not just an academic oddity). The worst thing about Java is that it had better have a great object system, because you're going to be forced to use it no matter what.

Perl5's beggest weakness (IMHO), is that its object system is probably the worst of any commonly used language. It ain't pretty, but it gets the job done. It's not so bad for the applications programmers to use (what difference does it make if you say "$obj->foo()" instead of "obj.foo()"?), but it is an effort in kludginess for anyone developing new classes. Fortunatly, Perl doesn't force you to use its object system. You can write your program in a purely functional or procedural manner, too.

In fact, thanks to CPAN (probably the largest and best example of code reuse ever), many programs can rely on existing classes and therefore are so simple that anything but procedural just gets in the way.

For instance, I wrote CGI::Search for my current employer (who then graciously allowed it to be publically released) in order to simplify the many seperate search scripts on our web site. The example script shown in the synopsis for CGI::Search is a little over 100 lines and contains everything my employer needs for the vast majority of our searches. Most of those lines are just filling in data structures, and the exact size will depend on the complexity of the flat-file database that you're searching and the number of input parameters. Doing these scripts as anything but procedural is just taking up extra space without adding anything. In other words, the script itself is just a little glue to tie user input into an object.

I doubt Java will ever go the route where you can use it without declaring at least one class. It would be too much of a change from where it is now.

Keep in mind that although Java might be great for those really big problems, little problems tend to outnumber the big problems. Perl fills that space quite nicely.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

There have been plenty of fruitful discussions about Java on this site and in other places.

The only issues Java may be suffering from are performance(flaky implementation accross the board), and lack of shrinkwrap products (or so some perlmonger things).

Okay, now that you have had a chance to reflect on your predisposition towards this post based on its title

That sentance epitomizes your own bias/ignorance -- why do you throw out disclaimers? huh Anynymous Coward?

You can't start a fruitful discussion by being obnoxious.

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.6x+5.8x. I take requests. ** The Third rule of perl club is a statement of fact: pod is sexy.

There have been plenty of fruitful discussions about Java on this site

I searched and didn't find any. Could you please point me to them? Note, I'm looking for posts that specifically address perceived problems people have with Java. Thanks.

The only issue Java is suffering from are maybe performance, flaky implementation accross the board, and lack of shrinkwrap products (or so some perlmonger things) .

Seeing as the complaints I was referring to are coming from Perl people, performance and lack of shrinkwrap products are probably of limited concern to them. They are valid when comparing to C/C++ and others though, so thanks for mentioning it. As for flaky implmentation, that isn't really the language specification, but does affect overall impression and, as such, is again a valid point.

why do you throw out disclaimers? huh Anynymous Coward?

Obviously you have a problem with the tone of my post. It was written rather hastily and I didn't carefully analyze how every sentence contributed to the overall impression. My apologies for this, but please try and stick to discussing the main points I brought up if at allpossible, thanks.

As for the disclaimers, I was trying to avoid projecting a bias as to which language I think is better and trying to get others to set aside their biases. I commonly use Perl, Java, Ruby, Python, C, and C++ interchangeably, and enjoy programming in all of them. What I'm trying to do here is get a feel for people's major complaints about Java, as I see a lot of complaints about it on this site.

Thank you, and sorry for any misunderstanding :)

I forgot how fun it can be to scour perlmonks. All of the following links are interesting, and at least half are relevant, and half are missing ;)
• Perl and Java's place in the Universe (and my resume)
• Jakarta Blues: Are Java Wrappers for Perl Practical?
• Cold Fusion
• Perl Vs. C
• Are there any Java texts assuming the user has a perl BG?
• It's official: Java sucks
• Why perl is more OO than C++ or Java...
• Threads vs Forking (Java vs Perl)
• Create type-safe Collections in Java... with Perl
• Java vs. Perl from the CB (no CB log included)
• POD vs. JavaDoc
• Client prefers java, but wants to hear a case for Perl
• Confirming what we already knew
• Griping about Typing
• Choose the most powerful language
• CGI (Perl) vs JSP
• OT: Web Services, Java and .NET
• "Obviously, You Will Need a Java Course..."
• Who is Perl? (Anthropomorphizing Everything)
• Why is it said that Perl does not implement true object orientation?
• On timely destruction?
• Why I hate Perl (discussion)
• Perl speed VS. other languages
• What does "efficient" mean?!?
• What does it take to LEARN Perl?
• Is perl scalable?
• Perl falls victim to shifting trends
• Questions On the Perl VM, Parrot, .Net, and the JVM...
• Perl Advocacy: Sometimes java is bitter...

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.6x+5.8x. I take requests. ** The Third rule of perl club is a statement of fact: pod is sexy.

Many of the threads about Java on this site are started with trollish negative statements about Perl in comparison to Java (often quotes from managers or co-workers). These are bound to draw angry responses. However, if you look at threads along the lines of "what other languages should I learn?" you will find many people recommending Java.

I think most serious programmers should learn Java these days, because there are a lot of interesting ideas being published in articles and books about Java. For example, Martin Fowler's book Patterns of Enterprise Application Architecture has examples in Java.

"You could define your own type-safe wrapper around the container" they say. Right, using cut-and-paste programming. IMHO, until Java gets true support for generic programming it is inferior to both C++ and perl..

Object-oriented programming requires good generic containers for objects. But strong compile-time type checking destroys the ability to create such containers

I disagree. While many popular static type checking languages have poor mechanisms for handling generic containers, some have rather nice ones.

For example I find Eiffel's generic classes elegant and powerful.

It also looks likely that Java will be getting generic types in the nearish future - although I've not spent the time to see whether its a nice implementation (although pretty much anything would be better than the current ghastly casting nonsense).

This isn't to say Java is one of my favourite languages (its not my most hated either :-)

Good point. The best explanation of this I've found is here.

As others have mentioned you can't really "fix" Java. Many "fixes" would involve changing the language so fundamentally it would no longer be Java. You can't "fix" Java if you prefer Perl in the same way you can't "fix" C++ if you prefer Common Lisp. You pick the language that best suits your needs and experience.

That said... if I could change Java I'd want :-)

• Better portability. Yes portability. I still have fewer cross-platform issues with Perl than I do with Java (to be fair Java is a lot better than it was, and improving all the time.)
• Allow multiple inheritance of implementation. There are problems with some implementations of multiple inheritance. I don't think Java's solution (only allow multiple inheritance of interface) is the right one. This won't change since it's a philosophical difference.
• Allow runtime access to the compiler. I miss eval. This won't change.
• Allow overloading of operators. I find this clarifies more than it obscures. Other people disagree. This won't change.
• Addition of closures. Anonymous inner classes are of some use, but I miss the power and conciseness of proper closures.
• Addition of generic classes. The Java Collections framework can be a major pain. Any language that forces me to use a cast to tell it what kind of object is being referenced is broken. Fortunately generic types are being added to the next version of Java.
• Addition of data tainting to the core language. Perl's "don't trust the data" security model is more useful to me than Java's "don't trust the code" model the vast majority of the time.
• Remove primitive types. The whole boolean/Boolean thing is a confusing mess and the language would be better without them. In my opinion of course :-) This won't change.
• Remove compile time checking of exceptions. I find this gets in the way more than it helps. You pay too heavily if you change the exceptions a class throws. Other people disagree. This won't change.
• Some sort of CPAN. 'Nuff said :-)
• A less verbose and more flexible syntax. Java borrows to much from C++ for my tastes. I find it unnecessarily verbose to write. Things that take a few lines of Lisp or Perl take many more lines of Java. Not fixable without creating a new language.
• "Standard" APIs that stay the same for more than a point release. You have to spend so much time figuring out what's core and what's not core for what version of Java, and which minor non-upward compatible API change needs to be dealt with.

Leonid Mamtchenkov

FWIW, for the past three or so years, all of my salary-based programming has been Java. All my productivity-based programming is perl. :)

Here's how I would improve Java...

• Get rid of primatives or ease the conversion to/from wrapper objects. Naw, just get rid of primatives.
• Operator overloading
• Wrapper objects should be mutable

WARNING

The following are semi-lighthearted changes I'd make if I ran the zoo:

• Embed electrial correction devices into all "hammer-weilding" developers. You know, the ones that think, "my language is the One True Language -- other so-called languages are beneath my contempt," and remove their capacity to spread their genes into future generations.
• Brand, scar, or otherwise mutiliate all "paper" certified "developers," and remove their capacity to spread their genes into future generations.
• Outlaw the use of integrated development environments for anyone with less than five years of experience in a given language...

to make someone program in Smalltalk for 5 years without an IDE.

FWIW, for those monks interested, there is a CPAN-esque Java site in the works (and will be done RSN (real soon now)) at www.cjan.org. Although it's currently vapor, it should be interesting to see how it turns out.

C˛

I recall I've seen this site in in the works state about year ago. It definetely looks vapor. Good luck to them anyway.

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