a warm, fuzzy "fuck you" to Java

[Ludovic]

i've probably ranted on this before, but it deserves it much, much worse.

okay, mr Hot Shot Java Teacher. You've taken your basic Java courses and maybe gotten your cert. Then how come YOU CANT REMEMBER SHIT ABOUT JAVA? You cant remember how long the basic data types are and I, with NO FORMER EXPERIENCE IN JAVA, am REMINDING you of size of basic data types throughout the course. Now that you've led me astray i cant even remember them myself.

now you've gotten me off to a bad start. you dont even remember if you can compare strings with "=="

dont even get me started on strings. STRINGS SHOULD BE OBJECTS OR THEY SHOULDNT BE. If strings are objects dont confuse the issue by assigning them with "=". If they are objects, then HOW COME I CANT FUCKING OVERLOAD THE "=" OPERATOR FOR MY OTHER DAMN OBJECTS.

i'm redesigning a page to make sure the objects are destroyed at the end (they are, but my idiot boss doenst trust the JVM) and wrote a compare function(procedure, or whatever the Java Gods decided to call it) taking parameter STRING1 then comparing STRING1=="STRING". if I send it the constant "STRING", it works, if i send it a variable initialized to "STRING", it fails.

THAT IS THE MOST INCONSISTENT PIECE OF CRAP LANGUAGE DESIGN I HAVE SEEN THIS SIDE OF THE 8.3 FILENAME LIMITATION. For consistencies sake, each constant string should be its own object, initiazed separately with its own address. And yes, i need to use equals(). But heres the catch: my wonderful VB-loving, bill gates jizz-catching, fake-hipster AOL-bashing Java instructor doesnt know Jack Chick about the fundamentals of the design of the equals() operation.

So I ask him "when you perform the equals() operation, by default, does it perform the == operation on all the consistituents of the object, or does it perform the == operation on the non-objects, and the equals() operation on the object?" and he DIDNT UNDERSTAND MY QUESTION.

Needless to say, as par for the course, the less useful case turned out to be true. Why would anyone want a default equals() operation that applied == to the member objects instead of recursively applying equals()? Was this language designed by Duns Scotus? Strom Thurmond? If i wanted to jump through hoops to write code, i'd program in assembly on a TRS-80 using a harmonica to send tones over a 20 baud modem. thank you very much.

[Miller]

My brain hurts.

[Larry Mudd]

And here I thought you had something against Indonesians.

Never mind.

[Tansu]

I don't understand all of the rant, but I know I like it. The last paragraph was one of the classics.

[zweisamkeit]

I understood everything in that rant. If you hadn't said MR. java teacher, I could've sworn you were talking about a former professor of mine.

I had her for Computer Science 2 (learning the advanced stuff of C++). She didn't know her ass from a hole in the ground. She'd recopy notes from other books and read them aloud. Did I mention that English isn't her first language, and so her "recopying" often left the text indiscipherable? If someone had a question, she was never, EVER, able to answer it. She made the final INTENTIONALLY so difficult that most people would fail it, but still gave everyone As and Bs so no one could say, "All your students failed! What's wrong!?" So I got an A- in the course, and I didn't learn shit.

The next class in the CompSci class line is Data Structures. There was no way I was prepared for it, so I delayed it a semester. Not wanting to have my programming skills (miniscule as they are) completely wither away, I signed up for Intro to Java. The teacher was listed as TBA until three days before the semester began. Guess who taught that class?

That's right! The same simpleton who taught my CS2 class! She supposedly is working on (doesn't even have) certification. She pissed off everyone in that class. The beginner programmers were utterly lost (she was doing the equivalent of Data Structures type lectures in an introductory course!), and the advanced programmers still weren't learning anything because she was only repeating the notes that she copied. So once again I wasted money on a course in which I learned nothing.

Now I'm in Data Structures. Most of my classmates there have suffered through the same prof I had for CS2 and Java. You should've seen the dismay of the prof when we warned him how underprepared we were. It's not because of laziness (well, not completely, anyway ), but we honest to god just didn't learn what we were supposed to. Now he's working double duty, trying to teach us what we should have learned a class ago, as well as what we're in HIS class for.

Sorry for hijacking your rant. I needed to let you know you're not alone, and I kind of went overboard.

[apotheosis]

Java? People are still paying attention to that?

Oh, you crazy kids with your wacky retro hijinx! *noogie noogie*

