This text was first posted on the Catalyst mailing list. It is an analyzis of value of the code generation technique that was popularized as 'scaffolding' by Ruby on Rails. It describes what makes the scaffolding so efficient in converting newcommers into avid users of the framework.

I would like you to imagine you in the position of a developer that has some idea for a web project, thinking about trying a new web programming framework. There are many to choose from, or you can also go the simple way and use CGI.pm or develop something for his own - how would you decide? Every framework is lots of code, lots of documentation so it's not an easy task. After reading those mountains of manuals you can discover that some limitations make the framework not really fitting to your project (some related thoughts in http://www.artima.com/weblogs/viewpost.jsp?thread=8826). This is that risk that scaffolding mitigates - you generate your application with minimal effort and you have a working example tailored to your database schema. You don't need to think if a example from the manual can be adopted to your data structures - you have it adopted automatically. This is the first advantage of scaffolding - easy evaluation.

The other important advantage is that it helps in the learning process. You get a non trivial working example. And again this example is based on your database schema - from the starting point you at once know much about the program. You don't need to internalize the arbitrary business rules of some unfamiliar application - the business rules are yours - so at once you can start and play with it. And a good scaffolding will give you much space for simple but meaningful modifications to tweak and play with.

Of course there are also disadvantages to code generation. It is impossible to come with a good schema to update the generated code when you release a new version of the generator and we don't want the programmers who use the scaffolding to be stuck forever to the version that they used the first time. One solution can be to limit the code generator to really most trivial part and move all other logic into traditional libraries that just happen to cooperate with the generated code - and this is what I try to do with InstantCRUD.

  • Comment on Why Scaffolding? Validation and learning.

Replies are listed 'Best First'.
Re: Why Scaffolding? Validation and learning.
by xdg (Monsignor) on Aug 21, 2006 at 11:38 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.

    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?

    -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.

[reply]
[d/l]
      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

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

        What about the maintainability of that application?

[reply]
Re: Why Scaffolding? Validation and learning.
by toma (Vicar) on Aug 26, 2006 at 18:05 UTC
    I like the scaffolding idea. I try many different tools and techniques. Scaffolding enables me to look at more alternatives by saving time.

    The challenge to getting scaffolding to work in a Perl environment is that there are so many dependencies. An interesting test is to start with a bare-bones perl build, get the cpan module configured, and type 'install Catalyst::Example::InstantCRUD'. When I tried this (linux FC3, perl-5.8.8), the build proceeds for quite a while, and then fails with: 

    Failed during this command:
  ISLUE/Catalyst-Plugin-Session-State-Cookie-0.05.tar.gz: signature_verify NO
  TKP/DBIx-Class-DigestColumns-0.02000.tar.gz  : make_test NO
    I would contrast this with Ruby on Rails, which installed and operated without errors when I tried it. I really like the concept, but a scaffold is only as stable as the ground underneath it. I think that keeping the underlying Catalyst modules working will be the major challenge to the possible role of InstantCRUD in getting new users to try Catalyst.

    It should work perfectly the first time! - toma
[reply]

Back to Meditations