firstname.lastname@example.org wrote on 10/19/2006 01:37:34 PM:
> So, one of the contentious topics at the Subversion Summit earlier
> this week was a choice of language for Subversion 2.0. There are many
> people who want to think about things like using some subset of C++
> for parts of the application (the "batons suck damn it, lets have
> objects!" crowd), and many other people who hate C++ with the fires of
> a thousand hells, and just don't want to see that happen.
> Another group advocated (and I'm not sure how serious this was) the
> idea of writing things like the command line client and other tools in
> something like Python, rather than doing so in C. This kind of thing
> would mean that our bindings would get a lot more attention, which
> would be nice.
> I'd like to propose another idea for how we could write parts of
> Subversion itself (not just the command line clients, but actual
> portions of the libraries) in a higher level language, but still
> expose a C level interface to the rest of the world, without dealing
> with the binary compatibility and other issues that come with C++.
> Ideally I'd see us writing the code at the level of libsvn_client in a
> language other than C, and that would call into things like libsvn_ra
> and libsvn_wc. If we went forward with ideas like reimplementing the
> working copy in a newer better faster way, we could decide then if it
> would be written in C or something else.
> 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?
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
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
I assume there are still layers of the code, like mod_dav_svn, that pretty
much have to be written in C. Does anyone see any problems with having
the code written in too many different languages?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 21 15:48:42 2006