I've had a play with C::R. While you can do really neat stuff with it, the problem is that others can do what they consider to be really neat stuff with it.
This is the same problem that's had with operator overloading in C++. Take the relatively innocuous statement i = j + k;. Do you know what's going on? Really? What would happen if I told you what classes i, j, and k were. Does that help? Oh, it doesn't?
99% of Perl coders doesn't understand basic list, scalar, and void contexts. Now, you're going to throw in a gazillion other contexts? Maybe not such a good idea.
Oh, and it imposes a 2-4x runtime overhead. (Note - I make this point last for a reason.)
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply]
[d/l] |
I remember reading mention of the performance hit. Dragonchild: Was your C::R experience before or after last month's release?
cat >~/.sig </dev/interesting
| [reply]
[d/l] |
I haven't touched it in at least a year, if not longer. My issues with it aren't performance-related, they're concept-related. I think that it's a neat idea and a great demonstration of Perl's power. But, it's something that should be avoided at all costs in productionable code, unless there's simply no other way to do what you want to do. And, I mean NO OTHER WAY. Like, you've seriously tried 3 or 4 other solutions first.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |