On Tue, Nov 14, 2006 at 06:31:50PM -0500, Gregory Maxwell wrote:
On 11/14/06, Chad Perrin perrin@apotheon.com wrote: [snip]
For that matter, I think there are JVM-embedded Ruby and Perl interpreters as well. Might as well allow it all, if you're going to do it that way.
I'd prefer we only have one.. simply because I'd rather have one large base of wikipedians speaking the same language than four fragmented groups. .... But I don't really care which one it is.
In this case, I think the fact that a lot of people will care might reduce the number of people willing to participate, to say nothing of the fact that the way you presented the idea it sounds like the Wikimedia collection of content (and the philosophy of how that content is handled and distributed) would be extended to client-side code. This being the case, it seems inconsistent and exclusionary to only "allow" a single client-side programming language outside of Javascript. Maybe that's just me, though.
Our site is innovative in many ways...(nearly) instant gratification, open access, revision control (never forget), Free Content, low barriers to entry.. etc.. as we step into the realm of executable content we should not abandon all the things that have made us grand.
Thus, my concern about the extension of the philosophy of content to executable content, and being inclusive in terms of interpreted source code that can be used.
We need:
- Can run safely in the JVM.
- Can perform graphics in the JVM, hopefully sound.
- near enough to interpreted (compile at preview would be a bummer :)
Plus new programmers really enjoy the ability to sit at a prompt and type in code). 3) Used in the outside world (we already have one home grown programming language, we don't need another) 4) Is broadly compatible with the JVMs on client systems. 5) Decent libraries for data handling, graphing, etc a big plus.
Agreed on each point, I think. The biggest problems are likely to be a working definition of "safely" and sorting out JVM compatibility on client systems.