@trogluddite said:
Maybe Ruby just makes it too easy? - folks using the more typical C SDKs of other applications have to work a lot harder to make robust add-ons, and things like thread safety etc. have to be considered and accommodated within their designs. Comparatively, wrapping everything in a module, and not messing with the kernel, is really not much to expect - anyone who can understand the API doc's should have no trouble understanding those things too.
The Ruby 'gurus' and mod's do a great job of advising us noob developers, but cannot force amateur dev's to heed their warnings. The techniques involved are not terribly complex (even I understand them!), and I have no problem with developers who consistently refuse to take good advice being censured for the ill effects that their plugins can cause.
To start, many thanks to the moderators for all your work to keep sketchUcation a friendly and useful place!
Personally, I think that the quarantine area is a good idea. Perhaps all plugins should go initially into quarantine until enough members weigh in to confirm that the plugin is safe? That might reduce the workload on the moderators. But certainly there should be VERY LOUD warnings to make it as hard as possible to ignore the fact that known bad plugins are bad. I also agree that if the original author doesn't respond to requests to clean up his code, it should be s#&$-canned - maybe with a residual warning for anyone who downloaded it previously. Our life situations change, and maybe the author no longer has time to devote to SketchUp, but one shouldn't be allowed to post something for free and then just walk away.
Much of the Ruby discussion reminds me of issues that were heatedly debated when weakly-typed, interpreted (i.e. scripting) languages rose to popularity. Those accustomed to strongly-typed, compiled languages opined that it would never be possible to be sure that a program would work, since classes and objects could be arbitrarily modified at any time by code outside the original source files. Despite these objections, in part because of the great power they add via extensibility, scripting languages are now widely used - most of the time, without all the terrible issues that the pundits predicted. But, along comes the occasional troublemaker or naif...
As others have noted, Ruby was deliberately designed so that even the core classes and modules can be modified on the fly by anyone. There are a few situations in which this capability is necessary. The Developer Console and TestUp code on GitHub is an example. They rely on overriding the builtin puts() to trap output from Ruby code (aside: that's all they trap. I added overrides to p, print, printf, and putc in my version because I have scripts that do more formatting than puts). But aside from those kinds of system utilities, I would claim it is never necessary or appropriate to modify the standard libraries. Instead, you derive a subclass, add your override there, and use that instead of the standard class in your code. It's done that way all the time in strongly-typed languages such as C++.
When the SketchUp developers chose Ruby as their extension language, they bought into its mutability along with the rest of Ruby. It seems to me that an outside effort to "undo" this aspect of Ruby would be highly likely to create as many new problems as it solved! Moderators, unless it simply fascinates you, I would put your energy elsewhere!
Steve
2012 Trimble Navigation Limited]