/me goes back to reading Bill Gates' "Idiot's Guide to World Domination"

[Avumede]

Your complaints about Java make no sense. It's very simple. == compares whether things are the same object. equals() compares contents of objects. To compare strings, always use equals() (unless you want in to be internationalized, in which case its slightly more complicated). The compiler probably assigns all constants to the same object, so that's why "String" == "String".

About String assignment with equals, I think you are confused. Equals is not overloaded. An equals does the same thing it does with any object, a = b will make a point to b. Since strings are constant, it behaves the same as a copy constructor. "+" is overloaded, though, and some people do have a problem with it. But really, who cares if it's a little inconsistent, it makes things much easier.

About your question whether .equals() on containers compares each element by .equals() or ==, this is all in the JavaDocs. It uses equals().

[bobkitty]

Originally posted by Larry Mudd
And here I thought you had something against Indonesians.

Never mind.

*I* thought he was upset with JavaMaven1 for some reason.

If I had understood a word of this rant, I would've said it was fabulous.

-BK

[capacitor]

My objection to Java is that it slows down my computer to XT-like speeds. And I took a Java course.

[Atreyu]

Heh.

And here I am opening this thread wondering if this might be a coffee rant inspired by headaches due to caffeine withdrawal.

[Tranquilis]

If i wanted to jump through hoops to write code, i'd program in assembly on a TRS-80 using a harmonica to send tones over a 20 baud modem. thank you very much.

Classic.

Brah-vo!

[JavaMaven1]

Originally posted by bobkitty


*I* thought he was upset with JavaMaven1 for some reason.
-BK

*sniff*

And here I was thinking that I was being called to the Pit. I've barely posted in the past few months and my first thought was I'd done something horribly, horribly wrong.


Don't scare me like that, people! Jeesh!

[quarx]

