On 10/21/06, Mark Phippard <markp@softlanding.com> wrote:
> 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.
No decisions have been made on IRC or in person about this or any
topic. There have been some people talking about how they'd like to
switch to a subset of C++ so that they can take advantage of some of
its features, using objects instead of bending over backwards to
reimplement that functionality in C, etc.
> 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?
Lua can be called from C just as easily as it can call into C. If we
wanted to we could expose exactly the same C API we have now, allowing
things like the Java, Perl, Python, and Ruby bindings to continue to
work.
> 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?
>
> 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?
Sure, that's certainly an issue we'd have to worry about. In this
proposal there would continue to be large chunks of code written in C,
the low level libraries especially, but perhaps even big things like
mod_dav_svn. Using multiple languages would introduce some problems,
there is no doubt, but I'm not convinced that they are insurmountable.
-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:27:36 2006