> 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.
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.
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.
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.
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?
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.
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.
Here's a different take on thinking about tables:
I wonder if this UI would work well for logic programming instead of stack-based.
It's not great for usability though :)
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 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.
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.
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.
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.
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.
Pretty niche case, but I feel there is something to explore here
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.
turtleyacht•8mo ago
dgellow•8mo ago
turtleyacht•8mo ago
What I like about this submission is arguments are themselves functions, so each call lays out its dependencies up front.