Towards Understandable Software
10 points by liberty
10 points by liberty
I'm not convinced that abandoning code or making it subservient to natural language prose is an effective solution to the accessibility problems of programming.
Programming languages are user interfaces which strike a balance between the needs of computers and the needs of humans. At their best, crisp formal notations are tools of thought which facilitate personal understanding as well as communication of ideas to other humans and machines. Like any user interface, there is inherent tension between designs which prioritize ease and familiarity for beginners and designs which give proficient users leverage and efficiency.
Learning APL-family languages has been especially influential for me. Like any formal programming language they took time and effort to learn, but once learnt they help me fit larger problems in my head at once and let me think about programming more precisely when I'm away from my computers, going for a walk or sitting with a chicken perched on my knee. I don't need a complex IDE to write K; I can think through problems in my head, on paper, or with a simple REPL.
Well-documented projects are a laudable goal, and literate programming can have benefits, but all documentation still takes time to read, write, and revise. As with testing, more documentation is not strictly better; favor concise, well-structured explanations, and concise programs that lend themselves to explanation. Code can be poetry, but most poems are not programs.
I am a fan of formal programming. But I don't believe your average user should become a programmer in order to harness the power of their computers. I'm not the average user. Most people will never learn how any of this works, so I'm looking to lower the bar so more can participate.
This is why I think LLMs are so popular. I see non-programmers use them all of the time in order to write code to do tasks for them. But, as I outlined in the article, there are major flaws with LLMs I'd like to avoid. People should be able to mod their games, make scripts, and extend their programs in natural language or a convenient user interface.
I may have been a bit overassertive with the "abolish code" framing, but a lot of people don't want to think about the code, and they shouldn't have to.
I think a programming mindset is inherently unnatural and must be cultivated somehow for computers to be empowering and truly useful to individuals, in much the same way that learning algebra, learning to draw from life, or even learning to read and write are "unnatural" skills but skills which enrich one's mental toolset and their ability to understand and think about the world. Everyone can benefit from learning a little about algorithmic thinking, even if they don't find programming particularly fun or they have zero interest in a programming career. Programming languages can help scaffold this kind of thinking!
I assure you, I am in extremely strong agreement with you that empowering non-programmers (perhaps "pre-programmers"?) is important and that LLMs represent a false path. Programming- and modifying existing software- should be much easier and more approachable than it is today. I just don't think natural language helps to close that gap. If anything I feel it erects barriers to understanding by requiring programs to be verbose and imprecise. In Isaac Newton's era, mathematics was expressed with prose, and it took a genius to invent integral calculus. Today, we have mathematical notation- often still flawed and inconsistent, but refined over centuries- that allows us to teach these ideas to average teenagers.
Both natural Inform and HyperTalk offer examples of widely-used "natural language" programming languages. I believe both illustrate the key weakness in leaning toward prose-shaped code: in skillful hands they can be made extremely readable and comprehensible to a relative novice, but they are both intensely frustrating for novices to write new programs in from whole cloth because- as you have observed- they are necessarily far less flexible than any human language, and their broad suggestiveness toward human language forces learners to probe at and struggle against the invisible edges of unstated grammar and semantics as they try to express themselves. The clarity of a really good Inform library doesn't come from resembling natural language; I'd argue it comes from the author's mental clarity and their skill as a teacher.
I hear you regarding natural language. What about visual programming? I think visual interfaces can provide more intuitive ways to understand the logic of programming than writing code. Many kids learn Scratch for a reason. There's no reason we couldn't extend that model further.
I think visual programming is a mixed bag. In some areas it helps.
Block-based editors like Scratch are successful in making syntax errors impossible by virtue of the blocks not fitting together; there are conceptual benefits there for early programming education. The downside is that they cost a tremendous amount of screen real-estate and make editing programs much slower and more tedious than in text-based languages; simple edits become dozens of laborious clicks and drags. While some Scratch enthusiasts have managed to build terrifyingly complex programs in that editor, I think it is only helpful for fairly small programs.
Most of the places where visual programming has been highly successful have been focused on very narrow domains where the intermediate steps of a computation can each be displayed in some comprehensible fashion, like box-and-wire graph editors for shader programs or audio processing. In these systems, every node can naturally be displayed as a texture or a waveform. The more abstract an operation or datatype is, the harder it is for visual programs to provide leverage. Again, many techniques that seem to provide intuitive at-a-glance understanding of a system don't work very well as the programs scale up in complexity; look to any nontrivial graph for UnrealEngine "Blueprint" scripting or a large LabView project to see what I mean.
Text is really, really effective as a flexible medium for conveying information. Every operating system comes with a vast array of tools for manipulating, querying, storing, and displaying text. Replacing text as a program representation means that in addition to the programming environment itself, you'd need to offer replacements for the rest of the text utility ecosystem, too: visual diff and merge tools, visual revision control, visual grepping, visual pastebins, support for your visual programming constructs in chat applications and online message boards where people share advice and discuss programs, etc, etc. It's possible to maintain a bijection between a visual and textual representation of a program, but that tends to require "smuggling" around some extra metadata (node positions in virtual space vs. intentional whitespace and comments in textual code, for example) which can become rather clumsy and force compromises for both representations.
Overall I'm doubtful that any single visual programming paradigm will be sufficiently rich, expressive, and clear to capture the full range of things textual languages do well today. A collection of smaller domain-specific solutions can work for many things though; consider Excel and its integrated suite of textual formulas, rule-based styling, interactive pivoting tools, and visually-constructed charts!
Programmers have abandoned non-programmers.
Visual Basic died. Framework-less PHP does not seem very active. Access is dead (although some database-like things like Notion and Airtable exist!)
We, programmers, are too in love with writing code. Many of us have lost touch with simple solutions to simple problems.
Python at some point took the non-programmer world by storm because... it looked simple, and had many tools that looked simple to use, such as Pandas. Interestingly, many programmers think that Python, Pandas, etc. suck. (For example, I roll my eyes quite hard when I see uses of Pandas that are trivial to do with the standard library.)
Many time ago, non-programmers would write HTML pages, even add colors and images to it. Nowadays, ask a programmer to create a static website and you'll get absurd complexity. Some of it is "necessary" (the world is no longer 800x600, 1024x768, and 1280x1024), but most is completely unnecessary. Give a non-programmer the processes that programmers use to create simple websites and they will run away screaming when 20 years ago they would have been happy editing HTML.
I find it deeply ironic (and disturbing and concerning) that some stuff is actually much harder nowadays!
Absolutely nonsense comment. Nothing is stopping anyone from writing HTML these days and it's easier than it has ever been. CSS got quite powerful, browsers are less broken, you have a personal coding assistant that will help you with everything. Same for writing raw python, you can just do it. Programming has never been easier. The complexity in modern tech stacks is often there for a reason but it should be used once there is a reason for it and definitely shouldn't be used by beginners.
If anyone isn't creating html websites or basic programs it's because they don't want to, everyone thought that every single person will know basic programming in the future (which is now), turns out people just don't want to do that. I can also argue that everyone should be able to work on their car or bike at the most basic level but people refuse to. That is just indicative of people not willing to do the task not of the task being difficult or impossible.
Computer skills in general just didn't really develop at all in my opinion in the general population, it has nothing to do with the complexity of programming. In fact people in education often say that they feel like the computer skills are regressing, are you telling me that's because of complex frontend frameworks?
There are many things in the article I agree with (I <3 literate programming, for example), but... I dunno, I don't think programming sucks. Some of it does, yes. Programming at a BigTech corp sucks more often than not. Writing programs for myself, my loved ones? I enjoy doing that to this day.
I was not aware of Entangled, that looks like a solid idea, and addresses my major painpoint with literate programming: LSPs and other, traditional tools are unaware of it, so editing literate programs can be a pain in the backside. That's the reason I mostly use literate programming with declarative languages, for NixOS configurations for example. With bidirectional LP... it might just make my life easier when using non-declarative languages. I'll give ReTangled a try!
Recommend using Entangled until I get stitching working on ReTangled if that's the main feature you're looking for <3
I have all the time in the world, will happily wait until ReTangled is close to meeting my needs. It's in a language I like more, on a forge I am willing to use (I'm not touching GitHub with a ten feet pole unless I'm paid for the trouble), and I'm not in a hurry.
I think there is a real grind going from something that you enjoy the moment-to-moment writing of to something that users will appreciate. There's a lot of error handling/serialization/deserialization/format projection/etc involved in turning something from a fun prototype to something worthy of production. (One of my rules is that a great user experience almost always involves messy internals.) I personally don't enjoy most of it and have been known to take shortcuts or just not do that work in the past.
I found I don't have trouble with that, either. But in most cases, I have a personal connection to my users, I see them use my work, and that's enough of a morale boost to get through the possibly boring parts.
I agree with you: programming doesn't suck. I was with the author of this article right up to that statement, then when "Embrace the GUI" appeared. I became disenchanted. GUIs seem to me to mostly exist so that director-level and above executives can believe that their workers are doing things that the executives can understand and do. I took a class in some visual, drag-n-drop, ETL thing, and I came away with how hard it would be to make something almost the same as your first system, and how hard it would be to version it all. Same with a visual, drag-n-drop cron replacement system my then-employers used in 2010. Easy for an executive to do some dragging and dropping, hard for the line workers to (A) spot errors, (B) keep versions and backups, and (C) re-use.
I proposed a GUI system that can be represented both visually and as text, leveraging the benefits of both. Non-programmers often have an easier time making visual connections rather than writing code in some cryptic language they have to learn.
Three comments here. One, the only GUI-based management tool (to administer a Unix system specifically) that I actually liked was IBM's SMIT (System Management Interface Tool if I recall correctly) for AIX. It had two flavors---a TUI and a GUI. They both worked the same (as much as they they could). The biggest feature I've yet to see replicated anywhere else is the ability to, just before you apply the action you drilled down into (like creating a new account, or adding, partitioning and mounting a disk), you could have it show you the script it was about to run. The ability to inspect the steps it was about to perform was tremendous and I wish more GUI (or TUI) based tools would do this.
Second, I feel that using a GUI and TUI have different base of expectation, that it's easier to customize, say, terminal use than it is GUI use (a bit more detail here). Apple showed (back in 1984 with the introduction of the Macintosh) that having all GUI applications use the same framework (menu, GUI conventions, what have you) make it easier to use as the same actions can apply across many applications, but that ease-of-use comes at a cost to power users, who often want a faster way to navigate the system that is usually provided.
Three, computer literacy (computeracy?) is not taught well, if at all. Reduced to its core definition (in my opinion) is "repeated operations." If you can instruct a computer to repeat a series of steps, congratulations! You have "programmed" a computer. But GUIs don't make that easy. Here's a task: resize a folder of 100 images. On a command line with the right tools, this is basically "for each image in this folder, resize it 50% smaller." How do you do this in a GUI? Again, you might have to have the a program that specially resizes all images in a folder, where as with the command line, you just need a tool to resize one image.
In my mind, the three comments are related, but I'm having trouble putting into words what they are.
For those interested in rich visual programming environments, Glamorous Toolkit is a good example of what can be done https://gtoolkit.com/ -- I don't think it's there, but it takes what has been built further and then some. There is also something to be said about image-based environments in a world of LLM-generated code.
I skimmed that glamorous toolkit website and got nothing. Do you have a few sentence summary of what it is?
I actually think I pretty strongly agree. Look at wysiwyg editors. They didn’t completely replace web dev but it did cut out a sizable niche for those who just want a website to do basic things or sell basic products. There’s still a large corpus of software that can be made simpler and just done with a good gui interface.
If you’re just gluing together code today or letting llms run rampant maybe you’d actually be better served with gui programming. Lots of code I write are often rest servers. There’s no reason why we can’t make something for this.