It's also how Mac OS X, Windows XP, Windows 95, and most of their precursors were designed. There's just been an acceptance amongst OS designers that testing with real humans is the only way to know if things are actually easy.
Programming languages are unique, however, in that the people building them are often also the users (and the more this is true, the better the language tends to be). C was designed to build UNIX, while ADA was designed for a customer...and we know which one survived.
But, I also simply can't buy the "people understand naturally" logic. People understand very little "naturally"...and even if you include pre-existing knowledge (like English, or spatial skills) in this "natural" knowledge you still end up with a pretty horrendous and limited programming language. Explaining an algorithm in English almost always takes a lot more "code" than writing it in a decent high level language.
testing with real humans is the only way to know if things are actually easy
Yes, yes, of course, sorry for being unclear - I just meant that we shouldn't rely on design-by-focus-groups or design-by-committee exclusively, that imaginative solutions require creativity, and for that you need someone with taste.
People understand very little "naturally"...
Well, OOP utilizes our spacial skills, at least in the form of all those pretty UML graphs? There is certainly a lot of thinking left to do about how exactly we understand programming languages, both on macro and micro levels - what metaphors we use to understand scope, objects, functional concepts, etc. It's from this thinking that new language designs will arise.
CRC cards on 3x5" card-stock are better than UML. Otherwise, I agree. Until GUIs for applications are as natural as passing 3x5 cards around, there's going to be an impedance mismatch between the GUI and the domain.
Ada has a pretty impressive record in safety critical systems; something that cannot be said of C. Aircraft software systems and many air traffic control systems in particular are all written in Ada.
And yet, somehow, I've never seen a single line of live ADA code...and there are literally hundreds of millions of lines of C code doing work right now. Not only that, someone is almost certainly starting a new program written in C right now...and now...and now...and now. And...you, guessed it, now.
I'm sure Ada had a useful life, possibly even in a niche where C would never be an effective tool. I was just saying that design-by-committee, even with a lot of user input, is probably not the right way to build a timeless programming language, and that building a language while using the language probably is.
Ada never caught on as a general purpose programming language, but a subset of it lives on in PL/SQL, the embedded language in Oracle. It's not the most flexible or elegant language, but it's easy enough to learn and extremely reliable. It's all about choosing the right tool for the job. Sure you can run C in-process with your database, but unless you really, really have to it's a bit pointless to risk i.
Programming languages are unique, however, in that the people building them are often also the users (and the more this is true, the better the language tends to be). C was designed to build UNIX, while ADA was designed for a customer...and we know which one survived.
But, I also simply can't buy the "people understand naturally" logic. People understand very little "naturally"...and even if you include pre-existing knowledge (like English, or spatial skills) in this "natural" knowledge you still end up with a pretty horrendous and limited programming language. Explaining an algorithm in English almost always takes a lot more "code" than writing it in a decent high level language.