...productivity and performance
It seems you are suggesting that productivity (and performance) are a function of the development tool.

It may be that design and those parts of the tools that we aviod using contribute more to "productivity and performance".

It's easy to get get lazy - bind a live table to a grid - limit a projects functionality to the narrower paradigms of the "macro-engines", like table-buffering, selects, scatters, views and gathers. Many of us have gone one step further - frameworks!

If we want performance and productivity, maybe we should get closer to the the more discrete, legacy pieces of the paradigm - maybe we should revist the rudiments of design and organization?!

But now - a lot of development seems to be: Slam a GUI together (put some spinning logos on it!) so the client will know we're doing something - and then guess our way through what the application needs to do later.

It's almost as if we are convincing ourselves as well as our users, that the GUI is everything. We do GUI layout without regard to how the GUI should relate the data and the user. Like urban myth, where a guy with a broom stick handle beats a room full of hustlers wielding 3000$ queue sticks, a day may come when those in corporate pollo shirts and laptops loaded with the latest and greatest astric dot astric, start getting beatup by time, budgets and no-body programmers with an old MS-Basica EXE (maybe an exageration).

Smart clients can usually see through the ruze the this or that platform gambit - so we need to be careful when we make our pitch. A marketing consultant once told a group of us that making negative comments about a particular compeditor or product (or technology) is bad for business. Eye rolling technical comparisons may be just as bad. You never know who in the room might get offended.