It's only a solved problem if you're exceedingly lucky, if you've built the exact same thing multiple times before, or if "solved" also includes "your customer is unhappy because the software doesn't do what he realized he needed it to do."
Contracts like these are motivation for both of you to get it right the first time.
Have you ever seen that work? I haven't. I've only ever seen such contracts devolve into finger-pointing and name calling and budget and deadline slips.
It doesn't matter how many unit tests you wrote before coding, if you don't run them you haven't tested.
That's why in test-driven development, you write a test, you run it, you watch it fail, you make it pass, you refactor the code, and then you repeat. No one who's ever done test-driven development would ever suggest that you write all of your tests before writing any code or that you run all of your tests only after you've written all of your code. TDD is a design exercise intended to produce well-factored, testable code which does only what it needs to do and includes comprehensive regression tests.
I won't speak for Damian, but my impression is that it's difficult to maintain, in part due to the limitations of Perl 5. Given the appearance of Pugs and PGE, it may not have been worth Damian's time to continue.
I have no problem with the 2 years for regexes though that could have happened as an extension to perl 5 (i.e. really slow but at least the syntax would have worked). That is it could have been done in parallel in terms of design.
You're looking for Perl6::Rules, which has several annoying limitations that go away only when you build your own regular expression engine (though to integrate lexical variable handling per the Perl 6 specification, you also have to rework how Perl 5 handles lexicals and aliasing).
Any indication of how steep the curve is going to be for those latter bugs / features?
I can imagine that a few of them will be tricky, but Rakudo right now supports some tricky features, so the balance of easy/difficult to implement won't shift too much.
What in your opinion has been the hold up with Perl 6?
Three things. First, revolutionary changes take a while. The original idea of shaving off some of the rough edges of Perl 5 quickly became obvious as too simple and small. Second, the lack of an implementation to give feedback to designers -- Parrot had a lot of missteps and false starts which took a long time to remedy. Third, an almost perpetual lack of funding, meaning that its schedule depends primarily on the availability and interest of volunteers. That's much more difficult to predict, even in software project management terms, than funded developer time.
Where did all the years go as you see things?
If I could go back in time and start over again, I'd get PGE and PCT running on Parrot in the first few months, even in very simple, naively-implemented fashion. Of course, the design team had to invent both of those, so that's a pipe dream anyway. It took around two years of the Perl 6 design process to redesign regular expressions and parsing into Perl 6 grammars, and that was well worth the time.
In your opinion how far off is a release?
I don't believe in giving a date for a stable release of Perl 6.0 in the form of Rakudo, but I will note that Patrick believes that the target number of passing specification tests is around 15,000. As of midnight this morning, Rakudo passed 6,175. That number could certainly be 6,400 by the next release (20 January). It was around 5,000 for the previous release in December. Extrapolate as you like.
Suppose you buy 1000 widgets for $1 apiece. You likely buy them on credit from the distributor. You have to pay them $1000 in 30 days (or if you're Wal-Mart, 60 or 90 days). If you can sell 1000 widgets in 30 days, you break even.
Suppose you drop the price to $0.97. If you can sell 1000 widgets in 7 days, you lose $30 -- unless you can find something else to do with that $970 for three weeks which can gain back that $30 and perhaps a little bit more. If you're really unimaginative, and if the dollar figures are in the millions range, not the thousands range, even short term interest on a bank account can give you modest returns.
That's without considering pay-for-shelving deals, or distributor overstock sales, or short discounts, or selling data-mined purchase habits, or any of the other ways to make money in the grocery business.
I never saw this as a viable business model regardless of the economy.
Why not? That's how American supermarkets function. If you're clever at finance, you can make a lot of money despite selling products at a very modest loss. I'm sure Wal-Mart has this figured out.
Yes, it's crazy for a head of state who wields roughly half of the power in deciding which laws get passed to have an opinion on which laws should be passed.
That part's fine. It's crazy for the head of the executive branch to submit bills to the legislative branch. If President-elect Obama wanted to submit bills, he should have done so while he was a Senator.
He was a professor of constitutional law but seems to believe that the chief executive should have a legislative agenda. (My mind boggles at what he thinks a senator should do.)
When [Perl 6] is done and there's a Python and a Ruby port to it, you'll be able to mix and match CPAN with RubyGems with whatever the Python thing is and everybody can work together using their favorite languages.
You can enlighten me with your definition of "agile development".
Certainly. Development occurs in short, frequent iterations, where the time between releases is fixed, but the contents of those releases is not. At the start of each iteration, someone selects the features to work on for that iteration based on their priority. The design of the system as released reflects only the design necessary to support the current feature set. Features are added to or removed from the iteration only if the estimated amount of work possible in the iteration changes.
Long-term planning and overall design is a matter of taste and risk management.
The way to read an entire file into memory in Perl has no easily translatable analogue in Java, but a Perl program written to read a line at a time in a loop can be translated directly to Java with very little effort. That's why I think that he probably used the later method.
I see this problem at least once a week: my guess is the OP used a for loop instead of a while loop. That's a wart in Perl 5, and a very common source of this type of error.
Taking this into account, my guess is that he made the classic mistake of recompiling the regex every time through the loop in the Perl program.
I doubt that, for two reasons. First, I can't imagine a log-processing regexp which is so complex that its compilation time can account for this magnitude of difference in performance. Regexp compilation time is meaningless as soon as you do IO. Second, I doubt that the regexp contained an interpolated variable, so it's likely compiled once and this is not even an issue.
Of course, we're debating code neither of us has read, so it's a silly benchmark anyway.
In terms of release often Pugs has been producing versions of Perl.
If Pugs has had a release in the past two years, that's news to me. The most recent release on the CPAN is from October 2006. Since then, Parrot has had at least 25 stable monthly releases.
Feb 2001 Conway gets a grant to get Parrot finished.
Damian has never worked on Parrot -- and the name Parrot didn't even exist until April 2001.
As for the reasons for skeptical there were serious problems with the much easier Python implementation.
Indeed there were. Parrot wasn't stable. The architect disappeared for six months. There was no PCT. The code was a mess, thanks in part to the Piethon contest. Parrot lost a couple of years due to that mess.
They are making progress but so far they have not gotten through all the road blocks by any stretch.
Please feel free to update the Parrot wiki with a list of the outstanding roadblocks, if we haven't already listed them.
You think "minimal planning" (as I cited in my follow-up comment) and "rapid, continuous delivery" can be compatible with adequate design for a major platform?
I believe that necessary and sufficient planning and iterative delivery are compatible with adequate design for a major platform. Our velocity developing Perl 6 increased dramatically when we started working this way.
... it does not appear compatible with the wikipedia definition.
I don't take Wikipedia citations seriously in debates.
I rewrote the perl code basically line for line (i.e. no optimizations) in Java using Java's built in regular expression parser, and the thing ran about 100x as fast.
Random-but-informed guess: these log files are large, and you slurped them all into memory in your Perl program, causing swap and IO thrash. You didn't do that in Java. Non-sequitur conclusion: Perl is useless.
I'm not going to dig through people's blogs, but here's a wikipedia quotation:
I asked for a quote that suggested that there's no design in agile development. You're certainly welcome to read as much into a quote as you like, but such a claim needs stronger supporting evidence. Here's your strawman argument:
If you deliver a platform (be it a bridge or a programming language) before the design is complete....
Every iteration builds on the whole, so that the whole is not complete until the final iteration, but each iteration should be self-contained and complete enough that its design is complete -- otherwise you won't know what you need to produce, and you won't be able to deliver that iteration.
At least with Perforce it was equally easy to get Perforce up and running on Linux or Win32 boxes. Typically you'd just have to copy one executable "p4" or if you prefer the GUI then additionally "p4v".
To my knowledge, almost no one besides committers used Perforce to check out the Perl 5 source code. The documentation suggested using an rsync mirror. That's what I did.
I can't help feeling that switching to "currently-Win32-neglected" git could possibly harm one of Perl's most attractive qualities; that many modules work cross platform.
I don't see how. This has very little to do with Perl modules, nothing to do with the CPAN, and everything to do with how people who hack on Perl 5 itself get its source code. (Very few of those use Windows, and they seem confident that Git on Windows is sufficiently usable.)
Perl 5 development does continue and you notice they do make releases very often to make Perl 5 better.
We release a new stable version of Rakudo (Perl 6 on Parrot) every month. If anything, I've argued that Perl 5 should have more frequent releases because of my experiences working on Parrot and Rakudo.
I have not taken a look at Perl 5 much so I cannot comment if the system is extendable or was worth expanding and extending.
I have. It's not. My rough guess is that at least a developer year of full-time refactoring might start to get the Perl 5 internals in shape to extend it to support at least some of the Perl 6 features -- but that would break almost every piece of XS code in the world.
I've had working code written in Perl 6 (publicly available, no less) for three and a half years. We've released 24 stable monthly releases of Parrot in a row. The last 13 of those have included stable versions of Rakudo (Perl 6 on Parrot). The question is not "if".
Why bother to learn the differences between Perl 5 and Perl 6 when you can go ahead and learn Python or Ruby?
Perl 6 is a better language than both Python and Ruby. That's not to say that Python or Ruby or bad, but they don't even have lexical variable declarations, let alone multidispatch, hyperoperators, grammars, subtypes, or any of a few dozen other features.
Oh, and did you know that Python 3000 was announced several months before Perl 6? Spread that bitterness around.
Agile development is certainly a valuable tool for many kinds of development projects. But it is not the answer to everything. Design is still required.
Can you name multiple agile advocates who've actually produced software who argue that design is not a part of agile development?
What about other design projects, like building a bridge?
There's a huge difference. We call software software because it's not hardware. We don't call bridges software because they're not software.
If you just want [Perl 6] you can use it today with Pugs. That is the "release often" and it finished.
I'm not sure how you apply "release often" to Pugs.
If you want a real release candidate the problem is Parrot.
The twenty-fifth stable monthly release of Parrot in a row will occur on 20 January 2009. This includes, by my reckoning, the 13th stable monthly release of Rakudo in a row.
There is no guarantee these problems will get solved.
Besides past results, no -- but what other guarantee will you get anywhere else?
Slashdot Mirror
It's only a solved problem if you're exceedingly lucky, if you've built the exact same thing multiple times before, or if "solved" also includes "your customer is unhappy because the software doesn't do what he realized he needed it to do."
Have you ever seen that work? I haven't. I've only ever seen such contracts devolve into finger-pointing and name calling and budget and deadline slips.
That's why in test-driven development, you write a test, you run it, you watch it fail, you make it pass, you refactor the code, and then you repeat. No one who's ever done test-driven development would ever suggest that you write all of your tests before writing any code or that you run all of your tests only after you've written all of your code. TDD is a design exercise intended to produce well-factored, testable code which does only what it needs to do and includes comprehensive regression tests.
I won't speak for Damian, but my impression is that it's difficult to maintain, in part due to the limitations of Perl 5. Given the appearance of Pugs and PGE, it may not have been worth Damian's time to continue.
You're looking for Perl6::Rules, which has several annoying limitations that go away only when you build your own regular expression engine (though to integrate lexical variable handling per the Perl 6 specification, you also have to rework how Perl 5 handles lexicals and aliasing).
I can imagine that a few of them will be tricky, but Rakudo right now supports some tricky features, so the balance of easy/difficult to implement won't shift too much.
Three things. First, revolutionary changes take a while. The original idea of shaving off some of the rough edges of Perl 5 quickly became obvious as too simple and small. Second, the lack of an implementation to give feedback to designers -- Parrot had a lot of missteps and false starts which took a long time to remedy. Third, an almost perpetual lack of funding, meaning that its schedule depends primarily on the availability and interest of volunteers. That's much more difficult to predict, even in software project management terms, than funded developer time.
If I could go back in time and start over again, I'd get PGE and PCT running on Parrot in the first few months, even in very simple, naively-implemented fashion. Of course, the design team had to invent both of those, so that's a pipe dream anyway. It took around two years of the Perl 6 design process to redesign regular expressions and parsing into Perl 6 grammars, and that was well worth the time.
I don't believe in giving a date for a stable release of Perl 6.0 in the form of Rakudo, but I will note that Patrick believes that the target number of passing specification tests is around 15,000. As of midnight this morning, Rakudo passed 6,175. That number could certainly be 6,400 by the next release (20 January). It was around 5,000 for the previous release in December. Extrapolate as you like.
Suppose you buy 1000 widgets for $1 apiece. You likely buy them on credit from the distributor. You have to pay them $1000 in 30 days (or if you're Wal-Mart, 60 or 90 days). If you can sell 1000 widgets in 30 days, you break even.
Suppose you drop the price to $0.97. If you can sell 1000 widgets in 7 days, you lose $30 -- unless you can find something else to do with that $970 for three weeks which can gain back that $30 and perhaps a little bit more. If you're really unimaginative, and if the dollar figures are in the millions range, not the thousands range, even short term interest on a bank account can give you modest returns.
That's without considering pay-for-shelving deals, or distributor overstock sales, or short discounts, or selling data-mined purchase habits, or any of the other ways to make money in the grocery business.
Why not? That's how American supermarkets function. If you're clever at finance, you can make a lot of money despite selling products at a very modest loss. I'm sure Wal-Mart has this figured out.
I have the impression that the President has enough work to do without trying to be a Senator as well.
That part's fine. It's crazy for the head of the executive branch to submit bills to the legislative branch. If President-elect Obama wanted to submit bills, he should have done so while he was a Senator.
He was a professor of constitutional law but seems to believe that the chief executive should have a legislative agenda. (My mind boggles at what he thinks a senator should do.)
This works today in Parrot. See Parrot Speaks Your Language.
We need more contributors. Money helps only if it enables people to devote more time to the project. (Money doesn't help me.)
Certainly. Development occurs in short, frequent iterations, where the time between releases is fixed, but the contents of those releases is not. At the start of each iteration, someone selects the features to work on for that iteration based on their priority. The design of the system as released reflects only the design necessary to support the current feature set. Features are added to or removed from the iteration only if the estimated amount of work possible in the iteration changes.
Long-term planning and overall design is a matter of taste and risk management.
I see this problem at least once a week: my guess is the OP used a for loop instead of a while loop. That's a wart in Perl 5, and a very common source of this type of error.
I doubt that, for two reasons. First, I can't imagine a log-processing regexp which is so complex that its compilation time can account for this magnitude of difference in performance. Regexp compilation time is meaningless as soon as you do IO. Second, I doubt that the regexp contained an interpolated variable, so it's likely compiled once and this is not even an issue.
Of course, we're debating code neither of us has read, so it's a silly benchmark anyway.
If Pugs has had a release in the past two years, that's news to me. The most recent release on the CPAN is from October 2006. Since then, Parrot has had at least 25 stable monthly releases.
Damian has never worked on Parrot -- and the name Parrot didn't even exist until April 2001.
Indeed there were. Parrot wasn't stable. The architect disappeared for six months. There was no PCT. The code was a mess, thanks in part to the Piethon contest. Parrot lost a couple of years due to that mess.
Please feel free to update the Parrot wiki with a list of the outstanding roadblocks, if we haven't already listed them.
I believe that necessary and sufficient planning and iterative delivery are compatible with adequate design for a major platform. Our velocity developing Perl 6 increased dramatically when we started working this way.
I don't take Wikipedia citations seriously in debates.
Random-but-informed guess: these log files are large, and you slurped them all into memory in your Perl program, causing swap and IO thrash. You didn't do that in Java. Non-sequitur conclusion: Perl is useless.
Good question. I'm not sure why anyone who doesn't hack on Perl 5 itself should care.
I asked for a quote that suggested that there's no design in agile development. You're certainly welcome to read as much into a quote as you like, but such a claim needs stronger supporting evidence. Here's your strawman argument:
Every iteration builds on the whole, so that the whole is not complete until the final iteration, but each iteration should be self-contained and complete enough that its design is complete -- otherwise you won't know what you need to produce, and you won't be able to deliver that iteration.
To my knowledge, almost no one besides committers used Perforce to check out the Perl 5 source code. The documentation suggested using an rsync mirror. That's what I did.
I don't see how. This has very little to do with Perl modules, nothing to do with the CPAN, and everything to do with how people who hack on Perl 5 itself get its source code. (Very few of those use Windows, and they seem confident that Git on Windows is sufficiently usable.)
We release a new stable version of Rakudo (Perl 6 on Parrot) every month. If anything, I've argued that Perl 5 should have more frequent releases because of my experiences working on Parrot and Rakudo.
I have. It's not. My rough guess is that at least a developer year of full-time refactoring might start to get the Perl 5 internals in shape to extend it to support at least some of the Perl 6 features -- but that would break almost every piece of XS code in the world.
I've had working code written in Perl 6 (publicly available, no less) for three and a half years. We've released 24 stable monthly releases of Parrot in a row. The last 13 of those have included stable versions of Rakudo (Perl 6 on Parrot). The question is not "if".
Perl 6 is a better language than both Python and Ruby. That's not to say that Python or Ruby or bad, but they don't even have lexical variable declarations, let alone multidispatch, hyperoperators, grammars, subtypes, or any of a few dozen other features.
Oh, and did you know that Python 3000 was announced several months before Perl 6? Spread that bitterness around.
Can you name multiple agile advocates who've actually produced software who argue that design is not a part of agile development?
There's a huge difference. We call software software because it's not hardware. We don't call bridges software because they're not software.
I'm not sure how you apply "release often" to Pugs.
The twenty-fifth stable monthly release of Parrot in a row will occur on 20 January 2009. This includes, by my reckoning, the 13th stable monthly release of Rakudo in a row.
Besides past results, no -- but what other guarantee will you get anywhere else?
Agreed. Making back $3 - 30 million is more difficult than making back $100 - $300,000.
That sentence answers and then asks its own question.