I do know someone who have successfully programmed in C# + ASP.NET using Notepad2/UltraEditor + command line. So it's not too far-fetched.

It depends on what you define as a 'tool'. Your POCO classes won't go anywhere unless a tool creates dyn. proxies of them at runtime or postcompiles them into a new assembly.

If a tool can setup, map and create your complete dal in 10 minutes, why spend hours in a texteditor to re-do what the tool could do for you much faster? Isn't that the point of using a tool? :)

I find it ironic you declare that resharper is necessary, while at the same time find that tools should be optional. :)

Actually, I think that I am being consistent here. I think that things that require tools are flawed. ReSharper is required to work effectively with C#, therefor, C# is flawed.

I gave the example of Boo, where I don't need R# in order to be effective. Would R# for Boo would be a good thing? Absolutely! But it is not required.

Tool - something that is required in order to get the code. You assumption about a complete dal in 10 minutes presume that I already have a schema. In such cases, a tool can certainly help, and would be valuable.

But think about this without the pre-existing schema, would I be able to be effective with just code, no tooling / generation required?

I don't agree with your assessment that you require SCSF to be effective with CAB. I spent a few months learning CAB long before SCSF came out. I do agree that you learn the foundations, and when I groked CAB, running CAB using SCSF was a breeze because I understood the concepts much like I said before that you really need to know why you do refactorings before you leap into using ReSharper to hone your kung-fu skills. ReSharper does not make for a better developer if he/she doesn't know why they're hitting all these keys and selecting this refactoring or that one. It does however make you a more effective developer when you know what you're doing. Same as SCSF which makes it easier to say implement the MVP pattern rather than creating 4 files manually and hand coding that. Although you need to know what it's creating and why in order to be effective. SCSF just makes you more efficient.

"Actually, I think that I am being consistent here. I think that things that require tools are flawed. ReSharper is required to work effectively with C#, therefor, C# is flawed."

Well, I don't consider myself an ineffective developer, yet I have no need for resharper or coderush or whatever. I think it's what you're used to.

"Tool - something that is required in order to get the code. You assumption about a complete dal in 10 minutes presume that I already have a schema. In such cases, a tool can certainly help, and would be valuable.

But think about this without the pre-existing schema, would I be able to be effective with just code, no tooling / generation required?"

And what will you do with that code? How will you get your schema? Using a tool!

I understand the point you're trying to make though: the tools used should be used because it makes the work easier however the operating user should still understand WHY the tool is used. Although I have to admit, that at some level and at some point, it doesn't matter really. Metaphore: does anyone care about the x86 asm emitted by the JIT at runtime? I don't: that's the CLR's job, that's the tool I use for that.

Often, a tool makes it so much easier to use a given thing ABC that NOT using the tool makes it almost too slow/inproductive. One could argue that the tool's necessity is then proven and thus that ABC is flawed, however you can also say that requirements to use ABC have changed so the tool is now more or less required now but wasn't before.

To give you a good example of that: TDD with mocks and refactor tools. One could argue with your argumentation that TDD is flawed by definition as mocks and refactor tools are essential to be productive with TDD. One could also say that TDD isn't flawed, it causes a change in how to work which implies that tooling is suddenly very important.

Metaphore: does anyone care about the x86 asm emitted by the JIT at runtime?

string asm = "";

for(int i =0;i<10000;i++)

{

asm += i.ToString();

}

Why is this bad? Understanding what the machine does (not necessarily at the ASM level is important to understand that in more than "Use StringBuilder" recommendation.

Other than that, I really like your arguments.

You can glance at a domain diagram in a DSL Tool and see intent much faster than if you examined code.

And for that, it is great.

Except, it takes me MUCH longer in most cases to get this DSL diagram to work the way I intend it to than it would in most text based DSLs.

Visual are a great way to SEE something, not necessarily great way to BUILD something.

I don't disagree with your approach, I just thing that this is something that needs to be considered as well.

I see all to often people goes ga-ga over the visual and getting themselves stuck over it in the end.

"Why is this bad? Understanding what the machine does (not necessarily at the ASM level is important to understand that in more than "Use StringBuilder" recommendation."

Sure, but to some extend. I've spend more than enough time in the dungeons of assembler, register tweaking/cache optimization etc. that I learned that the time spend on that kind of code and techniques is great but it also wastes a lot of time. Today, I don't care anymore. Don't you use .NET for the sole reason that it takes away so many headaches you'd otherwise have with a lower level platform like win32+C++? I do, and with that I delegate the obligation to do several things properly to the platform I build upon. Similar to a tool: the tool is used to fulfill a need to do a given action or sequence of actions.

What's a bit of a problem in discussions like this is 'what's a tool?' :) Most people think of a .exe with a UI, but I also see a DSL as a tool (text based for example) and ANYTHING which makes expressing what you want to do and getting that particular thing done easier and faster is IMHO preferable. The only drawback is that you by definition then depend on the tool to get that thing done, but you are always doing that anyway. One thing I agree on indeed is that people shouldn't fall for pretty pictures.

Typical example is the query builder in sqlserver management studio :) Some people really like that tool, while I can't believe anyone would want to use such a slow improductive tool while there's a DSL available to you: SQL.

@Oren

I am certinally not talking about "Todays" tools, so in today I think we both agree :-)

I am always looking for efficiency == pain.Ease();

I view future DSL Tools or whatever they may be called, as a visual ruby, BTW I am by no means a visual programmer, happy to roll in notepad as well. But I am starting to place constraints on myself, my intent is to be efficient, the last thing I want to do is fill my head with another xml format when a "good" tool could greatly ease the pain.

On a sidenote, I felt the pain of ASP.NET page / controls and their blackbox lifecycle and simply rolled my own. It was much faster to do that than trying to figure out why a postback doesn't work, didn't take that long.

You are really shaking thinks up, keep up the good work!

I think the post makes too big of a generalization. For instance, isn't Visual Studio a tool? And doesn't R# just have features that we wish were a part of Visual Studio?

****Tool -n.

"anything used as a means of accomplishing a task or purpose"

The computer is a tool. I love tools! If we didn't have tools we'd never of made flint,wheels & ipod nanos.

Via la tool!