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