I disagree. I think it encourages lazy evaluation -- in the coding sense -- because it defers in-depth analysis. Does it really help my evaluation to see a bunch of stub classes that subclass a parent? I suspect that framework disillusionment happens much later when discovering the holes in the framework that the scaffolding doesn't cover.

I also don't think it helps the learning process as much -- or at least, the help is limited to the initial parts of the learning curve for the framework. And if less code is generated, then the less learning that will occur. (Back to the stub classes point again.)

I think this is particularly true for "magic" scaffolding (sorry, Jifty) that is generated in memory on the fly instead of on disk. Tracing the action becomes a real challenge. ("Where did that method call get handled," followed by grepping through source.) Though from what I heard about halos in Jifty, this may be improving. I think it's a better design -- needing lots of stub classes seems like "ugly" design -- but the tradeoff is a steeper learning curve.

My view is that scaffolding helps most in these areas:

• Easy tutorials -- makes it easy to demonstrate powerful features without bogging down in details. (I.e. advertising and attracting new users)

• Standardization -- encourages one way to do it; makes it easy for other people to work on someone else's application; makes it easier to teach

• Rapid development by expert users -- once people know the framework and are typing the same thing over and over, they just want to automate the basics.

As a side note, the talk about scaffolding applies just as easily to h2xs, ExtUtils::ModuleMaker, Module::Starter, etc. I think they're great time savers and they lower the cost of starting a new module. But most of the validation for me came when I tried to do something that they didn't do well. (Which is why I wrote ExtUtils::ModuleMaker::TT to address one part of it.) And most of my learning about tricky ways to package CPAN distributions came when I needed to do something those scaffoldings couldn't handle by default.

Consider what other code generators you use. What do they help you do? What do they help new people do?

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.