Tabular Programming: A New Paradigm for Expressive Computing
The article introduces tabular programming, a structured coding approach inspired by the m8 Dirtywave tracker, enhancing maintainability and accessibility while utilizing minimal hardware and promoting clear data flow in programming.
Read original article
The article discusses the concept of tabular programming, inspired by the m8 Dirtywave tracker, a portable music sequencer. The author proposes a new programming environment that utilizes a tabular interface, allowing users to define functions in a structured format with fixed columns for function identifiers, input parameters, expressions, and output specifications. This approach encourages breaking down complex operations into simpler, composable functions, enhancing code maintainability. The proposed hardware would be minimal, featuring a Teensy 4.1 microcontroller, a small display, and a limited number of buttons for navigation and execution, eliminating the need for traditional keyboards. The tabular model aims to reduce errors, promote focused decomposition, and provide explicit data flow, making programming more accessible and portable. The article also illustrates the practical application of this model through examples of classic demoscene effects, such as plasma and tunnel effects, demonstrating how the tabular structure can effectively manage data flow and execution in a visually organized manner. The author emphasizes that this innovative approach to programming could lead to new paradigms by leveraging hardware constraints to rethink fundamental programming concepts.
- Tabular programming organizes code into a structured table format, enhancing maintainability.
- The proposed environment uses minimal hardware, allowing programming without traditional keyboards.
- The model reduces syntax errors and promotes clear data flow between functions.
- Practical examples demonstrate the effectiveness of the tabular approach in creating visual effects.
- The concept encourages rethinking programming paradigms based on hardware limitations.
Related
Atari ST Programming: Hatari, STOS and Turbo C
The article reflects on the Atari ST, a 16-bit microcomputer, its programming tools like STOS and Turbo C, and emulators Hatari and STEem, with plans for future coding examples.
The missing text focused programming environment
Chris Siebenmann critiques current programming environments for text applications, highlighting the limitations of GNU Emacs and Electron. He advocates for simpler, smaller-scale environments using HTML and CSS without JavaScript.
Emulating 6502
The author discusses a shift to retrocomputing, focusing on the MOS 6502 CPU, its architecture, and building gaming hardware, while developing an emulator tested with the Apple I computer.
Append-Only Programming
Ian Fisher's append-only programming methodology adds code to a single C file without editing, promoting clear interfaces and small functions, but complicating error correction and maintenance. Modifications are suggested for practicality.
Visual programming is stuck on the form
Wil Chung critiques visual programming for prioritizing form over function, arguing that the node-and-wires model oversimplifies programming logic. He advocates for designs that emphasize underlying functions to enhance user experience.
- Many commenters draw parallels between tabular programming and existing structured programming paradigms, such as assembly language and ladder diagrams.
- There is a discussion about the constraints of tabular programming, with some arguing that it can enhance maintainability while others express concerns about readability and usability.
- Several users highlight the potential for creative expression within tight hardware constraints, suggesting that this approach could lead to innovative programming methods.
- Some commenters question the practicality of tabular programming for general computing, suggesting it may be more suited for specific applications like music sequencing.
- References to historical programming languages and concepts indicate a broader context for understanding the implications of tabular programming.
15 comments> By rethinking how programming can work within tight hardware constraints, we might discover new approaches that actually enhance rather than limit creative expression.
This speaks to me. As a software engineer, I work with abstractions all day, and it is impossible for me to fully understand the system that I'm building. I often think I would be much happier if I worked on a product that I could actually understand from top to bottom and know all the details.
Here's a different take on thinking about tables:
It's not great for usability though :)
The author conveniently disregards the other extreme end of this, putting every instruction in a separate function, which is neither readable nor maintainable.
What I see here is similar. The code snippets I’m looking at look neither readable nor maintainable.
Some things that really do fit into tables, where there's no empty fields in the rows:
- Relational databases
- Hardware circuit truth tables
- Assembly language opcodes
- FPGA compiler output
- Matrix multiplication. Or some GPU programs e.g. if you want to have a conditional statement using multiply-add, then 'if (cond) then x1 else x2' would be 'out = (cond * x1) + (cond * x2)'.
Those things have good performance in one way or another. But it's not easy to make all the application logic fit into a table-based schema.
e.g. Why does someone choose a python web server framework which sends and receives JSON. It's really super easy to extend and add something without knowing what you'll need in advance.
But if you try to fit that into a table, you'll have to change the table schema for everything to try to best fit what the program does right at the moment. And then if there's one new extra complex or long-running function, it will never easily fit the same schema as the others. You'll have to break the big function down into some smaller common operations.
I wonder if this UI would work well for logic programming instead of stack-based.
Related
Atari ST Programming: Hatari, STOS and Turbo C
The article reflects on the Atari ST, a 16-bit microcomputer, its programming tools like STOS and Turbo C, and emulators Hatari and STEem, with plans for future coding examples.
The missing text focused programming environment
Chris Siebenmann critiques current programming environments for text applications, highlighting the limitations of GNU Emacs and Electron. He advocates for simpler, smaller-scale environments using HTML and CSS without JavaScript.
Emulating 6502
The author discusses a shift to retrocomputing, focusing on the MOS 6502 CPU, its architecture, and building gaming hardware, while developing an emulator tested with the Apple I computer.
Append-Only Programming
Ian Fisher's append-only programming methodology adds code to a single C file without editing, promoting clear interfaces and small functions, but complicating error correction and maintenance. Modifications are suggested for practicality.
Visual programming is stuck on the form
Wil Chung critiques visual programming for prioritizing form over function, arguing that the node-and-wires model oversimplifies programming logic. He advocates for designs that emphasize underlying functions to enhance user experience.