4 ms·

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 "th

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.

Swizec 6y ago
> Maybe most of it simply can’t be visualized 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
- subjectsigma 6y ago
  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.
  - neolog 6y ago
    I love the way you've put this.
  - TeMPOraL 6y ago
    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.
    - bitwize 6y ago
      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.
      - jodrellblank 6y ago
        > Emacs does these things right in a way that virtually every other IDE-like editor does wrong. ? > the wrong way VSCode handles File / Open by default ?
        6y ago
- fiddlerwoaroof 6y ago
  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.
  - magicink81 6y ago
    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 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/ http://worrydream.com/MagicInk/
- RobertKerans 6y ago
  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." [1] https://archive.org/details/mathematicians-delight-w.-w.-sawyer https://archive.org/details/mathematicians-delight-w.-w.-saw...
- lambda_obrien 6y ago
  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).
baryphonic 6y ago
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] [1] https://www.khanacademy.org/computer-programming/drawing-bonus-rotation/906448125 https://www.khanacademy.org/computer-programming/drawing-bon... [2] https://dynamicland.org/ https://dynamicland.org/
rytor718 6y ago
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 :)

Swizec 6y ago

> Maybe most of it simply can’t be visualized 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

subjectsigma 6y ago
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.
- neolog 6y ago
  I love the way you've put this.
- TeMPOraL 6y ago
  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.
  - bitwize 6y ago
    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.
    - jodrellblank 6y ago
      > Emacs does these things right in a way that virtually every other IDE-like editor does wrong. ? > the wrong way VSCode handles File / Open by default ?
      - 6y ago
fiddlerwoaroof 6y ago
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.
- magicink81 6y ago
  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 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/ http://worrydream.com/MagicInk/
RobertKerans 6y ago
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." [1] https://archive.org/details/mathematicians-delight-w.-w.-sawyer https://archive.org/details/mathematicians-delight-w.-w.-saw...
lambda_obrien 6y ago
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).

baryphonic 6y ago

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] [1] https://www.khanacademy.org/computer-programming/drawing-bonus-rotation/906448125 https://www.khanacademy.org/computer-programming/drawing-bon... [2] https://dynamicland.org/ https://dynamicland.org/

rytor718 6y ago

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 :)