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

[brianlheim@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.

What are some specific features or classes that would make life better here?

> - you can execute code live, but you have to restart the interpreter over and over again when you're editing classes.
> - the class library is flat, and there's no way to selectively import quarks. [...] every extension dumps its classes into a global namespace.

I have spent some time thinking about how an importing system could work in SC. R and Python are the languages whose importing I'm familiar with, although I think python's importing machinery is a bit heavier than what most people need.

I think for it to be really effective you would need to introduce both importing and namespacing at the same time. Both are important features, but introducing import without namespacing is likely to cause issues if you try to introduce it later.

An obvious choice for namespace notation is :: (used in C++ and R, and AFAICT not reserved in SC):

import GUI;

w = GUI::Window();

and then for putting namespaced items into global scope:

import GUI::*;

w = Window();

I think this is generally how I imagine this looking in common usage. How the features are implemented is an entirely different conversation.

-Brian

On Mon, Dec 25, 2017 at 1:36 PM, <nathan@xxxxxxxxxxxx> wrote:

On 2017-12-25 09:59, stefaan.himpe@xxxxxxxxx wrote:

Sclang has a lot of incredibly good stuff to offer but sometimes it makes me
curse. Without wanting to sound too negative, here are my top 5 pet peeves
with sclang in supercollider.

Feel free to add your own, or bash mine (or ignore the post altogether) :)

1. Order of mathematics operations. I understand it's an OO thing, but I
have shot myself in the foot too many times with this already. For a
language that is somewhat math-centric to adopt "alternative conventions" is
rather evil. [Read: apparently it's hard to unlearn old habits].
2. Having to declare all variables at the beginning of a function. It works
miracles for unreadability and breaking the flow.
3. The lack of an Sclang debugger - breakpoints, watch, ... those kinds of
things. Debugging code based on postln is entirely possible, but can be
frustrating, especially in combination with point 2.
4. Calling add on an array returns a new array instead of adding to the
existing one. I understand it has its advantages for chaining operations
etc. This, admittedly, is mostly a matter of me having to get used to the
conventions again.
5. No number five! I told you I'd keep it positive :D

hi stefaan,

i'm going to recycle an older post of mine. here are in my opinion the most serious flaws in sclang:

- it's slow.
- a lot of built-in functionality in the class library and interpreter prints a lot of crap to the post window that can't be suppressed. it gets in the way of any post output you actually want to see. (also maybe such messages should be going to stderr?) running our unit test system illustrates how bad this has gotten. probably worst of all, it compounds with your point 3.
- 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.
- you can execute code live, but you have to restart the interpreter over and over again when you're editing classes. yes, i've heard of ddwProto and it's nice, but a quark doesn't erase a quirk.
- the class library is flat, and there's no way to selectively import quarks. one bad quark can break the interpreter. every extension dumps its classes into a global namespace. if a naming conflict happens at some point between two quarks maintained by third parties, you're dead in the water and have to modify one of them. whoops, there goes portability.

yeah, the "var" thing is no fun, but Brian's work on the lexer/parser/compiler regression tests has made that much more likely to be improved in the future :)


nathan

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