A New Way of Looking at Software Development

From Suffrage to Software Development A Conversation About John Seddon

A New Way of Looking at Software Development

From the transcript of Dr Casey Morgan’s controversial presentation at CodeCon 2025

The auditorium buzzed with anticipation as Dr Casey Morgan stepped up to the presentation platform. Around them, 500 of the world’s top developers had just finished the morning coffee break, many still discussing their current projects using their familiar AST toolchains—some clicking through visual node editors, others using drag-and-drop tree builders to show off recent work.

‘Thank you for joining me today,’ Casey began, gesturing to dismiss the tree structures that had been displaying on the main screen. ‘I’m here to propose something… unconventional. A fundamentally different way to think about code representation that I believe could offer some unique advantages.’

She paused, scanning the faces of developers who had grown up building programmes by directly assembling syntax trees—clicking to add nodes, dragging to restructure branches, using visual editors, commands and APIs.

‘I call it “textual programming”.’

A wave of puzzled murmurs rippled through the audience. In the front row, Marcus Chen, lead architect at Distributed Dynamics, frowned slightly.

The Unusual Proposal

Casey’s concept was unlike anything the programming community had encountered: instead of building programmes by manipulating AST structures through visual node editors and drag-and-drop interfaces, programmes could be represented as linear sequences of human-readable symbols.

‘Imagine,’ Casey said, projecting a strange sequence onto the main display:

function calculateFibonacci(n) {
if (n <= 1) return n;
return calculateFibonacci(n-1) + calculateFibonacci(n-2);
}

‘This linear representation would encode the same semantic meaning as our AST structures, but as a sequential stream of characters that developers would… type directly.’

The audience stared at the bizarre notation with growing amusement.

The Immediate Concerns

Sarah Kim, Senior AST Engineer at MindMeld Corp: ‘Dr Morgan, I’m struggling to understand the practical implementation. How would developers ensure structural integrity? When I use a visual node editor, I literally cannot create a malformed tree—the interface simply won’t allow invalid connections. But with this… character stream… what prevents someone from typing complete nonsense?’

Casey nodded. ‘That’s certainly a challenge. The system would need to constantly re-parse these character sequences and provide error feedback when the text doesn’t represent a valid tree structure.’

The audience shifted uncomfortably.

Marcus Chen: ‘Wait, you’re suggesting a system where the code could be in an invalid state? Where developers could accidentally break their programme just by typing the wrong character? That seems like a massive degradation from our current reliability.’

Casey: ‘I understand that sounds concerning, but consider this: what if the ability to work in temporarily invalid states actually enables more fluid thinking? Sometimes you need to break something before you can rebuild it better. Current tree editors force you to maintain validity at every step, which might constrain exploration. Interestingly, there were early experiments with syntax-directed programming environments in the 1980s that enforced similar structural constraints, and environments like Mjølner for the BETA language that provided more structure-aware development tools, but they never achieved the fluidity that our modern AST tools provide. Perhaps the pendulum swung too far towards structural rigidity, and text could offer a middle ground.’

Dr Wright: ‘But Casey, you’re mischaracterising our current tools. Modern AST editors do support invalid intermediate states—they make them visible and actionable in ways text never could. When I’m restructuring a complex tree, the IDE shows me exactly which nodes are problematic, suggests valid completions, and even maintains partial compilation contexts. I can experiment freely whilst getting real-time feedback about structural issues. Your text approach would lose all of that sophisticated error guidance and replace it with… what? Cryptic parser error messages? We’ve already solved the flexibility problem without sacrificing the safety and intelligence of our tools.’

Sarah Kim: ‘And think about what else you’d be throwing away! Our semantic-aware merge algorithms that automatically resolve conflicts at the meaning level, real-time type inference that shows you the implications of every change, automated dependency tracking, intelligent refactoring that understands program semantics—all of that would be impossible with linear character sequences. You’d be asking developers to manually track imports, manually resolve merge conflicts, and manually verify type safety. It’s like proposing we go back to manual memory management when we have garbage collection.’

Unknown developer: ‘Not to mention accessibility. Our structure-aware screen readers work beautifully with AST nodes, providing rich semantic information to visually impaired developers. Text files would force them back to listening to character-by-character descriptions of syntax symbols. And what about internationalisation? AST nodes work universally, but your text files would tie us to specific character encodings and syntactic conventions.’

