This reminds me of the UML and the Model-Driven Architecture movement of the days before, where architect astronauts imagined a happy little world where you could just get away from that dirty coding, join some boxes with lines in all sorts of charts and then have that generate your code. And it will produce code you actually want to ship and that does what you want to do.
This disdain for writing code is not new. This classic essay about "code as design" from 1992 (!) is still relevant today:
In the presenter's worldview it seems as though a lot of subtle details are ignored or just not seen, whereas in reality seemingly subtle details can sometimes be hugely important. Consider Ruby vs Python, for example. From a 10,000 foot view they almost look like the same language, but at a practical level they are very different. And a lot of that comes down to the details. There are dozens of new languages within the last few decades or so that share almost all of the same grab bag of features in a broad sense but where the rubber meets the road end up being very different languages with very different strengths. Consider, for example, C# vs Go vs Rust vs Coffeescript vs Lua. They are all hugely different languages but they are also very closely related languages.
I suspect that the killer programming medium of 2050 isn't going to be some transformatively different methodology for programming that is unrecognizable to us, it's going to be something with a lot of similarities to things I've listed above but with a different set of design choices and tradeoffs, with a more well put together underlying structure and tooling, and likely with a few new ways of doing old things thrown in and placed closer to the core than we're used to today (my guess would be error handling, testing, compiling, package management, and revision control).
There is just so much potential in plain jane text based programming that I find it odd that someone would so easily clump it into a single category and write it all off at the same time. It's a medium that can embrace everything from Java on the one hand to Haskell or lisp on the other, we haven't come anywhere close to reaching the limits of expressiveness available in text-based programming.
You can cast this entire comment in terms of hex/assembler vs C/Fortran and you get the same logical form.
We haven't come anywhere close to reaching the limits of expressiveness in assembler either, yet we've mostly given up on it for better things.
Try arguing the devil's argument position. What can you come up with that's might be better than text-based programming? Nothing? We're really in the best of all possible worlds?
I don't think it's fair to call him a Non-Coding Architect. Have you seen his other talks, or the articles he's published via his website http://worrydream.com ? Bret clearly codes.
I really wish he did. I think one of the greatest disservices he does himself is not shipping working code for the examples in his presentation. We've seen what and we're intrigued, but ship something that shows how so we can take the idea and run with it.
A delay in releasing code would be valuable then. Those too impatient to wait can start hacking on something new now and give lots of thought to this frontier and those that want to explore casually can do so a few months later when the source is released. Releasing nothing is a non-solution. Why make everyone else stumble where you have? That's just inconsiderate.
Dicebat Bernardus Carnotensis nos esse quasi nanos, gigantium humeris insidentes, ut possimus plura eis et remotiora videre, non utique proprii visus acumine, aut eminentia corporis, sed quia in altum subvenimur et extollimur magnitudine gigantea.
bingo, this remembers me of people not having time to get bored and then innovate by giving your mind some free space to go around.
The typical scenario of the problem solution once you give it a break....
Fooling around with a paint brush in your study is fine, but real artist ship.
A bunch of ideas that sound great in theory are just that, it is only by surviving the crucible of the real world that ideas are validated and truly tested. When Guy Steele and James Gosling were the only software developers in the world who could program in Java, every Java program was a masterpiece. It is only once the tool was placed in the hands of mere mortals that its flaws were truly known.
Walk around a good gallery. There are a pretty good number of pieces entitled "Study #3", or something of that sort. An artist is playing around with a tool, or a technique, trying to figure out something new.
Piano music is probably where this concept gets the most attention. Many études, such as those by Chopin, are among the most significant musical works of the era.
In another talk Bret claims that you basically cannot do visual art/design without immediate feedback. I was wondering how he thought people that create metal sculptures via welding, or carve marble, possibly work. It's just trivially wrong to assert you need that immediate feeback, and calls all of the reasoning into question.
Good point. I think programmers would be better off dropping the artistic pretensions altogether and accepting that they are much closer to engineers and architects in their construction of digital sandcastles.
You're forgetting about the hundred even thousands of painting they did that are not in the gallery. These paintings are the same as "shipping" even though you never see them in the gallery.
You can't play around with a tool or technique without actually producing something. You can talk about how a 47.3% incline on the brush gives the optimal result all day long, but it's the artist that actually paints that matters.
This reminds me of the UML and the Model-Driven Architecture movement of the days before, where architect astronauts imagined a happy little world where you could just get away from that dirty coding, join some boxes with lines in all sorts of charts and then have that generate your code. And it will produce code you actually want to ship and that does what you want to do.
This disdain for writing code is not new. This classic essay about "code as design" from 1992 (!) is still relevant today:
http://www.developerdotstar.com/mag/articles/reeves_original...