we should be making implementation decisions based on what easiest for
users not what is easiest to implement. lots of people know and are
efficient
in Python, i've never even heard of Lua..
On Oct 21, 2006, at 7:09 AM, Erik Huelsmann wrote:
> On 10/21/06, Mark Phippard <markp@softlanding.com> wrote:
>> rooneg@gmail.com 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
>> 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.
>
> 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)]
>
>
> bye,
>
>
> Erik.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 30 04:26:19 2006