[#3986] Re: Principle of least effort -- another Ruby virtue. — Andrew Hunt <andy@...>

> Principle of Least Effort.

14 messages 2000/07/14

[#4043] What are you using Ruby for? — Dave Thomas <Dave@...>

16 messages 2000/07/16

[#4139] Facilitating Ruby self-propagation with the rig-it autopolymorph application. — Conrad Schneiker <schneik@...>

Hi,

11 messages 2000/07/20

[ruby-talk:04267] Ruby.next, Perl6, Python 3000, Tcl++, etc. -- Any opportunities for common implementation code?

From: "Conrad Schneiker" <schneiker@...>
Date: 2000-07-29 20:46:17 UTC
List: ruby-talk #4267
Hi,

While listening to a performance of List's piano transcription of
Beethoven's 6 symphony, I thought of combining the following themes of (1)
open source, (2) "there's more than one way to do it", (3) a suggestion that
Perl6 consider supporting multiple syntaxes, and (4) the MS .net idea of
common multi-language-friendly support libraries.

Given that Perl6 looks like it will be the next big rewrite to occur in the
Perl, Ruby, Python, Tcl, etc., range of languages, would it be possible to
do this in such a way that there could be a common core of libraries that
could be used by the next generation of all of these languages? Would a
common Unicode regular expression processing library be possible? I think
everyone who isn't using mark and sweep garbage collection will want to
eventually do so, so maybe there is something here that could also be
factored out into a common implementation library. Maybe likewise for
bytecode generation and packaging programs into single self-contained
executables.

Would a common generalized interface for doing C-extensions be feasible to
do in a way that would be mutually satisfactory to Perl6, Ruby.next, and
Python 3000? This would further make possible for language-specific modules
to share their underlying C code

Such a development might have other interesting synergies. For example, Tk
development seems to have preceeded at a snail's pace for the last several
year. If Tk provided an interface following a new standard common extension
mechanism, perhaps more of the effort that has previously gone into
<whatever>/Tk or <whatever>/<non-Tk-portable-GUIs> would go into Tk itself,
to everyone's mutual benefit.

I'm not sure if any of the above ideas are feasible and desirable, but if
anyone can think of some way to render them such, we have a brief window of
opportunity that may not reoccur for many years. For convenience of
reference, we might call such a system "osl.net" (for open source
languages). Some organizations such as O'Reilly and ActiveState already have
overlapping interests in Perl and Python, and so might have some natural
interest in promoting osl.net, if it were feasible.

Conrad



In This Thread

Prev Next