[HN Gopher] Tabular Programming: A New Paradigm for Expressive C...
___________________________________________________________________
Tabular Programming: A New Paradigm for Expressive Computing
Author : dgellow
Score : 74 points
Date : 2025-04-21 12:26 UTC (10 hours ago)
(HTM) web link (sam.elborai.me)
(TXT) w3m dump (sam.elborai.me)
| turtleyacht wrote:
| See also: _Table-oriented Programming (2002)_ -
| https://news.ycombinator.com/item?id=29735298 - Dec 2021 (126
| points, 87 comments)
| dgellow wrote:
| The name is kind of similar but they are unrelated concepts
| turtleyacht wrote:
| Maybe control tables? https://web.archive.org/web/20121024051
| 826/http://www.geocit...
|
| What I like about this submission is arguments are themselves
| functions, so each call lays out its dependencies up front.
| Johnbot wrote:
| This is giving me flashbacks to RPG II -
| https://en.m.wikipedia.org/wiki/IBM_RPG_II
| diggernet wrote:
| That very first example instantly brought RPG to mind for me,
| too.
| eschneider wrote:
| Yeah, but without the cool programming forms. :/
| poulpy123 wrote:
| 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
| dgellow wrote:
| It's not intended for a regular computer
| lantry wrote:
| > 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.
| lo_zamoyski wrote:
| > 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.
| hwpythonner wrote:
| 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.
| topspin wrote:
| 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.
| hcarvalhoalves wrote:
| 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
| debugnik wrote:
| 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.
| gregschlom wrote:
| 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 :)
| aniou wrote:
| 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...
| herr_shield wrote:
| 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.
___________________________________________________________________
(page generated 2025-04-21 23:01 UTC)