Re: Re: OT: JavaJunkies (Javamonks sorta)

[exussum0]

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.

[flyingmoose]

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.

[exussum0]

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.

Painful? The compiler will usually say, "no, you can't do that." But OOP and security does slow down an app, i totally agree.

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.

It's the problem with life and rules. People break them if they can be broken. It happens. Not because people are stupid, or malicious, or tricky. Sometimes, people make stupid mistakes. It's the reason people got into the habit of writing, if(1 == x). It's so people won't accidentally lose an equal symbol and create a software bug.

The problem is, when you hire a consultant, someone who has no reason to play nice other than to get the mission done, do you trust him to play nice? What about the developer that's still not seasoned enough to know better. What about the developer who says they don't care? When you have to clean up their messes, it's time lost and sometimes money lost due to "bad software practices."

About swing... I've done the same thing, and have done the "why isn't this thing" working for an hour or two. Swing issues can usually be reduced. Easily. If something isn't aligning right, have the user give you the constraints before hand. Something not aligning right? Change the background colour of the relative widgets and redisplay. You'll easily see where the broken overlap/stretching comes in.

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.

The only difference between Java and C in terms of procedural programming is making all your methods static. And the same goop you get with bad object design, can be done with bad procedural design. Look at student's C programs, that's usually pretty ugly.

BUt you are right, it doesn't make good coders. Java is a tool, just like perl or c. It takes good coders to write good code. Giving a person a car with automatic drive doesn't make them a good driver. It just makes it easier to do. But if you want to use a stick, know what you are doing.. 'cause just as it's better if you master it, it's easy to break.