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

[H. S. Teoh]

On Wed, Feb 27, 2013 at 02:02:01PM +0100, Jacob Carlborg wrote:
> 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.

OK, then let's agree to disagree. I see that there's no point in arguing
about this, since it ultimately comes down to preference, which can
never be reconciled.


> >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.

Yes, I was just talking about the order of parameters.


> >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.

Not sure who you're referring to here, but the reason reduce probably
will not change is because a lot of code relies on the current order of
parameters, and deliberately breaking that just for aesthetic (rather
than functional) reasons is not a good idea. It would be a different
story if the current order of parameters somehow makes it impossible to
implement some particular functionality. I agree that perhaps the
current situation is not perfect, but at least it's not a complete road
blocker.


> >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.

Isn't that the same as:

	map!((obj x) { doSomething(x); return x; })(range)

?

I know it's not as pretty, but at least it's possible.


> >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.

My point was that you only need one of them, not both. I don't see
what's the advantage of adding both isBlank and isPresent, when adding
just one will already give you the functionality of the other. I didn't
mean to say that it's a bad idea to add *either* one.


> >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?
[...]

Again, my point was not that it's a bad idea to have isBlank. My point
was that if you add isBlank, then isPresent is redundant, and I would
argue even harmful. The best APIs are minimal ones, that provide all
*necessary* primitives with minimal overlap between them.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??