I'm not so sure. Granted, I might write html in vim, but I'd prefer writing Markdown or ReStructuredText. We
could have a (subset of) full html in the hn comments - but it'd likely get in the way, rather than be helpful. Medium is a nice way to publish some text with images. Note the "with images" part. Vim is a much better text editor, but I don't think it's a very good hypertext editor. I don't necessarily need WYSIWYG all the time, but an object oriented/rich graphical editing environment certainly has its place.
I'm reminded of the original MVC paper[1] - about presenting an interface that matches the users mental model, through the interactive graphics and back into the computers internal data model.
Earlier it occurred to me how crazy it is that so many of our popular languages work on such primitive data structures still. The most obvious being null-terminated ascii strings in a globalized world - where ascii is effectively always the wrong choice (or at least, "not best"). But I'm thinking more about using any other structure than images, 3d models, databases. Why do we work so often with bare variables? I mean, in embedded programming, I guess it's interesting to think about two's compliment, overflow etc - but really. If we can't even handle numbers, vectors in a natural way - aren't we doing something terribly wrong?
The more I think about it, the more I come to believe that many of the ideas of hypertext, Smalltalk/Object Orientation, HyperCard, CAD/3D programs and 2d drawing packages (as well as decent DTP programs) are on the right track: let us use type information and other meta-data to manipulate structures - both "code" and "data" in richer ways. Let me see my code as a graphical finite state machine/diagaram. Allow me to work with my generated matrix as a heightfield in 3d and as a greyscale image. Let me visualize the steps of my sort algorithm, not just look at assembler in a debugger. Why not show me my stack(s) as 2d or 3d stack(s)? Not all the time, but when I want to?
I do like vim, for editing text, and working with our rather dumb programming languages, that might be considered "text+". But they're not really rich, they are hard to visualize, listen to, paint on. And for some things, that's fine. All we need is some text.
But I would argue most good history books has a few images, and maps. Rich media. Even math books do. Maybe the problem with fourth generation languages have been that they wanted to "fix" programming. Rather than just fix some parts, like Elm, with its natural integration of stepping back and forth in time.
Vim is a great tool - but it may be overspecialized on manipulating text: text objects, lines and letters. Those are not generally the semantic objects of programming (excepting perhaps those that make a living coding in brainfuck). I view lisp as a way to simplify "down" to text. And something like hypercard, smalltalk or the lively kernel project as attempts at simplifying "upward" -- to work with the structure. But that requires something beyond simple, human-readable text. You need to save a workspace, and a memory image. The systems acquire a lot of complexity in order to realize their simplicity.
But in case of lisp, the system is generally rather complex underneath. There's still compilation to machine code. There's still some kind of graphical interface, font rendering. Maybe what amounts to a different operating system who's only job is to boot your operating system that runs your lisp environment...
Personally I don't really think C is particularly simple. I still have to look at the assembly to know what's going on. And if the code ends up running on an Arm, or a CPU not yet invented, I'm still kind of lost. I don't really understand the details of how the assembly I can read, interacts with hyperthreading. In the end, what I really care about is the effect of the code - and that is really something I need to test and measure in the context of a running system. And the complexity of that, is likely so that I end up with sampling under various conditions, and doing some timing runs.
This "eagle view" approach doesn't mean I don't ever think about memory layout, algorithm complexity and such. But it does mean I rather rarely think about what actually happens deep inside the machine and the three cache layers.
[1] http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html