object oriented features are stuck on with duct tape
Perl 5's default object system is basically Python's object system. Everything Python programmers complain about (explicit self) and everything Python programmers haven't figured out yet (the conflation of namespace and class with no distinguishing between function and method makes for fragile classes) is a misfeature shared between the two languages. Python offers little additional value there, and it suffers greatly when compared to Moose.
you have to have a deep understanding of the language to understand what's really going on when someone assigns between variables that have different [sigils]
You only have to be able to understand subject/verb agreement in a spoken language (and you don't even have to know the term "subject/verb agreement"). That's one of the first things the book Modern Perl explains. (You can download it for free if you like.)
huge numbers of built-in magic 2-character variable names that you can't remember without a cheat sheet.
I've written a lot of Perl 5 over many years, and I can think of two or three I ever use. I could get that down to one.
Two substantial criticisms are "reference syntax is ugly", which is true and "most tutorials explain the language poorly", which is why I wrote what I believe to be a better book.
... it seems to me the decision to leave implementation up to "the cloud" rather than have a complete reference implementation is delaying it and may destroy it.
On the contrary, that's the best way to create a usable specification.
It's possible to do both, especially when you realize that optimizing a dynamic language well means understanding the 90% of the program you can optimize statically and doing so.
Dynamic languages move the notion of "type" from the variable to the value.
Some do, some don't. (Please refrain from committing the definitional fallacy.)
At least languages like Java and C# have value types that are guaranteed never to be null....
So do some dynamic languages.
I would've expected a big-time Perl guy like yourself to have understood such basic concepts.
I've programmed in too many languages to fall for such gross generalizations. Even if the point were correct and generally applicable, some languages allow coercion of null to appropriate values in certain circumstances (Perl's undef, for example) or allow you to implement the null object pattern through manipulation of base types (Smalltalk comes to mind). The point might be technically correct if you squint hard enough, but the implications are by no means as gross or widespread as the original post implies.
All this pseudo theoretical computer scientific bollocks holds no interest for the average person doing scripting.
Said "average person" was happy with a language which didn't use functions, which didn't use objects, which didn't use lexical scoping, which didn't use garbage collection, which didn't use JIT, which didn't have easy deployment, which didn't have libraries for network programming, which... well, sometimes the state of the art advances, and the average person could be a little bit more productive and write a little bit better code with a better tool.
Note, for example, that Ruby and Python have builtin regular expressions, their own library management systems inspired by the CPAN, and their own implementations of roles (of which I hear the authors of the Smalltalk traits paper have since suggested that statefulness is a virtue). Maybe they'll even get lexical scoping working one of these years.
If you have a test case which demonstrates that Perl 5 does the wrong thing, please submit it to p5p so that we can correct it. (See also the 23-year old file full of test cases which demonstrate that Perl does the right thing.)
Larry and Damian have worked on outlines and have proposed various timelines for Programming Perl 6, but I don't know its current status. My company, Onyx Neon, has other Perl 6 books in process.
... and replaced with? Look at the Perl 6 RFCs and make something coherent out of them. If you can pull it off in less time than it took the Perl 6 designers, you deserve a Fields medal.
Perl's syntax and type system still suck, even in Perl 6.
Have you tried Perl 6's type system? The combination of types, signatures, and multiple dispatch have ruined most other languages for me. (Pattern matching is a fine alternative in language which support that.)
Depending on who built the pyramids and how you interpret that strange passage in the Book of the Dead, yes. I realize that interpreting reports such as those from Gartner which suggest that the billion-plus personal computers in use now will become two-billion by 2014 requires similar skills, but those are the best numbers I've seen. (I've seen other suggestions that the number of personal computers available has averaged 12% annual growth over the past few years.) Do you have other statistics?
I am wagering that the designers of perl 6 tried to keep some of the perl 5 cultural and philosophical elements of the language when writing the new language (at least it sounds like they did based on what I've read so far).
The first time I wrote any serious code in Perl 6 (five years ago), I had to look up a few pieces of unfamiliar syntax, but the whole experience felt very comfortable. Perl 5 and Perl 6 share the same essence, the same perlishness.
I don't know. My interest lies in doing other things with Perl 6. I'd like to see a minimal hosting environment for Perl 6 applications based on something like Parrot bytecode, but we're not quite to the point where we can bundle an entire application, run it in its own memory space, and offer sandboxing and other limits.
(I agree completely about PHP's advantages in the cheap shared hosting world.)
Makes you figure there's a reason (La)TeX is still popular too, huh?
I see it this way: you get deployment right, you get ease of getting your first task done right, or you get libraries right. If you don't get any of those right, you get to work on screencasts.
If I'm programming in Python, then I'm not programming in Perl.
There are six and a half billion people in the world programming in neither. Now I suffer no illusion that all of them will become programmers, but it's no long bet to believe that more of them will become programmers. I care about that helping them solve their problems far more than about getting the mayfly attention of people who flit between the latest releases of dozens of languages, because the latter will move on to Haskell Prime or Java 7 or Factor soon enough anyway.
Slashdot Mirror
Not at all. Are you thinking of a metaobject protocol?
Roles provide compile-time method and dependency resolution. They're the antithesis of duck typing.
Moose is fully compatible with default Perl 5 OO.
That's a fair point until you use a module such as signatures or Method::Signatures.
Perl 5's default object system is basically Python's object system. Everything Python programmers complain about (explicit self) and everything Python programmers haven't figured out yet (the conflation of namespace and class with no distinguishing between function and method makes for fragile classes) is a misfeature shared between the two languages. Python offers little additional value there, and it suffers greatly when compared to Moose.
You only have to be able to understand subject/verb agreement in a spoken language (and you don't even have to know the term "subject/verb agreement"). That's one of the first things the book Modern Perl explains. (You can download it for free if you like.)
I've written a lot of Perl 5 over many years, and I can think of two or three I ever use. I could get that down to one.
Two substantial criticisms are "reference syntax is ugly", which is true and "most tutorials explain the language poorly", which is why I wrote what I believe to be a better book.
Parrot's 22nd release since 1.0 comes out next week.
On the contrary, that's the best way to create a usable specification.
Permit me to introduce you to the CPAN.
It's possible to do both, especially when you realize that optimizing a dynamic language well means understanding the 90% of the program you can optimize statically and doing so.
The words "professionals" and "volunteers" are compatible, especially when discussing free software projects.
In this case, read Perl's documentation for rand().
Some do, some don't. (Please refrain from committing the definitional fallacy.)
So do some dynamic languages.
I've programmed in too many languages to fall for such gross generalizations. Even if the point were correct and generally applicable, some languages allow coercion of null to appropriate values in certain circumstances (Perl's undef, for example) or allow you to implement the null object pattern through manipulation of base types (Smalltalk comes to mind). The point might be technically correct if you squint hard enough, but the implications are by no means as gross or widespread as the original post implies.
See pp to package Perl 5 applications into standalone distributions.
In a post full of nonsense, that quote sticks out as the strangest.
I'll take gems and the claims of "Ruby loves testing!" more seriously when gem tests run before installation.
Said "average person" was happy with a language which didn't use functions, which didn't use objects, which didn't use lexical scoping, which didn't use garbage collection, which didn't use JIT, which didn't have easy deployment, which didn't have libraries for network programming, which... well, sometimes the state of the art advances, and the average person could be a little bit more productive and write a little bit better code with a better tool.
Note, for example, that Ruby and Python have builtin regular expressions, their own library management systems inspired by the CPAN, and their own implementations of roles (of which I hear the authors of the Smalltalk traits paper have since suggested that statefulness is a virtue). Maybe they'll even get lexical scoping working one of these years.
If you have a test case which demonstrates that Perl 5 does the wrong thing, please submit it to p5p so that we can correct it. (See also the 23-year old file full of test cases which demonstrate that Perl does the right thing.)
What a shame you kept all of the inaccuracies in your comparisons, even after you responded to the corrections.
Larry and Damian have worked on outlines and have proposed various timelines for Programming Perl 6, but I don't know its current status. My company, Onyx Neon, has other Perl 6 books in process.
I recently moved my office, so I don't have my copy of The Practice of Programming handy. If you do, see chapter 9.
... and replaced with? Look at the Perl 6 RFCs and make something coherent out of them. If you can pull it off in less time than it took the Perl 6 designers, you deserve a Fields medal.
Have you tried Perl 6's type system? The combination of types, signatures, and multiple dispatch have ruined most other languages for me. (Pattern matching is a fine alternative in language which support that.)
Depending on who built the pyramids and how you interpret that strange passage in the Book of the Dead, yes. I realize that interpreting reports such as those from Gartner which suggest that the billion-plus personal computers in use now will become two-billion by 2014 requires similar skills, but those are the best numbers I've seen. (I've seen other suggestions that the number of personal computers available has averaged 12% annual growth over the past few years.) Do you have other statistics?
The first time I wrote any serious code in Perl 6 (five years ago), I had to look up a few pieces of unfamiliar syntax, but the whole experience felt very comfortable. Perl 5 and Perl 6 share the same essence, the same perlishness.
I don't know. My interest lies in doing other things with Perl 6. I'd like to see a minimal hosting environment for Perl 6 applications based on something like Parrot bytecode, but we're not quite to the point where we can bundle an entire application, run it in its own memory space, and offer sandboxing and other limits.
(I agree completely about PHP's advantages in the cheap shared hosting world.)
I see it this way: you get deployment right, you get ease of getting your first task done right, or you get libraries right. If you don't get any of those right, you get to work on screencasts.
There are six and a half billion people in the world programming in neither. Now I suffer no illusion that all of them will become programmers, but it's no long bet to believe that more of them will become programmers. I care about that helping them solve their problems far more than about getting the mayfly attention of people who flit between the latest releases of dozens of languages, because the latter will move on to Haskell Prime or Java 7 or Factor soon enough anyway.