std.getopt suggestion

[kennytm]

Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
> On 10/5/11 6:53 AM, Regan Heath wrote:
>> On Tue, 04 Oct 2011 20:39:42 +0100, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>> Did it ever prevent you from getting anything done with it?
>> 
>> That's not the question we should be asking. The question we should be
>> asking is, will anyone ever want to re-use getopts parser for something
>> other than a once off command line parse for a command line application.
> 
> I don't think yours is the right question either. This thread has become
> illustrative of a trend that would be great to change course a bit. I
> sustained my position in this thread longer than necessary in an attempt
> to explain this to me and others.
> 
> Let me give a little context. This summer there was serious talk about
> using D at Facebook for a project that would last three months in
> development. D fulfilled all requirements, but had problems with library
> availability. For example, I was asked about D's connectivity to OpenSSL
> and MySQL. I told them they can translate the appropriate C headers
> manually or semi-automatically. They looked into it but they gave up
> because they saw this effort as a foreshadow of several other missing
> libraries. The barrier of entry for using OpenSSL or MySQL in Python is
> very low. The project was written in Python.
> 
> A friend of mine, startup owner, read TDPL cover to cover and loved it.
> Then he did some more research and spent $7000 on a top-of-the-line
> machine to run his service-based application, written in Python. This is
> because he figured he has a lot of libraries already available for Python
> that will accelerate his productivity, and estimated that for his
> projected load he can compensate the speed difference. "Not everybody is
> Google, Facebook, or Yahoo", he said.
> 
> There are other similar stories; these are the most recent I remember. We
> now have the GNU integration to get busy with, and we need a host of
> other APIs that connect us to the world. The right question is, can we
> afford to discuss packing three globals into one struct in std.getopt at this time?
> 
> Making working code a tad better could go on forever, and might seem like
> progress. But it's not - it's asymptotic progress towards a local
> optimum, while we're looking at a hill of potential ahead.
> 
> I kindly suggest anyone with an interest in D's future to focus on moving
> the big rocks. We can worry about the gravel and the sand later.
> 
> 
> Thanks,
> 
> Andrei

I don't buy this. You make it sounds like the community cannot contribute
with more than 1 focus concurrently. The fact is that, the GCC integration,
making wrappers of C library and switching to non-global in std.getopt are
done in parallel by different subgroup of interests. I doubt if GDC will be
locked out of GCC or people will stop writing D wrappers just because 3
globals are proposed to be removed.