Marcus: ‘The security implications alone are staggering. Text files could contain hidden Unicode characters, be corrupted by encoding issues, or have malicious content inserted between visible characters. Our AST verification systems prevent all of that. And the environmental cost—think about all the redundant parsing and recompilation. Text would waste enormous amounts of computing resources that our direct tree manipulation avoids entirely.’

Dr James Wright, Director of Innovation Institute: ‘I’m concerned about the cognitive overhead. When I’m building a complex algorithm, I can see the entire tree structure, drag nodes around, visualise the flow. How would anyone comprehend programme structure from a linear sequence of characters?’

Casey: ‘That’s where it gets interesting—linear text might reveal different patterns than tree visualisation. You might notice repetitive structures, common sequences, or algorithmic patterns that are harder to see when nodes are spatially distributed. The constraint of linearity could force a different kind of structural thinking.’

Casey remained calm, though the room’s scepticism was palpable. ‘The idea is that developers would develop familiarity with common textual patterns. They’d learn to “read” the structure from the character sequences.’

The Growing Scepticism

As the session continued, the questions became more pointed:

Rapid Prototyping: ‘Casey, you mentioned quick sketching, but I can prototype by dragging a few function nodes together and see exactly what I’m building as I construct it. Why would typing individual characters be faster than visual construction?’

Version Control: ‘Instead of tracking AST transformations, we could diff character sequences directly. Imagine seeing exactly which symbols changed between versions—a completely new form of change visualisation.’

Universal Accessibility: ‘Text could be manipulated with the most basic tools imaginable. No specialised AST tooling required—potentially opening programming to entirely new populations who never learned tree manipulation interfaces, command-line utilities, or visual node editors.’

Cognitive Revolution: ‘Linear representation might unlock different types of thinking. Whilst AST commands encourage procedural construction, text could promote holistic algorithmic visualisation—potentially revealing new problem-solving approaches.’

Sara Kumar, Independent Developer: ‘Casey, this is mind-blowing! But I’m struggling to visualise the workflow. How would developers navigate these linear sequences? Our current AST tooling is so diverse and powerful—whether through tree views, command pipelines, or node graphs—how would you achieve similar precision with text?’

Casey’s eyes lit up. ‘That’s where it gets really interesting. Navigation could be character-based, word-based, or even pattern-based. Imagine search systems that find textual patterns across codebases—no need for complex tree queries or specialised AST search interfaces!’

The Mounting Objections

The questions grew more challenging as the session progressed.

Dr Wright: ‘Let’s talk about collaboration. When my team works together, we can see each other manipulating the same tree in real-time, pointing to specific nodes, discussing structure visually. How would that work with linear text?’

Marcus: ‘And error prevention—our IDEs guide us through valid tree construction. They suggest appropriate node types, validate connections, prevent impossible structures. Text systems would need to replicate all of that functionality whilst being fundamentally less intuitive.’

Sarah Kim: ‘Plus, there’s the execution efficiency issue. When I modify a node in my tree, the running programme updates instantly—real-time incremental compilation means our executables are always synchronised with the current AST state. With text, you’d need to reparse and recompile every time you make a change. That seems incredibly inefficient.’

Dr Wright: ‘And consider something as basic as cut and paste. When I copy an AST fragment, I’m copying a complete, semantically valid tree structure with all its type information and metadata. The IDE ensures I can only paste it in locations where it makes sense. With text, you’d be copying… character sequences? With no understanding of structure or validity? You could accidentally paste a function definition in the middle of an expression.’

Unknown developer: ‘But Casey, consider the sheer inefficiency. When I create that fibonacci function, I click “add function node”, type “calculateFibonacci”, set the parameter “n”, drag in a conditional, and set the values. With your text system, developers would have to manually type “function”, all the braces, “if”, “return”, parentheses, semicolons—why type all that structural syntax when the interface can handle it automatically?’

Casey: ‘Well, the redundancy does seem excessive when you put it that way…’

Sarah Kim: ‘The debugging implications are staggering. When something goes wrong, I can visually trace through my tree, see the data flow, identify problem nodes. You’re proposing we debug by… reading character sequences?’

Unknown voice from the back: ‘Dr Morgan, this feels like proposing assembly language when we have high-level visual programming tools. What’s the actual benefit?’

The Fundamental Questions

As the hour progressed, the audience’s concerns crystallised around core issues:

Safety: Text-based programming would introduce countless opportunities for errors that were literally impossible with guided tree construction.

Productivity: Every task that was currently visual and intuitive would become abstract and error-prone.

