@jameslo said:

@whale-av @ddw_music I've written assembler for at least 3 different processors and I remember all of them being easier to learn than Pd due to their regularity, completeness, consistency, and sometimes orthogonality

Well... yeah... there are reasons why graphical programming environments haven't taken over computer science... because they're simply not very good at the things CS needs. (One could make the argument that a great many computer musicians can get by without those things, sure.) In particular, data structures and "scope of influence" (such as local variable scope, or public/private variables and methods) are both highly articulate in modern text languages, and sorely underdeveloped in both Pd and Max. ([text] helps but I suspect everything is O(n*m) where n = rows, m = columns.)

There are reasons why my live coding dialect (demo linked below) is implemented in SuperCollider and not Pd/Max. In theory it may be possible to create an abstract syntax tree in [text] storage, but to be frank, it isn't worth the effort. If I really wanted that in Pd, it would be better to write the parser/compiler in Lua or Javascript and embed (but SC, by pulling the control layer out of the audio loop, is also designed for glitch-free dynamic instantiation of synthesis units, which Pd is decidedly not).

I wonder if @ddw_music is trying to teach that to students who don't view it as their primary objective, using a language that's particularly bad at conveying it?

I fully understand and accept that most of the students at this conservatory won't grasp the full implications -- that's fine. Still, every year, there are a few students who do soak it up and they can't get enough. For them, I think it is helpful to present a framework under which, for example, counting and list iteration could be understood as variations on the same structure, rather than discrete cases.

hjh