Components or generators?

Well, everyone seems to agree that RAD tools are the future of programming. Still, programming languages are being developed like RAD never existed - or with a very weak support at best. The way things are envisioned today, programmers will be developing or consuming components from here to eternity. But this is really not the essence of RAD. You can make components without RAD tools. What RAD is about is generating code.

Programming should be something akin to editing resources in today's IDE tools (I'm thinking Delphi, VB or Visual Studio): you have the option of writing their source code directly if you want to, but usually you don't because it's complicated - and there is a visual editor that does this for you. The resource description language is far too complex for anyone to mess with, but experts can probably do stuff not possible using the editor.

So what I'm saying is this: we don't really need programming languages to be utterly simple (well, not all of them anyway). Give us the power of C++ - and more, but organize development so that only expert programmers really need to write code. How to do this? Obviously, for non-expert programmers, we need to generate code. This is the point where, ironically, RAD tools fail, and the reason is that their code generation capabilities are not powerful enough. People fail to see this because everyone thinks that components should be the building blocks of everything and that non-experts only need to write glue code. Which is not what's really happening.

Any given component is way too rigid to use for simple stuff: it's good enough to do a complex banking transaction, but how do you make a component that does a simple iteration, recursion, or a sorting operation? The problem is too low-level for a component, yet too simple to be solved over and over again in every source file we write. I say, "for" and "foreach" statements are not nearly intelligent enough for what we need. We need "iterate_forwards", "iterate_backwards", "iterate_auto", "recurse", etc, and wee need a simple way to add more. And a simple way to use these without reading volumes of documentation or proving by trial and error which one is the one we wanted.

Public fields in C# outlawed by FxCop

There is a rule in FxCop that screams if there's a public field in a class. It says, convert it into a property, because properties work as fast as fields. This may well be true, but it's not an argument in favor of properties. How's this: it's much faster to create a field; and changing a field into a property is absolutely painless in C#? I thought this was the point of C# get and set accessor methods in the first place.