On 3/13/2015 7:51 AM, Chris wrote:
> Also, sometimes I have the impression that people use any excuse not to use D.

I've learned to be careful when people say "I can't use [insert your product] because of X." All too often, it isn't X at all. I discovered this by addressing the problem, and going back to the person and saying "X is solved", and they just kind of mumble a bit and say "that's great, but I still can't use it because of Y."

(Ironically, they'll often be using Product Z that also has flaw X and Y.)

In other words, X and Y are not the real reasons. The real reason may be something that isn't too palatable to say, so they look around for a real or imagined flaw, something that is more presentable, and say that.

It's important for us to find the real reasons, instead of chasing pots 'o gold at the end of rainbows.

On 3/13/2015 10:31 AM, Andrei Alexandrescu wrote:
> For example the expression (assuming s is e.g. a string)
>
>    File("/tmp/a").byChunk(4096).joiner.startsWith(s)
>
> opens a file, progressively reads chunks of 4KB, stitches them together at no
> cost, compares against a prefix until it makes a decision, then closes the file
> and returns the result. A putative Go user wouldn't even dream of using
> HasPrefix directly on a stream coming from a file; the whole endeavor would be a
> function that painstakingly takes all of these steps by hand.
>
> We need to take the "disconcerting" out the documentation equation while still
> exposing the power. s1.startsWith(s2) is perfectly apt for two strings, and that
> should be immediately apparent to someone who just needs that.

I suggest putting that snippet in the documentation as an example!

On 3/13/2015 10:35 AM, Andrei Alexandrescu wrote:
> One issue I see here is that it's difficult to group together functions with
> slightly different names but related functionality (e.g. findSplit,
> findSplitBefore, findSplitAfter).

That's what

  See Also:
       findSplit, findSplitBefore, findSplitAfter

is for.

On 3/13/2015 8:18 AM, Florin Mihaila wrote:
> Hi everyone,
>
> I'm the guy who threw the rock in the pond. I should probably
> clarify a few things about the notes (which Andrei posted with my
> permission).

Thank you very much. You've performed an invaluable service for us.

On 3/13/15 12:19 PM, Walter Bright wrote:
> On 3/13/2015 10:31 AM, Andrei Alexandrescu wrote:
>> For example the expression (assuming s is e.g. a string)
>>
>>    File("/tmp/a").byChunk(4096).joiner.startsWith(s)
>>
>> opens a file, progressively reads chunks of 4KB, stitches them
>> together at no
>> cost, compares against a prefix until it makes a decision, then closes
>> the file
>> and returns the result. A putative Go user wouldn't even dream of using
>> HasPrefix directly on a stream coming from a file; the whole endeavor
>> would be a
>> function that painstakingly takes all of these steps by hand.
>>
>> We need to take the "disconcerting" out the documentation equation
>> while still
>> exposing the power. s1.startsWith(s2) is perfectly apt for two
>> strings, and that
>> should be immediately apparent to someone who just needs that.
>
> I suggest putting that snippet in the documentation as an example!

Also: does /tmp/a have /tmp/b as a prefix?

File("/tmp/a").byChunk(4096).joiner.startsWith(
  File("/tmp/b").byChunk(4096).joiner)

I also wonder how efficient that is.


Andrei

On Friday, 13 March 2015 at 15:17:06 UTC, Andrei Alexandrescu wrote:

> There is something loosely related to curb appeal that has been discussed here before. Consider someone just starts with D and wants to figure whether there's a startsWith function in D.
>
> So they google for something like ``dlang startswith''. Nicely enough http://dlang.org/phobos/std_algorithm.html comes up first. (Ideally the individual page http://dlang.org/library/std/algorithm/starts_with.html would come up.)
>
> Anyhow, assuming the user clicks on the former, startsWith is easy to find at the top and then when you click on it...
>
> ====
> uint startsWith(alias pred = "a == b", Range, Needles...)(Range doesThisStart, Needles withOneOfThese) if (isInputRange!Range && Needles.length > 1 && is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[0])) : bool) && is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[1..$])) : uint));
> bool startsWith(alias pred = "a == b", R1, R2)(R1 doesThisStart, R2 withThis) if (isInputRange!R1 && isInputRange!R2 && is(typeof(binaryFun!pred(doesThisStart.front, withThis.front)) : bool));
> bool startsWith(alias pred = "a == b", R, E)(R doesThisStart, E withThis) if (isInputRange!R && is(typeof(binaryFun!pred(doesThisStart.front, withThis)) : bool));
> ====
>
> This in big bold font, too. The HTML way of saying, "you wanted startsWith? I'll give you more startsWith than you can carry." Picture the effect this has on someone who just wanted to see if a string starts with another.

