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

[nathan@xxxxxxxxxxxx]

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/