5 ms·
> At first glance, limiting each function to just five expressions seems incredibly restrictive. But this constraint actually encourages breaking down complex o
by sedatk 2y ago
> 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.
- sanderjd 2y agoYeah 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.
- dgellow 2y agoAgreed, and it is a very specific purpose. Note that it is based on Forth, not assembly
- dgellow 2y agoTwo 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.
- sedatk 2y ago> 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.
- dgellow 2y ago1. 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.
- sedatk 2y agoOh 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.