Adrian Sieber

Understanding Code in the Age of AI

— 1896 Words — 10 min

There are now many software developers which haven't manually written a line of code in months and some even in years. While it's incredible that AI has reached a capability level that makes this possible, it also comes with big problems:

  • Writing code manully lets you rethink your assumptions and discover better ways to reach your goals. This process is not happening when you rely on AI tools to write the code for you.
  • Writing code manually creates deep understanding of the intrinsicies of the logic that is hard to reach by only reading the code and/or specifications. It's easy for AI to forget edge cases or use incorrect / suboptimal algorithms.
  • AI is prone to reaching local optima in the design space of programs. If it started off in the wrong direction it will only try something else with external intervention.
  • You're reliant on frontier models being available to you. There are many ways access can be interrupted. E.g. through energy crisies, political turmoils, hardware bottlenecks, etc.

To make Write-Only Code more sustainable, I think first of all we need to develop tools to help gain the necessary understanding of the code after it was written. There are many ways this could be done:

  • Having agents add comprehensive documentation
  • Using additional abstraction levels to produce easier understandable code. E.g. a DSL that describes business processes

The one I want to focus on in this post is making code more readable by representing it graphically and thereby transforming it from a wall of text to something that is more inuitively comprehensible.

One way that has been done quite successfuly is with flowgraphs. Most successfully probably by n8n.

Screenshot of an n8n code flow graph

However, it requires you to buy into their ecosystem and it buries the actual code quite deep into the software stack.

Maybe there is another way, where we find a way to represent code graphically with a 1:1 mapping to the actual code. So instead of hiding and burieing it in abstractions, we just represent it more digestable.

Intuitevely, we're already used to this concept as we use variable names, code formatting, and syntax highlighting to do exactly that: We layout and colorize the stream of characters in a way that is easier to read and comprehend.

function sayHello(n){return`Hello ${n}`} 
function sayHello (name) {
  return `Hello ${name}`
}

So what if we bring this concept to the next level? One area where we actually have already have been doing it, is markup languages. While you directly write the TeX code, you most likely review it in its rendered form:


\boxed{
Z
=
\int_{\mathbb{R}}
\frac{e^{-x^2/(2\sigma^2)}}{\sqrt{2\pi \sigma^2}}
\cdot
\frac{1}{1 + \frac{\hbar^2 x^2}{m^2}}
\,dx
}
Complicated math formula

Maybe we can do the same thing for non-markup code?

Here is the same sayHello function we've seen earlier programmed with Blockly.

Screenshot of sayHello function in Blockly

Or we could be even more radical and say, for example, that functions are green circles and the return values are orange boxes:

Screenshot of an abstract sayHello function

I've been working on an automatic rendering engine at syvis.ad-si.com (GitHub repo) that can render arbitrary JavaScript code with several different themes. E.g. logging a simple object looks like this:

You might now say "This is hideous" or "This isn't more readable at all".

Additional advantages:

Stop dealing with badly formatted syntax and start reasoning about semantic.

  • Formatting independent
  • Partially language agnostic
  • Better overview
  • Simplifies reasoning over code

Disadvantages

Gets unwieldy for long code snippets

Usage

npm start -- path/to/javascript/file.js

Development

Start development environment:

docker run \
  --interactive \
  --tty \
  --volume "$PWD":/syvis \
  --rm \
  node bash

chokidar source/styles \
  --initial \
  --polling \
  --command 'stylus < source/styles/main.styl > public/screen.css'

User Interface

  • muuri - Responsive, sortable, filterable and drag-able grid layouts

Advantages Over Normal Code

  1. Easier readable - Humans are made to recognize visual patterns.
  2. Customizable
  • Consumer is not dependent on the author to choose appropriate formatting
  • Uncommon formatting preferences can be satisfied
  1. Less error prone - Erroneous and dangerous code can be additionally highlighted
  2. Better storage possibilities
  • Code could be stored and transmitted in a minified format (all insignificant whitespace removed)

Abstract

In most programming languages the semantic meaning of a program is disconnected from the formatting of the code and the naming of variables and keywords. This means semantically equivalent code can be written in a vastly different textual representations. This poses problems in terms of readability and understandability of code. Even minor modifications of punctuation or formatting in comparison to a developers familiar style can drastically decrease the performance. In order to mitigate these problems I propose to visualize code in a graphical and deterministic way. Instead of relying on the author of the code to format it in a acceptable manner, each developer can choose a visualization of their liking. This has the potential to decrease the error rate and increase the development speed of programmers.

