From: Felipe Contreras <felipe.contreras@gmail.com>
To: Patrick Donnelly <batrick@batbytes.com>
Cc: Fredrik Gustafsson <iveqy@iveqy.com>,
"brian m. carlson" <sandals@crustytoothpaste.net>,
git@vger.kernel.org, Ramkumar Ramachandra <artagnon@gmail.com>
Subject: Re: [PATCH/RFC 0/7] Support for Ruby
Date: Mon, 23 Sep 2013 13:53:49 -0500 [thread overview]
Message-ID: <CAMP44s2DfdqCLnp=CGf2O4tWi8LkoV=J2GTJiRORUGQjyrBnhg@mail.gmail.com> (raw)
In-Reply-To: <CACh33FpP_Afb-9eke8m282saUZEDA_ZVbUQvKc6R3EF3P1ZvTA@mail.gmail.com>
On Mon, Sep 23, 2013 at 1:20 PM, Patrick Donnelly <batrick@batbytes.com> wrote:
> Hello Felipe,
>
> On Sun, Sep 22, 2013 at 4:29 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Sun, Sep 22, 2013 at 3:12 AM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
>>> And see my humble test of what the speedup would be for git-submodule
>>> even with a faulty lua integration (still forking... but huge
>>> performance boost anyway):
>>> http://thread.gmane.org/gmane.comp.version-control.git/228031/focus=228051
>>
>> I don't see how that is relevant, but I'm certain the same can be done
>> with Ruby.
>>
>>> As you can see a lua integration would increase the git binary with
>>> 300kb.
>>
>> And my patch would increase it 49Kb.
>
> Unless you statically compile in Ruby (which is what the above quoted
> 300kb implied for Lua, in actually it is less than 200kb). [Also good
> luck statically compiling Python/Ruby into an executable.]
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.
>> 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.
> 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. If MediaWiki does indeed use Lua, it must be a tiny
fraction of it.
Lua is #25 in the tiobe index with 0.518%, Ruby is #13 with 1.382%,
right next to Perl. Ruby is 54 times used more in GitHub than Lua.
These are the numbers I have, if you have other numbers, please, share
them.
>> 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.
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.
--
Felipe Contreras
next prev parent reply other threads:[~2013-09-23 18:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-21 18:48 [PATCH/RFC 0/7] Support for Ruby Felipe Contreras
2013-09-21 18:48 ` [PATCH/RFC 1/7] Add support for ruby commands Felipe Contreras
2013-09-21 18:48 ` [PATCH/RFC 2/7] ruby: add setup script Felipe Contreras
2013-09-21 18:48 ` [PATCH/RFC 3/7] ruby: add simple wrappers Felipe Contreras
2013-09-21 18:48 ` [PATCH/RFC 4/7] ruby: rewrite 'request-pull' Felipe Contreras
2013-09-21 18:48 ` [PATCH/RFC 5/7] ruby: rewrite perl script Felipe Contreras
2013-09-21 18:48 ` [PATCH/RFC 6/7] ruby: remove one fork Felipe Contreras
2013-09-21 18:48 ` [PATCH/RFC 7/7] ruby: rewrite 'reset' Felipe Contreras
2013-09-21 21:29 ` [PATCH/RFC 0/7] Support for Ruby brian m. carlson
2013-09-21 22:52 ` Felipe Contreras
2013-09-21 23:56 ` brian m. carlson
2013-09-22 5:36 ` Felipe Contreras
2013-09-22 7:31 ` Fredrik Gustafsson
2013-09-22 7:43 ` Felipe Contreras
2013-09-22 8:12 ` Fredrik Gustafsson
2013-09-22 8:29 ` Felipe Contreras
2013-09-23 18:20 ` Patrick Donnelly
2013-09-23 18:53 ` Felipe Contreras [this message]
2013-09-23 19:20 ` Patrick Donnelly
2013-09-23 19:47 ` Felipe Contreras
2013-09-23 0:00 ` Junio C Hamano
2013-09-23 1:41 ` brian m. carlson
2013-09-28 22:57 ` Felipe Contreras
2013-09-23 18:17 ` Felipe Contreras
2013-09-28 22:56 ` Felipe Contreras
2013-09-28 23:06 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMP44s2DfdqCLnp=CGf2O4tWi8LkoV=J2GTJiRORUGQjyrBnhg@mail.gmail.com' \
--to=felipe.contreras@gmail.com \
--cc=artagnon@gmail.com \
--cc=batrick@batbytes.com \
--cc=git@vger.kernel.org \
--cc=iveqy@iveqy.com \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).