Never been to the site. I do agree that javasoft.com's forums are mostly filled with "write my code for me" kind of stuff, so I don't read that. I'm glad to see PerlMonks source in use, but it's sad for the language that touts Servlets, jsp, etc, to be running a java forum using Perl. Java people dislike Perl (from what I've seen), far more so than Perl folks dislike Java. Why? Usually it's that bias towards "clean OO & readability" and not being able to see the forrest for the trees.

When people have questions on perlmonks, I doubt that people spend more than 10 minutes writing something down on the norm.

Dead on. Perl/Tk questions can take 5 minutes to answer. Whole Perl/Tk apps can take 30 minutes to write. Swing? Those questions and programs can take hours and days! And this is coming from someone who was very good with Java in college.

So, why would a java community have a problem existing? Java is readable, but it is readable like an encyclopedia is readable. That is, you must do a LOT of reading, and a lot of studying. I don't find that conducive to algorithmic thought, and frankly, I find shiny things like functional programming and anonymous data structures to be too elegant to avoid. And you can't really post snippets, since anything non-trivial will take a page or two of code. So you, guess what, just point to online docs. Idioms? No interesting java idioms exist.

Another problem the java community has is the "100% pure java" mentality. Essentially, there is no CJAN (correct me if I'm wrong) full of awesome java jar files to do various tasks, so everyone ends up using the standard API. Innovation is shot, since the first thing you think is "Darn, no function to do that. I guess I'll give up". This is partly because, all of the "sandboxing" and "portability" stuff Java does prevents the API from including functions people actually might want to use, such as (as I was looking for yesterday), a J2SE function to validate OS passwords. Sun avoids such platform specifics like the plague.

In all, I guess I'm saying that the language is so monolithic, a community around it won't contribute to the knowledge of those involved as much. I know, if I really wanted, I could make some popular modules on CPAN and change the way people do work. In java? Unlikely. I don't think there is a place in java for a programmer to evolve, he is only a consumer of Sun API's.

So, all hope of a java community is doomed because of the monolithic nature of the language, we have greater hope for communities around Perl (us!), Lisp, Python, Ruby, and the other more flexible languages that the Java zealots often frown upon. Why? Because they are more fun.

I think you will find a lot of people saying they like java, but very few people being able to say why they like it (in a convincing way). They think Java was the first that invented a way of XYZ (example OOP, clean GUI programming, etc), when in reality, it is not the first, nor is it the best.

Whole Perl/Tk apps can take 30 minutes to write. Swing?

Swing is the same way. If you take a basic problem, and reduce it to a simpler one, solving one allows you to solve the other. That's why it's discouraged to post entire scripts here, no?

This is partly because, all of the "sandboxing" and "portability" stuff Java does prevents the API from including functions people actually might want to use, such as (as I was looking for yesterday), a J2SE function to validate OS passwords. Sun avoids such platform specifics like the plague.

Freebsd uses MD5-Crypt. Someone wrote a java class to deal with such stuff. Nothing hard. Just port over the c version. I's been up for a long time and I use it w/o problem. I also have one for traditional crypt. It's out there. YOu have to look a little harder, as there is no JPAN. Japan?

, I could make some popular modules on CPAN and change the way people do work. In java?

Jakarta.apache.org my friend. It's there and very real. They house log4j, xerces, xalan, a regular expression api (before it came out in 1.4, 1.3?)

few people being able to say why they like it (in a convincing way).

For some simple reasons.

Java forces me to be organized in terms of encapsulation. I like the fact I have permissions from stupid coworkers doing stupid things. In perl, it's a case of don't do that, or you'll hurt yourself. When someone hurts themselves at work, people we lose money. I rather not encounter someone wet behind the ears doing stupid things and then have to deal with it.

You can't do odd things like declare things public, then make them private. If the interface is designed to have something public, it's public and that's it. Don't undermine the design by changing it.

If you don't do strange JINI things, it's really cross compatable. I work on my mac and unix boxes at work and deploy to a windows desktop with minimal testing. There are bugs in the various JVM's, but they are rare.

I like the fact it's also verbose. I don't have to worky about someone not understanding ($#{$x[0]}; pm randomly inserted the striked out part.) what I've written and vice versa.


Play that funky music white boy..

To paraphrase Mr. Wall (I think, "I prefer people stay out of my house because they are not invited, not because I have a shotgun". Public/private can dominate a huge java app, and while occasionally useful for debug, they make tracing painful and the app slower.

Regarding "stupid coworkers", I prefer to either educate them or not work with them. I consider myself a professional, I expect the people who work with me to act like ones as well.

"Swing is the same way". No, it's much less productive. Try a complex layout in Swing, and the same in Perl/Tk. The Perl/Tk code will be 5x shorter (or more) and you can write it in much less time. I have spent literally hours fighting with the horrible evils (and horrible syntax) of "GridBagLayout".

I do agree that encapsulation is a good thing, but I don't like my hand forced. Some times, objects are not needed, and what you really have is code and a datastructure. Or a datastructure of objects. Objects everywhere is usually overkill and undermines simplicity, often making the code *more* complex. I am very disciplined as a coder, and I prefer to enforce my own disciplines. I do not need a language and it's totalitarian conventions slapping my hand.

Contrary to popular belief, good C code can be written. It just takes *good* coders. Java allows mediocre coders to appear to be talented because they are hiding behind OOP that allows huge interconnects between hundreds of files. Where a procedural coder can quickly be hit for not having a design, an OO java coder can usually say "of coruse I have design, look, UML!" and the design is often just a bunch of random objects. and that's PC.

Anyhow, long story short, Java and encapsulation don't make good coders. Good coders write well in all languages. Java is just decent at keeping bad coders from really showing it, and I think that's more dangerous than broken code. You don't know who in your organization is good and who is bad.

Java people dislike Perl (from what I've seen), far more so than Perl folks dislike Java

Maybe. I don't agree with one language is superior than the other. I think people with that mentality will run into pitfalls eventually. There are definate advocates of each language, I'm all for that. I think each(language) has it's uses - I've said this time and time again.

There are several PM'ers that use JJ as well, I know of several programmers out in the real world that use both(Perl and Java). We use both languages here, each are used for a particular application or process. Depending on what's best for the process or application. There are Java communities out there, but of course.. I'd like to see JJ succeed.

It may be ironic that it's run on Perl, the idea has come up to write it from the ground up in Java. It just takes time, right now I'm not sure how many people can invest that time into something like that. BTW, CJAN has come up.. maybe that idea will skyrocket. I think it's just a matter of time where people can come together and share their ideas in a somewhat central location.

Updated: Gramatical cleanup's and Ant comment at end

This is awkward because I agree with much of what sporty and flyingmoose have said on the topic, but I think the dichotomy of the two languages is best seen at the enterprise level. Perl suffers from lack of enterprise level acceptance for pretty much the same reasons that Java is accepted.

Never the twain shall meet? Possibly, though I was pleased to see that Java 1.5 has finally been released as I believe it will be much more developer friendly.. and besides the regex capability is now much more Perlish.

But on a much more interesting note for PM'ers is the work the JBoss group did to PHP's Post-Nuke. Seems to me a marriage of Perl with J2ee would good advertisement for both languages

While I've seen the Java zealotry that was mentioned in the post I believe it's just simply the "Java is my hammer" effect, as most good developers that I know weigh the tool to the job without predjudice.. ( ok just a little *g* ). The fact is in terms of maturity Java is still young in comparison to Perl or others. This youth explains the type/quality of existing documentation and support. In regards to ..there is no CJAN comment. The fact is that Java builds in the namespace inherently. It is only the limited number of quality contributions that limits it at this point.

Concerning the time required to develop or present Java problems in a fashion more conducive to an algorithmic mind, much of this has to do with the confusion around and in the wasteland of Java IDE's. From what I've seen comming from the developers that have moved into the eclipse IDE I have seen the quality ease of dialoge improving at a fast pace, as much of what use to be just enviornmental issues are more coherently and easily relagated to 'plug-ins'.

(Gotta say though that ant is a poor excuse for a job that is better done by Perl) -just another .02

FYI -- I've written a build system that is a Ant/Perl hybrid. Using the ant methods for controlling java compilation, deps, etc, and then using Perl as an overglorified make, installer builder, and so on (because it's faster). That worked really well. If Java wasn't a component, it would be more Perl though.

Enterprise solutions = App servers? If so, I don't think we need those. Those are more of a marketing trend. 500-1GB memory behemoths that are very slow, finicky, and notoriously painful to work on. Too many layers of middle-ware, IMHO...

I am excited about the Java 1.5 features (and the trend to make it more functional/friendly -- so when I use it I don't get mad) but some platforms don't get good ports anymore (evil SCO, etc) and unfortunatley where I work, we must continue to support those. It would be cool if these syntatic and gramatical features (which are not OS-specific) weren't written into the JVM, but as modules that could be supported under any JVM. Of course, this is a pipe dream.

Anyhow, Perl is not my only hammer. C and C++ are also frequent hammers of mine. But honestly, Perl isn't just a hammer. It's a whole tool-case. Java is more like a drinking straw than a hammer, and well... there are few apps I have seen that are written *BEST* in java.

Maybe I can explain it this way -- if a language is good for both high-level and low-level programming then I'll like it. Java is high-level. Assembler is low-level. This is why I stay away from Java and Assembler as much as possible. I want both, and I don't want a language that fights me.

Interesting.. I did the same thing here creating a Perl/Ant build and deploy framework. Especially when it came down to manipulating the descriptors it was the best tool for the job. It's been working like clockwork for the last couple of years

I was involved in the zvmOS/linux/WebSphere project testing here.. (Putting Linux/WebSphere on the mainframe). It's not ready quite yet, but I'm thinking if they'd have gone with a 2.6 linux kernel it would have been a winner. This is where utilization of an appserver starts to make sense. Popping Appservers on line (on demand) just by imaging a VM allows all the encapsulation pay off. By virtue of just changing a few parameters you've scaled on (or off) your entire delivery tier. I don't think you could just do that with mod-perl applications without having to dink with a ton of properties to allow inter communication with the newly created Server.

coreolyn

Having said that, java puts off a lot of people. Java, while it can perform, is very verbose. You cannot do terse things like complex sorting in say, 3 lines. In java, you create a comparator, and then you pass it to a sort function that does not accept anything but basic arrays. While creating the comparator allows for reuse and what not, it takes time to write. With perl and some other languages, you can express these things in fewer characters while losing only some of the readability -- but that's something one overcomes with experience.

If I'm writing say, something that deals with some complex form of matrix manipulations on various data, in perl, because it's not bound by data types like java, you can write something and debug quickly. Taking that solution and translating it to java could be argued faster than developing it alone in java. When people have questions on perlmonks, I doubt that people spend more than 10 minutes writing something down on the norm. Perl is like that. Doing a map on keys of a hash is really short and sweet. If you do something wrong, it's obvious to those better in perl, and is quickly fixable. In java, you have to compile and test.

Lastly, because it's compiled, it takes time to deal with things. I would equate the tediousness of dealing with compiling a bunch of sources, to setting up and deploying someone else's broken mod_perl. It takes time to deal with. It's not hard, but plain tedious.

I think PM is a place where people can exchange ideas on algorithms in a convenient way. Java junkies fails at this. The java questions I tend to have, is not because I don't know how to do neat tricks in java. There are few to be had. It's because of bad documentation, ala Apache Axis and using HTTP auth using dynamic proxies. It wound up being 1 line of java I didn't know and was documented nowhere. With perl, there are lots of tricks that can save time (writing or executing). Unfortunately, in perl, it's equally easy to trip up, i.e. $x=/(abc)/; if($1) {... } type errors. It doesn't make perl bad. It makes it more difficult, but that's because it's just that expresive. Java junkies may not take off like perlmonks has (over 4 years going?). But I've been wrong before. :)

I think that the idea behind Javajunkies is commendable, though I fear that the forums from Sun and JavaRanch may be leaving it with little energy.

I felt that Java was an abomination for the longest time, but today I will limit myself to regarding EJBs as an abomination, checked exceptions as the result of some sort psychotic episode, and the rest of the Java platform being tolerable to good. It seemed that Java was trying hard to do everything, and thus ended up being the wrong tool for every job. Since about version 1.3, though, it has improved very much, and I like the open-source nature of many major Java projects, particularly Eclipse, JUnit, and Ant. Java's performance has gotten much better over the years, too. I have less and less bad to say about it as time goes by, and I'll take Java over VB any day of the week.

Besides, I suspect that Java must have something going for it since the humble Xah Lee seems to dislike it almost as much as he dislikes Perl.

Perl still enjoys Most Favored Language Status with me, of course. Java still seems quite poopy and artless by comparison. ;)

A compiled Java file (.class), is just the byte code to be executed by JVM. And Perl, with it's complex syntax, when is parsed, a bytecode is also created, optimized, and than executed. But we can't forget that Perl is 10 times more fast to run than Java, including or not the parsing time of a Perl source, including or not the compilation time of a Java file.

Soo, the approach of Java to has it's code compiled to execut it, let's say, that in theory is good to make things faster. But in the practice we see easy that the "fast" point was forgot in Java.

Java is much more about OO than any other thing, and Perl is much more about make things done.

Java is much more about OO than any other thing, and Perl is much more about make things done.

I'd reword that just a little, Java is more about the managability of large scale application development than speed. I don't think even Java biggots would argue with that. But this node was about building a Java Support Community. Not Java vrs Perl.

coreolyn

I know we're straying off topic here, but...

Java is more about the managability of large scale application development than speed. I don't think even Java biggots would argue with that.

You'd be really surprised how often I've heard relentless java-bigots say that it was several (three or four, ususally) orders of magnitude faster than perl at the same thing. No joke.

My only point is: never underestimate the power of people's pre-conceptions. Of course... I guess that's what I get for hanging out in the wrong places.

------------
:Wq
Not an editor command: Wq
[download]

I'm sorry, but actually my post was a reply to the 1st reply of this node, that talk about the compilation of Java and it's speed, but I have posted this in the wrong place, and I saw that only now!

And I agree with your point, Java is more about large scale systems.

Well, Java has his good points, and Perl too, we just need to know what is best for what, since everything has it's good and bad side.

Graciliano M. P.
"Creativity is the expression of the liberty".

But how would I feel upon discovering the Cabal conspiracy to hide the brutal truth: perlmonks just looks like it uses Everything; really it's written in a much-enhanced version of the HQ9+ language.

Well if I'm looking for Java support I'd like to know that the people behind the machinery can at least manage a web site utilizing the language. It's a matter of credibility

coreolyn

I don't see how that matters. If you were looking for Fortran help, would you look for a website written in Fortran? There are plenty more participants capable of providing the help you need beyond those that wrote the website engine.

90% of every Perl application is already written. ⇒

dragonchild