content management

[trogluddite]

Yes, I hear what you're saying.
The solution, I think, is that the largest Ruby modules are ideally split down into small functional units - a form of 'primitive', so to speak. That way, there is much less of a need to look inside them - just as we cannot open primitives to see Malc's C++ code.
For the moment, many Ruby modules posted are very 'monolithic' - but that is mostly a consequence of developing the code. It is just simpler when editing/testing to build the code that way, and if the completed Ruby code meets the needs of a current project, it is much extra work to de-construct into simple "tools" - so the temptation is always to post a complete unit as a "fait accompli".

Another problem is that some of the new capabilities that Ruby allows do not interface easily with the 'green' world. For example, arrays in Ruby are incredibly powerful - containing multiple dimensions and mixed data types - but 'green' arrays are so limited in comparison that a "non-Ruby" interface can be nearly impossible to create.
I'm not sure that there is any easy way around that - part of the simplicity of 'visual modular' is the ability to easily see "F", "I", "S", and recognise the type of data and how it will behave. As you say, the "limitations" of green are also a strength in this case - Ruby is almost too versatile, and leaves us with only a generic connector which must rely on accurate documentation before we know how the connector may be used.

But possibly the biggest problem is that, for the moment, there are too few of us developing such things - and many of us are still overwhelmed adapting existing projects and learning all the new skills needed to make the most of Ruby. It may also be true that Ruby is being used even when primitives are a better solution - because 'emulating' the old methods in Ruby is the best way for folks to learn the new methods.
This is easily seen by how few new 'stream' DSP modules are posted recently, and billy's "X11" just about the only 'complete plugin' being developed 'in public'.
It was like this with assembly/DSP in the early days of SM - there was a long period of "maturing" before it reached the point of many "building blocks" being posted.

[tester]

I agree. I think one of "issues" related to ruby is, that there is no list of "target applications" being developed yet. For example - do you see a reason of duplicating functionalities of green prims and some basic modules/solutions? I don't. True potential of ruby is in few cases:

- things difficult (amount of wires is not measure of difficulty) to get via green prims
- things not possible to get in other way than ruby
- things too complex to create via methods other than ruby

Having said that, an open question remains: "okay, so - how we define these little blocks of code? what are they? what (operations) should they do?". Knowing the answer, it's like making functional module packs in old SM ways. What would be good, is a development of abstract (but specific) directions and then concepts to cover with ruby, I guess. For example:

- array vs array operations ("hmm... what list of operations or directions it would be?")
- operations on external content (partial extraction, loading, saving, exchaning, converting)
- randomness, statistics, combinatorics (arrays vs numbers)
- text based operations (like handy dictionaries, coloring, sorting, measuring)
- ...and so on.
- (what types of operations we often do in various areas of interests, software, analysis?)

If we have different interests, then it will be easier to extend that list. That's the initial thought.