> 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 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).
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
> 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 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.
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...
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.
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.
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
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.