D as a prototyping language (for C/C++ projects)

[Jacob Carlborg]

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