> this tabular programming environment isn't just about cramming programming capabilities into a Game Boy-like device. It's about rethinking programming from the ground up for a specific hardware context. (...)
> 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.
> 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.
For a programmer, the “system” is in a sense incidental to the domain and language you’re programming in. It has relevance only insofar as practicality demands it (like an astronomer knowing how to operate a telescope). There is no intrinsic value to this knowledge as such. Anything ‘beneath’ your language is implementation detail whose purpose is to simulate your language, program, whatever. It has nothing to do with your language and does not explain the language; any appropriate system that can simulate it will do.
1) all abstractions leak. We use them anyway because they are helpful, but you have to be expert enough to know when they're leaking, and know what to do about it. This invariably requires understanding the system underneath the abstraction.
2) I disagree that there is "no intrinsic value" in this knowledge. Even in purely monetary terms, my salary is much higher because I like to look underneath the abstraction. I agree that in our modern software systems that it is not practical to understand everything, and it's usually most "cost efficient" to operate at/near the highest abstraction layer. But this does not bring me joy! and what "intrinsic value" is there besides happiness?
Hence the comparison with telescopes. But knowledge of a tool is not to be confused with the field itself. We are not programming computers per se. We are using computers to simulate formalisms that can be carried out by people, in our heads or on paper, largely because it is tedious, labor intensive, and would take us longer.
The intellectual distinction is essential and, sadly, one that many in the field seem not to understand. Many seem to subscribe to a kind of "computer atomism" which installs the physical device in the center as the really real with abstractions as epiphenomena or illusions; the real stuff, they claim, are the assembly - nay! - the bits - nay! - the atoms - nay! - ... No. Assembly, bits, atoms, these are all irrelevant and incidental as far as the language and the formalism we're using is concerned. They are details that concern the instrument, not the language, which stands on its own.
I agree with not placing the computer at the center. After all it's a tool.
But I struggle with the idea that we can ignore the technical details. After all, even the highest abstraction comes from the physicality of the universe.
But maybe you are saying that the limitations of a tool shouldn't forbid you from thinking at the higher language level.
Or maybe I am just not enlightened enough to understand your point, to which I can only apologize.
> actually understand from top to bottom and know all the details.
In practice, you’re always going to hand-wave away some level of abstraction, whether that’s at the JavaScript, C++, C, LLVM, native ISA, CPU microcode, logic gates, transistor, chemistry, or physics level.
One could make a hardware simulator and code in low level components. For some applications it would make things a lot easier, everything else would be hard. It seems fun to be able to build the physical app.
This reminds me of ladder diagrams from industrial control systems—not because of the domain, but because both emphasize a linear, visually structured flow of logic.
The first glance of the code made me think of CNC g-code. Some older machines I've seen have tabular form similar to this, only because they have segmented displays. I suspect these concepts aren't as "new paradigm" as the author imagines.
Most such code is generated elsewhere and loaded into industrial machines. However, technicians frequently find themselves navigating and editing code directly at the console. Some are entirely capable of programming all of the steps involved in a complex operation directly in these primitive languages.
I've only skimmed the article but to me it sounds like what the author wants is essentially assembly language, where everything fits in 5 columns: label, opcode, 2 operands, comment.
Yes-and-no, I think. Limited usability of assembly language comes from limited resources (registers, operations) available to programmer, that leads to (so) many simple steps for more complicated tasks.
But, high-level language can offer a very interesting possibilities, even if it was not created for such kind of programming. For example, some time ago I made another attempt to emulate family of 65xxx. Previous versions were written in typical manner, like work of every other programmer on Earth.
A new approach, when a code was written in more regular way (see link below), like mentioned tabular-one, gave me excellent results. I was able to fully understood a program and processor logic and finally I was able to re-create a most magical command for 65xx: SBC/ADC with BCD support in very straightforward and clear way (especially for a cpu-like logic).
I have come to the same conclusion for a tracker that I am working on that is targeting the steam deck.
I designed an instruction set that is reasonably convenient to input via the gamepad controllers. Instead of typing, one selects instructions and operands from lists of options. It's surprisingly fluid to input and this makes it impossible to input invalid programs.
My current language is based on Forth, which is a better fit as that allows me to use more horizontal space and not have to think about registries and memory addresses. Similar to Forth my tabular format works with a stack based model where data flows implicitly between expressions.
> At first glance, limiting each function to just five expressions seems incredibly restrictive. But this constraint actually encourages breaking down complex operations into atomic, composable functions - which tends to produce more maintainable code.
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.
1. This is specifically designed for portable hardware with minimal controls - not general-purpose programming.
2. Like music trackers, unfamiliarity makes it look complex, but the rules are simple and consistent once learned.
The five-expression limit creates a natural balance in function decomposition that's neither too granular nor too monolithic. While the code might look strange initially, the structured format actually enhances readability once you're fluent in the paradigm - just as tracker musicians can quickly "read" musical patterns that would appear cryptic to others.
Readability is highly contextual and shaped by our existing paradigms. This article/concept explores whether different constraints might offer unique advantages for creative coding in specific environments.
> 1. This is specifically designed for portable hardware with minimal controls - not general-purpose programming.
I don't understand why portable hardware warrants a new programming model. What does make C such a significantly worse candidate for the examples given in the article?
> 2. Like music trackers, unfamiliarity makes it look complex, but the rules are simple and consistent once learned.
Columns and rows in tracker music have specific meanings: each column corresponds to a channel, and each row corresponds to a point in time. Not in this case. In this layout, columns are arbitrary, and their meaning changes every row. Rows don't have any more meaning than regular code. I don't think they're equivalent.
1. Because of hardware limitations. Writing text using arrow keys and 4 buttons is a real pain, error prone, requires formatting, uses way too much horizontal space. C would also be a horrible choice for creative programming, you cannot quickly tweak things around, iteratively and interactively develop your program. That doesn't match the tracker workflow I'm interested in.
2. In my concept columns and rows do have specific meaning too. Each row is a function (known as words in Forth, the language that is the closest to what I'm doing and a main source of inspiration). Columns have clear meaning, as mentioned in the article:
- function name
- input
- expressions 1-5
- output
That does match quite closely what my m8 tracker does in phrase view, where columns are:
- note
- volume
- instrument
- effects 1-3
I'm not sure what made you think that columns and rows are arbitrary.
For context, the main use case is to generate demo-scene like animations for my music. I would hate to write C on such a limited device for that purpose — in fact that's exactly what I do not want and the reason for this project to exist.
Yeah it's an interesting idea, but trying to read this code reminds me a lot of reading assembly. It's charming in its way, but there's also a very good reason we tend to reserve assembly code to very specific purposes nowadays.
Some random thoughts, might be interesting (or not).
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.
Didn't expect to see the M8 when opening this. It's truly an amazing device, and the tables are a really awesome addition to the typical audio modulation option.
that would be pretty confusing, as it happens M8 was partially inspired by another tracker called LGPT (Little Game Park Tracker, named after the device it ran on).
Maybe we have to try harder? My first thought was db queries pointing at html templates and/or css selectors where to put the output. That you have to pick working commands could be useful there.
I initially used the title « tabular Forth », as that has been one of my main source of inspiration. But eventually decided against and removed most mentions of the language, because at this stage I’m still not set on a specific design and choice of language, and prefer to keep my options open without feeling pressured by my old self (if that makes sense)
> this tabular programming environment isn't just about cramming programming capabilities into a Game Boy-like device. It's about rethinking programming from the ground up for a specific hardware context. (...)
> 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.
> 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.
For a programmer, the “system” is in a sense incidental to the domain and language you’re programming in. It has relevance only insofar as practicality demands it (like an astronomer knowing how to operate a telescope). There is no intrinsic value to this knowledge as such. Anything ‘beneath’ your language is implementation detail whose purpose is to simulate your language, program, whatever. It has nothing to do with your language and does not explain the language; any appropriate system that can simulate it will do.
1) all abstractions leak. We use them anyway because they are helpful, but you have to be expert enough to know when they're leaking, and know what to do about it. This invariably requires understanding the system underneath the abstraction.
2) I disagree that there is "no intrinsic value" in this knowledge. Even in purely monetary terms, my salary is much higher because I like to look underneath the abstraction. I agree that in our modern software systems that it is not practical to understand everything, and it's usually most "cost efficient" to operate at/near the highest abstraction layer. But this does not bring me joy! and what "intrinsic value" is there besides happiness?
but it has a tremendous impact on performance. making it hard to ignore.
Hence the comparison with telescopes. But knowledge of a tool is not to be confused with the field itself. We are not programming computers per se. We are using computers to simulate formalisms that can be carried out by people, in our heads or on paper, largely because it is tedious, labor intensive, and would take us longer.
The intellectual distinction is essential and, sadly, one that many in the field seem not to understand. Many seem to subscribe to a kind of "computer atomism" which installs the physical device in the center as the really real with abstractions as epiphenomena or illusions; the real stuff, they claim, are the assembly - nay! - the bits - nay! - the atoms - nay! - ... No. Assembly, bits, atoms, these are all irrelevant and incidental as far as the language and the formalism we're using is concerned. They are details that concern the instrument, not the language, which stands on its own.
I agree with not placing the computer at the center. After all it's a tool.
But I struggle with the idea that we can ignore the technical details. After all, even the highest abstraction comes from the physicality of the universe.
But maybe you are saying that the limitations of a tool shouldn't forbid you from thinking at the higher language level.
Or maybe I am just not enlightened enough to understand your point, to which I can only apologize.
> actually understand from top to bottom and know all the details.
In practice, you’re always going to hand-wave away some level of abstraction, whether that’s at the JavaScript, C++, C, LLVM, native ISA, CPU microcode, logic gates, transistor, chemistry, or physics level.
https://xkcd.com/435/
One could make a hardware simulator and code in low level components. For some applications it would make things a lot easier, everything else would be hard. It seems fun to be able to build the physical app.
You (and GGP) might enjoy:
https://www.nand2tetris.org/
also https://nandgame.com/
This reminds me of ladder diagrams from industrial control systems—not because of the domain, but because both emphasize a linear, visually structured flow of logic.
The first glance of the code made me think of CNC g-code. Some older machines I've seen have tabular form similar to this, only because they have segmented displays. I suspect these concepts aren't as "new paradigm" as the author imagines.
Most such code is generated elsewhere and loaded into industrial machines. However, technicians frequently find themselves navigating and editing code directly at the console. Some are entirely capable of programming all of the steps involved in a complex operation directly in these primitive languages.
This is giving me flashbacks to RPG II - https://en.m.wikipedia.org/wiki/IBM_RPG_II
That very first example instantly brought RPG to mind for me, too.
Yeah, but without the cool programming forms. :/
I've only skimmed the article but to me it sounds like what the author wants is essentially assembly language, where everything fits in 5 columns: label, opcode, 2 operands, comment.
It's not great for usability though :)
Yes-and-no, I think. Limited usability of assembly language comes from limited resources (registers, operations) available to programmer, that leads to (so) many simple steps for more complicated tasks.
But, high-level language can offer a very interesting possibilities, even if it was not created for such kind of programming. For example, some time ago I made another attempt to emulate family of 65xxx. Previous versions were written in typical manner, like work of every other programmer on Earth.
A new approach, when a code was written in more regular way (see link below), like mentioned tabular-one, gave me excellent results. I was able to fully understood a program and processor logic and finally I was able to re-create a most magical command for 65xx: SBC/ADC with BCD support in very straightforward and clear way (especially for a cpu-like logic).
For example: https://github.com/aniou/morfeo/blob/a83f548e98bd310995b3c37...
There is one thing that not fits into pure, tabular-like code logic: more complicated conditionals and loops. But maybe, in future...
I have come to the same conclusion for a tracker that I am working on that is targeting the steam deck.
I designed an instruction set that is reasonably convenient to input via the gamepad controllers. Instead of typing, one selects instructions and operands from lists of options. It's surprisingly fluid to input and this makes it impossible to input invalid programs.
What’s your project? I would love to try it out :)
it’s called shield tracker and is available here: https://bleep.toys/stracker
Awesome, thanks for sharing! Added to my weekend todo list :D
My current language is based on Forth, which is a better fit as that allows me to use more horizontal space and not have to think about registries and memory addresses. Similar to Forth my tabular format works with a stack based model where data flows implicitly between expressions.
When I first read the title, I had something in mind, but this is actually about structuring the code itself as a fixed-size table.
Here's a different take on thinking about tables:
https://www.youtube.com/watch?v=b5UK-VHbJlQ
> At first glance, limiting each function to just five expressions seems incredibly restrictive. But this constraint actually encourages breaking down complex operations into atomic, composable functions - which tends to produce more maintainable code.
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.
Two points:
1. This is specifically designed for portable hardware with minimal controls - not general-purpose programming.
2. Like music trackers, unfamiliarity makes it look complex, but the rules are simple and consistent once learned.
The five-expression limit creates a natural balance in function decomposition that's neither too granular nor too monolithic. While the code might look strange initially, the structured format actually enhances readability once you're fluent in the paradigm - just as tracker musicians can quickly "read" musical patterns that would appear cryptic to others.
Readability is highly contextual and shaped by our existing paradigms. This article/concept explores whether different constraints might offer unique advantages for creative coding in specific environments.
> 1. This is specifically designed for portable hardware with minimal controls - not general-purpose programming.
I don't understand why portable hardware warrants a new programming model. What does make C such a significantly worse candidate for the examples given in the article?
> 2. Like music trackers, unfamiliarity makes it look complex, but the rules are simple and consistent once learned.
Columns and rows in tracker music have specific meanings: each column corresponds to a channel, and each row corresponds to a point in time. Not in this case. In this layout, columns are arbitrary, and their meaning changes every row. Rows don't have any more meaning than regular code. I don't think they're equivalent.
1. Because of hardware limitations. Writing text using arrow keys and 4 buttons is a real pain, error prone, requires formatting, uses way too much horizontal space. C would also be a horrible choice for creative programming, you cannot quickly tweak things around, iteratively and interactively develop your program. That doesn't match the tracker workflow I'm interested in.
2. In my concept columns and rows do have specific meaning too. Each row is a function (known as words in Forth, the language that is the closest to what I'm doing and a main source of inspiration). Columns have clear meaning, as mentioned in the article:
- function name
- input
- expressions 1-5
- output
That does match quite closely what my m8 tracker does in phrase view, where columns are:
- note
- volume
- instrument
- effects 1-3
I'm not sure what made you think that columns and rows are arbitrary.
For context, the main use case is to generate demo-scene like animations for my music. I would hate to write C on such a limited device for that purpose — in fact that's exactly what I do not want and the reason for this project to exist.
Oh I missed that you used this to write code *on* that platform, not *for* it. Okay now it makes sense.
About columns, I pretty much meant expressions 1-5. They are arbitrary, unlike sound channels, there is no special meaning to, say, expression 2.
But since you use this to code ON the device, your tradeoffs are sensible.
Yes, I should have made that clearer, I see now it’s not obvious that I want the device itself to be the development environment :)
Pretty niche case, but I feel there is something to explore here
Yeah it's an interesting idea, but trying to read this code reminds me a lot of reading assembly. It's charming in its way, but there's also a very good reason we tend to reserve assembly code to very specific purposes nowadays.
Agreed, and it is a very specific purpose. Note that it is based on Forth, not assembly
Some random thoughts, might be interesting (or not).
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.
Didn't expect to see the M8 when opening this. It's truly an amazing device, and the tables are a really awesome addition to the typical audio modulation option.
Following GPU industry standards, this should be called a General Purpose Music Tracker.
I wonder if this UI would work well for logic programming instead of stack-based.
that would be pretty confusing, as it happens M8 was partially inspired by another tracker called LGPT (Little Game Park Tracker, named after the device it ran on).
Interesting, I didn’t know. I thought it was a direct descendants of LSDJ. I have an old school PSP around, I will try LGPT over the weekend :)
Maybe it's interesting as a scripting language for a music sequencer that has few keys, but I can't even think of a use case for regular computers
It’s not intended for a regular computer
Maybe we have to try harder? My first thought was db queries pointing at html templates and/or css selectors where to put the output. That you have to pick working commands could be useful there.
Forth mentioned, btw.
I initially used the title « tabular Forth », as that has been one of my main source of inspiration. But eventually decided against and removed most mentions of the language, because at this stage I’m still not set on a specific design and choice of language, and prefer to keep my options open without feeling pressured by my old self (if that makes sense)
[dead]
See also: Table-oriented Programming (2002) - https://news.ycombinator.com/item?id=29735298 - Dec 2021 (126 points, 87 comments)
The name is kind of similar but they are unrelated concepts
Maybe control tables? https://web.archive.org/web/20121024051826/http://www.geocit...
What I like about this submission is arguments are themselves functions, so each call lays out its dependencies up front.
[flagged]