Learning Curve: New developers would need to memorise syntax rules instead of learning through visual exploration.

Tool Complexity: Text editors would need to recreate all the intelligence of current AST tools whilst being fundamentally less capable.

Maintenance: Reading and understanding existing code would become dramatically more difficult without visual tree representation.

Sara Kumar, Independent Developer: ‘Casey, I have to ask—have you actually tried building a complex system this way? It sounds like you’d spend more time debugging syntax errors than solving actual problems.’

Casey smiled weakly. ‘The learning curve would certainly be steep initially.’

The Uncomfortable Reality

Towards the end of the session, the questions became more direct.

Dr Maria Santos, Education Director at Code Academy: ‘Casey, we teach programming through visual tree building because it’s intuitive—students can see programme structure immediately. You’re proposing we replace that with… memorising character sequences? How would that possibly be better for learning?’

Casey: ‘I wonder if visual-first education might actually be limiting in some ways. When students start with trees, they think in terms of discrete components. Linear text might encourage them to think about flow, narrative, the sequential logic of computation. Different mental models could lead to different insights.’

Several audience members shook their heads in disbelief.

The Uncomfortable Questions

Towards the end of the session, the questions became more philosophical.

Marcus: ‘Casey, I need to understand your thesis here. You’ve shown us a system that would make programming more error-prone, harder to visualise, more difficult to debug, and require extensive memorisation of arbitrary syntax rules. You’re asking us to give up immediate visual feedback for… what exactly?’

Sarah Kim: ‘Every advantage you’ve mentioned—rapid prototyping, version control, collaboration—we already have superior solutions for. Our visual systems are faster, safer, and more intuitive. I genuinely don’t understand the appeal of this approach.’

Dr Wright: ‘And the security implications worry me. Our current tree validators ensure code integrity. Text files could be easily corrupted or maliciously modified. How would text-based systems prevent tampering?’

Unknown developer: ‘Dr Morgan, with respect, this sounds like a needlessly complex solution to problems we’ve already solved. Why would anyone choose to make programming harder?’

The Final Challenge

As the session neared its end, Marcus Chen stood up with a bemused expression.

‘Casey, I want to understand something. You’ve proposed replacing our visual, guided, error-preventing development environment with a system based on memorising syntax rules and typing linear character sequences. A system where malformed programmes are possible, where structure is invisible, where collaboration becomes awkward text sharing.

‘I’m trying to find the upside here, but every supposed benefit seems to be something we already do better with visual tree manipulation. The downsides, however, are enormous: syntax errors, reduced productivity, harder debugging, steeper learning curves, and cognitive overhead.

‘So my question is simple: other than academic curiosity, why would any rational developer choose this approach?’

Casey looked out at the audience—hundreds of developers who could shape logic with drag-and-drop simplicity, who collaborated through shared visual workspaces, who had never known the frustration of syntax errors or the cognitive load of maintaining mental models of invisible structure.

‘Perhaps,’ they said quietly, ‘there are insights that only come from constraint. Maybe working with a more limited medium forces different kinds of thinking. Or maybe…’

They paused, seeing the politely sceptical faces.

‘Maybe you’re right. Maybe this is just an interesting academic curiosity with no practical value.’

Epilogue

Dr Morgan’s presentation ended to scant and unconvinced murmurs. Whilst their research into ‘textual programming’ generated some academic discussion amongst theoretical computer scientists, the broader development community found the proposal risible.

A few independent researchers built experimental text editors and basic parsers, mostly to satisfy their curiosity about this unusual approach. Most found the experience frustrating and unproductive—exactly as the CodeCon audience had predicted.

The general consensus was that Dr Morgan had demonstrated an interesting thought experiment about alternative representations, but nothing that could compete with the efficiency, safety, and intuitiveness of direct tree manipulation.

Whether textual programming represented a misguided approach or simply an academic exercise remained unclear. What was certain was that the development community saw no compelling reason to abandon their sophisticated, visual, error-preventing tools for the apparent chaos of linear character sequences.

The revolution, it seemed, would have to wait for more compelling advantages.

Dr Casey Morgan continues their research into alternative programming paradigms at the Institute for Computational Archaeology. Their upcoming paper, ‘Linear Text as Code Representation: A Feasibility Study’, is expected to conclude that whilst technically possible, textual programming offers no significant advantages over current tree-based development methodologies.

Bob Marshall's Blog

Bob Marshall's profile
55 followers