On 1/9/2014 10:18 PM, Manu wrote:
> Always
> finicky little details that take the most time, and I often find the phobos
> source code more helpful than the docs, which isn't a good sign.
>
> That's my general point. I think there's a lot of room for case study, and
> improvement.

You're right, and I see the same thing when I use ranges.

The only way to tackle it is when running into things, on a case by case basis, submit improvement proposals.

On Sat, 25 Jan 2014 10:15:28 -0000, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> Special cases are pure evil. There's nothing special about strings in this case.

This is a tangent to my suggestion.

I am arguing for domain specific language (aliases) where sensible, not domain specific functions.  If canFind can already handle all the desirable string cases, perfect, but lets alias it in std.string as "contains" so that people find what they expect to find first time and don't get frustrated looking for the correct generic name for the functionality they want.

There are likely other cases where we already have all the functionality in a nice generic function, but people struggle to find it because it has a suitably generic name.

I just want us to lower the bar for beginners coming from other languages like Java and C#.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Monday, 27 January 2014 at 14:27:42 UTC, Regan Heath wrote:
> On Sat, 25 Jan 2014 10:15:28 -0000, Peter Alexander <peter.alexander.au@gmail.com> wrote:
>> Special cases are pure evil. There's nothing special about strings in this case.
>
> This is a tangent to my suggestion.
>
> I am arguing for domain specific language (aliases) where sensible, not domain specific functions.  If canFind can already handle all the desirable string cases, perfect, but lets alias it in std.string as "contains" so that people find what they expect to find first time and don't get frustrated looking for the correct generic name for the functionality they want.
>
> There are likely other cases where we already have all the functionality in a nice generic function, but people struggle to find it because it has a suitably generic name.
>
> I just want us to lower the bar for beginners coming from other languages like Java and C#.
>
> R

I think that is a small short-term learning advantage but huge long-term damage for code readability. Now you suddenly need to not only remember what Phobos can do but also all defined aliases for that stuff.

What could have been awesome is to be able to define such aliases via DDOC so that IDE's can understand them and list in auto-completion, while still putting "real" name in source code. It would have solved discoverability issue without harming naming consistency.

On 1/27/14 6:27 AM, Regan Heath wrote:
> On Sat, 25 Jan 2014 10:15:28 -0000, Peter Alexander
> <peter.alexander.au@gmail.com> wrote:
>> Special cases are pure evil. There's nothing special about strings in
>> this case.
>
> This is a tangent to my suggestion.
>
> I am arguing for domain specific language (aliases) where sensible, not
> domain specific functions.  If canFind can already handle all the
> desirable string cases, perfect, but lets alias it in std.string as
> "contains" so that people find what they expect to find first time and
> don't get frustrated looking for the correct generic name for the
> functionality they want.
>
> There are likely other cases where we already have all the functionality
> in a nice generic function, but people struggle to find it because it
> has a suitably generic name.
>
> I just want us to lower the bar for beginners coming from other
> languages like Java and C#.

I just don't think this scales, though I understand it can sound reasonable before it being tried.

Walter doesn't like writing libraries so when he first defined Phobos' string support he simply took the string functions in Python and Ruby and implemented them. That didn't work well at all, in spite of the functions having the same names and semantics.


Andrei

On Mon, 27 Jan 2014 14:34:30 -0000, Dicebot <public@dicebot.lv> wrote:

> On Monday, 27 January 2014 at 14:27:42 UTC, Regan Heath wrote:
>> On Sat, 25 Jan 2014 10:15:28 -0000, Peter Alexander <peter.alexander.au@gmail.com> wrote:
>>> Special cases are pure evil. There's nothing special about strings in this case.
>>
>> This is a tangent to my suggestion.
>>
>> I am arguing for domain specific language (aliases) where sensible, not domain specific functions.  If canFind can already handle all the desirable string cases, perfect, but lets alias it in std.string as "contains" so that people find what they expect to find first time and don't get frustrated looking for the correct generic name for the functionality they want.
>>
>> There are likely other cases where we already have all the functionality in a nice generic function, but people struggle to find it because it has a suitably generic name.
>>
>> I just want us to lower the bar for beginners coming from other languages like Java and C#.
>>
>> R
>
> I think that is a small short-term learning advantage but huge long-term damage for code readability. Now you suddenly need to not only remember what Phobos can do but also all defined aliases for that stuff.

No, you really don't.

If you're writing string code you will intuitively reach for "substring", "contains", etc because you already know these terms and what behaviour to expect from them.  In a generic context, or a range context you will reach for different generic or range type names.

Likewise when reading code you will read "contains" and immediately know what it does, you don't need to remember that it's also called canFind .. why would you care?

Even *if* you decided to compare some string code with some generic code, and the two were actually doing the "same" thing with different calls, you wouldn't have any trouble at all in understanding each and then realising they do the same thing.

> What could have been awesome is to be able to define such aliases via DDOC so that IDE's can understand them and list in auto-completion, while still putting "real" name in source code. It would have solved discoverability issue without harming naming consistency.