I agree https://issues.dlang.org/show_bug.cgi?id=13676

--
Jacob Carlborg

On Friday, 13 March 2015 at 10:02:02 UTC, Walter Bright wrote:
> On 3/13/2015 2:22 AM, w0rp wrote:
>> I'll never forget what Bjarne said about people wanting a "simple language." His
>> response to "I want a simple language" was, "No, you don't!" Because it's always
>> "I want it to be simple... with just this one extra little feature in it."
>
> Yes. I've often seen posts here from people writing that they wanted stability, and then give a list of new features they want.

Same old strawman again.

there is introduce this completely new feature thta may be good, but ultimately increase the language size and complexity and will come with its set of bugs, and there is introduce feature X, that will complete what feature A, B and C, that are already in, so they can actually provide what they are supposed to without any holes.

Putting the 2 in the same bag is the very reason why we get stuff added or rejected pretty much randomly and never get stable.

On Friday, 13 March 2015 at 19:18:27 UTC, Walter Bright wrote:
>
> It's important for us to find the real reasons, instead of chasing pots 'o gold at the end of rainbows.

I suggest reading something about the lean startup methodology...
It really opens mind about issues like that.
---
Paolo

On Friday, 13 March 2015 at 19:18:11 UTC, Namespace wrote:
> On Friday, 13 March 2015 at 19:11:59 UTC, weaselcat wrote:
>> On Friday, 13 March 2015 at 19:03:29 UTC, Namespace wrote:
>>> On Friday, 13 March 2015 at 19:01:08 UTC, weaselcat wrote:
>>>> On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
>>>>> On 3/13/2015 3:34 AM, bearophile wrote:
>>>>>> "Strict mode" is a D2 with immutable+@safe+pure by default,
>>>>>
>>>>> Note that you can get this largely by starting a module with the following:
>>>>>
>>>>> immutable @safe pure:
>>>>>
>>>>
>>>> As far as I'm aware, there's no way to mark functions impure this way other than lexical location. Am I incorrect?
>>>
>>> There is no way to mark functions impure, mutable or virtual. ;)
>>
>> Is there a reason for this?
>> I currently put @safe: at the top of all of my D files, and use @trusted/@system as needed(i.e, barely ever except for IO.) I'm not sure if it's good practice but I prefer it.
>
> As always: there was many discussions and nothing was decided/done.
> The nearest thing we had (and I'm so proud that the suggestion comes from me :P) was: final(false), pure(false) etc.

This is really something that should be brought up again, it seems like a small change with a big payoff.

On 3/13/15 1:24 PM, weaselcat wrote:
> On Friday, 13 March 2015 at 19:18:11 UTC, Namespace wrote:
>> On Friday, 13 March 2015 at 19:11:59 UTC, weaselcat wrote:
>>> On Friday, 13 March 2015 at 19:03:29 UTC, Namespace wrote:
>>>> On Friday, 13 March 2015 at 19:01:08 UTC, weaselcat wrote:
>>>>> On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
>>>>>> On 3/13/2015 3:34 AM, bearophile wrote:
>>>>>>> "Strict mode" is a D2 with immutable+@safe+pure by default,
>>>>>>
>>>>>> Note that you can get this largely by starting a module with the
>>>>>> following:
>>>>>>
>>>>>> immutable @safe pure:
>>>>>>
>>>>>
>>>>> As far as I'm aware, there's no way to mark functions impure this
>>>>> way other than lexical location. Am I incorrect?
>>>>
>>>> There is no way to mark functions impure, mutable or virtual. ;)
>>>
>>> Is there a reason for this?
>>> I currently put @safe: at the top of all of my D files, and use
>>> @trusted/@system as needed(i.e, barely ever except for IO.) I'm not
>>> sure if it's good practice but I prefer it.
>>
>> As always: there was many discussions and nothing was decided/done.
>> The nearest thing we had (and I'm so proud that the suggestion comes
>> from me :P) was: final(false), pure(false) etc.
>
> This is really something that should be brought up again, it seems like
> a small change with a big payoff.

Yah, we sorely need a way to undo an attribute. BTW "@undo" is short and sweet. -- Andrei