On Tue, Feb 26, 2013 at 10:01:59PM +0100, Jacob Carlborg wrote: [.[..]
> Return the date from two days ago:
> 
> Ruby on Rails:
> 2.days.ago
> Date.today
> Time.now
> 
> D:
> Clock.currTime - 2.days
> // Not sure how to do the other two in D
> 
> This is not that bad but it's a bit less intuitive. Here we also have shortening of "current" which just saves three characters, for no reason.

I find the Phobos version more readable, actually. Writing "2.days.ago" is all neat and clever and everything, but the logician in me protests at what all those '.'s are referring to, and they do. Code is not English, and when it pretends to be English, it makes me suspicious that something is subtle going on that I'm not aware of. And when I'm coding, that's something I don't like -- I need to have the assurance I know exactly what's going on. And yes I can learn to parse "2.days.ago" eventually, but it's just additional mental load for only superficial convenience.

But YMMV.


> I think it's mostly std.algorithm that is the problem.
> 
> * reduce - The "reduce" function is really weird. It can't be used as a property. The signature is:
> 
> reduce!(fun)(seed, range)
> 
> When it should be:
> 
> reduce!(seed, fun)(range)
> 
> And:
> 
> reduce!(fun)(range, seed)

IMHO this is just bikeshedding. I actually find Phobos' order more intuitive (to me anyway), because the function you're reducing on, ideally, should be inlined, so it makes sense to pass it as a compile-time parameter, and the seed value is what you start with, so it makes sense to have it appear as the first parameter.

But I can see where UFCS will fail to kick in here, which makes it a bit annoying, I suppose. But reduce was designed before UFCS made it into DMD.


> * No algorithm functions for associative arrays.

Yeah that area needs some work.


> * tap - Ruby has a really nice function, "tap". In D it would look like:
> 
> T (func, T) (T t)
> {
>     func(t);
>     return t;
> }
> 
> You can do things like:
> 
> Foo foo ()
> {
>     return (new Foo).tap!((f) {
>         f.x = 3;
> 	f.y = 3;
>     });
> }
[...]

Couldn't you use map for this purpose?


On Tue, Feb 26, 2013 at 10:04:50PM +0100, Jacob Carlborg wrote:
> On 2013-02-26 20:52, H. S. Teoh wrote:
> 
> >Do you have any specific examples?
> 
> Some more:
> 
> isBlank and the opposite isPresent. These exists in Ruby on Rails, this is my D version:
> 
> https://github.com/jacob-carlborg/mambo/blob/master/mambo/core/core.d
[...]

Unfortunately, on this point I have to disagree.

I find !isBlank much better. Generally, I prefer a more minimal API, but I suppose people coming from Ruby might expect a more "rich" kind of API design (caveat: I don't know Ruby). Having too many ways of stating the same thing makes me wonder if there's some subtle bug lurking somewhere. What if isPresent is not 100% equivalent to !isBlank? And I don't mean just hypothetically; I've seen cases of libraries where bugs cause two supposedly-opposite functions to be not exactly opposite, and then code starts to depend on the buggy behaviour, causing hidden bugs later when the code gets fixed, etc.. A lot of unnecessary problems when you could have just written !isBlank in the first place.

Now, I used to be a Perl fanatic, so I totally understand TIMTOWTDI and all that, but I think having a separate function just to encode !isBlank is a bit too extreme.  The language has boolean operators for a reason, after all.


T

-- 
If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton

On 2/26/2013 1:26 PM, H. S. Teoh wrote:
> Having too many ways of stating the
> same thing makes me wonder if there's some subtle bug lurking somewhere.
> What if isPresent is not 100% equivalent to !isBlank? And I don't mean
> just hypothetically; I've seen cases of libraries where bugs cause two
> supposedly-opposite functions to be not exactly opposite, and then code
> starts to depend on the buggy behaviour, causing hidden bugs later when
> the code gets fixed, etc.. A lot of unnecessary problems when you could
> have just written !isBlank in the first place.

This is a subtle but very important point.

On 2013-02-26 22:26, H. S. Teoh wrote:

> I find the Phobos version more readable, actually. Writing "2.days.ago"
> is all neat and clever and everything, but the logician in me protests
> at what all those '.'s are referring to, and they do. Code is not
> English, and when it pretends to be English, it makes me suspicious that
> something is subtle going on that I'm not aware of. And when I'm coding,
> that's something I don't like -- I need to have the assurance I know
> exactly what's going on. And yes I can learn to parse "2.days.ago"
> eventually, but it's just additional mental load for only superficial
> convenience.

I don't agree. BTW, the whole point of having programming languages is for programmers to read and write it. Therefore they are similar to English (or some other language). For the computer the language is just in the way. It just wants to execute machine code.

> IMHO this is just bikeshedding. I actually find Phobos' order more
> intuitive (to me anyway), because the function you're reducing on,
> ideally, should be inlined, so it makes sense to pass it as a
> compile-time parameter, and the seed value is what you start with, so it
> makes sense to have it appear as the first parameter.

I never said it shouldn't be passed as a compile time parameter. Look at the example. I added the seed to the compile time parameter list.

> But I can see where UFCS will fail to kick in here, which makes it a bit
> annoying, I suppose. But reduce was designed before UFCS made it into
> DMD.

Then it should be changed. Oh, wait. We can't break any code, every

I don't know why I keep bothering. You (not as in "you" personally) never want to improve anything.

> Couldn't you use map for this purpose?

No, not as far as I know. "map" expects a range and returns a new range. "tap" expects an object and returns the same object. You can use "tap" to tap into chains of method calls and change an object.

> Unfortunately, on this point I have to disagree.
>
> I find !isBlank much better. Generally, I prefer a more minimal API, but
> I suppose people coming from Ruby might expect a more "rich" kind of API
> design (caveat: I don't know Ruby). Having too many ways of stating the
> same thing makes me wonder if there's some subtle bug lurking somewhere.
> What if isPresent is not 100% equivalent to !isBlank? And I don't mean
> just hypothetically; I've seen cases of libraries where bugs cause two
> supposedly-opposite functions to be not exactly opposite, and then code
> starts to depend on the buggy behaviour, causing hidden bugs later when
> the code gets fixed, etc.. A lot of unnecessary problems when you could
> have just written !isBlank in the first place.

This is not about adding "isPresent" to an already existing "isBlank" this is about adding "isBlank" or "isPresent" which don't exist.

> Now, I used to be a Perl fanatic, so I totally understand TIMTOWTDI and
> all that, but I think having a separate function just to encode !isBlank
> is a bit too extreme.  The language has boolean operators for a reason,
> after all.

isBlank does way more than checking if a value is false or not. Do you read the code at all?

-- 
/Jacob Carlborg

On 2013-02-27 03:52, Walter Bright wrote:

> This is a subtle but very important point.

It's not about adding the inverse of an already existing function. It's about adding a function that doesn't exist at all. Don't you read the post and the code at all? Or do I express myself so badly?

-- 
/Jacob Carlborg

On Wednesday, 27 February 2013 at 13:02:02 UTC, Jacob Carlborg wrote:
[...]
> This is not about adding "isPresent" to an already existing "isBlank" this is about adding "isBlank" or "isPresent" which don't exist.
>

[...]

>
> isBlank does way more than checking if a value is false or not. Do you read the code at all?

This thread got busted up into separate threads over the web interface, so maybe some people (like me) did not read everything you suggested.

OK I see you wanted to add only one or the other, not both. I like the idea of having this function in the std.lib. I added it to my own "standard.me" library.

--rt

PS: The web interface thread splitting is very annoying!

On Wed, Feb 27, 2013 at 09:07:15PM +0100, Rob T wrote:
> On Wednesday, 27 February 2013 at 13:02:02 UTC, Jacob Carlborg
> wrote:
> [...]
> >This is not about adding "isPresent" to an already existing "isBlank" this is about adding "isBlank" or "isPresent" which don't exist.
> [...]
> >isBlank does way more than checking if a value is false or not. Do you read the code at all?
> 
> This thread got busted up into separate threads over the web interface, so maybe some people (like me) did not read everything you suggested.
> 
> OK I see you wanted to add only one or the other, not both. I like the idea of having this function in the std.lib. I added it to my own "standard.me" library.

This is interesting. I have also been collecting a bunch of stuff that I constantly reuse in my own code. I wonder if we should do a survey of people's "standard.me" libraries to see what are the functionalities most commonly missing from Phobos? That might give us some interesting insights into what would be most profitable to add to Phobos.

Having said that, though, I found that my D personal library is much smaller than my C/C++ one, mostly because Phobos already covered a large part of that functionality! So Phobos is doing *something* right, in spite of all its current flaws.


[...]
> PS: The web interface thread splitting is very annoying!

We *really* need to look into fixing the mailman gateway, which is largely the cause of this problem. If I had the power to do it, I would.


T

-- 
Microsoft is to operating systems & security ... what McDonalds is to gourmet cooking.

On 2013-02-27 21:07, Rob T wrote:
> On Wednesday, 27 February 2013 at 13:02:02 UTC, Jacob Carlborg wrote:
> [...]
>> This is not about adding "isPresent" to an already existing "isBlank"
>> this is about adding "isBlank" or "isPresent" which don't exist.
>>
>
> [...]
>
>>
>> isBlank does way more than checking if a value is false or not. Do you
>> read the code at all?
>
> This thread got busted up into separate threads over the web interface,
> so maybe some people (like me) did not read everything you suggested.
>
> OK I see you wanted to add only one or the other, not both. I like the
> idea of having this function in the std.lib. I added it to my own
> "standard.me" library.
>
> --rt
>
> PS: The web interface thread splitting is very annoying!

Ok, then my apologize.

-- 
/Jacob Carlborg

On 2013-02-27 21:16, H. S. Teoh wrote:

> This is interesting. I have also been collecting a bunch of stuff that I
> constantly reuse in my own code. I wonder if we should do a survey of
> people's "standard.me" libraries to see what are the functionalities
> most commonly missing from Phobos? That might give us some interesting
> insights into what would be most profitable to add to Phobos.

That's a good idea. This is my library:

https://github.com/jacob-carlborg/mambo

It's a bit outdated. It started around 2007 with D1 and Tango.

> We *really* need to look into fixing the mailman gateway, which is
> largely the cause of this problem. If I had the power to do it, I would.

I agree. I apologize that I got frustrated in the confusing of threads that were split.

-- 
/Jacob Carlborg

On Wednesday, 27 February 2013 at 20:18:29 UTC, H. S. Teoh wrote:
[...]
> Having said that, though, I found that my D personal library is much
> smaller than my C/C++ one, mostly because Phobos already covered a large
> part of that functionality! So Phobos is doing *something* right, in
> spite of all its current flaws.
>
>

I also found that my D version of my std.me lib is a lot smaller than the C++ version, so Phobos seems to do a lot more than the C++ std lib does, and what I've used so far seems to be well done. I've only managed to scratch the surface though.

I think with C++ you have to use boost to get the same as what you get with Phobos, but I never liked working with boost.

--rt

On Wednesday, 27 February 2013 at 20:43:47 UTC, Jacob Carlborg wrote:
> That's a good idea. This is my library:
>
> https://github.com/jacob-carlborg/mambo
>
> It's a bit outdated. It started around 2007 with D1 and Tango.
>

I had a look at your isBlank function. Why not check if length exists and run it as follows?

@property bool isBlank (T) (T t)
{

   static if (__traits(compiles, t.length))
   {
       if (t.length == 0)
          return true;
   }

...

That would be more generic I think.

--rt