I think I would dislike this.. not sure.  Do our docs have "synonyms" in function descriptions.. then at least google would find "contains" on the page next to canFind and you would have an answer.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Mon, 27 Jan 2014 16:19:54 -0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/27/14 6:27 AM, Regan Heath wrote:
>> On Sat, 25 Jan 2014 10:15:28 -0000, Peter Alexander
>> <peter.alexander.au@gmail.com> wrote:
>>> Special cases are pure evil. There's nothing special about strings in
>>> this case.
>>
>> This is a tangent to my suggestion.
>>
>> I am arguing for domain specific language (aliases) where sensible, not
>> domain specific functions.  If canFind can already handle all the
>> desirable string cases, perfect, but lets alias it in std.string as
>> "contains" so that people find what they expect to find first time and
>> don't get frustrated looking for the correct generic name for the
>> functionality they want.
>>
>> There are likely other cases where we already have all the functionality
>> in a nice generic function, but people struggle to find it because it
>> has a suitably generic name.
>>
>> I just want us to lower the bar for beginners coming from other
>> languages like Java and C#.
>
> I just don't think this scales, though I understand it can sound reasonable before it being tried.
>
> Walter doesn't like writing libraries so when he first defined Phobos' string support he simply took the string functions in Python and Ruby and implemented them. That didn't work well at all, in spite of the functions having the same names and semantics.

What specifically didn't work?  All I can recall are UTF and slicing issues, some of which remain with us today.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 1/28/14 3:28 AM, Regan Heath wrote:
> On Mon, 27 Jan 2014 16:19:54 -0000, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> Walter doesn't like writing libraries so when he first defined Phobos'
>> string support he simply took the string functions in Python and Ruby
>> and implemented them. That didn't work well at all, in spite of the
>> functions having the same names and semantics.
>
> What specifically didn't work?  All I can recall are UTF and slicing
> issues, some of which remain with us today.

Problem is what we had was a crappy strings API because it used none of D's inherent advantages. What we have now is much better.

Andrei

On Tuesday, 28 January 2014 at 11:26:39 UTC, Regan Heath wrote:
> No, you really don't.
>
> If you're writing string code you will intuitively reach for "substring", "contains", etc because you already know these terms and what behaviour to expect from them.  In a generic context, or a range context you will reach for different generic or range type names.

Trusting intuition is not acceptable. I will go and check in docs in most case if I have not encountered it before. Check each time for every new aliases. I'd hate to have this overhead. Right now all I need to do is to stop thinking about strings as strings - easy and fast.

>> What could have been awesome is to be able to define such aliases via DDOC so that IDE's can understand them and list in auto-completion, while still putting "real" name in source code. It would have solved discoverability issue without harming naming consistency.
>
> I think I would dislike this.. not sure.  Do our docs have "synonyms" in function descriptions.. then at least google would find "contains" on the page next to canFind and you would have an answer.

They don't have it right now and I propose to introduce it for this very reason.

On Wed, 29 Jan 2014 09:52:01 -0000, Dicebot <public@dicebot.lv> wrote:

> On Tuesday, 28 January 2014 at 11:26:39 UTC, Regan Heath wrote:
>> No, you really don't.
>>
>> If you're writing string code you will intuitively reach for "substring", "contains", etc because you already know these terms and what behaviour to expect from them.  In a generic context, or a range context you will reach for different generic or range type names.
>
> Trusting intuition is not acceptable.

Sure it is, if we're talking about making life easier for beginners and making things more "obvious" in general.  Of course, not everyone has the same idea of obvious, but there is enough overlap and we would *only* define aliases for that overlap.  In short, if people expect it to be there, lets make sure it's there.

> I will go and check in docs in most case if I have not encountered it before. Check each time for every new aliases. I'd hate to have this overhead.

Huh?  Assuming you have a decent editor checking the docs should be as simple as pressing F1 on the unknown function.  And, that's only assuming it's not immediately obvious what it's doing.  Are you telling me, that you would be confused by seeing...

if (str.contains("hello"))

I seriously doubt that, and that's all I'm suggesting, adding aliases for things which are obvious, things which any beginner will expect to be there, and currently aren't there.

I am *not* suggesting we add every obscure name for every single function, that would be complete nonsense.  Lets not get confused about the scope of what I'm suggesting, I am suggesting a very limited number of new aliases, and only for cases where there is a clear obvious expected name which we currently lack.

> Right now all I need to do is to stop thinking about strings as strings - easy and fast.

Sure, once you learn all the generic terms for things.  I *still* have trouble finding the LINQ function I need when I want to do something in the LINQ generic style .. and I've been using LINQ for at least a year now.  The issue is that the generic name just does not naturally occur to me in certain contexts, like strings.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wed, 29 Jan 2014 06:49:30 -0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/28/14 3:28 AM, Regan Heath wrote:
>> On Mon, 27 Jan 2014 16:19:54 -0000, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>> Walter doesn't like writing libraries so when he first defined Phobos'
>>> string support he simply took the string functions in Python and Ruby
>>> and implemented them. That didn't work well at all, in spite of the
>>> functions having the same names and semantics.
>>
>> What specifically didn't work?  All I can recall are UTF and slicing
>> issues, some of which remain with us today.
>
> Problem is what we had was a crappy strings API because it used none of D's inherent advantages. What we have now is much better.

Sure, but it would be better still if the commonly expected names for routines were present.. is all I'm saying.  I am certainly not suggesting we go back to a bad API, I am just saying there are some functions people expect to see, and they're not there, and that is frustrating; perhaps enough to put someone off.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/