On 10/21/06, Erik Huelsmann <ehuels@gmail.com> wrote:
> Ah, but that's why Garrett is explicitly rejecting Python, Ruby or
> Perl as a higher level language. Interfacing with Python is (in my
> personal experience) a big pain.
>
> Lua is designed to be easy to interface with, both to call into from
> anything that supports C interfaces as well as that it supports
> calling into C (or anything that can support C interfaces) itself.
Exactly.
> Reading on the Lua site, it supports OO as well.
>
> > When all is said and done, I do trust the committers, and that they are
> > going to take all of this into account before making any decision. If you
> > think you can write better, faster code in Lua and it is all still easy to
> > use from language bindings and TortoiseSVN etc.. then I trust you. I just
> > do not really see what we are not doing now with Subversion because of the
> > language choice.
>
> > If people really think that C is holding them back, maybe they should
> > spend some time with the JavaSVN code to see if it proves or disproves
> > this notion? It is a good chunk of the Subversion code written in an OO
> > language. While Java is likely a non-starter for a language change, the
> > fact that the JavaSVN code exists and is at the 1.4 level might make it a
> > good proving ground for testing what applying OO concepts can do. There
> > are some enhancements over the Subversion API that have been made in
> > JavaSVN, so perhaps there is some validity to the language holding things
> > back?
>
> Well, given that the merge-tracking branch -after months of
> development- is not much more than svnmerge.py in C, I do understand
> some people feel they need to be able to write higher level
> constructs, not worrying about memory management and other things that
> have been invented and implemented several millions of times before.
Yep, that's basically what I'm thinking. I mean look at what JavaSVN
has done with less programmers than us and in less time. Sure, some
of that is because we paved the way for them, but some of it is just
features they've added that we haven't yet. Or take a look at SVK.
Whatever complaints you have about Perl, you must admit that it's
allowed fewer programmers to move faster than we have in many ways.
> So, that's what I understand from the background. I too however have
> my concerns. From one of the papers on the Lua site: "All statements
> in Lua are executed in a global environment, which keeps all global
> variables and functions. This environment is initialized at the
> beginning of the host program and persists until its end." This
> sentence seems to conflict (badly!) with our opinion that our
> libraries are to be thread safe: global variables generally are not,
> as is the global interpreter resource. Or is the article outdated?
> [Lua-an extensible extension language (http://www.lua.org/spe.html)]
You can run multiple instances of the Lua VM if you wish to, each of
which is completely separate from the rest.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 17:23:27 2006