On 10/21/06, Mark Phippard <email@example.com> wrote:
> firstname.lastname@example.org wrote on 10/19/2006 01:37:34 PM:
[ snip summary of arguments made for changing languages ]
> > So, the way I'd propose doing this would be to start making use of Lua
> > for our higher level language. Now this may seem a little weird,
> > since we don't even have Lua bindings at the moment, and most of you
> > have probably never used it, but bear with me here. Lua is a
> > scripting language that's designed to both embed C code (i.e. call
> > into C libraries, like we do with the bindings today) and be embedded
> > within C code (i.e. act as an embedded scripting language for a big
> > application, this is actually done within things like World of
> > Warcraft and other similar games). With decent Lua bindings for the
> > lower level performance critical parts of the application, we could
> > fairly easily implement chunks of the application in Lua, while still
> > providing a C interface that would enable us to build bindings for
> > other languages.
> I have to admit that I do not "get this". Not so much this specific
> proposal, but the whole idea of changing languages. What are the problems
> caused by the current language choice that would be solved by a new
> language? They likely exist, but I do not recall them being discussed
> publicly (maybe on IRC??) very often. How do you know that you are not
> trading one set of *known* problems for a new set of *unknown* problems?
> Changing languages seems like it could be one of those collosal blunders
> that eventually kills the project.
> I have some practical concerns. How are you going to provide good Java
> (or other language) bindings if the code is in Lua or Python or Ruby? How
> does something like TortoiseSVN make use of the code?
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.
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
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.
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)]
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 21 16:09:45 2006