Parrot's register scheme really does help, as do PMCs, which allow much better polymorphism and much better extendability than Perl 5's built-in ADTs. Of course, the JIT and scary goto core don't hurt op execution and dispatch either.
I didn't mention that I prefer PIR so as not to confuse people, but you're right -- I much prefer writing for IMCC than for raw Parrot. Thankfully, having to care about the distinction mostly went away a long time ago.
Parrot is indeed register based. At least when compared to Perl 5, this is a tremendous advantage. Perl 5's VM spends a lot of time fiddling with its stack (pushing a marker on, pushing arguments on, pulling arguments off and checking for a marker) that Parrot can avoid altogether. Of course, that means that Parrot needs to spend time saving and restoring register stacks, but Dan's position is that there's enough good research on the subject to make optimizations practical.
Plus writting in parrot asm is fun!
Tell me about it. I'm a day or two from checking in simple-but-useful OpenGL bindings.
You only have to recompile XS modules if the new version of Perl has broken binary compatibility. That happens sometimes with major releases (between 5.6.x and 5.8.x), but rarely in minor releases. It's actually a goal that 5.8.x releases all have binary compatibility. If a release breaks that, Nick'll release a new version very quickly if at all possible.
You're right about Perl 6's successor to XS, though. It's NCI and it's fabulous, even now.
Unix Power Tools was definitely an inspiration for the Hacks series. Fortunately, the Hacks are a lot shorter, a lot more focused, a lot less expensive, and very much easier to write.
Re:Legitimate question.
on
BSD Hacks
·
· Score: 4, Informative
The goal of a Hacks book is much different from a Cookbook. A Cookbook will cover everything common you'll eventually want to do. A Hack will cover things you may never have known you want to do, but will want to do after you read them.
(I edited this book, so that was my goal at least.)
I think there is a driving market force, one which you alluded to.
Any product has at least two main categories of costs, design and manufacturing. Software manufacturing costs -- making enough duplicates for all of your customers -- are low. If someone can design (and, in this case, write) the software for a low cost, he can sell it cheaply or even give it away.
As soon as someone gives away a good enough solution, there are price pressures on everyone else. They have to prove they're worth the money somehow. How do you compete in a market that suddenly has an infinite supply, though?
I was specifically thinking of the Color LaserJet 8500, which did have a Canon engine but had little connection to HP except for the name, some of the design, and most of the selling. While it was a nice machine, the external entity which actually built the thing couldn't figure out how to make a PCL engine, so HP had to ship extra firmware six months after introducing the printer.
That's embarassing because the alternative was Adobe's PostScript.
Please don't repost our articles without permission. (I've never denied permission to anyone who asked, but we have several speedy servers and a lot of bandwidth.)
The depth is my fault. We normally run articles under 2000 words and I guided Ed to write for that length.
I'd also like to see a deep analysis of how programming has changed (or hasn't) in the past forty years, but that seems like a Master's thesis, not an article. Maybe next year.
Spam is fundamentally identical to telemarketing and direct postal mail.
Not in my case; I don't pay extra to receive telemarketing calls or junk mail. Nor does the telephone company or post office block my driveway so I cannot drive to work in the morning. However, spammers have hit my mail server so hard that it cut off my connection to the outside world, preventing me from working from home.
Don't misuse the word criminal, please.
When a spammer takes advantage of a poorly secured system belonging to another person without permission and forges the e-mail addresses of other innocent people not involved in spamming, I will use the word "criminal". I know of no better way to summarize fraud, theft, and trespass.
When you give your email to a website operator, and that website operator sells it, that money is what keeps your content cheap or free.
When I write free software and distribute it for free (with my e-mail address in the documentation so people can contact me or know that I contributed to the project) and I receive spam, how does your argument make sense? There are hundreds of thousands of computers with my e-mail address stored in credits files somewhere; how does this keep the Internet free?
However, it does make one wonder why O'Reilly would publish it.
Because in the thirty years since Brooks wrote the first edition, computers are a few times more powerful, at least an order of magnitude cheaper, and modern programmers have the opportunity to be maybe twice as productive as those who wrote OS/360 in assembly. I want people to ask a few questions:
Is it still a good book?
Do Brooks' postulates still hold true today?
If so, do his conclusions still work?
If not, are there similar conclusions to draw?
Has the field of programming changed in the past 35 years?
If not, why not?
The first page is somewhat flippant, but Ed and I worked on it to make it less jarring. I think it's necessary to raise the question of what exactly has changed since the late '60s.
Perl seems like a nice language, but the fact they have conventions for things like $_ or @_ is a bit odd. Isn't that the sort of practice that drives any practical programmer nuts?
They're pronouns. Think of $_ as "it" and @_ as "them".
Ahh, I merely linked the first likely Google result. The entry read surprisingly well, so I thought it might have been from the dictionary that recently added the term Perl. Thanks for the reference.
Slashdot Mirror
Parrot's register scheme really does help, as do PMCs, which allow much better polymorphism and much better extendability than Perl 5's built-in ADTs. Of course, the JIT and scary goto core don't hurt op execution and dispatch either.
I didn't mention that I prefer PIR so as not to confuse people, but you're right -- I much prefer writing for IMCC than for raw Parrot. Thankfully, having to care about the distinction mostly went away a long time ago.
Parrot is indeed register based. At least when compared to Perl 5, this is a tremendous advantage. Perl 5's VM spends a lot of time fiddling with its stack (pushing a marker on, pushing arguments on, pulling arguments off and checking for a marker) that Parrot can avoid altogether. Of course, that means that Parrot needs to spend time saving and restoring register stacks, but Dan's position is that there's enough good research on the subject to make optimizations practical.
Tell me about it. I'm a day or two from checking in simple-but-useful OpenGL bindings.
You only have to recompile XS modules if the new version of Perl has broken binary compatibility. That happens sometimes with major releases (between 5.6.x and 5.8.x), but rarely in minor releases. It's actually a goal that 5.8.x releases all have binary compatibility. If a release breaks that, Nick'll release a new version very quickly if at all possible.
You're right about Perl 6's successor to XS, though. It's NCI and it's fabulous, even now.
I know Larry. It's Perl. See perlfaq1.
Unix Power Tools was definitely an inspiration for the Hacks series. Fortunately, the Hacks are a lot shorter, a lot more focused, a lot less expensive, and very much easier to write.
The goal of a Hacks book is much different from a Cookbook. A Cookbook will cover everything common you'll eventually want to do. A Hack will cover things you may never have known you want to do, but will want to do after you read them.
(I edited this book, so that was my goal at least.)
That's why the U. S. DoJ brought suit against Microsoft for the abuse of a monopoly position through anticompetitive behavior.
I think there is a driving market force, one which you alluded to.
Any product has at least two main categories of costs, design and manufacturing. Software manufacturing costs -- making enough duplicates for all of your customers -- are low. If someone can design (and, in this case, write) the software for a low cost, he can sell it cheaply or even give it away.
As soon as someone gives away a good enough solution, there are price pressures on everyone else. They have to prove they're worth the money somehow. How do you compete in a market that suddenly has an infinite supply, though?
Hey, JavaScript isn't so bad.
You're right; I did oversimplify.
I was specifically thinking of the Color LaserJet 8500, which did have a Canon engine but had little connection to HP except for the name, some of the design, and most of the selling. While it was a nice machine, the external entity which actually built the thing couldn't figure out how to make a PCL engine, so HP had to ship extra firmware six months after introducing the printer.
That's embarassing because the alternative was Adobe's PostScript.
Except for the ones Canon manufactured and HP assembled, rebranded, and sold.
I wrote a little program to generate Sun's strategy. Here's what they're doing today:
Next month, it'll be:
(I realize that half of those statements make no sense. That's how you know it's working.)
Perhaps the number of net users increased at a higher rate than did the number of people who play or plan to play these games.
It's easier to waste a few aggregate hours of a thousand faceless people than a few seconds of your own life.
Agreed. As an editor and a programmer, I've seen terrible abuses of English and code. I've learned to appreciate simplicity and locality in both.
Woe to the language developer who invents some sort of passive voice programming, though.
How ironic that you used the English cognate a mere four words later!
Please don't repost our articles without permission. (I've never denied permission to anyone who asked, but we have several speedy servers and a lot of bandwidth.)
The depth is my fault. We normally run articles under 2000 words and I guided Ed to write for that length.
I'd also like to see a deep analysis of how programming has changed (or hasn't) in the past forty years, but that seems like a Master's thesis, not an article. Maybe next year.
Not in my case; I don't pay extra to receive telemarketing calls or junk mail. Nor does the telephone company or post office block my driveway so I cannot drive to work in the morning. However, spammers have hit my mail server so hard that it cut off my connection to the outside world, preventing me from working from home.
When a spammer takes advantage of a poorly secured system belonging to another person without permission and forges the e-mail addresses of other innocent people not involved in spamming, I will use the word "criminal". I know of no better way to summarize fraud, theft, and trespass.
When I write free software and distribute it for free (with my e-mail address in the documentation so people can contact me or know that I contributed to the project) and I receive spam, how does your argument make sense? There are hundreds of thousands of computers with my e-mail address stored in credits files somewhere; how does this keep the Internet free?
Because in the thirty years since Brooks wrote the first edition, computers are a few times more powerful, at least an order of magnitude cheaper, and modern programmers have the opportunity to be maybe twice as productive as those who wrote OS/360 in assembly. I want people to ask a few questions:
The first page is somewhat flippant, but Ed and I worked on it to make it less jarring. I think it's necessary to raise the question of what exactly has changed since the late '60s.
They're pronouns. Think of $_ as "it" and @_ as "them".
How about Regexp::English in Perl 5 or Perl6::Rules in Perls 5 and 6?
I skimmed them. Honestly, I wondered more about how Parrot would fare than looking for odd Perl results.
Ahh, I merely linked the first likely Google result. The entry read surprisingly well, so I thought it might have been from the dictionary that recently added the term Perl. Thanks for the reference.
It never was an acronym. See an explanation of Perl's name for an explanation of the backronym.