Re: [sc-users] Re: top five sclang pet peeves

[amindfv@xxxxxxxxx]

> 
>> for a language that deals heavily with asynchronous operations
>> (interprocess / networked communication), sclang sure doesn't offer a lot
>> to make asynchronous programming less painful.
> 
> Devil's advocate -- maybe this is a documentation problem? Condition() is
> not horrible -- when you know how to use it, it's nearly transparent (and
> improving on that transparency would require a pretty hefty redesign of the
> language, because as it is now, callbacks need to have access to the
> thread's local scope).
> 
> But we don't have a document explaining how to handle "async ops for
> dummies" because -- and this is one of my pet peeves -- we only ever
> document classes and methods, and we never document important topics that
> would be useful to non-computer-scientist users. "Never" -- yes, I'm
> overstating, but let's be honest -- I'm not far wrong, am I?
> 
> fork {
>    var score = Score([
>        ...
>    ]),
>    cond = Condition.new;  // ***
>    score.recordNRT(...,
>        action: { cond.unhang }  // ***
>    );
>    cond.hang;  // ***
>    ... go on
> }
> 
> *Three* lines only, where the "..." may span hundreds of lines. It's very
> slightly weird to write "unhang" before "hang" when the unhanging happens
> later, but this is not excruciating. It's not even that difficult to
> understand, if it were explained in a place where users could find it
> easily.
> 

I think documentation is definitely part of the problem, but sclang also (iiuc) simply lacks some concurrency primitives. For example, transactional memory (so helpful!), or "actor model" concurrency, or the ability to (iiuc) do computations on different CPU cores.

I 100% understand and respect focussing on making sclang good at what it's good at instead of making it a completely general-purpose language. On the other hand, the above (especially transactional memory) are a big part of why I do most of my supercollider coding in a general purpose language (Haskell) these days.

But! The other reason for switching was having a strong type system (algebraic types and inference), and I wouldn't recommend bolting that onto sclang at this point :D

Tom
_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/