Future Work

  • Touch based
  • Drag and drop

Misc

Visual Programming

  • Alice - Object based educational programming language plus IDE.
  • Node-RED - Flow-based programming for the Internet of Things
  • Greenfoot Frames - Frame based editing environment.

Mobile Coding

Links on how to code on mobile/touch devices

Code Visualization

  • js2flowchart - Convert JavaScript code into SVG flowchart.
  • flux - Visualize Haskell programs as data-flow diagrams.

Talks

Online IDEs

  • CodeSandbox - Online editor that helps you create web applications.
  • observablehq - Interactive notebooks for data analysis, visualization, and exploration
  • Onelang - Cross compile/transpile code to several languages online.
  • runkit - Interactive notebooks with very version of every npm package pre-installed.
  • meemoo - Online flow based creative tool maker.
  • livecode - Develop apps "live", using a visual workflow language syntax.
  • touchdevelop - Adaptive editor with support for drag & drop but also normal code.

Visual Programming Languages for Haskell or Haskell-like Languages

  • Visual Haskell
  • Viskell
  • FunBlocks
  • The Gem Cutter – A Graphical Tool for Creating Functions in the Strongly-typed Lazy Functional Language CAL (pdf)
  • Vital (archive.org link)
  • A Visual Programming Environment for Functional Languages (pdf)
  • https://github.com/pkamenarsky/typedraw - Visually describe Haskell/Purescript/Elm types

Other Functional Visual Programming Languages

  • Instant playful access to serious programming for non-programmers with a visual functional programming language (pdf)
  • The “Physics” of Notations: Towards a Scientific Basis for Constructing Visual Notations in Software Engineering* (pdf)
  • I know what you did last summer: an investigation of how developers spend their time (pdf) (papers that cite it)
  • Evidence-based programming language design
  • Language design for programming reliability

    semicolon as separator is about ten times more prone to error than semicolon as terminator

  • Code Bubbles - Rethinking the User Interface Paradigm of Integrated Development Environments.

People

More Resources

  • https://github.com/ivanreese/visual-programming-codex
  • https://github.com/hypotext/notation
  • http://chaim.io/download/Gingold%20(2017)%20Gadget%20(1)%20Survey.pdf
  • http://blog.interfacevision.com/design/design-visual-progarmming-languages-snapshots

TODO

  • Search for more information about "Projection editor"
  • Checkout marco röders project "codb"
  • https://stackoverflow.com/questions/26848419/syntax-highlighting-with-text-style-instead-of-colors
  • https://softwareengineering.stackexchange.com/questions/87077/how-can-a-code-editor-effectively-hint-at-code-nesting-level-without-using-ind
  • jGRASP
  • https://harc.github.io/seymour-live2017
  • lively.openComponentInWindow('my-component')
  • lively.html.registerButtons
  • Make histogram of line lengths => find 90% percentile and use for formatting
  • Hierarchy of code interaction:
    1. Reading
    2. Patches (e.g. change a string)
    3. Minor changes (e.g. write a function)
    4. Major changes (e.g. restructure code)
    5. Create a new project => Code editor should be optimized for this interaction pattern
  • Minimap
  • Feature flags
  • http://www.esterel-technologies.com/products/scade-suite/software-prototyping-desgin/scade-suite-advanced-modeler/
  • https://www.ansys.com/products/embedded-software/ansys-scade-suite
  • https://blog.janestreet.com/putting-the-i-back-in-ide-towards-a-github-explorer/
  • http://futureofcoding.org -
  • https://codeocean.com - cloud-based computational reproducibility platform
  • http://glench.github.io/fuzzyset.js/ui/ - A Human-Readable Interactive Representation of a Code Library
  • http://penrose.ink/ - Create diagrams by typing mathematical notation in plain text.
  • https://github.com/SamyPesse/codemirror-widgets
  • https://github.com/LivelyKernel/lively4-projectional-editor
  • http://bl.ocks.org/jasongrout/5378313

If you have any comments, thoughts, or other feedback feel free to write me @AdrianSieber. Thanks for your help! 😊