Its on! Let’s take some chunks out of DSL blub coders too, cos they never think about semantics, uniform notation or intermediate parse trees.

Wasn’t meant to be a barrage of fury but I’m definitely going to be more diplomatic next time.

Anyhoo – on the whole topic of coding within a framework versus understanding it, I think everybody should read “Code Generation In Action.” It’s awesome. The guy’s like, OK, you’ve got to build a J2EE enterprise app with EJB. The DB has 150 tables, so you’re going to need 150 beans, that’s 7 files per bean (that really is how EJB works), so, let’s see, 150 * 7 = 1,050, so that means we’ve got to write 1,050 files, so, if you do it by hand, that’ll take three years. So, let’s write something in Ruby to autogenerate every bean and all the affiliated files for each bean, that’ll take maybe a week, maybe a few days. Boom, problem solved. In fact it even makes using a hefty framework like EJB seem relatively reasonable, as long as you’re writing Ruby to write Java for you, instead of actually writing Java, because, you know, who would write Java by hand when it’s so much quicker to write Ruby which writes Java for you?

He’s basically trapped in a framework Java project, and instead of being like, oh well, better take my lumps and code to the framework like I’m supposed to, he’s like, no no no, that’s too much work, frameworks are easy enough to code to that I can write a program to do it for me. It’s funny too because his attitude is so nonchalant, he’s like, obviously, since we’re using a Java framework, we could write Java, but that would be a waste of time. It’s such a kickass, cowboy attitude, but the book has this incredibly dry, serious delivery, with UML diagrams and everything, like a standard “enterprise Java” book which just happens to casually mention that coding Java is basically a waste of time.

Anyway, reason I bring it up, if you’re not a framework coder, but you’re on a framework project, this is one way to just totally go beyond the limitations of framework coding.

I’m willing to bet a year’s worth of salary that the Next Big Language will bring with it a lot of bad programmers and those will bring their bad habits with them.

I wouldn’t want to make that bet against you! I’m not actually in disagreement with that; I just think that I’m still going to call it a Rails issue rather than a larger thing, because the larger thing is really difficult to get a handle on.

Also, Tim’s writeup on my alleged “rant” does nail your :conditions concern, turns out to be a nonissue.

However, I think Tim took the criticism entirely personally, it certainly wasn’t intended as a rant, and the whole thing could be a lame-ass flamewar unless it’s treated with diplomacy. I definitely should have written that post differently.

Although, the inverse argument can be made as well — developers that insist on “rolling their own” each time they work on a project are just as bad as developers that don’t understand the nitty gritty. Arguably, they’re worse — because if you stumble across that removal code snippet, you can always refactor it to improve performance. If someone writes their own flavor of strings to squeeze out that last drop of efficiency, your project is married to it forever.

It’s definitely important that developers understand mid-level concepts like SQL, and even low-level concepts like floating point arithmetic, memory management, the stack and the heap, and even the ALU and how it processes instructions. That doesn’t mean that they should be thinking about it every time they write a line of code. That’s why we write in fancy languages like C#, Java, Python, and Ruby — so we don’t have to worry about things like that all the time. Same thing goes for frameworks.

Framework coders don’t go beyond the framework. They’ll never look at SQL produced by the framework and try to figure out if it’s using an index or running a full table scan. As far as they know, code starts and ends at the framework.

Other developers understand that the framework generates SQL, what it looks like, and that sometimes you have to grab these statements from the log and describe them in the SQL console to see how efficient they are.

And the same analogy for view sourcing your HTML, or reading the generated XML, or checking out the cache control HTTP response headers, just to make sure what you’re telling the framework to do is what you want to happen.

Separately, I’ll have to see if there’s an upgade for the OpenID plugin that will fix the delegate issue,

(your openid login did not work for me. I use ewout.org which delegates to myopenid.com)