I feel your pain, Ludovic. MY Java teacher was borderline autistic and didn't know shit about computer programming or computers. He was finally fired when he started harrassing the black students in our class and let slip the fact that he didn't know what a C drive was (I swear to God I'm not making this up.). All in all, he was John Nash without the talent.

FWIW, the VAST majority of console jocks I've met and worked with taught themselves just about everything they know from books and other programmers. Many programming teachers are notoriously terrible at getting their point across and have awful interpersonal skills. I finally got through Javascript with some textbooks and more than a little help from my friends. Also, I seem to remember a lot of good resources on the web.

As far as your classes go, that same vast majority of programmers I know consider them to be a necessary waste of time. They get that all important piece of paper and move on to high-paying jobs never to look back at the bullshit courses they had to put up with.

Good luck with Java. And don't fret: There are plenty of other languages out there. C++ used to be my favorite.

[Ludovic]

Avumede: "About your question whether .equals() on containers compares each element by .equals() or ==, this is all in the JavaDocs. It uses equals()."

from java.sun.com, documentation on the object object:
"The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any reference values x and y, this method returns true if and only if x and y refer to the same object (x==y has the value true). "

This has been my experience in programming as well. how would one take advantage of that supposed feature in the JavaDocs?

[Avumede]

Ludovic - you are correct, and the JavaDocs are correct when you say equals on Object is the same as ==. However, thats just on Object. Most of the useful classes like String, List, etc. will overload equals and implement a version that compares.

Specifically, since you seemed to be asking about containers, your question is not what whether equals() is the same as == on containers, but whether equals() on containers will evaluate element equality by equals() or ==.

For example:
a = new String("hi"); b=new String("there"); l = LinkedList(); l.add(a); l.add(b);
c = new String("hi"); d =new String("there"); q = LinkedList(); q.add(c); q.add(b);
so is l==q? No, since they are different objects.
Is l.equals(q) true? That depends on whether a will compare with c using == or equals(). If ==, then no, since a and c are different objects (same with c and d). If equals(), then yes since they contain the same data.

From the Javadocs for List:

Compares the specified object with this list for equality. Returns true if and only if the specified object is also a list, both lists have the same size, and all corresponding pairs of elements in the two lists are equal. (Two elements e1 and e2 are equal if (e1==null ? e2==null : e1.equals(e2)).) In other words, two lists are defined to be equal if they contain the same elements in the same order. This definition ensures that the equals method works properly across different implementations of the List interface.

So we see that this List, and those derived from List will compare elements using equal() if at all possible. So in our example, l.equals(true) returns true.

[Avumede]

Whoops, change q.add(b) to q.add(d). But you get my gist, i hope.

[Derleth]

Y'know, all of this worry about objects and methods to test equality simply doesn't exist in Perl. In Perl, you have three data types:

• Scalars: Every singular thing. Numbers, strings, binary, anything. Any size. Strings are converted to numbers on the fly ("1" == 1 and "1_776" == 1776), so you really don't have to worry about that aspect. Size is unlimited: In Perl, size is always theoretically unlimted. The limits of Perl are the limits of your hardware. You can read whole partitions into a scalar, if your machine can support that kind of thing. Assigning a scalar is like this: $scalar = "23";
• Arrays: Every plural thing. Lists, basically, with all of the standard subscripting operations. Zero-based numbering, which I like but you might not. Creating a scalar is as easy as @list = [5, "berry", $scalar, "12",]; (5 is a number, "berry" is a string, $scalar is a scalar and is interpolated, and "12" can be either a number or a string based on context.) You can use negative subscripts to access elements at the end.
• Hashes: You might call them associative arrays or linked lists or dictionaries. A hash is a series of key-value pairs: By subscripting the key, you get the value. Here's an example:
  

  # This is a comment. Comments begin with octothorps.
  # You might notice the punctuation in variable names.
  # This is intentional.
  # Scalar names start with dollar signs,
  # list names start with at symbols, and hash names start with percent signs.
  # This makes code ever so much more readable, because the variable's name tells the variable's type.
  %hash = { "Fred" => "Flintstone",
  "Wife" => "Wilma",
  "six" => "6", 
  "bignum" => 1.7e26,}; # Lists use square brackets, hashes use curly brackets.
  # Punctuation is a strength of Perl.
  
  $his_name = $hash{"Name"}; # Fred
  
  $bignum = $hash{"bignum"}; # A number, not a string.
  
  print "$hash{"Wife"}\n"; # Prints Wilma and a newline.

Simple, neh? Plus, Perl is freely available and open-source. Which might not matter now, but no company can ever blackmail you into accepting something just for the privilige of using Perl.

Perl and Java are both interpreted languages, and they both get compiled to bytecode and run inside a virtual machine (but you can program the Perl virtual machine in an assembly language called Parrot (currently under development as part of the Perl6 project) ). What makes Perl shine is its ability to process text, and it gets that from regular expressions.

Whole books have been written on regular expressions (such as "Mastering Regular Expressions" published by O'Reilly). Any decent Perl book (and a whole line of spectacular ones are published by O'Reilly ) will have large chunks devoted to the care and use of regexps (as they are called). With regexps, you can do anything to text you can dream of in just some few characters. Powerful, terse, and able to ruin your day, regexps are the lone gunmen of the Perl world. (Damn, that's a good sig.) Get them right, however, and you will be on Easy Street whenever you have to process text.

So, should you invest time and money getting a text and learning a bit of Perl? Hell, yeah! Perl is one of the most-used languages in the realms of CGI and administration of Unix-like systems. (It was invented by a sysadmin, but it has translated to CGI really well.) It's used by almost everyone (one O'Reilly book teaches how to apply it to bioinformatics applications) and it's not going away. Hack Perl, be happy.

[Derleth]

OK, I screwed up. In my list example, 5 can be a string as easily as "12" can be a number. And vice-versa. Perl really is easy that way.

[Dreaming of Maria Callas]

Originally posted by Derleth
Y'know, all of this worry about objects and methods to test equality simply doesn't exist in Perl.

Not to hijack the thread, but Derleth, don't you think all the changes made to Perl for "Perl" 6 (they shouldn't even have kept the name, but realised this is a new beast and picked some new moniker), which will mean that a great deal of Perl 5 code won't even run anymore, make people lose interest in Perl?

Someone on Slashdot said that Perl looks like an explosion in an ASCII factory, it was the ugliness of the language that turned me off from it. Java's beautiful by comparison.

UnuMondo

[Avumede]

Of course Perl has the same issues as Java about equality. What about eq versus ==? It's pretty much the same concept.

Yes, Perl makes it much easier to do simple things. However, I would suggest Python if you are looking for a higher level language. Not as ugly and headache-inducing. Although Perl6 looks like it will fix a lot of Perl's big mistakes.

[Derleth]

Perl4 code still works, even though Perl5 has been out for a long time now (by language development standards). I think Perl6 will have to be able to cope with all of the legacy code, even if it's completely different under the hood.

