“What next?”
I&#x27;d say the elephant in the room is graduating beyond plaintext (projectional editor, model-based editor).<p>If you think about it so many of our problems are a direct result of representing software as a bunch of files and folders with plaintext.<p>Our &quot;fancy&quot; editors and &quot;intellisense&quot; only goes so far.<p>Language evolution is slowed down because syntax is fragile and parsing is hard.<p>A &quot;software as data model&quot; approach takes a lot of that away.<p>You can cut down so much boilerplate and noise because you can have certain behaviours and attributes of the software be hidden from immediate view or condensed down into a colour or an icon.<p>Plaintext forces you to have a visually distracting element in front of you for every little thing. So as a result you end up with obscure characters and generally noisy code.<p>If your software is always in a rich data model format your editor can show you different views of it depending on the context.<p>So how you view your software when you are in &quot;debug mode&quot; could be wildly different from how you view it in &quot;documentation mode&quot; or &quot;development mode&quot;.<p>You can also pull things from arbitrarily places into a single view at will.<p>Thinking of software as &quot;bunch of files stored in folders&quot; comes with a lot baggage and a lot of assumptions. It inherently biases how you organise things. And it forces you to do things that are not always in your interest. For example you may be &quot;forced&quot; to break things into smaller pieces more than you would like because things get visually too distracting or the file gets too big.<p>All of that stuff are arbitrary side effects of this ancient view of software that will immediately go away as soon as you treat AND ALWAYS KEEP your software as a rich data model.<p>Hell all of the problems with parsing text and ambiguity in sytnax and so on will also disappear.