Aww right, Brett Victor's DYNAMICLAND website is finally online!
This piece on 'Ladder of abstraction' from Brett Victor's website is everything I've been struggling to articulate for a while.
http://worrydream.com/#!2/LadderOfAbstraction
<<Unfortunately, development environments generally don't support this process. Most are actively hostile to it. We live in primitive times.
If a language requires a "compile" or "refresh" to show the results of a change, it even denies us interactive control. >>
<<Perhaps someday this will change. Perhaps IDE makers will focus on dynamic exploration instead of static analysis, rich visualization instead of line debugging. Perhaps language theorists will stop messing around with arrows and dependent types, and start inventing languages suitable for interactive development and discovery.
Until that glorious day, it is our sad but unavoidable responsibility as system designers to build our own tools. >>
Also his 'Kill Math' on visualisation:
http://worrydream.com/KillMath/
<<Teach the current mathematical notation and methods any way you want -- they will still be unusable. They are unusable in the same way that any bad user interface is unusable -- they don't show users what they need to see, they don't match how users want to think, they don't show users what actions they can take.>>
<<Mathematics, as currently practiced, is a command line. We need a better interface.>>
My thoughts:
There is of course the valid argument that the Unix command line simply lets you do things you can't in our existing GUIs.
This is true.
What we actually need are GUIs that visualise the command line, and command lines that take realtime feedback from GUI elements.
Alan Kay: https://archive.org/details/AlanKeyD1987
<<The sad part of [the doing -> images -> symbols] diagram is that every child in the United States is taught math and physics through this [symbolic] channel. The channel that almost no adult creative mathematician or physicist uses to do it... They use this channel to communicate, but not to do their thing. >>
Unfortunately, I would disagree with this line from Brett Victor's original article:
<<They can be crude, ugly, and fragile. They can crash twice a day. They simply need to serve as scaffolding for our understanding.>>
No. This won't do.
If we have dynamic environments CONNECTED TO THE INTERNET which crash twice a day, WE ARE GOING TO GET A LOT OF PEOPLE SERIOUSLY HURT.
The Internet is a digital war zone. Our tools must be dynamic, but they must be SAFE to connect to that war zone.
I mean, sure, I fully understand, in an environment YOU CONTROL, which isn't receiving packets from the Russian Mafia and 4chan, and you're just after insight to an isolated data system, yes, it doesn't matter if it 'crashes'. It can crash safely.
But if you ever put that code into production, by God that code that was 'good enough' to make your mockup better not be accepting raw unescaped HTTP variables and executing them on the Unix command line as root.
How to square that circle, is hard.
@natecull Also, with crudity, ugliness, and fragility, there’s a point beyond which your users give up on you.¹
___
¹Especially those users who aren’t professional programmers.
@natecull looking at the system, (seems to be a fairly basic set of sensors, EL displays, maybe a beamer (projector) overhead it *shouldn't* crash twice a day. If it does; there are problems with the gEMI (inteference from other things are getting into where they should not be).
Solving *that* is not rocket science; might mean a bit more shielding, redesign or relocation of RF based equipment and paying attention to both signal and protective earth (earth ground) but it *can* be done.
@basus @natecull the problem I see (this may not be through any bad intent but simply Bret the tech is trivial) is that there isnt any gitlab or wiki or other place shared showing you how to replicate the experiments. I can see they are using easy to obtain commodity electronics and AV equipment, but even basic pointers on how to build just one bit would help. Especially as I could directly use some of the tech for my work where many non tech staff and patients could use it for activities.
@natecull There's ... an element of this in docfs.
@natecull "As long-time users of Unix, we're well aware of the power, efficiency, scalability, and flexibility of the command line. At the same time, there are times it's more efficient to view or interact with graphical presentations. Rather than being doctrinaire about one or the other, each mode should be utilised to its best advantage where appropriate."
@natecull "In general, _commands_ and _data output_ should utilise a console. _Content_ output _may_ be directed to console (e.g., ASCII text dumps, or an abstract or brief description), but will _generally_ be presented as a graphical presentation equivalent to an HTML document, PDF or DjVu presentation, or various eBook formats."
@natecull The problem with GUI is that you’re at the mercy of what the designers thought of at the time in what you’re allowed to try. Command lines are black magic, but they’re perfectly willing to let you erase your system in your experimentation
@natecull For example, there is no reason that filenames in a directory listing on a terminal screen can't be hyperlinked to the corresponding file representation in the GUI.
We have simply stopped thinking about these things. For no good reason.
Conjecture: The www sucked too much of us too much into it.
@natecull Thanks!
Ok, I’m in, but I really wish their LANDING PAGE didn’t make you pinch and zoom at the end of 2017.
@natecull Of course, given their goal, why should they care about something as paltry as a website?