Got it, thanks! We'll all stop now. You've saved us quite a bit of time.
Re:Slashdot to change? Not likely
on
Linuxworld Fun
·
· Score: 1
Not to flamebait here...
If you were truly concerned about the potential interpretations of your post, perhaps you should have checked Slash 1 against the current CVS tree. (I'd also like to see your version of the SQL commands which would be faster with subselects.) A good benchmark is much more difficult than a frantic hand-waving.
Canon, of course, being not so much a competitor as the company that makes the engines for HP laser printers....:)
Re:Did the author get paid?
on
Think Python
·
· Score: 1
O'Reilly also allows authors to choose whether to make the book freely available. It's part of the contract negotiation process. The most recent example that comes to mind is Free as in Freedom, which is still in print.
If you were adept enough to read that, surely you were clever enough to notice it's never PERL within the text of the man page. You might even have noticed a link to perlfaq1, which explains the joke.
I've personally noticed people who write PERL have a strong tendency to write awful code.
Pseudohashes were also supposed to improve performance. They did, by about 15%. Unfortunately, they worsened the performance of normal hashes by the same amount.
5.8.0 added "restricted" hashes, through Hash::Util, and the 'fields' pragma will continue to work. You're not sunk.
Being concise usually leads to unreadable code? I disbelieve your assertion, for it is well known that, as the length of description increases, the probability of overflowing the attention span and the number of ideas readers can keep in mind simultaneously increases. Consequently, one should strive to make things as simple as possible to ease understanding and uptake. I shall repeat the main ideas of this paragraph, restating them as briefly as possible, to underscore my point, to provide a memorable phrase, and to serve as an object lesson:
Oh no, we wasted our time! Our boss, Mr. Anonymous Coward doesn't like what we did! He'll fire us for sure! Quick, porters, let's rip out all of the things we wanted to work on for our own projects, and let this brave, kind soul show us the way!
Oh wait, you're talking about PERL I work on Perl. My mistake, sorry.
That's the size of the source code distribution, thanks to an increase in the number of modules in the core library and a tremendous growth in the test suite.
Apples are red, oranges are orange. Why would you write an application server, libraries, and development tools from scratch, when so many are already available for Perl?
We didn't force one programmer to sit around idly without a PC to play with while his "partner" was writing Mickey Mouse code to an agreed specification using automatic code-generation tools.
I'm not familiar with that particular XP practice. Your description has the most superficial similarities to pair programming, however. Can you elaborate on where you have encountered this variant?
if an open source programmer toils day and night "for fun", is it fair that someone takes all that work and sells it as if it were his own...like any Linux distro?
If I didn't find it fair, I wouldn't have chosen an open source license.
Re:Perl's had it's day - It's become like COBOL
on
Apocalypse 5 Released
·
· Score: 1
"Most people" aren't programmers. Why would you choose a programming language based on the technical recommendations of someone who has little basis for making such a suggestion?
It's a pun. Besides that, why can't "lone" be a plural adjective? Expand it to "alone", as its Middle English etymology could allow, and pick your preferred definition. "Exclusive" or "Only" would work.
(I can't believe I'm defending Chris Carter, though.)
It might even be a requirement to get a module into CPAN; I'm not sure.
It's not a requirement, but it is highly recommended (and easy) . If you add a new feature to Perl or fix a bug, tests and documentation are both required.
XP is designed to handle specification changes very well. Since it avoids the big design up front, it's
easier to recover from a change due to a misunderstanding or the customer changing his mind. The
point is to prevent recoding (or any sort of risk) by breaking a project into very small tasks, by
communicating regularly with the customer, by unit and acceptance testing, and by tackling the tasks
with the most business value in each iteration.
Design only what you need right away, and no more. If you have unit tests in place to exercise the code and if you have acceptance tests to exercise the specification and if you have refactorable (and refactored code) in the simplest possible state, the cost of change goes way down.
Even if the hardware were free, it, in and of itself, has no effect on the affordability of the software itself. The customer, if anything, has MORE money to spend on the OS (remember, an OS can save or cost you time and effort).
Would you buy a new car for $5000 if it required fuel costing $3.50 per gallon? After all, you've saved between seven and ten thousand dollars on the price of the car.
From a simple economic sense, you may be right. I'm not sure people want to see their bargains eaten up by recurring costs, though.
Slashdot Mirror
Got it, thanks! We'll all stop now. You've saved us quite a bit of time.
If you were truly concerned about the potential interpretations of your post, perhaps you should have checked Slash 1 against the current CVS tree. (I'd also like to see your version of the SQL commands which would be faster with subselects.) A good benchmark is much more difficult than a frantic hand-waving.
Canon, of course, being not so much a competitor as the company that makes the engines for HP laser printers.... :)
O'Reilly also allows authors to choose whether to make the book freely available. It's part of the contract negotiation process. The most recent example that comes to mind is Free as in Freedom, which is still in print.
If you were adept enough to read that, surely you were clever enough to notice it's never PERL within the text of the man page. You might even have noticed a link to perlfaq1, which explains the joke.
I've personally noticed people who write PERL have a strong tendency to write awful code.
Pseudohashes were also supposed to improve performance. They did, by about 15%. Unfortunately, they worsened the performance of normal hashes by the same amount.
5.8.0 added "restricted" hashes, through Hash::Util, and the 'fields' pragma will continue to work. You're not sunk.
Being concise usually leads to unreadable code? I disbelieve your assertion, for it is well known that, as the length of description increases, the probability of overflowing the attention span and the number of ideas readers can keep in mind simultaneously increases. Consequently, one should strive to make things as simple as possible to ease understanding and uptake. I shall repeat the main ideas of this paragraph, restating them as briefly as possible, to underscore my point, to provide a memorable phrase, and to serve as an object lesson:
Oh no, we wasted our time! Our boss, Mr. Anonymous Coward doesn't like what we did! He'll fire us for sure! Quick, porters, let's rip out all of the things we wanted to work on for our own projects, and let this brave, kind soul show us the way!
Oh wait, you're talking about PERL I work on Perl. My mistake, sorry.
Visual Basic compiles to C?
Yes, pseudohashes are deprecated in Perl 5.8.0. They will be removed completely in Perl 5.10.0.
That's the size of the source code distribution, thanks to an increase in the number of modules in the core library and a tremendous growth in the test suite.
Apples are red, oranges are orange. Why would you write an application server, libraries, and development tools from scratch, when so many are already available for Perl?
They do both have a sort of anti-troll sentiment...
Perl has buffer overflows? In my mind, it's one of a class of languages particularly immune from that sort of thing. Did I misunderstand your example?
I'm not familiar with that particular XP practice. Your description has the most superficial similarities to pair programming, however. Can you elaborate on where you have encountered this variant?
If I didn't find it fair, I wouldn't have chosen an open source license.
If I were you, I'd abbrev. the long words.
"Most people" aren't programmers. Why would you choose a programming language based on the technical recommendations of someone who has little basis for making such a suggestion?
Neither could you.
It's a pun. Besides that, why can't "lone" be a plural adjective? Expand it to "alone", as its Middle English etymology could allow, and pick your preferred definition. "Exclusive" or "Only" would work.
(I can't believe I'm defending Chris Carter, though.)
I was considering writing a review, actually. It's well-worth reading.
XP is designed to handle specification changes very well. Since it avoids the big design up front, it's easier to recover from a change due to a misunderstanding or the customer changing his mind. The point is to prevent recoding (or any sort of risk) by breaking a project into very small tasks, by communicating regularly with the customer, by unit and acceptance testing, and by tackling the tasks with the most business value in each iteration.
Design only what you need right away, and no more. If you have unit tests in place to exercise the code and if you have acceptance tests to exercise the specification and if you have refactorable (and refactored code) in the simplest possible state, the cost of change goes way down.
You're not the only one. It's possible, and I (who have absolutely no control and probably no influence) think it's a great idea.
From a simple economic sense, you may be right. I'm not sure people want to see their bargains eaten up by recurring costs, though.