future of scaffolding / simple suggestion

Hi, I have a change I want to submit, just want to check that it's relevant first.

Is scaffolding continuing as normal?

When I see posts about getting rid of dynamic scaffolding, does that refer to scaffolding .erb templates, or to the scaffold controller method?

The scaffolding templates all use

<% for x in y %>

instead of

<% x.each do |y| %>

Total subtle psychological difference, but with Rails having such incredible success, a little thing like that will encourage a lot of new Ruby programmers to use iterators instead of explicit iteration. For many programmers this is a big change:

When I started programming in Ruby, another programmer criticized my code. He was real subtle about it. Any time I wrote a for loop, he told me he'd never used one in Ruby. I was like, sure, that's great, have you ever used scaffolding? He was encouraging me in good habits, and scaffolding was my excuse for keeping up bad habits.

The code generated by the scaffolding templates is the first introduction to Ruby for many people. Using iterators in the scaffolding is kind of like putting out a welcome mat, and encouraging people to leave their bad habits at the door.

He doesn't provide any examples of what he "considers harmful", but I think you've misunderstood his point. He's basically saying: if you need to do some work on a collection of objects you probably don't need to explicitly iterate over the collection; you can use the Enumerable methods instead.

For example, I believe he means that:

   orders.select(&:complete).each(&:archive!)

is better than:

   orders.each do |order|      if order.complete?        order.archive!      end    end

There's nothing wrong with the way the scaffolding iterates (for x in y).

-- tim

So? That’s the same loop. “for … in” is easier to write and looks nicer in templates.

"for x in y" is basically just syntactic sugar on top of "each" in Ruby, it's not an explicit loop in the same sense that the following would be:

x = 0 while x < arr.size   # do something with arr   x += 1 end

Like Mislav said, some consider "for x in y" nicer looking than "y.each do |x|".

Cheers, //jarkko

Hi, I have a change I want to submit, just want to check that it's relevant first.

Is scaffolding continuing as normal?

When I see posts about getting rid of dynamic scaffolding, does that refer to scaffolding .erb templates, or to the scaffold controller method?

