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

Re: [sc-dev] Towards SC 4



It would also make an SC4 an *immensely* larger project, since all of the domain specific stuff would have to be reimplemented in the new language, and we'd get no reuse of existing SC lang code. I agree that an SC4 is a good opportunity to break things to make them better, but a new language would also mean that there would be no compatibility with SC3 code. It's interesting, but it sounds more like something completely new, rather than an SC4.

S.

On 12 Nov 2013, at 14:26, Andrea Valle <valle@xxxxxxxxxxx> wrote:

I'm not a programmer guru at all but really, SC vs. Python…
I'm a regular Python user but
SC is *much* more elegant, concise, expressive…

I understand the point but if we want to send emails with SC or similar we can use various tricks…

2c, of course :) 

-a-



--------------------------------------------------
Andrea Valle
--------------------------------------------------
CIRMA - StudiUm
Università degli Studi di Torino
--------------------------------------------------

"This is a very complicated case, Maude. You know, a lotta ins, a lotta outs, a lotta what-have-yous." 
(Jeffrey 'The Dude' Lebowski)

On Nov 12, 2013, at 3:22 PM, Dan Stowell <danstowell+sc3@xxxxxxxxx> wrote:

2013/11/12 Scott Wilson <i@xxxxxxxxxxxxxx>:

On 12 Nov 2013, at 13:42, Bovermann Till <till.bovermann@xxxxxxxx> wrote:

(2) What about (officially) extending an existing state of the art
programming language such as Ruby ( https://www.ruby-lang.org/en/ ) or
_javascript_ with
(a) guaranteed realtime waiting (as crucial for musical tasks) and
(b) synthdef generation?

I have the feeling that Ruby is pretty close to SClang, however it lacks
both the rt features and the extensive music-oriented library of SC.


Be aware that those languages (or individual implementations of them) may or
may not be realtime friendly.

Indeed. Ruby is surprisingly SC-like (although I would favour Python)
but I believe neither is true-realtime-friendly (Python for sure, cos
of its gc and its global-interpreter-lock).

Personally I do agree with Till's assertion that we'd gain greatly by
piggybacking on an existing language, as long as it was a decent one.
Note that there are some existing possibilities already in overtone,
scalacollider etc... they don't have an sclang feel though.
Piggybacking on _javascript_ is a tempting idea given the way the future
is currently looking. (cf <http://flockingjs.org/>)

Dan

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/