[HN Gopher] How do you visualize code?
___________________________________________________________________
How do you visualize code?
Author : otras
Score : 131 points
Date : 2022-01-18 14:50 UTC (8 hours ago)
(HTM) web link (alexanderell.is)
(TXT) w3m dump (alexanderell.is)
| m3047 wrote:
| > This made me think about how I tend to visualize code, and it's
| a little hard to describe.
|
| This tells me someone is good at imagining castles in the air and
| that they have difficulty describing their vision. I can't even
| tell if the castle is stable, shimmering, changing color or
| shape.
|
| There is an analogy to at least some forms of meditation here:
| the vision is a distraction to suffer through (however pleasant
| the suffering) to return to the practice.
|
| I recommend working on the problem and being able to articulate
| and understand the problem. Two people could see and enumerate a
| castle and a bridge (and little else) and agree on this vision.
| Then one could propose burning it down, while the other would
| propose a trebuchet or breaching mine. A breaching mine would be
| overkill for a castle made of wood, but stone don't burn. We
| don't even know if the bridge goes over the walls or even touches
| them.
|
| I love interesting and entertaining mythologies and applaud them,
| but they're not to be conflated with The Problem. Listen
| carefully to the mythologies of the people you work with, and
| watch carefully if they're more interested in spinning a tale or
| working on the problem.
| plutonorm wrote:
| I think it's madness that we don't work like this. We would
| greatly increase productivity. Unfortunately, like most new
| ideas, few people see the potential.
| TuringTest wrote:
| Creating good software visualization tools is _damned
| difficult_ , that's why most platform developers don't even try
| to do it. Most programming tools limit themselves to text
| parsing and tree-building, because tree structures are the
| simplest to build and layout programmatically.( _)
|
| There is also a certain scorn for visual languages, because
| there are hardly any good general purpose languages and there
| are few developers specializing in the areas where specific
| ones are most useful. So visualization tools are often confused
| with them and derided for it.
|
| However, when a good visual tool for programming it is
| universally adopted, and like what happens with the AI paradox,
| no longer considered a visual tool (see syntax highlighting,
| "intellisense" autocomplete, inspect expressions at debugging,
| file minimaps and function trees...)
|
| (_) There are some excellent visual tools for software
| inspection, but they tend to be proprietary and/or tied to a
| single language or having their own IDE (e.g. see Sourcetrail),
| so they can't be easily generalized or integrated with other
| standard development tools, so they get limited usage.
|
| https://www.sourcetrail.com/
| RobertRoberts wrote:
| I found it odd that the drawing were confusing until I added my
| own personal imaginary time component.
|
| Spacial memory include how I "feel" about something as much as
| the logic of what it is. When I misplace something I "feel" like
| I put that object (keys, book, etc...) in some place, despite it
| not being there.
|
| So, like the idea of "I remember putting my keys here", there is
| a timeline.
|
| The images of the boxes "main" and "counter" with all the lines
| was confusing, but if I had drawn them myself, I would have tiny
| timeline/memory of each line movement from one to another. Just
| the same as I recall (vaguely sometimes) why I wrote a piece of
| code or structured my files some way.
|
| So, to change the thought from "what a mess of lines between the
| boxes" to "these lines really mean something to me", I would
| either have to have drawn them myself, or have some time
| component (ie, lines drawn during actual demo of code being run)
| to represent "how I visualize" the actual logic/code/system.
| AnIdiotOnTheNet wrote:
| I don't really visualize 'code' so much as I visualize data
| structures as arrangements of rectangular blocks of memory and
| arrows pointing to them. I find that once I understand how the
| data is supposed to move and transform, the code almost seems to
| write itself.
| xwdv wrote:
| I don't visualize code, I _feel_ it, underneath my finger tips.
| I'm what they call a vimmer. Right now, when I think of a
| location in a code base where I want to go, I can feel the nerves
| in my hand anticipating the movements and keystrokes I'll need to
| execute in order to get there, and the subsequent commands needed
| to make the edits I want. There's little reason to look at the
| screen if all these moves are done perfectly, the screen is only
| there to provide context. The physical structure and layout of a
| project is irrelevant when you have powerful tools. It might as
| well be a flat file in my mind. All that matters is the anchor
| points. The words to search for, the phrases to find. This is the
| highest level of coding.
| goblin89 wrote:
| When I have trouble juggling a complicated system in my head, I
| like to visualize it as documentation.
|
| Thanks to automated documentation generators it's possible to
| document various units directly in the code, but it doesn't
| replace tying it all together in a cohesive knowledge base,
| nicely formatted in HTML. (There's tooling that helps with that,
| too.)
|
| To me, writing and updating how-tos, references, glossaries,
| organizing it in sections is a methodical activity that produces
| useful questions and helps me understand not just the
| responsibilities of different units do but also general
| background and the larger picture, while producing a concrete
| deliverable useful to future maintainers and operators as a side
| effect.
|
| Illustrations can also be useful to include. There isn't a one-
| size-fits-all approach and it really depends on what you are
| trying to illustrate--a high-level architectural overview may
| warrant a data flow or component dependency diagram, while a
| complicated communication between threads might call for a
| timeline view. (Again, thinking in terms of documentation is
| useful--consider future readers and future maintainers, what they
| would want to learn and how much of a pain would it be for them
| to update.)
|
| I believe illustrations don't work as well on lower levels though
| like individual code units. If a higher level diagram is not
| enough and you come up with one that has to change every time
| implementation changes, perhaps somewhere there's coupling that
| could be loosened and cohesion that could be tightened. (That, or
| I might not have worked on sufficiently complex projects.)
| holografix wrote:
| I'm not a professional software dev so apply many grains of salt.
|
| I code with pen and paper beside me, specially when doing
| anything that involves another thread or these days a go-routine.
|
| Drawing boxes and lines to symbolise go-routines and channels.
| juancn wrote:
| I just don't visualize it much.
|
| I do visualize dataflow, and tend to encapsulate responsibility
| boundaries, so as to be able to assert properties of a bunch of
| code and not have to think about the internals. But other than
| big block analysis I just don't break it down that much.
|
| I've been coding for 37 years, 23 of those professionally (it's
| not bragging, just to establish that I've read and written a lot
| of code), at this point I just kind of read the code a bit like
| prose, or more like a "Choose your own adventure" book.
|
| I do like to have the ability to navigate symbols and do typed
| searches of a code base, I also appreciate typing and mutability
| properties of things (everything is assumed mutable unless proven
| otherwise, which complicates concurrency analysis).
|
| It's my experience that most coders think similarly, and you can
| usually assume quite a bit about how something is structured once
| you grasp the style of the programmers that built it, this also
| means that sometimes you can even predict the kinds of bugs they
| will tend to have. We're not all so unique after all.
| adonovan wrote:
| The challenge of becoming a programmer is that of learning to
| flip between all these different mental visualizations and more,
| unconsciously and without effort, just as the challenge of
| becoming a musician is that of seeing melody, harmony,
| intonation, progression, rhythm, phrasing, dynamics, and so on,
| without effort, as each moment demands.
| ethbr0 wrote:
| As a fractal mental miasma of equations. Doesn't everyone?
|
| https://www.youtube.com/watch?v=GIKfEAF2Yhw&t=30s
| programmarchy wrote:
| You get used to it. I don't even see the code. All I see is
| blonde, brunette, redhead...
|
| https://www.youtube.com/watch?v=7-GTcHZkfCs
| [deleted]
| DrBoring wrote:
| That's the same way I count cards.
| https://youtu.be/DeazgPwP3D0?t=41
| ethbr0 wrote:
| In all seriousness, I do have a gripe with folks not allowing
| for artistic license in representing a specialized, trained
| thought process as a 2D visual artifact.
|
| If the actual process couldn't be understood by & isn't
| relevant to 90% of the viewers, why is accuracy the goal?
| Instead of summarization and communication?
|
| I look at representations of underlying systems all day, that
| aren't accurate to the underlying mechanics. But they're
| useful!
| whatshisface wrote:
| The representation is semi-based on reality as some people
| with extremely good visual imaginations do use them as
| scratch space for equations in a way that looks kind of
| like the "numbers in the air" metaphor, except that the
| numbers are in their imaginations, not hallucinated in
| front of them.
|
| It is not very common among scientists, but I am willing to
| bet that a lot of people who end up in the visual arts
| (i.e. who put these scenes in movies) experienced math in a
| way that matches the visual metaphor when they were in
| school.
| DrBoring wrote:
| This visual imaginations comment reminded me of Dr.
| Temple Grandin, who who written books about her own
| visual imagination
| https://en.wikipedia.org/wiki/Thinking_in_Pictures
|
| I think my own mind is visual. I can prototype physical
| inventions in my head. Ex: Once, given a need for a tool
| that I didn't have, I considered the parts I had on hand,
| and recreated the tool using spare parts. The time from
| realizing the need for the tool, to having a working
| replacement was a few minutes.
|
| When I code, before I start planing on paper, I can see
| the various functions that I need to write or algorithms
| that I'll have to use.
| beaconstudios wrote:
| his example is literally just data flow programming:
| https://www.youtube.com/watch?v=WjJdaDXN5Vs&t=924s
|
| I've had a project related to this on the back burner for a
| little bit - data flow programming is really cool and helps with
| understanding code logic (and can be inherently reactive, which
| is IMO the future of programming) but it's hard to scale up.
| erwincoumans wrote:
| For run-time visualization, I use Chrome about://tracing it gives
| very good details, over a time horizon, synchronized over
| multilple threads/processes. Zoom into nanosecond detail or zoom
| out over seconds or minutes overview.
|
| I have my own simple C++ code to generate those traces (json
| data), there is also an official sdk for it (Perfetto is the new
| shiny way)
|
| For static code analysis, I use Doxygen, it parses the headers,
| can make high level module diagrams and fine grained dependency
| graphs. It uses Graphviz/dot for rendering the graphs.
| menaerus wrote:
| Quite interesting application of tracing tools, I've only used
| it for build time optimizations. Do you perhaps have a
| screenshot to see how the end result would look like ?
| MaulingMonkey wrote:
| Profiler flamegraphs can be a wonderful tool for understanding
| actual execution. It turns out that execution time is a useful
| proxy / reasonable approximation for code's importance to the
| overall application.
|
| Bonus points for using an intrusive, explicitly annotated tracing
| API of some sort, which lets you capture enough parameter
| information to understand not just where, but what, the code is
| doing.
| pkdpic wrote:
| Love this question and Im forever inspired by the way engineers
| visualize their code especially when actually white-boarding (in
| the before time...). Was hoping to see more actual visualization
| examples in the article / thread.
|
| If anyone knows of a site or project dedicated to cataloging
| whiteboard visualizations point me in the right direction.
| hcs wrote:
| Mynatt analyzed whiteboard use in 1999's "The Writing on the
| Wall" [1], which led to an interactive whiteboard system called
| Flatland [2], but it's not focused on programming.
|
| More recent, detailed, and programming-specific is "How
| Software Designers Interact with Sketches at the Whiteboard"
| [3].
|
| I had thought I remembered a site with a more thorough
| treatment of this, but I might have just been thinking of the
| sprawling Visual Programming Codex:
| https://github.com/ivanreese/visual-programming-codex
|
| [1]
| http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.13....
| (PDF)
|
| [2]
| https://ecl.cc.gatech.edu/sites/default/files/publications/C...
| (PDF)
|
| [3] https://cs.gmu.edu/~tlatoza/papers/tse15-sketching.pdf
| (PDF)
| DrBoring wrote:
| I still support a full stack web app that I wrote for a client 10
| years ago.
|
| Whenever I revisit a section of code that I haven't looked at
| since then, I always have to re-learn the code's logical
| structure and function. I'm sure most developers have experienced
| this.
|
| I wonder if, 10 years ago, I were to have routinely viewed my
| code in a visual manner like in the article, would today's
| relearning process take less time and frustration.
|
| Sort of like when you revisit an old beloved vacation spot. Even
| though those memories have aged, the layout of the spot is
| relatively the same. You quickly remember where things are
| located.
|
| I also wonder what value a code visualization like this would
| have for a new developer working with the code.
| kgilpin wrote:
| AppMap (https://appland.com/docs/how-to-use-appmap-diagrams.html)
| is an open source tool we created to record and visualize code
| execution. It currently includes interactive dependency graph and
| trace views, and works with Node.JS (+TypeScript), Ruby, Java,
| and Python.
| jcelerier wrote:
| I draw graphs of it very akin to the schemas in the article
| zby wrote:
| In 'Why we talk' (https://www.amazon.com/Why-We-Talk-
| Evolutionary-Evolution/dp...) Dessalles arguments that we have
| two modes of talking - the first one is visual and probabilistic,
| the second one is topological - that is concerned about zero one
| questions - like if something is inside or outside of something.
| The first one is about imagining situations and judging their
| salience (or improbability). The second is about argumenting -
| simplifying the information so that you can 'proove' stuff. The
| point is that visuals are too rich and there can be too many ways
| to imagine things - so it is hard to convince someone that a
| particular scene is wrong or right. When you simplify things to
| the topological level of question if something is inside
| something or outside - then you can use inference to arrive at
| some logical conclusions, with steps so obvious that it is hard
| to argument against them.
|
| Programming is mostly about logic - that is why it is hard to
| visualise. I think this is the problem with 'visual programming
| languages' (like https://enso.org/ - which, disclosure, is in my
| investmet porfolio) - and also here. This is kind of surprising -
| because we naturally expect the visuals to be as rich as the
| logic. But we need to carefully think about what is complementary
| here.
| hutzlibu wrote:
| "Programming is mostly about logic - that is why it is hard to
| visualise"
|
| Maybe I understood it wrong, but I do not see that logic ...
|
| Rather the opposite, since programming is about very strict
| defined logic - it is possible to visualize it very clearly.
| The various UML diagramms for example can do a good job with
| that.
|
| The hard part, is to make tools, that generate the diagrams for
| you in a meaningful way automatically. Because generating them
| by hand, by dragging and clicking around somewhat works, but is
| apparently way less efficient than just writing the code. (and
| doing both is just double work)
| zby wrote:
| The UML diagrams are a good example of the problem I am
| talking about: they carry too much (unessential) information
| - you can draw the boxes in too many ways.
| hutzlibu wrote:
| Hm, I am still not sure I understand your point:
|
| I mean the UML spec as its whole is quite a mess, sure,
| which is why it is not so relevant anymore. But very
| specific defined UML diagramms, like UML class diagramms -
| carry just the essential information for me. Like class
| name, member names with types and connections showing me
| where this class interfaces or inherits from. I really
| liked that and preferred it much over the same information
| in code representation.
|
| But doing it by hand was just not worth it for me.
| zby wrote:
| Diagrams are visual and need many more bites than the
| code they are created from. Just compare a gif of a
| diagram and its description. The additional information
| is how the boxes look - are they big or small, colors,
| what font is used, what margins are there, and many more.
| Describing it I use text and divide the differences into
| categories - but maybe I should just write that for the
| visuals you need information for each pixel.
|
| When you interpret the diagrams you map them into a much
| smaller space of meanings. In that process you throw out
| a lot of that visual information.
| hutzlibu wrote:
| Ah, now I understand what you mean. It is certainly true,
| that there is additional information in a diagram.
|
| But - most of that information is just visual help to
| transport the raw information - to enable you to decode
| the information (which is what this is all about, as
| decoding code is mental work).
|
| The x y position of a uml class diagram for example, is
| irrelevant in terms of raw data, but it makes a
| difference to the brain, of whether one diagram is
| centered or in some corner. Likewise all the other
| information, like color etc.
|
| They are simply there to help you understand the main
| information. So I do not think they carry unessential
| information. If the color of a diagram helps get the
| information across - meaning it makes it easier for the
| reader to understand the main information - than that
| information might be not essential, but still important.
| Whether that works, depends of course on the diagrams and
| tools and how they get used. Again, this is the hard
| part.
| dragonwriter wrote:
| > Diagrams are visual and need many more bites than the
| code they are created from.
|
| Only if you store them inefficiently.
|
| > Just compare a gif of a diagram and its description.
|
| A bitmap image (GIF or otherwise) is an inefficient way
| to store a diagram. For a purely semantic diagram, the
| source it represents _minus_ anything not actually
| represented in the diagram is sufficient; if you have
| additional presentational information you need that, too.
| For a diagram-specific format, something like graphviz or
| mermaid source is a possible representation.
| danielodievich wrote:
| In couple of my previous jobs I often needed to quickly
| understand large, disparate codebases, without having them
| compile.
|
| I've used Source Insight (https://www.sourceinsight.com/) to do
| this with great success. SI builds the typical tree of nodes and
| dependencies, except it can do so without having to compile
| anything, and can do so with multiple languages. It also has
| absolutely superb code/fuzzy search experience.
|
| Really old school tool, for a while it was site licensed at
| Microsoft, ran by just a few devs here in Issaquah, WA.
| hcs wrote:
| Ever since I saw the cover of Elements of ML Programming [1],
| which shows the book as charting a course across "Logos Island",
| I've wondered what a _programming language_ might look like as a
| navigable space. Perhaps something like walking through a syntax
| diagram, but that hardly captures it, especially when so much of
| the semantics of a language is in its standard libraries. Would a
| program be a path through the language world? Would we think of
| the world as containing all possible user-defined functions, and
| we 'd edit our way across this space?
|
| For a historical metaphorical discussion of visualizing
| programming, I enjoy this bit from Johan Georg Raeder's 1984
| thesis "Programming in Pictures" pp79-80 [2]:
|
| "What real-world metaphors can fit programming? To get a feeling
| for how immense our initial search space is, let us amuse
| ourselves with a few possibilities. Is a program like a road with
| intersections and forks where we have to make decisions depending
| on our current errand, and with roadside inns where we can spend
| computation time or, if we are careless, completely overflow our
| stack? Or shall we abolish the 'meta-view' and, instead of seeing
| the program from the sky, put the programmer inside the program
| by presenting a view of a tunnel he/she can drive through? At
| each intersection one might have to throw dice or make guesses to
| introduce some of the challenge, fantasy and curiosity found in
| computer games. Perhaps we should rather present programs as
| physical, three-dimensional objects that we can turn around and
| view from different angles and in different light so as to reveal
| the various facets of their structure. Can we present a program
| as a play with actors and objects on a stage?"
|
| See also Raeder's "Survey of Current Graphical Programming
| Techniques" (1985)
|
| [1] https://archive.org/details/elementsofmlprog0000ullm
|
| [2]
| https://archive.org/details/RaederProgrammingInPictures/page...
| mr_tristan wrote:
| I find that programming languages are themselves a great
| reference... for the logic of a single thread. The moment you
| start doing concurrent development, or hell, even basic event-
| driven code, it gets much harder to "just read along". This is
| where I would kill for visualizations to help out.
|
| Like, if you fork your process at a point, vertically split the
| text into two columns with a line saying "new thread over here".
| And then highlight any points of synchronization.
|
| I think when people think of visualizations, it's "everything is
| a 2D graphic". When really, there could be new ways to laying out
| and navigating text-based source.
| oweiler wrote:
| That would be awesome! Is there any IDE that does that?
| hutzlibu wrote:
| Not yet, as far as I am aware. And it is really a nontrivial
| problem to make something like this, that not just looks
| neat, but works efficient.
|
| (I know this, because I am working on something like that,
| since quite a while)
| qwertyuiop_ wrote:
| No love for UML ? https://www.omg.org/spec/UML/2.5.1/About-UML/
| dlojudice wrote:
| you might not love, but not to mention it's weird to say the
| least, after all UML was a way to visualize code and its
| abstractions.
|
| it could be said that it is another symptom of our field of
| study: things are forgotten very quickly.
| ethbr0 wrote:
| Oh, UML. That thing I learned formally in college and then
| never once used in professional practice. :)
| otras wrote:
| Plenty of love for UML :)
|
| That's a good point that I omitted it. I was more thinking
| about things as the individual diagrams/views into the system
| (e.g. class diagrams, structure diagrams, sequence diagrams),
| and to me, UML seems more of a general superset collection of
| those individual views (and, importantly, agreement on what
| they are). While it contains many of the visualizations I
| mention, the visualizations themselves are more interesting to
| me than the general modeling language.
|
| My list is definitely incomplete!
| buescher wrote:
| For my purposes (embedded), UML statecharts are as good as
| any other way to do statecharts, and sequence diagrams are
| occasionally useful. The 10,000 foot view you started off
| with of big program blocks, also, especially to just draw out
| the processes in a system.
|
| The complementary question, though, is how do you visualize
| data when coding? Some debuggers have features for
| visualizing data structures, time-series data, etc but there
| is plenty of room for improvement.
| tyingq wrote:
| I know it's filesystems and not code, but the SGI Irix "fsn" file
| system navigator, featured in Jurassic Park, seems worth
| mentioning:
|
| https://en.wikipedia.org/wiki/Fsn_(file_manager)
| kraftman wrote:
| A long time ago I was thinking about this and how if you could
| better visualise the relationships between functions/modules, it
| would be clearer to see where there are issues with coupling and
| cohesion. I think for the most part it could look fairly clean
| with nice heirarchical relationships, but then the links to
| common utility files could get a bit messy.
|
| I took a stab at implementing it in Love2d but didn't get far
| before getting distracted with UI design/development:
| https://i.imgur.com/kznL4.jpg
| groby_b wrote:
| There's also all kinds of probabilistic visualizations, which is
| maybe a third axis in that diagram. (I.e. call coverage, sampling
| profilers, various o11y approaches)
|
| Research example: http://www.ijstr.org/final-
| print/apr2020/A-Hybrid-Weighted-P...
|
| I think that will be an important field especially for software
| running at a large scale - because it allows to get a better
| understanding of large systems. It's also a loss of fidelity that
| has strong implications for individual interactions.
|
| (And yes, I know o11y is already a large tool there. I'm just
| thinking we've merely scratched the surface of probabilistic
| views)
| austincheney wrote:
| Here is my dumb army guy approach to programming anything. It
| doesn't work for everybody.
|
| 1. Think about the problem.
|
| 2. Form a tentative plan (the visual part).
|
| 3. Write a rough draft of code (the code doesn't have to work
| yet).
|
| 4. Test it and make it work (minimum viable effort).
|
| 5. Refactor. Polish the code and eliminate tech debt.
|
| Think about the problem. Get a solid vision for what you want
| done. Once you have solid emotional confidence about that end
| state balance it against what you have. With that you know what
| you are missing. That stuff that is missing is the work you must
| perform.
|
| When you think functionally everything is an input and an output
| depending upon context. This allows thinking about the flow
| control directly without worry for the composition. If you have
| been programming for more than a couple of days the leet code of
| loops and conditions are completely ignored from planning as
| implied tasks much like you don't spend your time actively
| thinking about breathing when planning your day. Now you have a
| plan. Plans often fail as soon they become necessary, so the plan
| itself is irrelevant. What's important is the planning, the
| thought exercise not the product, the thinking about what needs
| to be done so you know what to do.
|
| Programming then becomes a conceptually visual experience. Simply
| the write the code you see in your mind. The most important thing
| here is that you have a visualized a plan and know what you need
| to write. The code doesn't even have to work at this point.
|
| Then write the code. Test what you have written. Fix the code so
| that it solves the desired problem. Only then should you actively
| toil with composition. When composition is saved for last it
| becomes an exercise in refactoring.
|
| Refactoring is a form of code polish. It allows cleaning away the
| rough spots from the rough draft in order to achieve conformance
| to code style, build rules, and validation criteria. Refactoring
| also allows the combining of similar mechanisms which increases
| simplicity and reduces tech debt.
| todd8 wrote:
| I have been intrigued by the idea of visual coding tools for
| _many_ years, but these kind of tools have always disappointed
| me. They remind me of the system used to teach small children to
| program in the programming language Scratch, see [Scratch].
|
| I prefer to "visualize" my code as manipulating a set of logical
| assertions that characterize the state of the computation,
| ultimately reaching the point where the state of the
| computation's properties satisfy the requirements. Somewhat like
| that explained in [Gries1987] and [Dijkstra1976]. Visual tools
| are just too coarse to capture the details necessary to ensure
| correctness or real-life requirements.
|
| While UML diagrams sometimes help to make sense of a complex set
| of OO Class relationships, this is far from how I normally work
| with the meaning of code in my head while programming.
|
| [Scratch]
| https://en.wikipedia.org/wiki/Scratch_(programming_language)
|
| [Gries1987] https://www.amazon.com/Science-Programming-
| Monographs-Comput...
|
| [Dijkstra1976] https://www.amazon.com/Discipline-Programming-
| Edsger-W-Dijks...
| coldtea wrote:
| > _I prefer to "visualize" my code as manipulating a set of
| logical assertions that characterize the state of the
| computation, ultimately reaching the point where the state of
| the computation's properties satisfy the requirements_
|
| OTOH, functional code should be more like a pipeline (graph),
| and thus better suited for visualisation.
| grimgrin wrote:
| does anyone here write code, align with having aphantasia, and
| have some form of an alternative answer to thread? alt.answer
| might end up being the same answers, idk what i'm saying, barely
| know what i'm asking
| NateEag wrote:
| Yes.
|
| I don't visualize code because I can't visualize on demand,
| period.
|
| I think of it in terms of words and logical abstractions.
| Textual memory, reading comprehension, code intelligence tools,
| and search are how I understand and navigate projects.
|
| I say things like "You're looking for the immutable
| DEFAULT_HEADERS property. I think that's in the HTTPResponse
| class?" fairly often.
|
| I like documenting a project's high-level organization (top-
| level folders and what they do) in the readme or a similar
| place.
|
| I'm strongly opposed to manually-created diagrams about a
| codebase because they require insane discipline to keep up-to-
| date.
|
| I like having tooling to generate diagrams from the current
| state of the code. Ditto interactive tools with useful visual
| components (popups that show the doc comments for the
| abstraction under your cursor, auto-completion hints, SQL query
| editors that show you the visual schema of the tables in your
| query and the foreign keys to related tables [hypothetical, yet
| to find one that does this like I wish they did], etc).
|
| I sometimes use git-heatmap to get an idea of what files in a
| project see the most change. Such files are usually worth
| getting to know better.
|
| I frequently use ag / rg to search for fragments of text that I
| recall being near the code I'm looking for.
| TOGoS wrote:
| Calling code on the left, function-being-called (or rather, its
| stack frame) on the right. Unless it's asynchronous message-
| passing stuff in which case the parts are in disconnected spaces.
|
| At my previous job there was a lot of code that abused a pub-sub
| system to effectively do buggy temporally-coupled RPC. This
| didn't fit any paradigm I knew how to visualize (it went straight
| into the "fucking mess, don't try to understand it unless you're
| going to fix it" section of my mental library) and therefore I
| had a very hard time understanding what was going on, or getting
| much done at all, for that matter. I opened some tickets with
| suggestions for ways we could make it make sense but management
| deemed that type of work lower priority than chair-warming (this
| was last fall during the 'employees should be in the office X
| hours per week' period; meanwhile I was living 300 miles away) so
| I gtfo.
| kokanee wrote:
| Whenever someone presents a flow diagram to describe software or
| infrastructure, I pretty much panic. It always seems like
| everyone in the room immediately understands this kind of thing,
| but to me every box and line and arrow looks like sheer
| ambiguity.
|
| I tend to think in bulleted lists. Programs are a series of
| steps, often containing substeps and branches. Infrastructure
| allows data (requests) to traverse a series of steps as well.
| Each branch of steps and substeps looks like a bulleted list in
| my head.
| holografix wrote:
| That's not your fault. Often these diagrams display too much
| information at once and most crucially, without _order_ of
| execution.
|
| When I get shown one of these I immediately demand to be walked
| through it from the perspective of the most common user story
| the system satisfies.
| yboris wrote:
| For _TypeScript_ I created a visualization of function calls - a
| function call graph:
|
| https://github.com/whyboris/TypeScript-Call-Graph
| vorticalbox wrote:
| this looks interesting, at my work we have a sdk wrote in
| typescript and im intrested to see how it looks
| telxosser wrote:
| Awesome thank you. I am an old man trying to get into software
| engineering and think in graphs. This is perfect.
| rdubs333 wrote:
| I am working on a technology illustrated design system book that
| might help you visualize code. I am a visual designer that
| learned to code. Its a free ebook on Apple - https://mtrees.io
| ogogmad wrote:
| Slightly tangential: This is how I visualise how the behaviour of
| the QR algorithm varies over all possible PSD matrices:
| https://en.wikipedia.org/wiki/QR_algorithm#Visualization
|
| In this case, it's less important to understand the convoluted
| structure of some code, than to understand how a simple but
| opaque algorithm behaves in general.
| [deleted]
| leetrout wrote:
| From a previous posting here in HN code2flow
|
| https://github.com/scottrogowski/code2flow
|
| https://news.ycombinator.com/item?id=29496014
|
| A friend of mine sent me this a while back which is kinda related
|
| https://splootcode.io/
| pnathan wrote:
| One of my professors in grad school was really into code
| visualization and we dabbled through a survey of the code viz
| approaches back then (~10 years ago now, geez).
|
| I do not visualize code. I did, once, in a way, but that faded...
|
| Any serious attempt to view code in a true
| multimodule/multithread/dynamic/static way to really _see_ the
| whole thing in toto takes us out of the Euclidian space we all
| wander in, to the _different_, tree based, non-linear space of a
| turing machine simulating some aspect of an extended lambda
| calculus (how extended? depends on your language). Code flows
| into and out of data, closing, suspending, and continuing, on one
| or more processors on one or more computers, through dizzying
| heights of dependencies, libraries, networks, and languages.
|
| A Riemannian/Euclidian space is simply not the model needed to
| break into actual code viz.
| zokier wrote:
| Code Bubbles (from 2010) is the most convincing code
| visualization tool that I can recall:
| https://www.youtube.com/watch?v=PsPX0nElJ0k
|
| Shame it never grew beyond a research prototype.
| dpedu wrote:
| I think of code as a series of nerve cells. Nerve cells have
| internal logic (the nucleus) and a connection to others (the
| axon). Nerve cells should all generally be about the same size;
| one being bloated is a sign of a code smell - an area that could
| be refactored into smaller chunks. Real nerve cells only have one
| axon but, in programming, a single connection to the rest of the
| code base just isn't always realistic. However, a spaghetti mess
| of interconnection within a codebase is a code smell too.
| 100011_100001 wrote:
| Interesting metaphor. I was going to say a mindmap, but nerve
| cells also make sense. I also have the same code smell litmus
| test, if two different paths call the same thing twice (aka
| they both link to the same place), but like you said sometimes
| it's unavoidable.
|
| With microservices things get a little bit more complex though.
| Anyway, very apt metaphor.
| teunispeters wrote:
| Aphantasia. I don't do "visual"
|
| I have an odd form though, I do maps of relationships - including
| obligations and expected deliveries. Works largely for people and
| places too. And yeah, including likelihoods of delivery or
| accuracy of result.
|
| So I have a default rule of "always check inputs". One can always
| take a section of the map and - like algebra - substitute a
| variable for a block, and keep that separate to keep problems
| more manageable.
|
| When I'm reading code, I'm building a map in my head of how it
| does things.
|
| I'm not very effective at communicating such maps, so I have
| difficulty writing or speaking some of the time, but it's no
| barrier with programming.
| godshatter wrote:
| I came here to say something similar. I also have aphantasia,
| and I generally keep a list of concepts this function (I'm a C
| guy) needs to do, what assumptions it needs to make, and where
| it fits in the general process. It needs to be general enough
| to be called in other contexts. It should verify that the input
| pointer is not null and it can safely ignore freeing that as a
| resource since it's done somewhere else. It needs to return one
| of these errors, and needs to add one of them to the
| error/description list since it's new with this function. It
| needs to handle the case where the passed-in error code pointer
| is NULL. Things like that.
|
| I've tried to visualize code with diagrams and whatnot, and it
| only gets in my way. I suspect that like some abstract math
| concepts visualization will always only get in the way except
| for an abstract very simplified picture of what's going on. But
| it's certainly possible that I'm missing some visualization
| skills most 4-year olds have and if I could visualize I would
| be able to handle it just fine.
| wccrawford wrote:
| I don't have aphantasia, but I do have a harder time
| visualizing things than most people. I also don't even attempt
| to visual code. What would it even look like, other than code?
|
| Organizing it in my head just happens in the same way that
| remembering a list of steps to solve any problem does. There's
| no visual component. For that matter, there doesn't need to be
| an audio component, either.
| mikewarot wrote:
| For me, Pascal is a pretty good 2d _map as software_ experience.
| Begin /End pairs along with indenting 2 spaces each time make it
| easy to understand and provide landmarks that are easy to spot. I
| imagine this is true for most languages.
|
| The only thing better would be if I could compile it to an
| abstract syntax tree I could manipulate, change the name of a
| routine, etc... then reverse back to updated code.
___________________________________________________________________
(page generated 2022-01-18 23:01 UTC)