So the use of standard abstractions and conventions in something like a DAL show a lack of what, exactly?

It shows a lack of nothing. What DAL is a code generator that writes large quantities of code based on your 'models'? It simply provides a better or easier interface.

Here is what I meant: When a commercial application becomes popular to generate large amounts of code to do a small amount of work, like some CRUD, I personally feel that shows a flaw in the fundamental way the language works. The language should either be able to offer you a better way of doing it yourself, or writing a small framework for yourself. If neither of these are viable options, I would consider that a serious knock against the language.

I'm hoping I'm not getting into a flame war -- not my intent.

Here's the problem with what you said -- the word "code". It's not defined. In any kind of large environment, my application uses all kinds of compiled code. So what if I push a button or flick a switch to use another hunk of code that I don't have to write or test? Is using System.Io somehow "better" than say, having an automated macro that generates IO based on some user preference?

Yes -- I would agree that if I have to write and maintain a large amount of code to do easy stuff we've got a problem somewhere. But if my platform is powerful enough to allow me to use multiple Data Access paradigms without any work on my part? Who cares if when I flip the switch the code is generated and compiled or if it was generated and compiled last week or last year?

Take a look at something like CodeSmith. Here's a tool that uses .NET to write programs for .NET. Now yes, you can generate a lot of code that way -- if you want to look at it like that. You can also go and get open source libraries and templates that will generate tested, proven, full-featured libraries based on your particular situation. Isn't that a much better thing than simply having one paradigm that everybody has to shoe-horn their work into?

No cause for concern - I understand that a lot of what we are disagreeing on here are small points. This is the proper venue for discussion, and I appreciate your points. I do agree that having some sort of code generation does have a place, and can be useful. But it is also has it's problems, especially related to maintainability. Lastly, the last time I looked at some code generation, there was so much custom junk built on top of the generated code, it was like they were using a round peg for a square hole.

Obviously, I am biased by what I have seen in practice. I also dislike a lot of 'magic', or things I don't understand and have control over being tightly integrated with my code.

I've had a lot of bad experiece with Code Generation as well.

What I think I see happening over the past few years is a lot of authors and researchers developing code generation templates as part of their work. So instead of the guy who's got the book telling you to make 7-tier, multi-phasic, distributed apps, you got the guy, a website, a following, and a set of templates and wizards that make this thing for you.

I'm not crazy about that at all, but I think it is having the effect of evolving the code generation community. I'm seeing a lot more people who want to "program the programming" Most, of course, create monsters. But it only takes one good set of easily-used and rock-solid templates to create real value for everybody. So in the old days, there was 5-10 CASE tools and they all sucked, now there's more like 500 template authors, and 10-15 are pretty good. In my opinion, that's a good trend, but the genre of "code generation" still has a well-deserved negative connotation.

Please. Keep down-modding me on this thread. Show me how you really feel! (laughing) By voting me down you can show your disagreement without actually having to participate in the discussion.

this entire post was destined to be a flame war...