(If you know something I don't, tell me.)

Avumende: That's not really a problem, because sometimes it's useful to be able to differentiate between strings and numbers. But Perl doesn't make you think about it if you don't want to (and it would make sense for you not to). It isn't an issue in Perl because Perl doesn't make it one, and instead strives to do what you mean.

I sometimes use Python myself. I like the interactive development environment, but the sheer codebase just isn't there. There are Perl modules for doing nearly anything you would want to do, all available through CPAN.

Finally, about beauty: You can write train wrecks in any language, including Java and Lisp and other 'pretty' languages. You can also write beautiful assembly and Basic, two languages not noted for their asthetics (to put it mildly). Beauty comes from the inside, places like elegant program design and logical flow control and intelligent use of pre-written code (be they modules or libraries or macros). Good programmers can write well (readably and efficiently) in any language.

Perl is a language that does not enforce a format, like FORTRAN and Python and Ruby do, because to prevent people from doing stupid things (like writing unformatted messes of ASCII) prevents them from doing clever things (like writing once-use programs on the command line to solve annoying little problems).

Perl also has a much more idiomatic syntax than other languages: You can do things like say

while (<>){
chomp;
print;}

to mean that you want to read every line in the standard input stream, remove the newline character or characters, and print it to standard output. To me, that's perfectly intelligible and readable, like reading casual English instead of prose. (In fact, a lot of Perl can be understood by comparing it to English or another natural language.) It takes some getting used to, but any language you want to get good at takes practice and effort.

[Rilchiam]

Originally posted by JavaMaven1



*sniff*

And here I was thinking that I was being called to the Pit. I've barely posted in the past few months and my first thought was I'd done something horribly, horribly wrong.


Don't scare me like that, people! Jeesh!

Yeah, I jumped into this thread with my fists up, ready to defend you!

So many posters with multiple-use names...

[Ludovic]

thanks, Avumede, for pointing out that a lot of the existing objects implement equals() in a sane manner. I havent really taken the time to look at a lot of them, in fact, i sort of assumed that they did a good implementation, but i may look further into those types of object for future reference.

however, if I am creating an entirely new data structure for some heavy-duty programming, what would have been ideal would be to implement a default equals() sanely in the first place. for instance if I have an object with the following pseudocode data structure:

object insanelylongobjectnamethatsnotcapitalizedeither:

memberObjectType1 obj1;
memberObjectType2 obj2;
memberObjectType3 obj3;

boolean equals(insanelylongobjecttype compObject);

then 90% of the time, i will implement equals() thus:
return ((obj1.equals(compObject.obj1))&&
(obj2.equals(compObject.obj2))&&
(obj3.equals(compObject.obj3))

i dont want to have to write that every single friggin time i write my own object. however, I won't complain any more, since the way they implement it (merely defaulting to "==") at least has the advantage of being simple to implement. My instructor had led me to believe that by default it recursively applies "==" to the member objects, which makes no sense at all.

So my rant against my instructor still stands

Now, a rant against perl would be a whole 'nother thread....."This may seem a bit weird, but that's okay, because it is weird."--Wall. nuff said. (honest to goodness, i have had to deal with folks who coded pointers to pointers to arrays of hashes of arrays of hashes in perl. no thanks!)

[Derleth]

Ludovic, you can do the exact same pointer shit in C, and in fact you have to to implement hashes. Perl allows you to do what you want, and some people want to do stupid shit. Some people want to watch "The Beverly Hillbillies" all day and all night, some people want to mainline cocaine, and some people want to create needlessly complex programs. People can be stupid. Perl doesn't try to stop them.

Why is it so permissive? Because the developers want to allow you to do really smart things as well. Like write an RSA encryption program in two lines (this implementation calls the external but standard program dc, something Perl makes very easy). I don't think that's even possible in Java (I don't know how much Java enforces a certain format), and I know it isn't in Python.

By basically getting out of your way and letting you do what you want, Perl places a lot of responsibility on the programmer. The responsibility to write objects that others can't mess with (yes, Perl has good OO support), the responsibility to enforce security (more meaningful in *nices, where you can do with Perl anything you can do with a shell script (plus a shitload more)), and the responsibility to write readable code (one of the main thrusts against Perl, but can be made against even languages with a strictly enforced format). But with responsibility comes power, and Perl is great at empowering the programmer to do the job and get on with it.