The current plan (as far as I'm aware) is to keep generated scaffolding, but replace the old-style scaffold templates with ones meant for restful resources. Most or all of this work has already been done in trunk. The new templates use the .erb extension.

The scaffolding templates all use

<% for x in y %>

instead of

<% x.each do |y| %>

Total subtle psychological difference, but with Rails having such incredible success, a little thing like that will encourage a lot of new Ruby programmers to use iterators instead of explicit iteration.

There is an assumption that web developers build the models and controllers of a Rails app, but designers often build the view templates. The assumption continues that designers are less likely to know Ruby, so code in templates should be as accessible as possible. To a designer familiar with PHP or Perl, the 'for user in users' style of enumeration is probably more accessible than the 'users.each do |user|' style.

[snip ...]

The code generated by the scaffolding templates is the first introduction to Ruby for many people. Using iterators in the scaffolding is kind of like putting out a welcome mat, and encouraging people to leave their bad habits at the door.

Perhaps it's more like putting out a welcome mat written in a language your friends understand but your guests don't.

Personally, I never use the for style enumerators, but I don't use scaffolding for anything except throwaway code either. YMMV.

That’s too bad. Dynamic scaffolding was “throwaway” (temporary) and, because of that, it’s dead now. Resource scaffolding (default scaffolding in trunk) is really good not only for quick setups to populate data, but as a skeleton for real production controllers and views, too!

> Total subtle psychological difference, but with Rails having such > incredible success, a little thing like that will encourage a lot of > new Ruby programmers to use iterators instead of explicit iteration. > For many programmers this is a big change: > > explicit iteration considered harmful | Jonathan's Techno-tales > considered-harmful/

He doesn't provide any examples of what he "considers harmful", but I think you've misunderstood his point.

I'm not **presenting** his point. I'm presenting his **post** as an illustration of **my** point, which is that for many developers, switching from explicit iteration to using iterators is a major change.

I think your understanding of the link I posted is correct, but tangential to what I'm actually saying here.

> Is scaffolding continuing as normal? > > When I see posts about getting rid of dynamic scaffolding, does that > refer to scaffolding .erb templates, or to the scaffold controller > method?

The current plan (as far as I'm aware) is to keep generated scaffolding, but replace the old-style scaffold templates with ones meant for restful resources. Most or all of this work has already been done in trunk. The new templates use the .erb extension.

OK, so the new .erb scaffolding templates are the ones to use. (Thank you.)

> The scaffolding templates all use > > <% for x in y %> > > instead of > > <% x.each do |y| %> > > Total subtle psychological difference, but with Rails having such > incredible success, a little thing like that will encourage a lot of > new Ruby programmers to use iterators instead of explicit iteration.

There is an assumption that web developers build the models and controllers of a Rails app, but designers often build the view templates. The assumption continues that designers are less likely to know Ruby, so code in templates should be as accessible as possible. To a designer familiar with PHP or Perl, the 'for user in users' style of enumeration is probably more accessible than the 'users.each do |user|' style.

True; but encouraging programmers new to Ruby to write their code as if it were PHP isn't going to result in beautiful code. The risk you're taking there is of a glut, in a few years' time, of ugly Rails code based on PHP programmers building by guesswork. There's already a ton of it out there, and as the momentum keeps building, there will only be more.

> Using iterators in the > scaffolding is kind of like putting out a welcome mat, and encouraging > people to leave their bad habits at the door.

Perhaps it's more like putting out a welcome mat written in a language your friends understand but your guests don't.

I think you might be overestimating the difference between these two lines of code. An each may look somewhat unfamiliar, but it probably won't actually result in anyone's head exploding. I mean the word "each" is a relatively intuitive word, and people who are **completely** new to programming often find it **more** intuitive than a for loop.

Seriously. I once taught some college girls Java. They couldn't wrap their heads around it. The irony is that a year before they had done Scheme and had no trouble with it at all. Recursion and lists are much more intuitive to the complete novice, because the ideas are more elegant. For loops are pretty weird to people who aren't used to them. The only people who find for loops intuitive are people who are used to them because they've been exposed to bad programming languages for a significant amount of time.

Personally, I never use the for style enumerators, but I don't use scaffolding for anything except throwaway code either. YMMV.

No, of course my mileage doesn't vary. What kind of moron would I have to be for my mileage to vary from that? Thanks a lot. Jesus.

I'm right there with you, but that's the problem. I'm right there with you because I know better. If all the experienced programmers avoid for loops and scaffolding teaches for loops, that creates an unnecessary rift between experienced programmers and newbie programmers. You want that divide to be a gentle continuum. It's like Kathy Sierra's graph, the curve from "I suck at this" to "I rock at this." You want users to scale that curve as quickly as possible.

It's like the way acts_as_taggable is used in applications all over the place. It was just designed as a demo for polymorphic associations, but people saw it, copied it, and put it in production code. If you give people an example of how to do things, that's how they will do things. It's the power of monkey see, monkey do. Since you know monkey see, monkey do is going to happen, you might as well plan for it and do some good with it.

True; but encouraging programmers new to Ruby to write their code as if it were PHP isn’t going to result in beautiful code. The risk you’re taking there is of a glut, in a few years’ time, of ugly Rails

code based on PHP programmers building by guesswork. There’s already a ton of it out there, and as the momentum keeps building, there will only be more.

Dude, get a hold of what you’re saying! It’s just a syntactic variant, but it’s still enumerating >.<

I mean the word “each” is a relatively intuitive word, and people who are

completely new to programming often find it more intuitive than a for loop.

So you’re saying that

@posts.each do |post|

… is more intuitive than

for post in @posts

The latter not only reads better, but is easier to type. Using the former forces the designer to know about blocks and their arguments!

Seriously. I once taught some college girls Java. They couldn’t wrap their heads around it. The irony is that a year before they had done Scheme and had no trouble with it at all. Recursion and lists are much

more intuitive to the complete novice, because the ideas are more elegant. For loops are pretty weird to people who aren’t used to them.

You sure you taught those people well? Because I’d like to see a college girl getting fancy with recursions while still not understanding a simple for loop. Man, you need to loosen up - just because we use a language that supports iterators doesn’t mean we’re the best and that every other will eventually crumble under the ugliness of its loops!

Personally, I never use the for style enumerators, but I don’t use

scaffolding for anything except throwaway code either. YMMV.

No, of course my mileage doesn’t vary. What kind of moron would I have to be for my mileage to vary from that? Thanks a lot. Jesus.

Now you’ve just called the rest of the community (which uses for loops and scaffold generators) morons.

Please take this discussion from -core to -talk.

Thanks! jeremy

One last post - sorry Jeremy, couldn’t resist: http://pastie.caboo.se/65456

Run the script inside the framework root! It finds for loops in Rails code and finds out who commited them :slight_smile:

Here are the results for trunk: {“bitsweat”=>2, “marcel”=>1, “rick”=>3, “david”=>30}

DHH wins with 30 instances! So you see, even the king uses for loops.

> Please take this discussion from -core to -talk.

One last post - sorry Jeremy, couldn't resist: Parked at Loopia

Run the script inside the framework root! It finds for loops in Rails code and finds out who commited them :slight_smile:

Here are the results for trunk: {"bitsweat"=>2, "marcel"=>1, "rick"=>3, "david"=>30}

DHH wins with 30 instances! So you see, even the king uses for loops.

My mistake.