Oh… so much to respond to in this thread… Sorry for what will be one of my longer missives…
First, imagine my surprise to wake up to a thread named after a debate that was still raging when I learned programming 40 years ago. Yes, there was a time when people argued about the value of “structured code”.
Max has always failed the “Princess Bride” principle for me: The code often “doesn’t mean what you think it means”. I think this is because, beyond the basic atoms, the constructs don’t have simple effects, easy to reason about. Inserting a send/receive is an example that you want to be able to note, and erase from your mental model of the patch - but you can’t because it affects message order, which is another difficult, global effect in the system.
There’s a long history of visual programming systems, and for the most part they have failed as general programming solutions. The only real successes one can point to are Max and Scratch, both fairly domain specific. The large hurdles remain abstraction, and data structures - and after decades of development (I remember Dan Ingalls’ and Jaron Lanier’s efforts in the 80s) - there is still no breakthrough. As prior comments attest, these remain the pressing problem in larger Max systems.
Two of the main arguments against “structured code” back in the day were:
- We can’t afford to waste memory and CPU on standardized looping constructs over hand crafted code.
- A programmer can better express program flow as they understand the whole problem.
Modern programming has destroyed all that: We have plenty of CPU and memory (for 99.99% of tasks), and no one programmer writes everything any more. As such - coding for clarity, robustness, and reusability generally top all other concerns. As a professional programmer, these concerns are always first. But when we are programming for our personal aims, these need to be first too: Even this kind of programming is no longer a personal endeavor: We open source our code, build on other code frameworks and libraries, and hope people will examine what we do.
Saddly, the call outs from Max are C and Java, and JavaScript. C, by modern standards, is weak in the abstraction department. Java seems now deprecated for Max - and I won’t miss it. JavaScript has the best promise, but well structured code in JS takes almost as much discipline as Max: As a language it was only designed for programming in the small. Compounding all this difficulty is that getting into and out of the language in question is a significant amount of work, which leads away from building the thing at hand.
So where does this leave us? Max does well at audio signal chain, and somewhat well at UI objects that reflect state… but when it comes to control and structure - both of code and of music - I find it totally unworkable. Sorry Max, I can’t bring myself to code anything complex in you.
For myself, my current project is a live-performance oriented percussion sequencer controlled by grid controllers. I am coding it in Haskell: Functional (the current forefront of programming systems), highly concurrent (good for real-time and music), and built to support abstraction in the small and in the large. It will present MIDI in/out ports so I can connect it to other things.
Where I’m looking for better integration with Ableton Live, I will do it via remote scripts: Python is moderately better at larger code, and the Live API is much easier to use from Python than via Max (or even JS via Max). I’ll have to plumb some connection between the Python and the Haskell (probably an OS pipe or perhaps a TCP socket)… which is sad, but frankly seems less awkward than building this thing in Max.
Sooooo… anyone know what the programmable extension environment in Bitwig looks like…?
