I love this kind of stuff, but it feels like shooting fish in a barrel when the examples used are inherently visual. Lots of programming deals with abstract "things" that don't naturally lend themselves to being visualised, and it's there that some of the the more difficult challenges of programming exist (perhaps because they're difficult to visualise in the first place).
I'd like to see Bret's brilliance tackle visualising those types of examples.
Maybe most of it simply can't be visualised, but I feel like there's a lot of unrealised potential in that space.
I feel like having programmed consistently since I was 9 (24years now, wow) this is my biggest strength. When it comes to code and architecture I sortof just see it in my mind. It’s very plastic. Like a malleable thing that my brain does without really knowing how or why. It’s just there.
Can’t even put it into words. Can’t draw it either. Like when you ask math people how they do some of the really complex stuff
This comment resonated a lot with me. Here's something I was thinking about recently:
1) I also started programming very young, maybe eight or nine years old.
2) My first language was Python and I still program in Python today, the programming language with the motto "there's only one way to do it". At some point I had to write Perl for a summer job and it's TMTOWTDI attitude and many symbols nearly broke my brain, I hated it for most of the summer.
3) I used vim and then emacs for a very long time, and recently started using Visual Studio Code and Pycharm. This made me realize that one of my favorite features of any editor was actually the minimap VSC provides on the side by the scrollbar (which Pycharm does not by default provide). Not having it, having it, and then not having it again made me realize I utilized it a surprising amount even though it's a seemingly trivial feature compared to, say, code completion or syntax highlighting. It was just very fast for me to jump around a large file by clicking on the minimap; I knew where to click to jump to the function or class I wanted.
4) I am a vicious style guide zealot. I got poo-poo'ed once by a coworker for submitting a large commit where the only changes were renaming things to snake_case. But the code just looked wrong to me, I had to do it. I write C/C++ in K&R style and find it difficult to read code not indented as such.
I was sitting on my lunch break and all these things kind of crashed together into a great epiphany - maybe the reason I program in this specific way is because the code has to look a certain way in my head. Like I'm literally imagining a sort of minimap in my brain and if the syntax, conventions, order, spacing, etc. are wrong it screws up my very visual model because it literally looks wrong. The more rigidly the code follows the rules, the more visually consistent it is and the easier it is to structure.
Your comment makes me wonder if there really is some semi-visual, semi-textual model that certain programmers form of their code, which is ever-present but really hard to express in other ways. I also wonder if this is a common thing, and if it helps or hurts when programming.
I'm like you - except I started with C++ (and prior exposure to Basic, Pascal, and VBA). The code has to "look right"; it's a visual thing, but there's no describable or drawable "shape" I could point to.
I've been through the "code case and bracket style must match" period, but eventually my brain abstracted over it, and it's now a free variable - I can work with any style, but it must be consistently used, or else it'll trigger that visual feeling of literal ugliness.
I also had a visual enlightenment with Lisp code, where one moment, I thought it was clumsy, and then something clicked, and ever since I consider a (properly formatted) Lisp code beautiful.
I understand this phenomenon all too well. I experienced another, similar phenomenon, albeit not with the code itself.
I've done literally all my best work for the past 25 years in Emacs. Recently I decided to switch to Visual Studio Code because "that's where the momentum is now". Well, it lasted a few weeks and then it was back to Emacs. I wondered why this was.
I realized that despite using Borland and Microsoft IDEs in the 90s, I never acclimated to the way IDEs in general handle small tasks like bracket matching and indentation. Emacs does these things right in a way that virtually every other IDE-like editor does wrong. I can work with vim, but working with VSCode has a sort of tactile (instead of visual) "ugliness" about it that increases friction and makes me actually less productive.
That and the wrong way VSCode handles File / Open by default made me frustrated enough to go back to Emacs.
Right: Electric indent. Tab at beginning of line automatically indents line to desired depth. Editor's guess at indentation level is almost never wrong, and the exact level is configurable.
Wrong: Hit return and the next line is automatically indented; other than that you're on your own.
Right: Flash the opening bracket or quote when you type the closing bracket or quote.
Wrong: "Helpfully" close opening brackets or quotes, but do not provide Paredit-like structured editing features, leaving the user to accidentally type spurious extra brackets/quotes. (Some IDEs skip over the preinserted closing mark when you type the same mark with point on the closing mark. But they're woefully inconsistent about this and Visual Studio Code does not do this.)
Right: Visiting a file does not otherwise affect editor state.
Wrong: All state for the editing session in the current window is clobbered when you do File / Open from the menu. User must spawn a new window in order to preserve editing state in this window.
Quietly pleased to find I agree with your wrongs, especially “helpfully” adding a closing pair item, but sad I haven’t used something that does them better.
Speaking only for myself, I’m a wee bit “on the spectrum,” and basically work in some kind of “symbolic IDL,” inside my head.
As long as I never need to verbalize my design, I can keep a pretty massive architecture completely unwritten, in my mind. This makes it possible to work extremely quickly, with big “on the fly” changes to my implementations; performed “inline,” as I work.
The moment that I need to verbalize or “overall” document things, though, the whole gravy train comes to a screeching halt, as my brain needs to do some kind of “context switch.”
BTW: my code is pretty “anal.” Highly formatted and documented. I actually feel physically uncomfortable, if it isn’t formatted the way I like.
Yeah, I’ve always found this sort of Bret Victor argument weird: yes, perhaps more graphical tools are the future. However—in both writing and math, it seems like there’s a tendency to start with more pictographic notations (Egyptian hieroglyphs or Greek geometrical figures) and move towards more abstract notations (phonetic alphabets or algebraic notation). It’s not clear to me that attempting to reverse the trend and pictorializing programming languages actually benefits anyone, except when learning. it’s a bit like my experience learning Lisp: when I started out, I was really into indentation-based syntaxes that hide parentheses; once I started to internalize the structural editing tools, I discovered that the “cluttered” parenthetical notation was actually a reason _to_ use lisp and not something to be covered up.
You make a great point about notations becoming more abstract for more advanced use cases, indeed this may be a "natural" process. However I'd like to add nuance with the observation that Bret may not be suggesting that we reverse the trend from abstract notation back to concrete visualizations. Actually I think he is calling for a rich variety of visual/concrete notations and symbolic/abstract notations that work in concert together to express our dynamic concepts, and extending those with the use of the dynamism of the computing medium to add interactive aspects to the notations (ala "Magic Ink").
His talk "Media for thinking the unthinkable" goes into detail on this, especially from minute 10 to minute 17:
https://youtu.be/oUaOucZRlmE?t=600
The essay Magic Ink: INFORMATION SOFTWARE AND THE GRAPHICAL INTERFACE also goes into detail about this topic
http://worrydream.com/MagicInk/
Yup, when I do programming, I imagine the data inputs to be some "shape" and, in my mind, that shape transforms as I apply operations to it, like `filter`, `map`, `take N`, etc. I just visualize what I want the data to do, then start modifying it.
Another set of analogies I use is that the data, to me, is like clay or a block of wood, and I'm either forming or carving it depending on the context. For example, if I am doing some calculation where I take several bits of data and combine them to get a result then I'll imagine "forming" the data like clay in my mind as I apply mathematical operations to it like `*` or `sin`. If I'm doing stream operations in some "rules engine" where I need to sort through the data, rather than a straightforward equation like the former example, then I imagine "carving" the data like wood with `filter` or `reduce`.
I also get a "feeling" when I look at code or architecture as to better ways to do it, I don't have evidence at the time to support my feeling, but later on they are often correct.
Also, I don't break things down into tasks as such, but I do start a project/task by commenting with TODO at high level and then drill down, much like a functional programmer would do so. For example, if I'm writing a tool to count the number of lines in a file, I would start with something like:
# TODO: initialize the program
# TODO: load the file
# TODO: count the lines
# TODO: output the count
# TODO: finalize the program
Then, as I go along, I add the more-specific steps to replace the "load the file" (or I just remove the TODO prefix and it acts as a organizational sectioning comment), and eventually I'll start taking those comments and turning them into code/functions when they're sufficiently atomic. I kind of imagine this as a combination of clay and wood, I'm building up the comments like clay, but also sort of "carving" the raw comments into code (the block of wood is an empty file, and I'm carving it bit by bit into the form it will eventually become: a file that compiles into a program that does what it should).
Yep, I definitely do something similar. I respect Bret Victor greatly (his Magic Ink essay has had more of an effect on what I do as a career than almost any other single thing), but I've never really been completely on board with this idea -- though in fairness it's a response to an implementation of a very specific programming environment, it's not a general solution.
Re mentally visualising, I'm reading a book called Mathematician's Delight[1] at the minute, and its first chapter has one of the neatest pieces of writing on abstract reasoning that I think I've ever read, it's reified a lot of instinctual ideas I had about how I program. I've clipped quite a lot of notes from it -- this in particular is relevant I think:
"Beginners in geometry are sometimes puzzled by being told that straight lines have no thickness. We shall never, we are told, meet a straight line in real life, because every real object has a certain thickness. One of Euclid's lines, however, has no thickness. Two lines meet in a point, and a point has no size at all, only position. We shall never meet a point in real life, either, for all real objects have a certain size, as well as a certain position It is not surprising that pupils wonder how we know anything about objects which no one has ever seen or ever can see.
This difficulty is a good example of the confusion which can come from misunderstanding the methods of abstract thought. We have seen that Euclid's geometry grew out of the methods used for building, surveying and other work in ancient Egypt, This work was done with actual ropes or strings, real linen threads with actual thickness. What does Euclid mean when he says that a line has no thickness, although he is using results suggested by the use of thick ropes? He means that in laying out a football field or in building a house you are not interested in the size or the shape of the knots made where one rope is joined to another. If you allowed for the fact that ropes possess a definite thickness, if you carefully described all the knots used by a bricklayer, you would make the subject extremely complicated, and no advantage would be gained. Euclid therefore says, if an actual rope has thickness, neglect this in order to keep the subject reasonably simple.
The position is not that Euclid's straight lines represent a perfect ideal which ropes and strings strive in vain to copy. It is the other way round. Euclid's straight lines simplified account of the complicated way in which actual ropes present a rough, behave."
In context, he was responding to Khan Academy using these same examples in a learning environment that they said was inspired by Bret Victor.[1] For what it's worth, he has been working on a collaborative computing space called Dynamicland for some time now that does explore his ideas and fit in with with his ideals.[2]
Maybe it can't be visualized (but I doubt it-I'm sure it can), but I don't think it must be. The goal of Brett's arguments is how to teach students to learn programming, not making every programming problem ever visual.
Once a person learns how to think about programming problems, they become better at creating their own mental models and visualizations. And maybe someday they'll figure out how to create visualizations of these complex things you and I can't yet :)
I'd like to see Bret's brilliance tackle visualising those types of examples.
Maybe most of it simply can't be visualised, but I feel like there's a lot of unrealised potential in that space.