NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
In the near future, the probability is close to zero. In the distant
future, I'll be dead, and posterity can do whatever they like... :-) --lwall
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
State Machines, math transforms, etc. (Score:1)
Re:State Machines, math transforms, etc. (Score:2)
My rant against Shawn's technique is primarily rooted in building up all of the complexity you describe to build one system once in one programming language. When you get into building one abstraction that can generate multiple implementations (including nasty easy-to-get-wrong-versions in C), along with the corresponding docs, it certainly makes sense to abstract out the work into a code generator.
It's the old cost/benefit analysis. If you're willing to put a lot of work into a tool to get a lot in return (and ultimately save work in the process), then a code generator is certainly justified. On the other hand, building up all of those abstracts and tools that just get in the way to build one single application seems like wasted effort to me. Especially if that "code generation" can be replaced by dynamic programming or better use of structured data (worst case).
Reply to This
Parent