Similarly, we have a Circus Open Mic in Seattle (https://www.facebook.com/events/533760116677373/) where ground rules are that admission is free and open to the public but it's generally a supportive and in-community audience. We've had comedians, magicians, aerialists, acrobats, jugglers, extremely weird people, clowns, and strip history lessons.
I present both of these as ideas for ways to develop and grow without being subject to eternal Google search indexing and YouTubing by random civilians. I think both of these seem to come down to controlling the venue and rules. If you experiment in a bar or club, you're in the wild.
We do these in theatres, black boxes, and dance/performance spaces. This allows us to control the door.
We solve this problem in Clown Jam by essentially just being audience for each other. It's open to anyone who wants to come practice but no one is a "civilian" and there are reasonable person ground rules about posting pictures and video.
I can't read APL but perhaps that is readable. I'm unsure that other common dynamic languages like Ruby or Python are readable purely in comparison purely for using http://en.wikipedia.org/wiki/COBOL#Verbose_syntax.
Well, the problem here is that C using gems are going to often be memory corruptingly buggy until and unless either the gem source is updated to declare the proper parts volatile or Ruby's own C API is reworked to evolve this bug out of existence and then gems would have to be updated to use the API anyway.
Both problems are hard and the current state of affairs is apparently some random amount of the time we'll get memory corruption bugs.
Right now, doesn't the GC traverse the entire heap and keep all objects where the memory's value looks like it might possibly be a pointer to some other object in memory?
This certainly isn't an awesome solution but couldn't the GC backtrace(3) the current process and look at %eax at all C stack frames to additionally include that value in the "pointers currently plausibly in flight" list?
A fairly commonsensical approach is to just require all extension authors to annotate their code properly. At some basic level, this happens with Perl with its oft-maligned DSL for generating C code that happens to do all the right declarations. You might then end up writing your code using more macros. It's certainly not pretty but it is sound.
A plausible rewrite of that function in an XS for ruby would leave the function declaration and wrapper code up to your equivalent of xsubpp to execute your DSL and transform the wrapped code to fully functional C. If you build a C using extension from Perl, you'll find an XS file like http://cpansearch.perl.org/src/SIMON/Devel-Pointer-1.00/Poin... which during the `perl Makefile.PL && make` step is transformed via `xsubpp Pointer.xs > Pointer.c` and then compiled as normal C.