[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



amindfv wrote
> 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.

To add these, SC needs preemptive multitasking... and if we have preemptive
multitasking, then we have to have mutexes (or transactional memory)... and
we have to explain to people whose first job is not programming why thread B
can go in and interrupt thread A and mess around with objects that thread A
was using.

It might be cool if we had preemptive multitasking. That would mean, for one
thing, SC code could implement its own watchdog and stop some thread that
went into an infinite loop. But it would also introduce a class of
hard-to-understand, hard-to-reproduce bugs in user code, whose solution is
hard to explain outside of computer science circles. It might reduce SC's
accessibility.

So I think you've done the right thing -- if you need hard-core concurrency,
use a different language.

Haskell, btw, is at the top of my list for other languages I would learn,
given enough time (although lisp would be more useful, if I wanted to switch
to Emacs for live coding).

hjh



--
Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html

_______________________________________________
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/