bh:
But I don't understand why you think libraries are a problem. Loading the library with the project does use extra cloud space, but it avoids software rot, which is what happens when a library changes its API in some way that's not compatible with older programs using it.
Mose librarites are good. The problem is ones like bignums and my hashtables library that add data types or replace primative blocks. These should be an extension.
bh:
I guess part of the problem is that we use the word "extension" differently from how Scratch uses it. Their extensions are much like our libraries: an add-on collection of blocks that work with the vanilla Scratch evaluator and UI. To us, an extension is a major rewriting of Snap ! itself, done by someone other than us, and distributed on a web site they maintain. Are you thinking about Scratch-style extensions? If so, I don't understand how we aren't already providing that. When you say that half the people make libraries, and half those libraries "should be extensions," I don't know what that entails.
I meant a fork of GitHub - jmoenig/Snap: a visual programming language inspired by Scratch , including both complete rewrites and also simpler things that add datatypes or edit primitives. Snap! Build Your Own Blocks 6.0.1 - dev - may not t, but most things do.
Another advantage of using forks is that you can have forks of forks, like json is a fork of hashtables is a fork of snap.