| 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.
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)
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/
|