| Excellent points! > I've yet to encounter a more precise and usable input mechanism than the keyboard.
> You can also imagine more effort into displaying code in a less textual manner, even if the keyboard remains the primary input. I agree the keyboard is definitely a great 'high bandwidth/fidelity' input mechanism and I don't see it being easily replaced. Can we use it to manipulate something other than 'text files'? As a simple incremental improvement, manipulating a tree like structure directly comes to mind. I'll note that the powerful operations in most text editors already use models that treat the text as something more structured than a 'sequence of lines'. > how can I express (circle (/ height 2))? The second expression is where programming gets interesting. I don't imagine text being completely eliminated at all levels, but a hybrid model where you could have many views of the same 'literal'. E.g. something like http://aprt.us where you can draw an object, but then also fiddle with it's parameters in another inspector - including binding those parameters to other inputs. I imagine you'd also also have snippets of text here and there, or occasional text views of objects. > But plain text has a nice advantage over these: it's always clear how to reproduce what you see. This actually a valid point and I hadn't thought much about it. Perhaps the trust is just a result of the current situation where text cloning (copy-pasting) is reliable, but object cloning is either impossible or hacky. If I could drag a diagram off a wikipedia page, manipulate its parameters and integrate it with my program - that would be something. > Sketchpad (https://en.wikipedia.org/wiki/Sketchpad) is kind of interesting here, as my impression was that what made it special wasn't just the interactive graphics but that it was a constraint-based system Yes! Interestingly that model isn't widely used either. An interesting generalization of this could be an 'interactive' programming experience - where I try to compose two artifacts and the computer offers N options to do that composition, based on what it knows about the artifacts and known constraints. Then I narrow them down by selecting one or adding more constraints, etc. Type checking is very clunky and rigid form of doing composition that IMO forces me to do too put in too much effort of the wrong kind. > Symbolic computation has the possibility of doing something and then telling the programmer why it did what it did. This does sound interesting and touches on another issue I have with the systems today, that they require me to simulate the computer in my head too often (while sitting in front of a computer, ironically). I suppose light table like tools are trying to solve the problem, but there is a broader problem in that the surrounding infrastructure is not conducive to such tools - many interesting things I'd want to see are buried in secret file formats and internal in-memory structures of the compilers and runtimes. > A graphical object is one example, but what if we could do that for all kinds of output? Yes that would be awesome! > Maybe textual output is problem, not textual programs? As are 'hidden' representations that I have to mentally simulate.
Ideally I want to see not just the immediate program I'm manipulating (text or otherwise) but also the implications - the affected parts of various other intermediate representations all the way to the running, live system that will be affected. |