Very outdated, and for a period in which the only Ruby on Rails book had just come out and in which there were no new Perl books released. The initial sell-in period of a book's first printing is almost always a huge spike, as sales representatives concentrate on sales into channels for the months leading up to a release, in hopes of generating big frontlist sales and strong potential for backlist sales as the inventory management within the channels shuffles the physical copies to the places where they sell best.
Anyway, I'll grant you that Ruby book sales in one quarter did best Perl book sales. How about the rest of the statistics, showing that people are abandoning Perl and Python in droves for Ruby?
I'm just a bit tired of hearing people advocating it, when there's still close to nothing to show for it after 7 years of planning and some rudimentary prototyping.
That's nice.
I'm a lot tired of Internet blowhards thinking that they have all of the brilliant answers to the thorny software development problem of "Good, cheap, or fast -- pick two!" when we've already chosen "Good" and we've never not been able to pick "Cheap". I'm sure I don't have to tell you that Microsoft spent more money on paying the salaries of its Vista developers during their coffee breaks for one week than we've spent on Perl 6 in at least the past three years.
If you have a solution, please join one of the IRC channels or one of the mailing lists and enlighten us. "Code faster", "Stop trying," and "Release something that's not what you want to release nor meets your standards of quality or the reason you started this project," are unacceptable solutions. (See Can't You Just...? and Can't You Just...? redux.)
Are you talking 20,000 lines of code or 200,000 lines of code?
20,000 lines of Perl is a moderately big program. It's probably equal in complexity to at least 250,000 lines of C, perhaps 500,000. Do you count SLOC for CPAN libraries too? Do you count the SLOC for shared libraries used in the C program?
Perl6 is the Duke Nukem Forever of computer languages.
Duke Nukem Forever is written entirely by volunteers for almost no money, and is being developed entirely in public, with the source code available now and forever? Someone tell George Broussard.
I have not used Perl for a while but when I did I would have called it a scripting language. It just didn't lend it's self to large programs.
Why not? I've used it for large programs that are still in place. You're reading the output from one of them right now.
(You won't hear me arguing that Slash is and has always been a good example of maintainable Perl code, but you won't hear Cmdr Taco arguing that he's a good example of a programmer either.)
Larry wrote, "Ruby kind of screwed up on its declaration syntax". What is he referring to?
Ruby variables automagically spring into existence on first declaration. This happened in Perl 1 - 4 and also Perl 5 by default, though if you use the strict pragma, Perl will warn you about the use of undeclared variable names. (This is why he mentioned the my operator in Perl somewhere near that quote.)
Perl 6 requires variable declarations for everything except one-liners.
Larry still doesn't seem to get that languages like Python and Ruby have surpassed Perl because they are easier on the eyes.
Statistics, please. (Your assertion doesn't match the statistics we're seeing at O'Reilly, surveying job advertisement data and book sales.)
The last thing I want to do on Monday is pour over a thousand lines of Perl code trying to figure out what some hack was trying to do.
s/Perl// in that sentence, or have you never seen the horrors that barely-competent monkeys perpetuate upon the world in any language you tell them to use? (s/(po)ur/$1re/ too, while I'm in a regex mood.)
If this isn't relevant to the conversation per the mods, then may they all write a million lines of Perl and then be forced to maintain it for all eternity.
I've written plenty of Perl in my day, and I don't mind maintaining it. Of course, I know what I'm doing, I practice TDD, I refactor mercilessly, I choose good names....
Re:Perl 6: The Language of the Future (... Forever
on
State of the Onion 11
·
· Score: 1
A language with a clean design means that you can collaborate with others.
That sounds great, until you're trying to work with code written by a barely-competent monkey who has no business sitting in front of a keyboard, or in a business domain where you have absolutely no experience, or any of a dozen scenarios that have a greater influence on maintainability than choice of language.
I think "scripting language" refers to the idea that what you write in the program happens in that order.
I don't understand what you mean by this. All of these languages have flow control.
That's not like C or Java, when what happens when the program runs is what is inside the main function (or static method). And that happens only after you turned your text file into something else.
PIR on Parrot runs what's inside the function annotated as:main, but it does so whether the file is text or processed bytecode. Besides that, I could write a C or Java interpreter if I really wanted to which could work on source code.
"Say" implies speach, not text and substituting it for "print" or "printf" (println is Pascal) simply because it's "shorter" is silly...
You might as well say that print implies hot metal plates covered in ink, write implies scribes, and puts is a misspelling of a Yiddish euphemism. Everything in a digital computer is a metaphor, including data structures more complex than a single bit. The forces of anti-silly lost their battle years ago, probably even before there were moths... er, bugs.
Why can Microsoft not slip release dates without getting flack, but it's okay for open source projects?
Microsoft developers waste more paid development time checking e-mail and chatting around the water cooler in a week than most F/OSS projects ever have.
I just looked up the meaning of 'evangelist' for curiosity's sake, and it means, in Latin, a person who brings the word of God. Notice that the word contains 'angel'.
It's Greek, actually. The word comes from eu, which means "good", and angelos, which means "messenger". New Testament Greek tends to use angelos to mean "messenger from God", but that's a specialization of an existing word.
Rails is just as extensible as Catalyst, if not moreso...
Have you ever tried to swap out ActiveRecord in its entirety for something else? The corresponding change in Catalyst is much easier than in Rails. (Rails 2.0 might have changed this; I don't know.) Rails is very proudly opinionated, while Catalyst goes to great lengths not to enforce any single particular component.
... how come the Perl community is tripping over itself to be Rails all of a sudden?
Nice synecdoche, but Auntie Beeb's programmers are really not the whole of the Perl community. Plenty of the Perl community doesn't care one whit for web programming, for starters.
You can't judge a language on its own. You have to judge programs written in that language, and those depend on plenty of external critera: the problem domain, the experience of the original author in that problem domain, the experience of that author in the language, the quality of the code, and more.
What is unclear to me is just what branch of human sciences studies what kinds of similarities and differences programmers are looking for.
I think it's a combination of computer science and linguistics, with some degree of human factors included. There are a lot of ways to analyze a programming language -- ease of use, ease of learning, succinctness, power, abstraction possibilities -- but there's relatively little debate over existing languages along those lines beyond "I don't know Perl and I don't like its syntax" or "Java needs closures".
I'm well aware that some people have tried both languages and prefer the syntax of Python to Perl (and vice versa; vertical whitespace rules drive me crazy), and that's fine. I work on Perl because I find that it offers a nice answer to some of those questions, and I think that we can improve the answer even further in Perl 6 for the several billion potential programmers in the world. I also don't mind explaining why certain things are they way they are, at least to people willing to ask questions smarter than "How can anyone read all those punctuation characters?"
But since I have you on the line, so to speak, are you in fact asserting that Perl is like natural languages?
Yes, to some degree. The primary goal of Perl, like other programming languages, is to communicate with other programmers. There appear to be two schools of thought on how to do this. One of them comes from the mathematicians, who appreciate simplicity and uniformity of expression (as least per their on definitions of both) as a primary design criterion. The other comes from the linguists, who (in my opinion) have somewhat better ideas of how people (not just mathematicians) really communicate.
I'm not saying that one is bad and the other is good. You'd never likely get the Turing model or the lambda calculus out of a linguist, for example, and COBOL and AppleScript aren't great examples of applying linguistic principles to language design either -- so there's a balance to strike between them.
I'm not sure either linguistics or computer-language development is well served by this comparison.
I agree to some degree, but just because no one has ever done it perfectly doesn't mean it's not worth doing.
On a day-to-day basis, does it actually guide your choices about the language?
Yes, actually. Remember that Perl is an artificial language, so it can simultaneously be more and less a pastiche than English. Consistency and syntactical similarity of semantics are important in natural language (avoid false cognates) but even more so in a programming language. The Perl 6 designers believe strongly that similar things should look similar and dissimilar things should look dissimilar. As well, concepts such as noun markers and subject-verb agreement (context) are present in Perl, as well as pronouns (topicalization). This brings up other problems such as ambiguous antecedents.
The designers evaluate new operators and concepts in terms quite heavily. Mnemonics are important, as well as the proper length of identifiers and semantics of their names. For example, Perl 6 uses say instead of println because we believe it will be a frequent operation -- more frequent than print and as such deserves a shorter identifier. Whatever the syntax for accessing the current continuation will be, it's likely to be somewhat longer, as it's not something we want people to need to use more than a few times.
When I was first learning perl, I couldn't make sense of why ex. push/^\s*#/ ? @c : @d, $_ wasn't working.
That one's pretty easy. It's because there's a hard-coded prototype (in Perl 5 terms) in the parser that prevents the automatic flattening of an array when it's the first argument to push. Of course, your jab about "macro toy language" isn't fair. I can't think of a language with operator precedence and nested expressions that doesn't have to do something similar in certain places.
... the notion that Perl "has a striking resemblance to natural language" is a dream of people who don't really know much about how "natural language" looks, i.e., non-linguists.
... and several of the other trained linguists who use and develop Perl.
Surely at some point (probably later, rather than sooner) the number of users who aren't duped by spam will be such that spammers will have no market.
What makes you think that the people sending the spam care if there's a market for the products advertised through spam? As long as there are people gullible enough to hire spammers, spammers will happily send spam without caring if anyone ever reads it. The profit for spammers is in between advertisers and recipients.
Slashdot Mirror
Female character sniffed. "Wooly-headed men," she thought.
Male character sighed. "If only other male character were here," he thought. "He understands women."
Very outdated, and for a period in which the only Ruby on Rails book had just come out and in which there were no new Perl books released. The initial sell-in period of a book's first printing is almost always a huge spike, as sales representatives concentrate on sales into channels for the months leading up to a release, in hopes of generating big frontlist sales and strong potential for backlist sales as the inventory management within the channels shuffles the physical copies to the places where they sell best.
Anyway, I'll grant you that Ruby book sales in one quarter did best Perl book sales. How about the rest of the statistics, showing that people are abandoning Perl and Python in droves for Ruby?
That's nice.
I'm a lot tired of Internet blowhards thinking that they have all of the brilliant answers to the thorny software development problem of "Good, cheap, or fast -- pick two!" when we've already chosen "Good" and we've never not been able to pick "Cheap". I'm sure I don't have to tell you that Microsoft spent more money on paying the salaries of its Vista developers during their coffee breaks for one week than we've spent on Perl 6 in at least the past three years.
If you have a solution, please join one of the IRC channels or one of the mailing lists and enlighten us. "Code faster", "Stop trying," and "Release something that's not what you want to release nor meets your standards of quality or the reason you started this project," are unacceptable solutions. (See Can't You Just...? and Can't You Just...? redux.)
20,000 lines of Perl is a moderately big program. It's probably equal in complexity to at least 250,000 lines of C, perhaps 500,000. Do you count SLOC for CPAN libraries too? Do you count the SLOC for shared libraries used in the C program?
Duke Nukem Forever is written entirely by volunteers for almost no money, and is being developed entirely in public, with the source code available now and forever? Someone tell George Broussard.
Why not? I've used it for large programs that are still in place. You're reading the output from one of them right now.
(You won't hear me arguing that Slash is and has always been a good example of maintainable Perl code, but you won't hear Cmdr Taco arguing that he's a good example of a programmer either.)
Ruby variables automagically spring into existence on first declaration. This happened in Perl 1 - 4 and also Perl 5 by default, though if you use the strict pragma, Perl will warn you about the use of undeclared variable names. (This is why he mentioned the my operator in Perl somewhere near that quote.)
Perl 6 requires variable declarations for everything except one-liners.
Not everyone wants to suckle at the teat of Microsoft hanging out of a Novell uniform.
Ideas are cheap. Let's see your code. You can find my Perl 6 code all over the Internet. Start with Parrot.
I've had working Perl 6 code running (and published on the Internet publicly for everyone to see) for two and a half years now. Please try to keep up.
Statistics, please. (Your assertion doesn't match the statistics we're seeing at O'Reilly, surveying job advertisement data and book sales.)
s/Perl// in that sentence, or have you never seen the horrors that barely-competent monkeys perpetuate upon the world in any language you tell them to use? (s/(po)ur/$1re/ too, while I'm in a regex mood.)
I've written plenty of Perl in my day, and I don't mind maintaining it. Of course, I know what I'm doing, I practice TDD, I refactor mercilessly, I choose good names....
That sounds great, until you're trying to work with code written by a barely-competent monkey who has no business sitting in front of a keyboard, or in a business domain where you have absolutely no experience, or any of a dozen scenarios that have a greater influence on maintainability than choice of language.
I don't understand what you mean by this. All of these languages have flow control.
PIR on Parrot runs what's inside the function annotated as :main, but it does so whether the file is text or processed bytecode. Besides that, I could write a C or Java interpreter if I really wanted to which could work on source code.
You might as well say that print implies hot metal plates covered in ink, write implies scribes, and puts is a misspelling of a Yiddish euphemism. Everything in a digital computer is a metaphor, including data structures more complex than a single bit. The forces of anti-silly lost their battle years ago, probably even before there were moths... er, bugs.
Microsoft developers waste more paid development time checking e-mail and chatting around the water cooler in a week than most F/OSS projects ever have.
It's Greek, actually. The word comes from eu, which means "good", and angelos, which means "messenger". New Testament Greek tends to use angelos to mean "messenger from God", but that's a specialization of an existing word.
I believe this is the 4GL fallacy.
Have you ever tried to swap out ActiveRecord in its entirety for something else? The corresponding change in Catalyst is much easier than in Rails. (Rails 2.0 might have changed this; I don't know.) Rails is very proudly opinionated, while Catalyst goes to great lengths not to enforce any single particular component.
Nice synecdoche, but Auntie Beeb's programmers are really not the whole of the Perl community. Plenty of the Perl community doesn't care one whit for web programming, for starters.
You can't judge a language on its own. You have to judge programs written in that language, and those depend on plenty of external critera: the problem domain, the experience of the original author in that problem domain, the experience of that author in the language, the quality of the code, and more.
I think it's a combination of computer science and linguistics, with some degree of human factors included. There are a lot of ways to analyze a programming language -- ease of use, ease of learning, succinctness, power, abstraction possibilities -- but there's relatively little debate over existing languages along those lines beyond "I don't know Perl and I don't like its syntax" or "Java needs closures".
I'm well aware that some people have tried both languages and prefer the syntax of Python to Perl (and vice versa; vertical whitespace rules drive me crazy), and that's fine. I work on Perl because I find that it offers a nice answer to some of those questions, and I think that we can improve the answer even further in Perl 6 for the several billion potential programmers in the world. I also don't mind explaining why certain things are they way they are, at least to people willing to ask questions smarter than "How can anyone read all those punctuation characters?"
What are you talking about? PERL was never a good language. Fortunately, it was never as popular as Perl, despite having a confusingly similar name.
Why not just print @bar;?
Yes, to some degree. The primary goal of Perl, like other programming languages, is to communicate with other programmers. There appear to be two schools of thought on how to do this. One of them comes from the mathematicians, who appreciate simplicity and uniformity of expression (as least per their on definitions of both) as a primary design criterion. The other comes from the linguists, who (in my opinion) have somewhat better ideas of how people (not just mathematicians) really communicate.
I'm not saying that one is bad and the other is good. You'd never likely get the Turing model or the lambda calculus out of a linguist, for example, and COBOL and AppleScript aren't great examples of applying linguistic principles to language design either -- so there's a balance to strike between them.
I agree to some degree, but just because no one has ever done it perfectly doesn't mean it's not worth doing.
Yes, actually. Remember that Perl is an artificial language, so it can simultaneously be more and less a pastiche than English. Consistency and syntactical similarity of semantics are important in natural language (avoid false cognates) but even more so in a programming language. The Perl 6 designers believe strongly that similar things should look similar and dissimilar things should look dissimilar. As well, concepts such as noun markers and subject-verb agreement (context) are present in Perl, as well as pronouns (topicalization). This brings up other problems such as ambiguous antecedents.
The designers evaluate new operators and concepts in terms quite heavily. Mnemonics are important, as well as the proper length of identifiers and semantics of their names. For example, Perl 6 uses say instead of println because we believe it will be a frequent operation -- more frequent than print and as such deserves a shorter identifier. Whatever the syntax for accessing the current continuation will be, it's likely to be somewhat longer, as it's not something we want people to need to use more than a few times.
That one's pretty easy. It's because there's a hard-coded prototype (in Perl 5 terms) in the parser that prevents the automatic flattening of an array when it's the first argument to push. Of course, your jab about "macro toy language" isn't fair. I can't think of a language with operator precedence and nested expressions that doesn't have to do something similar in certain places.
... and several of the other trained linguists who use and develop Perl.
What makes you think that the people sending the spam care if there's a market for the products advertised through spam? As long as there are people gullible enough to hire spammers, spammers will happily send spam without caring if anyone ever reads it. The profit for spammers is in between advertisers and recipients.