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