On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
>
>> Whatever, anyway.
>
> Translation of that being:
>
> "Boring pedestrian issues like simple string logging are bikeshedded for YEARS, yet PhD-level esoteric stuff makes it into phobos with relative ease."
>
> https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md
>
> cautios and determination, isn't? or, revolutionary and conservative, how I did put it...

+1

At least decisions are finally being made on several fronts recently though.

W.r.t this feature, I was personally looking forward to it ... guess I'll stick with the Octave/R/Python "troika" for rapid protoyping numerical analysis code.

On Sunday, 1 February 2015 at 10:00:38 UTC, uri wrote:
> On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
>>

> W.r.t this feature, I was personally looking forward to it ... guess I'll stick with the Octave/R/Python "troika" for rapid protoyping numerical analysis code.

Unfortunately for D, many of the wannabe users reach similar conclusions in the end...

On 2/1/15 1:54 AM, eles wrote:
> On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
>
>> "Boring pedestrian issues like simple string logging are bikeshedded
>> for YEARS, yet PhD-level esoteric stuff makes it into phobos with
>> relative ease."
>
> At least for me, this was a valuable English lesson. I had never quite
> grasp the meaning of "being fed up" before.

Well I don't know what to say. I agree with some of your points but not with most. It's a bummer you are being frustrated, but I know it's impossible to please everyone and I'm not sure how we can convert your frustration into something productive. -- Andrei

On 2/1/15 2:00 AM, uri wrote:
> On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
>>
>>> Whatever, anyway.
>>
>> Translation of that being:
>>
>> "Boring pedestrian issues like simple string logging are bikeshedded
>> for YEARS, yet PhD-level esoteric stuff makes it into phobos with
>> relative ease."
>>
>> https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md
>>
>> cautios and determination, isn't? or, revolutionary and conservative,
>> how I did put it...
>
> +1
>
> At least decisions are finally being made on several fronts recently
> though.
>
> W.r.t this feature, I was personally looking forward to it ... guess
> I'll stick with the Octave/R/Python "troika" for rapid protoyping
> numerical analysis code.

Which feature are you referring to? -- Andrei

On Sunday, 1 February 2015 at 10:00:38 UTC, uri wrote:
> On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
>>

>
> W.r.t this feature, I was personally looking forward to it ... guess I'll stick with the Octave/R/Python "troika" for rapid protoyping numerical analysis code.

Because static arrays are not convenient enough to use, I'll have to use another language that does not even provide static arrays. Makes sense.

On 1 February 2015 at 09:46, eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> Whatever, anyway.
>
>
> Translation of that being:
>
> "Boring pedestrian issues like simple string logging are bikeshedded for YEARS, yet PhD-level esoteric stuff makes it into phobos with relative ease."
>
> https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md
>
> cautios and determination, isn't? or, revolutionary and conservative, how I did put it...

What I read in that link is:

I would have tried again... I was out of patience and energy... I didn't want to hack on DMD...  (I made up the last quote)

Nothing happens if you lack any desire to work.

On Sunday, 1 February 2015 at 09:20:11 UTC, eles wrote:
> but the grounds that I was criticizing were not this ones. were the grounds of "it ma be done otherwise, just look at this nice bed-of-nails syntax"!

Yeah, I agree that the library solution for what should be builtin makes no sense.

In language design it is often a good idea to prototype potential language features as a library solution first, but not in the standard library...

On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu wrote:
> I know it's impossible to please everyone and I'm not sure how we can convert your frustration into something productive. --

How about designing the language before implementing it? Then one can discuss the design, rather than the implementation...

Talk is cheap as you like to point out... So talk more before starting on a new cycle, and save the expenses for what is worth "paying" for.

On Sunday, 1 February 2015 at 15:46:44 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 1 February 2015 at 09:20:11 UTC, eles wrote:

> Yeah, I agree that the library solution for what should be builtin makes no sense.

Yet, there is such a bias for over-appreciating the library features... an overappreciation that I fail to understand or see benefits of it beyond a certain point.

I guess it has to do with orthogonality or with the "easy-implementation" of the language.

All this wile forgetting that as long as the elephant in the room is the GC, all other things combined matter less.

On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu wrote:
> On 2/1/15 1:54 AM, eles wrote:
>> On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
>>

> Well I don't know what to say. I agree with some of your points but not with most. It's a bummer you are being frustrated, but I know it's impossible to please everyone and I'm not sure how we can convert your frustration into something productive. --

One thing that the library-auto solution does not provide is the *granularity* of what I ask the compiler to infer.

I want the compiler to infer some things, like the length of the static array, but not others, like the type of the elements.

What if I want to go from

float[$] = [1.09, 1.1];

to

int[$] = [1, 1];

but instead I make a mistake and I write:

int[$] = [1, 1.1 /* note that I forgot to drop the decimals here */ ];


The "auto" will give me a floating point array, the program might work for a while, than unexpected bugs start arising.

Propensity for bike-shedding behind the covers of intellectual refinement puzzles me.