Unmaintainable code...

[swpalmer]

Yeah... this nonsense is filed under Off Topic for a reason .

Besides, only My opinion matters  

[Jeff]

Isn't this all opinion based? Just depends on how your mind works and what you find easy to work with?

Kev

Yes, to a degree its religious though I think there are good arguments that can be reasonably made.  (Such as, to humans used to natural language, whitespace is a delimiter not a token and thus it is hard to read in environments where it is treated as a token.)

BTW, Jeff's definition of religion:

"Relgion is an opinion or belief into which you invest emotion."

[tortoise]

I really don't see it. Perl is basically C after it's had a few drinks. You can use it exactly like C, all if/else, do while, while, for, ++, etc contructs are there (except Perl lacks switch), in the exact same form. Add in regular expressions, a looser structure, and a lot of shortcuts and that's it. You can very easily ramp up to more advanced Perl, and until you're comfortable with it just use Perl as a looser C with some nice conveniences. Nobody is suggesting Perl in its monstrous entirety needs to be used in all scripts.

I am sure that I could "learn" perl and in time read it and understand it with relative ease.. but I would consider that a tremendous waste of time.

This Perl phobia (not just you, it's quite common) is like a child taking his cough medicine. It's not that bad!

Perl saved me immense time. So much so that Java or C or even Python would have literally been impossible, the number of things I had to implement in the time I had. There's a time and place for everything, and chances are CPAN's already done it for you

I believe that people with a mind for programming can understand most of C/C++, Java, BASIC, Pascal, Python, etc..  just by looking at code that has been written in it, without knowing ANY of those languages ahead of time.

1   2   3   4   5

qsort []     = [] qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x                  where                    elts_lt_x   = [y | y <- xs, y < x]                    elts_greq_x = [y | y <- xs, y >= x]

The Haskell community declares this quicksort program to be learnable from just looking at it, "You should be able to understand the program without any previous knowledge of either Haskell or quicksort." (from the official "Intro to Haskell", http://www.haskell.org/aboutHaskell.html). I really disagree. That program's also nothing, Haskell gets much more bizarre. It makes Perl seem like reading a children's book. Yet Haskell  is an excellent choice for certain situations. There's no such thing as a one size fits all language, they've all got their strengths. Including Perl. They've all got their weaknesses. Including Java.

Games published by our own members! Check 'em out!

[Jeff]

I really don't see it. Perl is basically C after it's had a few drinks..

Of everclear, maybe.  (Everclear == 199 proof alcohol).

The primary thing that makes PERL unreadable is the idea of "context".  A single variable has differnt values and meanings depending on where and how it is used.

You have to effectively run a light-weight PERL parser  in your head to understand the context and thus meaning of the code.

It was an interesting idea, and it can be very convenient to WRITE but it does make it hard to read.

[swpalmer]

There's no such thing as a one size fits all language, they've all got their strengths. Including Perl. They've all got their weaknesses. Including Java.

Sure, I'm of the opinion that Perl's weaknesses GREATLY outweigh it's strengths.  I fully admit that there are a few things that CAN be expressed easily and neatly in Perl... though the reality is that every Perl program I've seen is a mess. Of course that made me stop looking at Perl so I haven't seen all that much.

So, after seeing how awful the code was that was produced by people that actually knew Perl it was clear that there was no point in learning it.. Why spend the effort so I know how to write ugly un-maintainable code?

I find your Haskel example easier to understand than Perl, but I fully admit it still sucks.  People may say that it fits certain problems very well...  so does Prolog and other languages that never get used in "real life".

[MGodehardt]

my favorite part is:

Inline Assembler: Sprinkle your code with bits of inline assembler just for fun. Almost no one understands assembler anymore. Even a few lines of it can stop a maintenance programmer cold.

[K.I.L.E.R]

Can Java have inline assmebly?

[Matzon]

well it could do a call to:
private native Object randomUnmaintainableCodeAcceptingAllArguments(Object data);

which was implemented in pure asm  

[princec]

How about a class that stores its bytecode in a byte[] array, and creates its own classloader to load & resolve the embedded class, and then delegates all its private internal workings to the embedded class by using reflection?

Cas

[Matzon]

hmm, you upped the ante - that code should ofcourse embed somekind of quine to make it even more fun

Games published by our own members! Check 'em out!

[Jeff]

How about a class that stores its bytecode in a byte[] array, and creates its own classloader to load & resolve the embedded class, and then delegates all its private internal workings to the embedded class by using reflection?

Cas

I think using reflection probably has to be outlawed in the Java Obfuscation Competition for the same reasons the pre-processor is outlawed  in the C contest.

It just makes it too easy

[Raghar]

well it could do a call to:
private native Object randomUnmaintainableCodeAcceptingAllArguments(Object data);

which was implemented in pure asm  

You have that code wrong.
It's
private native int calllllllAndBlastOutWindoze(ByteBuffer b);

[K.I.L.E.R]

private native windowsPerformedAnillegalOperationAndMustBeShutDown(ByteBuffer _buffer)
{
  int nonsense = 0xFF11AE;
  System.out.println("BUFFER OVERFLOW EXCEPTION IN ADDRESS NONSENSE" + nonsense);
  System.exit(1);
}

[Raghar]

You can't implement native methods.

[K.I.L.E.R]

Now you can.

[K.I.L.E.R]

Yeah... this nonsense is filed under Off Topic for a reason .

Besides, only My opinion matters  

Seconded.

[blahblahblahh]

Java 1.5 beta enters the mix...

Someone at Sun apparently doesn't like the

1   2   3   4   5   6

if( something || something && something ) {   ... }

...because the stack traces for runtime errors collapse that multi-line if check into a single line before reporting the number. With a code numbering editor, you will be told that the runtime error is in the "if( something" line, even if it isn't.



I only noticed because I was getting:

NullPointerException

in the line

1	if( myVariable != null

LOL!

[although, obviously, this is a bug with the 1.5 beta (line numbering for stack traces *has* to take into account EXACT source layout - including all blank lines as significant etc).]