> The second part — what computers can do — is a well understood domain that can be modeled beautifully, and tasks involving it can be automated trivially I ha

> The second part — what computers can do — is a well understood domain that can be modeled beautifully, and tasks involving it can be automated trivially I have a chipset that I'd like modeled, and can I have some trivial drivers by next Tuesday? Modern computers are not trivial. They are probably the most complicated devices on the planet, full of features, edge conditions and screw cases that are not obvious even to very skilled developers. I've done some very fast platform bring-ups and gotten them to ship, projects organized to be very light-weight and agile (in the non-political sense) and it's still many person-years of effort and a bunch of time on the phone with vendor support, discussing chip-level bugs (can that model please include the bugs? That would help a lot!) No talk at all about pleasant abstractions, we need to ship this pile of silicon. Visual interfaces are for toy programs that spend resources on making pretty illusions of how the world should work. Underneath the pretty glitz are piles of slain dragons and machinery that people take for granted and apparently think can be wished away. That's fine for end-users and application level folks, assuming they can get their jobs done without resorting to breaking the abstractions (and any sufficiently large or long-lived project will). But someone has to worry about memory management, concurrency and synchronization, all the drivers for fucked-up hardware that (say) locks up when you fire data at it too fast, what happens when the file system fills up or that configuration file is mangled by an upgrade. All that nasty stuff that the "drag a blue wire from point A to point B -- see, easy!" doesn't handle, and never will. On one project we had a clock that would, very occasionally, go backwards in time. It took a calendar year of going back-and-forth with support and ultimately a phone call with the chip architect to figure out the problem (the workaround for the bug was unpleasantly expensive). It's easy to model a clock and come up with a set of expectations. It is much, much harder to make a clock work in the real world. You would not believe how hardfought some of this stuff is, for features that are "trivial". Visual programming is great when it works -- I've certainly done my share of it -- but we should not mistake ease-of-use in some domains for revolutionizing programming in general, or (worse) expecting the paradigm to work when things get complicated and large.