I switch back and forth between Bret Victor's perspective and yours- while what we do now has its advantages, it also has its disadvantages, and the same goes for these other ideas. I think what he's lamenting (and what I keep coming back to) is that many of the inconveniences and shortcomings we fight today were solved decades ago, and there hasn't been a lot of work to bring both approaches together. You can't deny the powerful effect of legacy code on the way things progress (C++ and Objective-C are good examples).
The biggest area that we could advance in without even touching the way we do stylesheets/markup/text files is debugging. We still use line-by-line step-through debugging (or even just a bunch of print statements, in a lot of dynamic languages!), while compilers internally have had complex data and control flow analysis for years. Why can't we look at the dataflow through a whole function while we edit it? Why don't we have better visualization tools for which paths are taken under what conditions? This is all near trivial for a computer to tell us, but we often sit here and stare at our text editors and debuggers for hours puzzling through it.
The other biggest area that we could improve is programming languages themselves. For a long time we've been stuck with (for the majority of the industry) either the C family, with its header files and
literally undecidable parsing and incredibly poor semantics of
undefined behavior and unrestricted aliasing and all, or a tower of babel of exorbitantly dynamic interpreted/JIT languages with memory layout semantics so restrictive they can't even handle Minecraft without accidentally running into
memory bandwidth problems.
Happily, we are starting to see a light at the end of the tunnel with language design at least. While web programming is still a hopeless, roiling mass of JavaScript frameworks and "transpiled" languages that completely reinvent themselves every two weeks (
The Birth and Death of JavaScript is hilarious on that topic), there are a few new languages that actually bring some sanity.
- Google's Go, while not really useful for OS dev and not my favorite language by any means, is a fantastic replacement scripting language in many ways- it's still garbage collected, but it has sane memory layout semantics (i.e. not "box everything and let the GC handle it!"), a sane type system (i.e. type inference rather than "tag all the values and dispatch everything at runtime!"), and is thus natively compiled (rather than "let's interpret it- no, let's JIT compile it to try to gain back the performance we flushed down the toilet with a giant Rube-Goldberg contraption!").
- Mozilla's Rust is more at the level of C or C++, but with proper modules, sane semantics wrt undefined behavior, aliasing, etc. (and thus more optimization opportunities than C, harking back to the days of FORTRAN), static memory and thread safety so your system libraries aren't riddled with remote code execution vulnerabilities (again, already solved years ago in languages like Ada), and a much simpler type system that retains more power than plain C (no multiple virtual inheritance thank you).
What we need is to combine the simple semantics and formats we have with the analysis and visualization tools Bret Victor is talking about. Then maybe we can move forward.