No one has to fix bugs in Perl 5 besides a couple of people at ActiveState, which has customers. People work on Perl 5 because they want to. (I still send in patches occasionally, even if I spend most of my available time working on Parrot.)
If total depravity due to original sin were an issue in the New Testament, I would expect it to say something about infant baptism and not tie baptism to actions of knowledge such as repentence, faith, and confession. (You probably should have quoted the fifth chapter of Paul's epistle to the Romans, as well.)
I really do recommend reading the anti-Nicene fathers on this issue. It's very interesting to compare them to the post-Nicene fathers especially on the issue of Mary and virginity. In particular, only post-Augustine does the question arise as to the circumstances of her conception.
... and yet the "total depravity" argument and the "the original sin is procreation" argument didn't appear in any documented form in mainstream early Christian thought until Augustine, and only those theological families which spring from Augustinianism follow those beliefs. Given nearly three centuries from a very conservative dating of the earliest parts of the New Testament and the Council of Nicea, the lack of manuscript evidence for both beliefs prior to Augustine is rather telling that he provided the first documented apology for such beliefs.
Because of this so hailed 'flexibility' I now have to install two *complete* desktop environments, just because the program I want to use happens to use 'the other one'.
That sounds like a packaging bug to me, honestly. Even if your KDE- or QT-based torrent client did mark dependencies on all of KDE, certainly having your package manager download all of the dependencies correctly is a huge advantage over almost all software installation I've seen on other platforms.
Comparing this to proprietary OSs makes you wonder why the open source community still doesn't 'get' it (I mean, examples enough).
Rhetorical question: is comparing the whole of software installed by default (or provided in a repository) by any random Linux distribution really comparable to the paucity of software installed by default by a proprietary operating system?
Certainly, as you say, "examples enough" if you expand your comparison to include thousands of proprietary software packages from thousands of vendors.
To be fair, Java has included generic typing as of version 1.5.
Can you really call that type safety? I have the impression that real type safety requires type information to exist. If your preprocessor erases it, it's not there.
There is nothing I know like [Inversion of Control] for any other language...
I'm not sure if you mean "I only know Java", "I didn't know that IoC is a 20 year old pattern", "I don't know that IoC and event-driven programming are almost completely isomorphic", or something else. Can you elaborate?
Java doesn't have to be over engineered,and I would hardly call its object model a toy ( cough perl/php objects are toys cough cough).
I'm not an expert on PHP objects, but Perl objects are typesafe through collections, they do support dynamic invocation, and they do support the method missing operation.
Are you claiming that Java's lack of those features makes it not a toy?
And yet, implementations of plenty of dynamic languages (Groovy, Python, Ruby, Scheme, etc.) exist on the JVM, often with comparable (or better) performance on similar hardware to the dominant native implementations, where non-JVM implementations exist.
To accomplish that, sometimes you have to throw out some of the dynamicism of the language (ObjectSpace in JRuby, for example). Other times, you do take advantage of all of the compiler and optimization work poured into the JVM... at least on those platforms where it runs. (Perl 5 is more portable than the JVM.)
Of course, as the JVM lacks an invoke-dynamic opcode, you have to emulate it at a level higher than JVM opcodes. That is to say, every language that needs an invoke-dynamic opcode (every language with late binding) has to reinvent the same thing, and optimizing one doesn't optimize the others. The same goes for plenty of other nice features found in dynamic languages such as lexical scoping, closures, first-class functions, multiple dispatch, run-time class generation, method missing, etc.
The fact that certain benchmarks run faster on the JVM implementations than the native implementations is a demonstration that the JVM has nice optimizations, not that it's an easy or full-featured platform on which to build a dynamic language. (C's not a very nice platform on which to build a dynamic language either, but it's possible there too.)
... if you have these four features, you can build nearly every interesting feature of any other language out there on top of them.
Similarly, it's possible to build just about any type of object system atop the Perl 5 object system. You can even build a CLOS-style object system (though it does take a bit of work to get multiple dispatch to work correctly.)
However, the result should be clear to anyone who remembers Lisp pre-CLOS or who's tried to work with code which uses several object systems built on Perl 5 in the same program, or any Tcl programmers: sometimes providing one good and sane default that works for 95% of the uses is better than giving everyone the same tiny box of carefully-crafted tools and patting yourself on the back for adhering to a mathematical model of purity that breaks down when you don't invent everything from scratch for each tiny program.
You wrote bad code, and it's the language's fault? Did a camel lock you in a room and force you not to write good code? Did a llama threaten to burn down your house unless you removed all unnecessary whitespace and used only single-letter variable names?
Don't pat yourself on the back too much. You could write something even more vague and content-free. How about:
Python is like wearing a hat. People will stop you on the street and say, "My my, how dapper you look! Why, I don't remember the last time most people wore wonderful hats like yours! Toodle-oo!" Contrarily, Perl is like not wearing a hat. Maybe it's like wearing a vest that no one can see.
I leave it to the reader to draw his or her own conclusions about which language is better.
I very honestly believe the decision to run with a register machine is because Java and.Net didn't.
I believe that a lot of the decision is because Perl 5's stack-based architecture is the source of much frustration.
I got the distinct impression the devs hadn't read one page of Java or.Net VM specs.
.Net VM of course; even if there were a time machine available to read those specifications, I wouldn't touch encumbered specs if I had any intention of working on a F/OSS project.
As well, you're assuming that none of the Parrot developers have read some of the studies done on optimizing the JVM by switching to a register-based architecture, such as Shi, Gregg, & Beatty 2005.
Why?...news to me.
If the last time you checked in on the project was before 2005, your opinions are very out of date.
Maybe you were expecting to be able to write several lines of code in a lambda function? To me, that would make the code much less readable.
That seems like a tautology. You don't know why it's useful to have lambdas containing more than one expression, so you can't imagine trying to read them. I recommend the book The Little Schemer; it's easy to read and very enlightening.
If Scheme isn't your bag, then play with Ruby's blocks sometime. They're essentially lambdas, and they can be arbitrarily complex. (There are some semantic warts with the way Ruby's operators and especially functions handle them sometimes, but that doesn't hurt the idea.)
Perhaps the best way to explain it is so say that a lambda represents a reusable and modular chunk of behavior. Sometimes you want to name them. Other times you don't. (I'm sure you wouldn't want to think up a unique name for each iteration block in your program.) Limiting lambdas to a single expression in Python (and enforcing read-only closures) limits some of their applicability and power for abstractions. Scheme and Lisp go a long way by more-or-less considering lambda application the fundamental unit of computations.
Slashdot Mirror
That's a big assumption! My wild guess is that maybe one out of four bug reports have enough information to reproduce the bug.
No one has to fix bugs in Perl 5 besides a couple of people at ActiveState, which has customers. People work on Perl 5 because they want to. (I still send in patches occasionally, even if I spend most of my available time working on Parrot.)
The AC meant that there are Perl 6 implementations which run on Parrot, a Haskell backend, and a CL backend. (There's also a Perl 5 backend.)
Very true, but we do give you the complete source code to all of our older versions. Go crazy.
If total depravity due to original sin were an issue in the New Testament, I would expect it to say something about infant baptism and not tie baptism to actions of knowledge such as repentence, faith, and confession. (You probably should have quoted the fifth chapter of Paul's epistle to the Romans, as well.)
I really do recommend reading the anti-Nicene fathers on this issue. It's very interesting to compare them to the post-Nicene fathers especially on the issue of Mary and virginity. In particular, only post-Augustine does the question arise as to the circumstances of her conception.
... and yet the "total depravity" argument and the "the original sin is procreation" argument didn't appear in any documented form in mainstream early Christian thought until Augustine, and only those theological families which spring from Augustinianism follow those beliefs. Given nearly three centuries from a very conservative dating of the earliest parts of the New Testament and the Council of Nicea, the lack of manuscript evidence for both beliefs prior to Augustine is rather telling that he provided the first documented apology for such beliefs.
Nit: Augustine of Hippo didn't write any part of what most Christians consider to be the Bible.
The EU is jealous of Florida's particular geography?
That sounds like a packaging bug to me, honestly. Even if your KDE- or QT-based torrent client did mark dependencies on all of KDE, certainly having your package manager download all of the dependencies correctly is a huge advantage over almost all software installation I've seen on other platforms.
Rhetorical question: is comparing the whole of software installed by default (or provided in a repository) by any random Linux distribution really comparable to the paucity of software installed by default by a proprietary operating system?
Certainly, as you say, "examples enough" if you expand your comparison to include thousands of proprietary software packages from thousands of vendors.
Can you really call that type safety? I have the impression that real type safety requires type information to exist. If your preprocessor erases it, it's not there.
I'm not sure if you mean "I only know Java", "I didn't know that IoC is a 20 year old pattern", "I don't know that IoC and event-driven programming are almost completely isomorphic", or something else. Can you elaborate?
I'm not an expert on PHP objects, but Perl objects are typesafe through collections, they do support dynamic invocation, and they do support the method missing operation.
Are you claiming that Java's lack of those features makes it not a toy?
Unless you mean argument unpacking or call by reference when accessing @_ directly, I have no idea what you mean. Can you elaborate?
To accomplish that, sometimes you have to throw out some of the dynamicism of the language (ObjectSpace in JRuby, for example). Other times, you do take advantage of all of the compiler and optimization work poured into the JVM... at least on those platforms where it runs. (Perl 5 is more portable than the JVM.)
Of course, as the JVM lacks an invoke-dynamic opcode, you have to emulate it at a level higher than JVM opcodes. That is to say, every language that needs an invoke-dynamic opcode (every language with late binding) has to reinvent the same thing, and optimizing one doesn't optimize the others. The same goes for plenty of other nice features found in dynamic languages such as lexical scoping, closures, first-class functions, multiple dispatch, run-time class generation, method missing, etc.
The fact that certain benchmarks run faster on the JVM implementations than the native implementations is a demonstration that the JVM has nice optimizations, not that it's an easy or full-featured platform on which to build a dynamic language. (C's not a very nice platform on which to build a dynamic language either, but it's possible there too.)
Similarly, it's possible to build just about any type of object system atop the Perl 5 object system. You can even build a CLOS-style object system (though it does take a bit of work to get multiple dispatch to work correctly.)
However, the result should be clear to anyone who remembers Lisp pre-CLOS or who's tried to work with code which uses several object systems built on Perl 5 in the same program, or any Tcl programmers: sometimes providing one good and sane default that works for 95% of the uses is better than giving everyone the same tiny box of carefully-crafted tools and patting yourself on the back for adhering to a mathematical model of purity that breaks down when you don't invent everything from scratch for each tiny program.
You wrote bad code, and it's the language's fault? Did a camel lock you in a room and force you not to write good code? Did a llama threaten to burn down your house unless you removed all unnecessary whitespace and used only single-letter variable names?
That's manifest typing.
My favorite definition of "strong typing" comes from Shriram Krishnamurthi's Programming Languages: Application and Interpretation (p. 205):
Benjamin Pierce (author of Types and Programming Languages) wrote something similar (see Mark Jason Dominus quoting Pierce on "____ typing"):
Unless you're talking about how hard you have to hit the keys, you're wrong. Even after generics, you're wrong.
You're probably thinking of the web programming language PERL, which is basically a joke. This article is about Perl.
Come up with that one all by yourself, did you? Hilarious.
Don't pat yourself on the back too much. You could write something even more vague and content-free. How about:
I leave it to the reader to draw his or her own conclusions about which language is better.
I think you mean "us poor sheeple". "Morons" isn't nearly elitist enough.
I believe that a lot of the decision is because Perl 5's stack-based architecture is the source of much frustration.
.Net VM of course; even if there were a time machine available to read those specifications, I wouldn't touch encumbered specs if I had any intention of working on a F/OSS project.
As well, you're assuming that none of the Parrot developers have read some of the studies done on optimizing the JVM by switching to a register-based architecture, such as Shi, Gregg, & Beatty 2005.
If the last time you checked in on the project was before 2005, your opinions are very out of date.
That seems like a tautology. You don't know why it's useful to have lambdas containing more than one expression, so you can't imagine trying to read them. I recommend the book The Little Schemer; it's easy to read and very enlightening.
If Scheme isn't your bag, then play with Ruby's blocks sometime. They're essentially lambdas, and they can be arbitrarily complex. (There are some semantic warts with the way Ruby's operators and especially functions handle them sometimes, but that doesn't hurt the idea.)
Perhaps the best way to explain it is so say that a lambda represents a reusable and modular chunk of behavior. Sometimes you want to name them. Other times you don't. (I'm sure you wouldn't want to think up a unique name for each iteration block in your program.) Limiting lambdas to a single expression in Python (and enforcing read-only closures) limits some of their applicability and power for abstractions. Scheme and Lisp go a long way by more-or-less considering lambda application the fundamental unit of computations.