in reply to Why Scaffolding? Validation and learning.

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:

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?

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re^2: Why Scaffolding? Validation and learning.
by philcrow (Priest) on Aug 21, 2006 at 13:55 UTC
    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.
    While seeing stubs doesn't immediately aid evaluation of the framework, it does shorten the learning curve, making it possible to reach the evaluation stage sooner.

    I think the role of code generation is the same at every stage. It simply reduces the typing (or file copy/edit) burden on developers. This is true for seasoned developers or new comers looking to explore the framework. The fact that it also standardizes the idioms for common coding tasks is just a nice side effect.

    Anything that helps me move more quickly from data model diagram to finished app is a winner.

    Phil

      Anything that helps me move more quickly from data model diagram to finished app is a winner.

      What about the maintainability of that application?

        Perhaps my initial comment was a bit abbreviated. My main point is that a good generator benefits experienced users as much or more than it benefits newcomers looking for a quick peek at a framework they might want to use.

        My particular generator (Bigtop) spends a great deal of effort to split the code it makes into that which is likely to change and that which you modify with your own code. This aids maintenence since you can continue to regenerate to good effect even after initial production deployment. We did this recently in an ORM migration. Bigtop did about half the work in the first hour. I did the rest over the next week or so.

        Phil