On Mon, Sep 23, 2013 at 2:20 PM, Patrick Donnelly <batrick@xxxxxxxxxxxx> wrote:
> On Mon, Sep 23, 2013 at 2:53 PM, Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
>> Yes, but that's not what the words said, the words said 'lua
>> integration' and 'ruby integration' would take that much. Either way
>> it doesn't matter, shared libraries exist for a reason. We don't need
>> to statically compile openssl do we? No? Good.
>
> Uh, you're willfully ignoring the conversation about avoiding
> dependencies. One way to do that is to include and statically link Lua
> along with Git. The cost of doing that is 200kb. I know this because I
> actually do it for Nmap.
Dependencies are avoided when it's possible and sensible to do so.
Yet, we still depend on a bunch of things.
My proposal to replace perl/shell with ruby would actually remove two
dependencies and add one, so in effect would remove one dependency. Of
course, people could still build with NO_RUBY=y, just like they can
build with NO_PERL=y, and deal with the consequences.
>>>> IMO the problem with lua is that it's too simple, it's syntax doesn't
>>>> resemble c, perl, python, shell, or ruby, it's just weird. Also, it's
>>>> much less popular, it's not as powerful, and there isn't a big
>>>> community involved with Git like with Ruby.
>>>
>>> *sigh*. At this point you've really cemented your purpose here as a
>>> language evangelist. It's unfortunate I have to reply to dismiss this
>>> FUD (which you complained about earlier, ironically) otherwise
>>> community accepts it as fact ("oh, I remember some guys saying Lua was
>>> a language for idiots...").
>>
>> I dismissed the claim as FUD, when the conclusion was exaggerated, and
>> there was no evidence in sight.
>>
>> When I say Ruby is a superior alternative, I provide evidence.
>
> You have provided *no* evidence.
I have, you just chose to ignore it.
>>> Lua is by no means *simple*. Try "small" or "lightweight". Its syntax
>>> is engineered to be readable and amateur friendly. You've placed Ruby
>>> on a pedestal alongside those other major languages but its syntax
>>> doesn't resemble any of those.
>>>
>>>>Also, it's much less popular
>>>
>>> https://sites.google.com/site/marbux/home/where-lua-is-used
>>>
>>> The hallmark of a good embedded language is your users don't even know
>>> it is there.
>>
>> Users don't even know in what language those projects are programmed,
>> that's irrelevant.
>
> *Absolutely relevant*: as normal git user *never* wants to know, care,
> or be exposed to the details of how `git` operates.
So? Before and after this patch they still wouldn't be exposed.
This is a total red herring.
>> If MediaWiki does indeed use Lua, it must be a tiny
>> fraction of it.
>
> They just started using it. Well done cherry-picking 1 example from a
> host for your dismissal.
I didn't cherry pick anything, I used the project I'm more familiar
with, replace MediaWiki with any other of your examples, and the claim
still stands.
>>>> it's not as powerful,
>>>
>>> This is really funny to me. Despite Lua's small size, it has lead the
>>> way for modern dynamic language features, such as coroutines, block
>>> level scoping and real closure, incremental GC, a simple and usable C
>>> API (*yes* this is a feature), and a register based VM [1]. It is
>>> consistently placed as the *fastest* dynamic language in existence
>>> [e.g. 2]? The LuaJIT compiler often achieves competitive or better
>>> performance than C [3]. What about this isn't powerful?
>>
>> Talk is cheap, show me the code.
>>
>> Do what I did. Add lua bindings for several C functions, replace a
>> script with a Lua script (like git request-pull), replace a major
>> builtin (like git reset), and show how this succinct example I
>> provided in Ruby would look like:
>>
>> cb_data = 'foo'
>> for_each_ref() do |name, sha1, flags|
>> puts '%s: %s: %s' % [cb_data, name, sha1_to_hex(sha1)]
>> end
>>
>> Let's see how it looks.
>
> I address your performance claims, you dismiss them and then ask for
> code to compare? Code which is primarily bindings to C which does all
> the work? No thanks, that circle jerk doesn't interest me.
I didn't make any performance claims, you made claims about being a
powerful language, well, let's see how powerful it is.
Ruby is so powerful I was able to write these patches with moderate
effort, surely if Lua is so powerful you can do the same.
>> Until you do that, I'd say you are the one that is language
>> evangelizing, I'm providing an actual real solution to a very
>> important problem.
>
> As mentioned elsewhere, the solution Git is using is to move porcelain
> commands to C. You're manufacturing problems and spreading FUD.
This effort has no end in sight, and as I've explained, using Ruby as
an interim solution would actually speed up the move to pure C.
In fact, I would know much more about the impediments since I sent
twenty eight patches to start replacing 'git rebase' with C code:
http://thread.gmane.org/gmane.comp.version-control.git/233396
They got rejected without so much as a reply. Why if it's so important
to move the scripts to C did these patches get ignored? Because it's
not. None of the core developers are interested in this, because they
don't use Windows, so it's not a priority for them.
> I'm letting this thread die as I only wanted to confront your baseless
> dismissal of Lua. If you want to continue this, I'll do it offlist.
Until you, or anyone, shows me the code, I'll continue to dismiss Lua,
or any other proposed solution.
I know doing what I did in Ruby would be very difficult in Lua, or any
other language for that matter, which is why I ask you to actually do
it, because I know you won't do it, because it's hard, which proves my
point.
I've proved other people wrong on this list by writing the code, if
you are not willing to walk the talk, then there's no point in
discussing. Even if I were to agree that Lua is a better option (which
I'm not), what have we achieved? Nothing. Who is going to implement
that? Not you, not me... So?
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html