Sounds like you are unaware of the algorithm benchmarks regarding Lua's register-based JIT.

Sounds like you are unaware that heavy-players in the video game industry *all* mix & match Lua and C++ for their engines.

Wow! You must know something we don't! Why don't you get a job in a big software house in the games industry and tell them how *wrong* they all are?

Apparently, a lot of people in the software business have trouble with pointers. That includes Linux, and its many, many security breaches and flaws in its history. Of course, I'm not calling people stupid. I'm simply stating what is widely known. Safe programming is hard. Pointers are error-prone. People who deny that are either superbly arrogant or ignorant of the many serious events in the software industry. If you can avoid unsafe code by using a safer language, than you ought to. You don't seem to have read this bit: "No access to kernel memory, -functions but through predefined binding."

Your assuming NetBSD developers are morons shows how ignorant you are. Have you ever even looked at *BSD system code?!

So Smalltalk is not OOP, right?

The problem is that people look at Perl - without having learned it - and say "unreadable!"
That really is the kind of circular thought only stupid people can achieve - "I dunno Perl, so I can't read Perl, so I don't know Perl, so I think it's unreadable (...)"
Now, anybody seriously considering reading large arrays into Perl can ask the Bioinformatic guys how Perl is cutting it for them, or also choose to use the Perl Data Language which seems good enough for some guys in an Astrophysics department.

Perl is not black magic. It just takes reading the Camel book.
Now, if you don't, you will see consctructs that will make you go "Wow, how did he come up with that?!".
Some people don't want to read...There's nothing Perl or Larry Wall can do about that...

When you say "Perl is scary" I take it you mean that you don't like TIMTOWDI.
I have often pondered about this. It seems a simple design has its advantages - you quickly pick up the simple rules, and away you go. Now, there's an aspect of engineering. Java, Python, they might be better for the larger software houses, in the sense that they facilitate things for the "code monkey". There's nothing wrong with that job position, although the term is derrogatory. Eiffel, for example, is a well-designed language that takes that approach very explicitly (they even say there's no space for the "language guru" in Eiffel).
But Perl is no more scary then C++. C++ is large, complex, full of hidden gotchas. That never stopped it from being used at a very large scale.
I really feel most arguments against Perl are lazy and not well thought out.
Let's say Perl is "complex", like, say Common Lisp is "large and complex". I tend to think these complex languages are the languages of the experts, the power-users. The language bend and twist to the expert's desires. This makes them achieve great productivity.
The point being, there's a learning curve to Perl (not much, it takes reading the Camel book) and other "complex" languages, but there's a pot at the end of the rainbow in personal satisfaction and productivity.

Exactly...WTF!
Perl and Perl's hacker community, when you think about it, did amazing feats, bending Perl to take whatever shape they wanted/needed.
People wanted OOP - Perl's closures allowed that. Perl's OOP is better than most would think. (Read: Object-Oriented Perl).
Want to program in functional-style? They proved you could do a lot of FP stuff in Perl. (Read: Higher-Order Perl).
They even went ahead and gave Perl a Meta-Object Protocol, sort of CLOS-style (CLOS = Common Lisp Object System, which some would argue is the most advanced out there).
And Perl is pretty fast, when compared to Python or Ruby.With a huge number of libraries (CPAN).
So Perl is pretty successful and has held its own as one very flexible language. The fact that the language did not change much, and yet achieved so much, is really a testament to its happy, fortuitous design.

IMHO some mistakes were made in not supporting things that are not Perl per se, but would be crucial in a modern programming language:
- Perl is a PITA for C-interoperability and a lot of Python these days is about, in fact, using a deeper C layer (why not more Lua, then?). C is crucial for speed (that means number-crunching and graphics), for software re-use, and its *the* lingua franca of software.
- Some sort officially-sanctioned GUI should've been adopted. Again, this isn't Perl per se, but having mult-platform GUI support could've secured a better position at the desktop space (but most Perl people work at the data center/server level).

And then there's Perl6...Perl6 was supposed to be great - its design is great - but IMHO the developers made the mistake of forgetting the lessons of the past, forsaking an advanced functional language for the implementation of complex language features - this despite Audrey Tang's effort - and then got caught in a labyrinth they can't get seem to get out of. And this move might have been caused by pure prejudice against Haskell or sheer stubborness, I don't know.

Whatever the reasons (and to be fair, one got tired of following the slow progress of Perl6), letting Pugs die when Audrey had done so much by herself just didn't seem rational at all. Maybe it was, maybe it wasn't, but if the history of programming languages servers as a parameter, the odds were in favor of a Haskell (or SML, or Ocaml, etc.) implementation, because the advanced features Perl6 was aiming for, to my knowledge, were never decently implemented with the usual bag of C-oid tools (the olnly thing that comes to mind is Mathematica, which was very buggy in its initial version, when compared to Maple). Smalltalk, Lisp, etc. They all seem to built some sort of interpreter or language kernel and grow the language from there. It doesn't seem that was what the Perl6 implementors were doing. It's almost as if they were emulating the Java developers - and we know how long it took then to implement a modicum of advanced language features over there...

I agree with him. Paypal has a terrible track record, and if a moderately successful fundraiser can cause them to seize funds. Since the shelter isn't a business with a track record of sales, it could take significant effort to get access to those funds. And since Paypal isn't a regulated bank, there's no recourse other than taking them to court.

Paypal is convenient, and is only worth the risk if you can afford to lose the transaction.