When people attack Perl, they often do it on the basis of readability. That's why I think it's very important to write clean and understandable code when it's for public consumption. It's not so much a Perl vs. Java thing as a general advocacy thing. Note that I didn't say never to use Perl idioms. Just know the difference between idiomatic and confusing.

Maintainable by whom?

Maintainability is an interaction between code, users, and programmers. I think that most "Perl hackers" would prefer to work with eduardo's code. Most people who put Perl on their resumes would prefer what dws produced.

I personally prefer working with people who can figure out things like:

$freq_count{$_}++ for get_words(<>);

# Takes one or more strings, returns all words it finds.
sub get_words {
  map /(\w+(?:'[ts])?)/g, @_;
}
[download]

(Not that I try to abuse people, but should I find something convenient, I like not having to worry about whether the next person can figure that out.)

This is difficult subject to discuss without histrionics. I mentioned on the CB one day that I try to avoid the use of $_ because I think it makes code harder to read, and it was not a very popular notion.

Most of the advanced people on this site would certainly prefer eduardo's version, but my experience has been that many of the people I have to work with every day just don't know Perl well enough to quickly grok stuff like $frequency{$_}++ for (split /\W/, <>) quickly. Because of this, I try to stick to the more standard control structures when I can, and especially avoid stacking up a lot of operations on one line.

I still use things like map, grep, hash slices, and extended regular expressions, but not when something simpler will work with similar efficiency.

First up, you have picked one of perls strongest features to beat one of Java's weakest. If you compared opening a window and displaying a list of selections, I think I know which language would come out ahead.

And now to the debate. The fantastic people who designed perl made some particular choices about the functionality they were going to build into perl. The possibly fantastic people who wrote Java made different choices. Why did the perl designers stop at map and split and not continue to give us commands like 'load_and_split'?

Why did the Java designers stop long before that? I suspect that the Java designers were expecting people to write classes like 'load_and_split' and share them around. But for various reasons the Java community doesn't work like the perl community and so these higher level functions don't get passed around.

If there was a decent string library produced by someone, then java would win in your example because all average java programmers would be using GNU.string.file_load_and_split( FH, "\W") or however you would say it in Java. But we ended up with the great designers somehow and so we have the great functions that do just enough and not too much.

If Dr Conway hadn't found perl you might have found java developers touting their Conway.quantum.superpositions or Wall.array.map functions as being the epitomy of programming.

Perl people seem to delight in commands which are powerful but still somehow clear. Java people seem to love lots of code. But there's no reason why de facto standard class libraries couldn't be generated and passed around

However given the amount of head kicking it takes to get people to use CGI and strict here at the monastery, I imagine you could never get Java developers to use other peoples classes. They'd always be whinging about how they could do it faster or one line less or something. Sounds kinda familiar actually...

____________________
Jeremy
I didn't believe in evil until I dated it.

Hmmm. Another look what I can do in two lines discussion. I've been in quite a few of these so let me toss in something that might be a little different.

no. not quite. the purpose of my original node was not that by a long shot. The purpose of my node was to discuss the relative complexity between VHLLs and more "systems" languages, especially as related to maintenance programming. To be honset, I am a little bit distressed that it was taken to be a "language wars" node, because I can guarantee you, that was *not* the intent.

First up, you have picked one of perls strongest features to beat one of Java's weakest. If you compared opening a window and displaying a list of selections, I think I know which language would come out ahead.

I am afraid I am going to have to disagree with this point. Currently, for a living, I am a maintenance java developer, working on an AWT application, so I do know the inner workings of managing UI's. Quite frankly, I do not find that the AWT or Swing would provide a clearer more concise, easier to maintain example than say, Tk, or Win32, or any of the other modules. I agree that the comparison would not be so drastic, but I think the languages would end up roughly "even." I do however believe that the code that would be required to grab, process, and understand the data that was put in to one of these "lists of selections" would probably be considerably easier in a VHLL. I do not have time right now to work up a small example, however tonight I may create an AWT example, a PerlTK example, and for fun a Python Win32 example... (or I may forget about this and have a fun night away from "the machine" :)

As for everything else, yes... one of the greatest values of Perl *is* the community there is no doubt of that. And one of the greatest things the community has created *is* CPAN. However, the code that I showed used *no* CPAN modules, it used the inner expressiveness of the language. That's the incredible thing... Larry Wall (and those around him) worked very hard to create a language that is *expressive*, not because it has a wonderful class library (although it does), not because we have TheDamian or merlyn or Larry... but because the *language*, as a VHLL, allows me to *express* my program efficiently, without the overwhelming propegation of variables and constructs that create a supporting scaffolding for the *actual* task at hand... a problem that I see *every single day* on production Java code from dozens of different sources.

My node happened to be on Perlmonks, and it happened to show 2 (as tilly showed via maintenance coding) poor lines of Perl code. However, this node could have been at ISETLmonks or PythonMonks or RubyMonks, or any of the hundreds of other languages which allow the programmer the freedom to *express* their software, rather than mechanically dictate and regurgitate it.

However given the amount of head kicking it takes to get people to use CGI and strict here at the monastery, I imagine you could never get Java developers to use other peoples classes. They'd always be whinging about how they could do it faster or one line less or something. Sounds kinda familiar actually...

Well, you're never going to get all people everywhere to agree on the 100% right set of modules... and even when you give them good evidence as to why doing things a certain way leads to better results... sometimes they ignore you. Wouldn't it be nice to have them make these mistakes in a language that when *YOU* go to maintenance code behind them, because their code was flawed (as so many hand rolled solutions have a tendency to be), you can replace their cargo-cultness with a few concise, expressive, ideomatic, and well tested and understood lines of code (probably using a CPAN module or two)? :) I know that's a situation I'd much rather be in.

no. not quite. the purpose of my original node was not that by a long shot. The purpose of my node was to discuss the relative complexity between VHLLs and more "systems" languages, especially as related to maintenance programming. To be honset, I am a little bit distressed that it was taken to be a "language wars" node, because I can guarantee you, that was *not* the intent.

Regardless of your intent, you finished with a value judgement that is likely to annoy people from one camp or the other. Similar effects can be achieved by noting that it takes less keystrokes to do the same command in one text editor or another. You may have presented facts, but making the judgement is the problem.

not because we have TheDamian or merlyn or Larry... but because the *language*, as a VHLL, allows me to *express* my program efficiently,

What? You say that it's not because we have good language designers, it's because we have a good language. Can you explain this further? How do we get a good language without the good language designers?

You appear to be labouring under a heavy confusion about language, syntax and functions. I see no syntactic difference between a core function and one provided by a module.

Now the real point you make in your post is that that nobody at Java had the wit to create the map object, and none of the third party developers had the wit to create it and share it. This is not a feature of VHLLs( finally figured it out - Very High Level Language), this is a difference between having good people working in the community and having the best people. It's also about having the best people bruise egos because certain neophyte coders think that they can roll their own better than the best. Java seems to be full of people who are convinced that they are so good that they don't need anyone elses code.

I keep trying to tell you that if someone with more than half a wit wrote some decent routines for java, your example would be invalid. But the core designers didn't. The third parties didn't, or nobody used them. But you can't differentiate languages because of a core function that they do or don't have. You need to compare things like syntax, which are specific to the language, not functions which are common (Turing complete, remember?)

Yet this is what you do. From the examples you give it would be so easy to write a regexp class, and a hash class, and a map object and then use them in a two line example to show how easy it is to count the words in a file using java. Why doesn't anyone (in Sun or outside Sun) write these classes? Could it be because they lack good designers, like Wall, Schwartz, Conway and the rest? People who are also good at figuring out how far to go with the functions and features, but not further?

What you really meant is that perl doesn't let you make such a horrible mess of code like your java example by giving you core functionality to avoid the mess. But that's not true either. You could have written that routine in 20 lines of really bad perl. It's just because the people who design perl care about it's use and smack bad programmers on the bottom when they show bad work around here. We may be one of the last cliques in society where we value a kick up the bum for bad work over someone telling us how great we are for being able to program.

Well, you're never going to get all people everywhere to agree on the 100% right set of modules...

But you get people claiming that the core modules (or functions, or classes) are more correct than the ones in java. It's some form of hero worship, and it's prevalent everywhere. (This isn't a personal poke. I get told so many times that language x is better than language y because of a function that nobody who programs y thought to write)

. However, this node could have been at ISETLmonks or PythonMonks or RubyMonks, or any of the hundreds of other languages which allow the programmer the freedom to *express* their software, rather than mechanically dictate and regurgitate it.

I could go patch the source code (I flatter myself) for any of these languages (including java) or add modules or classes so that you could do your example in two lines of code in any of them. Good coders will always find ways to use a language to express themselves. We have good coders in our community and we are lucky that they write the example docs as well. I bet Larry Wall could turn that java code into something that really sparkles. Good coders can do that.

____________________
Jeremy
I didn't believe in evil until I dated it.

First up, you have picked one of perls strongest features to beat one of Java's weakest. If you compared opening a window and displaying a list of selections, I think I know which language would come out ahead.

That's a loaded statement and you know it. I have been developing Perl applications to "open a window and display a list of selections" for almost 10 years, and it's really really easy. It requires a web browser and a web connection. Oh, is that what Java tends to require as well? Oh, do my CGI scripts work with more browsers and more OSes? Oops.

And, if you're talking about stand-alone systems, I've got a webpage that acts as its own secure server (though this only works with browsers that understand ActiveX). Oops, did I just beat you again?

*grins*

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

*grin*

A three year lag? This should be fun.

My opinion hasn't really changed, even though I now know a bit more about Java. If you were thinking I was getting partisan about Java - don't. I don't like it much, mainly for the reasons eduardo gave.

But that Java code can be rewritten to look a lot like the Perl code eduardo put up. Use some iterators, a wrapper for the regexes. We aren't exactly a community of people who can write good Java.

The example code that gets released with libraries is usually childlike so everyone can understand it.

The statement I made was loaded to show that Java isn't all bad. In your example, you've picked Perl's best applications area - CGI. CGI.pm existed before Java did, and has been baked well. Possibly you should compare CGI.pm to Tomcat and the like - the comparison might be a little closer.

I don't see that there's anything in Java (or Python, etc) which prevents someone from writing modules that rival Perl's. I do see that the Java community is dedicated to a mediocre level of programming that the perl programmers around here couldn't lower themselves to, if they tried.

I suspect that some of the smarter Java guys where I work could cram that example into a few lines - but they're not the kind of people who release their work, and that ultimately is where we really win.

____________________
Jeremy
I didn't believe in evil until I dated it.