<p dir="ltr"><br>
On May 20, 2014 12:00 PM, "Albert Y. C. Lai" <<a href="mailto:trebla@vex.net">trebla@vex.net</a>> wrote:<br>
><br>
> On 14-05-20 08:58 AM, silvio wrote:<br>
>><br>
>> Only because we can't just execute an IO action and fill in the result.<br>
>> And this list doesn't even include examples where the programmer had to<br>
>> resort to making a pointless temp variable just to avoid using too many<br>
>> complicated functions.<br>
><br>
><br>
> I agree that requiring extra variable names to express data propagation is a problem. I disagree that any notation that goes like<br>
><br>
>     third_effect {first_effect} {second_effect}<br>
><br>
> is a solution. I have written it to highlight the problem: the order of the effects is neither entirely left-to-right nor entirely right-to-left, but rather a haphazard "start somewhere in the middle, go right for a while, now suddenly jump back to the left". This is also my second biggest gripe with Lisp, Scheme, SML, Caml, every impure functional language.<br>

><br>
> One thing the do-notation gets right is that I/O effect order is the simple top-to-bottom.<br>
><br>
> The solution is to liberate programming from the plain text file.<br>
><br>
> Draw a dataflow-like diagram. Arrange effect boxes in one order to indicate effect order. Draw lines or curves between them to indicate data propagation and/or parameter passing.<br>
><br>
> Can programming be liberated from the plain text file?</p>
<p dir="ltr">Having done a number of projects in Max/MSP and PD, I have to say this is a horribly inefficient programming interface. It seems attractive in small doses, but it doesn't scale well.  Additionally it's not at all clear how to design an editor that allows for decent automation, which can slow down many workflows.</p>

<p dir="ltr">If you're interested in this interface, I'd suggest that you try PD for a while.</p>