This is not a pissing contest ... but calling it a fact is also silly.

Perl has integrated debugging. Perl has pluggable runops so profilers can be attached to the platform (e.g. Devel::NYTProf). Distribution == CPAN and the 'make dist' system from ExtUtils::MakeMaker, again built in.

The introspection is -different-, perhaps, but I'm not sure I'd say it's better or worse.

Nothing meaningful? You set it to break into the debugger when that exception is thrown, and then debug it. I'm honestly not sure how this is any different an experience to in java - any java application not actively being debugged will write a stack trace to its log file and either exit or move on to the next request too, no?

Not really true. Yesterday I was trying to debug resource-loading issues. In any normal programming language, you can just strace it and you'll see where the program is doing I/O and you can figure out where it's trying to load files from. But if everything is in a jar, you don't see any OS-level I/O happening when Java tries to load something, so you have to invent all-new tools just to figure things out. When you switch to Java you throw away 40 years of UNIX for a bunch of private methods implemented by summer interns at Sun 20 years ago. The third-party libraries are fine, but the core is not.

Also type erasure.

I agree but if we're comparing Java to Perl, type erasure is only slightly hacky compared to the whole 'bless' thing.

Funnily enough, they're both examples of the same problem, stitching new features onto a language that was not at all prepared for them.

I never used strace even when doing C and sometimes C++ and still managed. Eclipse can't be beaten for Java, C/C++, PHP, Perl, Ruby and Python development.

EDIT: I just used "strace /usr/bin/java -jar myjar.jar" and saw what looks IO but I'm not familiar with strace output yet. It looks like a handy utility though. Can you give an example of something that you expected to see but didn't when you tried it?

While Java has many problems, I don't consider packages to be a wrong choice necessarily. Not all good choices will be introspectable with unix-y tools (like mmaping a vm's state into memory).

> Attach to any running process and analyze away.

Interesting. It never occurred to me to want this. What sort of use case is this for? It seems Perl is capable of something similar:

    use Enbugger::OnError 'USR1';

Then 'kill -USR1 pid' and your process will jump into the debugger.

learn more here: https://metacpan.org/module/JJORE/Enbugger-2.013/lib/Enbugge...

Or strace -p whatever, or gdb -p whatever.

Shockingly, attaching to running processes has been a feature of UNIX for decades.

Wow, that's cool! Thanks for sharing that. Does Perl also have something similar to Python's "import pdb; pdb.set_trace()", which lets you drop into a debugger at a predefined location in your code? I've been finding that really helpful.

Knowing Perl, it probably is possible, and I just never learned about it.

... drop into a debugger at a predefined location in your code?

Add the line where you want the execution to stop:

    $DB::single = 1;

Then, run your program as:

    $ PERLDB_OPTS=NonStop perl -d program.pl

See: http://perldoc.perl.org/perldebug.html

>>The java runtime makes everything else look amateurish and unprepared.

The java 'runtime' is hardly Java. Its like saying Pentium is C.

Java the language is hardly comparable with a scripting language like Perl.

Seriously?

This is a fact: <opinion here>.

Java calling anyone else's stack traces is backwards and hilarious, and only going to get better in about 15 years when java finally gets lambdas.

Counter point.

When I was at Google, the opinion among some of the SREs I knew was that Java there was better than elsewhere so you actually did get reasonable debugging stack traces, but the C++ libraries there were still significantly easier to debug problems in than the Java ones.

Yes, I know that those AbstractFactoryFactories let you produce convenient higher order abstractions, but when things go pear shaped, they can make it really hard to figure out what was supposed to be happening, let alone where it went wrong.

AbstractFactoryFactory nothing--maybe Google's sensible enough not to use frameworks which create bytecode and inject it into running processes, but try to debug something configured via annotations or XML sometime.

I believe that Google is sensible enough. But yes, you have a point.

A recent amusing counter-example:

http://stackoverflow.com/questions/4185665/guava-equivalent-...

Half the point of CPAN is "installability", it is trivial to d/l and install lots of modules. There is also CPAN Testing which drastically helps portability. Can Java really compete with a Perl module that has a long list of dependencies (50+ is a pain but will work) and some code tying it together...? [That was the example in the GP post.]

With all due respect to the Java runtime (if not its memory use :-( ), it is part of a totally different ecosystem compared to the usual suspects of the scripting languages.

(And I'd argue that it is always easier to debug a scripting language than C/C++/Java, except maybe just for long running server processes.)

"Can Java really compete with a Perl module that has a long list of dependencies (50+ is a pain but will work) and some code tying it together...? " Maven does it. I'm pretty sure that all main languages have their equivalents too.