This is hard to answer in a short comment. I'll try, though you're welcome to contact me for more details through the information on my website.
Retrofitting tests onto an existing project is hard. Not only is it tedious, time-consuming work, but you're always haunted by specters that ask "How do you know the test isn't broken?" It's nice to have the tests, but you'll spend a lot of time and energy creating them that could be better spent adding new features and improving existing features. Besides that, it'll likely sap any motivation you might have had for testing.
It's much easier to draw a line in the sand and say "all new features and bugfixes will have tests, starting now". Before you fix a bug, write a test that explores the bug. It must fail. Fix the bug. The test must now pass. Before you add a new feature, write a customer test that can demonstrate the correct implementation of the feature. It must fail. Add the feature. The test must now pass. From the programmer level, you can write programmer tests through the standard test-driven development style.
It still can be tricky to get started, especially with customer tests, but they don't have to be beautiful, clever, or comprehensive. They just have to test the one feature you're working on sufficiently to give you confidence that you can detect whether or not it works. You'll likely have better ideas as you gain tests and experience and it's okay to revisit the test suite later on to make it easier to use and to understand.
The nice part about this system is that it adds tests where you need them where the code is changing, whether it's a part full of bugs or a part under continual development.
Keep in mind that to do testing this way, you need to be able to work in short, clearly-defined, and frequently-integrated steps (story and task cards, in XP terms). You also need the freedom to change necessary sections of the code (collective code ownership). It helps to have a good set of testing tools, so, depending on your language, there's probably an xUnit framework with your name on it. Also, it can be counterproductive to express your development and testing time estimates separately. At first, testing well will slow you down. It's tempting to throw it out altogether as a time sink. As you learn and your test suite grows, however, the investment will pay off immensely.
Your goal is difficult but doable. It's well worth your time.
My point was that naive implementations that rely on accurate From headers will occasionally break in the real world, not that you can never trust that header.
(I'm an SPF fan, though I do confess to yelling at "You sent me Sobig.f!" messages. If you know enough to identify Sobig, how did you fail to discover that it spoofs the From header?)
Maybe I'm an atypical e-mail user, but I've received plenty of spam "from" people I'd whitelist. Most of the core Perl developers, for example, have been joe-jobbed from time to time. Relying on spammers never to forge public information is pretty unworkable.
Speaking of Sobig, I've received 14.4 megabytes of bounce messages in the past two days. If a spammer forges my e-mail address, how many whitelist challenges will I receive? Saying it's "illegal" doesn't help; spammers regularly break the rules.
Any workable solution to spam has to address two realities. One, forging addresses is trivial. Two, client-side filters mean you still have to pay for receiving and storing messages you don't want. I don't see whitelisting as handling either challenge.
I fear this thread is about to die, but you might be interested in a Lamba the Ultimate thread about macros in Java. Designing a language well means finding a balance between power and flexibility. I'm personally very much against taking out features that might confuse new programmers or that can be misused, but I do believe in managing complexity well.
Very few languages that completely prevent beginners from doing stupid things allow experienced users to do very clever things. I hate that.
So everyone who is just getting their feet wet will have No Idea what the Power Coders are thinking, right?
That's true of any programming language. The question is where you put the simplicity and where you put the complexity. (I've written about this before -- though see Schuyler's take for a better explanation).
Unless you have a really, really simple language that has no libraries and no chance to grow, odds are you'll have to adapt to something that's different in someone else's code, if you ever read code from someone else. Larry's really good about hiding complexity and allowing people to be productive while knowing a small fraction of what's available in Perl. I believe Perl 6 will make it easier to encapsulate this complexity where you don't have to see it unless you really really need to see it.
What you describe sounds like a standard maintenance program. I don't write Perl code that anyone off of the street can read without knowing Perl. I write code that competent developers can maintain. A big part of that is self-discipline, which no language worth using can enforce.
It seems like constant change in a language would be a bad thing, right?
It certainly can be. I'm willing to go on record that the problems in Bugzilla were more lack of discipline on the part of its developers than any systemic problem. Consider how often any open source project is rewritten and redesigned (not refactored). This is a problem that afflicts every language.
I'm answering the question why hasn't Parrot made more progress?. I believe the answer to that is, because it's been mostly a volunteer effort. There are lots of people who contribute what time and skills they have, and I think they've done a fantastic job. There are also more people contributing all the time.
As for Perl 5, Python, and Ruby, you should check out how many of the original developers are or were paid to work on those languages full-time. I'm not sure about Matz, but I know Guido has been doing half- or full-time Python development for several years now. Until a couple of years ago, so had Larry.
I'm sorry if you don't like the answer, but finishing software takes time. Sure, volunteers help, but I'm not sure that forty people giving one hour a week is even half as useful as one of the top people giving forty hours a week.
Please don't misunderstand. I'm happy to see people who can give an hour a week. The pay is lousy, a few people on Slashdot will take every chance they can get to gripe about your work, and it's a big project, but you'll be helping build software for millions of people to use. There's lots to do, though, and plenty of room for anyone who'd like to help.
Perl 6 can be prototyped in the original C-based Perl 5 and when it is done a module can be written to generate code for any number of existing backends and interpreters.
I look forward to seeing your Perl6::Continuations, Perl6::Rules, and Perl6::Types modules on the CPAN.
Perl 6 isn't completely implemented on Parrot because Perl 6 isn't completely designed yet. Perl 5 isn't completely implemented on Parrot because no one's had the right combination of time, talent, and funding to implement it yet. The same goes for any combination of Perl and Parrot you care to mention. As of last month or so, there had been somewhere around five man years of Perl 6 and Parrot work funded.
Paying one developer to work on Parrot for a year and a half would double the amount of full-time contributions.
The parallels to Mono and DotGNU are inappropriate. Not only are they reimplementing something that's already been designed and implemented once by legions of funded developers at Microsoft, Ximian pays people to hack on Mono.
I have had code in Parrot for years. I have commit access.
I've taken hundreds of kilobytes of notes during Perl 6 design meetings.
I read the Apocalypses, Synopses, and Exegeses as they're being written and revised, weeks and months before they're released.
I helped quadruple the number of tests in the core test suite between Perl 5.6 and Perl 5.8.
I think I have a pretty good sense of Perl 5, Perl 6, and Parrot.
I also know how many Perl Foundation dollars have been spent to get Parrot where it is today. It might be enough to hire one of the top.NET folks for most of a year. For the money, Parrot's a bargain.
It's not just you, but about 80% of the syntax stays the same. Much of the rest requires a few parser rule overrides. See... And Now For Something Completely Similar, also by Damian.
Backwards compatibility is a huge concern. That's why Ponie exists and why Dan's so careful about supporting Perl 5 semantics on Parrot. (As well, I expect 80% of the core Perl 5 tests will port to Perl 6 with surprisingly little work.)
Damian intended to demonstrate as many of the new features as possible while reusing one example and progressing through more and more powerful techniques. He thought it'd be simpler and easier to understand. It's a difficult article to write, no matter how you approach it, since it summarizes to a list of "Here's another way to do that, having these advantages and these disadvantages:" statements.
I think he suceeded, but it's also possible that I'm too close to the material to judge this accurately.
the language is becoming more obtuse if thats possible.
Read the last page of Exegesis 6 to see the Perl 5 version of the code. It's astonishingly simpler and clearer in Perl 6.
The perl programmers I know don't get along well with other languages, mostly because they have spent so much time learning the intricacies of Perl syntax.
See the CD Bookshelves which are in open formats but don't use DRM. That doesn't mean they're not copyrighted, though. You're expected to do the right thing but you're not forced to do it.
Slashdot Mirror
Disk space, bandwidth, CPU cycles... there are lots of ways to make that metaphor. :)
Remember to use his spray paint.
Did Amazon switch away from a Mason-powered site recently? I haven't heard anything from my contacts there.
Amazon uses Perl.
A network aware operating system is aware of services that haven't yet been invented? Are there any operating systems that fit your criteria?
This is hard to answer in a short comment. I'll try, though you're welcome to contact me for more details through the information on my website.
Retrofitting tests onto an existing project is hard. Not only is it tedious, time-consuming work, but you're always haunted by specters that ask "How do you know the test isn't broken?" It's nice to have the tests, but you'll spend a lot of time and energy creating them that could be better spent adding new features and improving existing features. Besides that, it'll likely sap any motivation you might have had for testing.
It's much easier to draw a line in the sand and say "all new features and bugfixes will have tests, starting now". Before you fix a bug, write a test that explores the bug. It must fail. Fix the bug. The test must now pass. Before you add a new feature, write a customer test that can demonstrate the correct implementation of the feature. It must fail. Add the feature. The test must now pass. From the programmer level, you can write programmer tests through the standard test-driven development style.
It still can be tricky to get started, especially with customer tests, but they don't have to be beautiful, clever, or comprehensive. They just have to test the one feature you're working on sufficiently to give you confidence that you can detect whether or not it works. You'll likely have better ideas as you gain tests and experience and it's okay to revisit the test suite later on to make it easier to use and to understand.
The nice part about this system is that it adds tests where you need them where the code is changing, whether it's a part full of bugs or a part under continual development.
Keep in mind that to do testing this way, you need to be able to work in short, clearly-defined, and frequently-integrated steps (story and task cards, in XP terms). You also need the freedom to change necessary sections of the code (collective code ownership). It helps to have a good set of testing tools, so, depending on your language, there's probably an xUnit framework with your name on it. Also, it can be counterproductive to express your development and testing time estimates separately. At first, testing well will slow you down. It's tempting to throw it out altogether as a time sink. As you learn and your test suite grows, however, the investment will pay off immensely.
Your goal is difficult but doable. It's well worth your time.
My point was that naive implementations that rely on accurate From headers will occasionally break in the real world, not that you can never trust that header.
(I'm an SPF fan, though I do confess to yelling at "You sent me Sobig.f!" messages. If you know enough to identify Sobig, how did you fail to discover that it spoofs the From header?)
Maybe I'm an atypical e-mail user, but I've received plenty of spam "from" people I'd whitelist. Most of the core Perl developers, for example, have been joe-jobbed from time to time. Relying on spammers never to forge public information is pretty unworkable.
Speaking of Sobig, I've received 14.4 megabytes of bounce messages in the past two days. If a spammer forges my e-mail address, how many whitelist challenges will I receive? Saying it's "illegal" doesn't help; spammers regularly break the rules.
Any workable solution to spam has to address two realities. One, forging addresses is trivial. Two, client-side filters mean you still have to pay for receiving and storing messages you don't want. I don't see whitelisting as handling either challenge.
What happens when a spammer forges a whitelisted From address?
There are certainly hashes in Perl 1. See hash.[ch], for example.
Did you file a bug report for your Makefile issue? Richard Clamp is maintaining this version.
I fear this thread is about to die, but you might be interested in a Lamba the Ultimate thread about macros in Java. Designing a language well means finding a balance between power and flexibility. I'm personally very much against taking out features that might confuse new programmers or that can be misused, but I do believe in managing complexity well.
Very few languages that completely prevent beginners from doing stupid things allow experienced users to do very clever things. I hate that.
That's true of any programming language. The question is where you put the simplicity and where you put the complexity. (I've written about this before -- though see Schuyler's take for a better explanation).
Unless you have a really, really simple language that has no libraries and no chance to grow, odds are you'll have to adapt to something that's different in someone else's code, if you ever read code from someone else. Larry's really good about hiding complexity and allowing people to be productive while knowing a small fraction of what's available in Perl. I believe Perl 6 will make it easier to encapsulate this complexity where you don't have to see it unless you really really need to see it.
What you describe sounds like a standard maintenance program. I don't write Perl code that anyone off of the street can read without knowing Perl. I write code that competent developers can maintain. A big part of that is self-discipline, which no language worth using can enforce.
It certainly can be. I'm willing to go on record that the problems in Bugzilla were more lack of discipline on the part of its developers than any systemic problem. Consider how often any open source project is rewritten and redesigned (not refactored). This is a problem that afflicts every language.
I'm answering the question why hasn't Parrot made more progress?. I believe the answer to that is, because it's been mostly a volunteer effort. There are lots of people who contribute what time and skills they have, and I think they've done a fantastic job. There are also more people contributing all the time.
As for Perl 5, Python, and Ruby, you should check out how many of the original developers are or were paid to work on those languages full-time. I'm not sure about Matz, but I know Guido has been doing half- or full-time Python development for several years now. Until a couple of years ago, so had Larry.
I'm sorry if you don't like the answer, but finishing software takes time. Sure, volunteers help, but I'm not sure that forty people giving one hour a week is even half as useful as one of the top people giving forty hours a week.
Please don't misunderstand. I'm happy to see people who can give an hour a week. The pay is lousy, a few people on Slashdot will take every chance they can get to gripe about your work, and it's a big project, but you'll be helping build software for millions of people to use. There's lots to do, though, and plenty of room for anyone who'd like to help.
I look forward to seeing your Perl6::Continuations, Perl6::Rules, and Perl6::Types modules on the CPAN.
Parrot's been around two years, not three. The oldest Perl 6 code I can find running on Parrot goes back one year.
Perl 6 isn't completely implemented on Parrot because Perl 6 isn't completely designed yet. Perl 5 isn't completely implemented on Parrot because no one's had the right combination of time, talent, and funding to implement it yet. The same goes for any combination of Perl and Parrot you care to mention. As of last month or so, there had been somewhere around five man years of Perl 6 and Parrot work funded.
Paying one developer to work on Parrot for a year and a half would double the amount of full-time contributions.
The parallels to Mono and DotGNU are inappropriate. Not only are they reimplementing something that's already been designed and implemented once by legions of funded developers at Microsoft, Ximian pays people to hack on Mono.
Would that everyone were so blind!
I think I have a pretty good sense of Perl 5, Perl 6, and Parrot.
I also know how many Perl Foundation dollars have been spent to get Parrot where it is today. It might be enough to hire one of the top .NET folks for most of a year. For the money, Parrot's a bargain.
It's not just you, but about 80% of the syntax stays the same. Much of the rest requires a few parser rule overrides. See ... And Now For Something Completely Similar, also by Damian.
Backwards compatibility is a huge concern. That's why Ponie exists and why Dan's so careful about supporting Perl 5 semantics on Parrot. (As well, I expect 80% of the core Perl 5 tests will port to Perl 6 with surprisingly little work.)
Heh, true. I meant the Exegesis, though.
That's a fair concern.
Damian intended to demonstrate as many of the new features as possible while reusing one example and progressing through more and more powerful techniques. He thought it'd be simpler and easier to understand. It's a difficult article to write, no matter how you approach it, since it summarizes to a list of "Here's another way to do that, having these advantages and these disadvantages:" statements.
I think he suceeded, but it's also possible that I'm too close to the material to judge this accurately.
Parrot has both today. (Okay, it just picked up the standalone binary compiler a couple of days ago.)
Read the last page of Exegesis 6 to see the Perl 5 version of the code. It's astonishingly simpler and clearer in Perl 6.
See the Inline modules on the CPAN.
See Perl Design Paterns, an article on Perl.com.
See the CPAN.
I've read the Perl parser. You're right about this one.
Signatures and types are completely optional. If you're writing a small utility to parse text, you don't have to use them.
See the CD Bookshelves which are in open formats but don't use DRM. That doesn't mean they're not copyrighted, though. You're expected to do the right thing but you're not forced to do it.
I'm willing to try parallelizing development a little more. If Mr. Brooks wants to send in good patches, I'll apply them whatever his philosophy.
My guess is two more, though the more people who contribute, the sooner Programming Perl 6 will be released.