On 4/13/19 4:38 AM, Abdulhaq wrote:
> On Saturday, 13 April 2019 at 05:37:31 UTC, Walter Bright wrote:
>> On 4/12/2019 10:18 PM, H. S. Teoh wrote:
>>> writing (x % 2) conveys intent much better
>>> than (x & 1).
>>
>> They produced different code.
> 
> This is a non-sequitur, the fact that some compilers produce different assembly does not say anything about how well the functions convey intent.
> 
> However, in general, knowing that the bit-twiddling variety of a function produces different code to the mathematically precise expression, would just make me stop and think twice, three or even four times

Actually, this right here is *EXTREMELY* good reason in favor if isOdd/etc (again, not that my intent is to get it into Phobos).

Even if a programmer IS fully versed in low-level bit twiddling[1] and they know full-well (and remember off-the-top-of-their head) that "& 1" is a parity check (AND they remember offhand which 0-vs-1 result means which) AND they know full-well (and remember off-the-top-of-their head) that "% 2" *ALSO* means parity check (and remember offhand not only which result means which, but ALSO remembers offhand without having to think about it, whether the the "&1" result is equal or inverted from the "%2" result)...

[1] Not all programmers are, and frankly, not all programmers need to be - even as much as I believe low-level experience improves a programmer.

...EVEN (falsely) assuming ALL of that above is off-the-top-of-the-head basic knowledge for ALL users of your supposedly *MULTI-PARADIGM* language...then...you *STILL* face the problem of whether your users know that there's a FREAKING CODEGEN DIFFERENCE in "&1" vs "%2"..AND that one results in better codegen, *AND* *WHICH ONE* results in better codegen!!!

This example is *the whole freaking point(!!!)* behind basic HLL abstractions!@!!

People need to know the even/odd parity of a value, either they check it via some provided guaranteed-optimal interface...or they roll-their own and are EXPECTED to guess the preferred implementation between two theoretically-equivalent implementations by enumerating and verifying the codegen details of the known-possible implementations. Is it an unstated GOAL here to waste developers' time and effort???

Again, I am *not* looking for inclusion of isOdd/etc into Phobos. If you really want your language to be a systems-language instead of multi-paradigm, then that's your business. But what I *DO* care about is that at *least* one of the leaders behind D actually *comprehends* the freaking basics of programming psychology and fundamental logic well enough to admit the validity of this reasoning without allowing themselves to be biased by their own personal programming abilities.

I'm not a fan of Apple products (aside from Apple II), or Apple platforms (beyond Apple II), or even modern-day Apple as a company...but even *I* can recognize these basic, obvious truths:

1. Apple has a vested interest in being inclusive of novice and less-than-expert programmers.

2. Apple's inclusion of isOdd/etc successfully addresses what is quite *obviously* (based on the very same stackoverflow data that Walter & Andrei have mocked and knee-jerk disregarded) what is *clearly* a very real, common stumbling block among non-low-level-experienced programmers. (Again, disregarded by W&A as incompetent and unworthy of D-user status.)

3. DLang leadership considers both novice developers as well as other developers who lack sufficient low-level experience as failing to meet the minimum bar for being a D user.

4. DLang isn't especially interested in recruiting novice developers nor other developers who lack sufficient low-level experience, whereas other languages like Swift are.

5. Therefore, when it comes to language adoption, Swift has a notable leg-up against D - which D leadership willingly accepts.

If W&A are content with the truths of 1-5, then I have no issue with D beyond the disappointment that it's not as multi-paradigm as I'd thought and hoped for. But if W&A object to any of 1-5, then that's far worse - I take issue with the ability and willingness of D leadership to recognize, value, and follow basic psychology of programming, and basic logic and reason in favor of flawed, unvalidated personal biases.

On 4/13/19 4:38 AM, Abdulhaq wrote:
> On Saturday, 13 April 2019 at 05:37:31 UTC, Walter Bright wrote:
>> On 4/12/2019 10:18 PM, H. S. Teoh wrote:
>>> writing (x % 2) conveys intent much better
>>> than (x & 1).
>>
>> They produced different code.
> 
> This is a non-sequitur, the fact that some compilers produce different assembly does not say anything about how well the functions convey intent.

That may be so, but it *does* very clearly demonstrate the value of specifying intent rather than implementation.

As with any abstraction, the separation here of intent vs implementation frees the code/programmer who needs to check parity from needing concern themselves with which implementation is optimal. This is the whole point of HLL-abstractions.

That is demonstrably relevant in this case *because* the two possible implementations produce different code.

Again, this is basic HLL Programming Abstractions 101.

On 4/16/2019 11:11 PM, Nick Sabalausky (Abscissa) wrote:
> 2. Apple's inclusion of isOdd/etc

Actually, Apple rejected it:

"Only isMultiple(of:) was approved during review, so the final implementation does not include isEven or isOdd."

https://github.com/apple/swift-evolution/blob/master/proposals/0225-binaryinteger-iseven-isodd-ismultiple.md

On Wednesday, 17 April 2019 at 06:11:56 UTC, Nick Sabalausky (Abscissa) wrote:
> On 4/13/19 4:38 AM, Abdulhaq wrote:
>> [...]
>
> Actually, this right here is *EXTREMELY* good reason in favor if isOdd/etc (again, not that my intent is to get it into Phobos).
>
> [...]

Just to note that isOdd/isEven was not actually accepted in swift 5. isMultiple(of:) was deemed worthy enough to cover all usecases. The initial post unfortunately maaaayyyy  have made it seem like all were accepted because of the name of the file, which Andrei pointed out later :o)

See the notes form the review manager and swift core team:

https://forums.swift.org/t/accepted-with-modifications-se-0225-adding-ismultiple-to-binaryinteger/15689

Cheers,
- Ali

On Friday, 12 April 2019 at 02:29:38 UTC, Walter Bright wrote:
> On 4/11/2019 4:24 PM, Mike Franklin wrote:
>> On Thursday, 11 April 2019 at 23:03:00 UTC, Walter Bright wrote:
>> 
>>>   bool isOdd(int i) { return i & 1; }
>>>
>>> Filling the standard library with trivia is not a good idea. Not knowing about a common operator is not a reason to add library functions.
>> 
>> For me it's not about knowledge of the operator.
>
> That was the reason given for it.
>
>
>> It's about conveying the reason for why that operation is being done.  For example, if you do `i & 1` are you checking for even or odd, or are you masking off irrelevant bits.
>
> If you're masking bits, you should call it:
>
>    return i & MyBitFlag;
>
>
>> Creating functions like `isOdd` or `GetLeastSignificantBit` help convey intent without having to supplement code with comments.
>
> No they don't. For example, if I saw "isOdd" in code, I'd wonder what the heck that was doing. I'd go look up its documentation, implementation, test cases, etc., find out "oh, it's just doing the obvious thing", and be annoyed at the waste of my time.
>
> It wastes the time of everyone reading the code, documenting the function, and the QA staff. It hides the useful stuff in the library when it's alongside a morass of junk like this. It wastes the time of the poor shlub perusing the library. It makes the library look like a bunch of filler rather than useful stuff.
>
> I don't believe anybody's code is so well-documented that this is all that's left. Meaning you're wasting your time documenting the wrong things.
>
> I call this sort of stuff the "Illusion of Progress".

Sorry to bump an old (hijacked) thread, but I have just discovered something hilarious that absolutely needs to go here:

The same author of the is-odd npm package also has a package called 'is-even'.
Now that, I'm sure we can all agree, is bullshit.

On Thu, Apr 25, 2019 at 10:49:47PM +0000, Terry Arkson via Digitalmars-d wrote:
> On Friday, 12 April 2019 at 02:29:38 UTC, Walter Bright wrote:
> > On 4/11/2019 4:24 PM, Mike Franklin wrote:
[...]
> > > Creating functions like `isOdd` or `GetLeastSignificantBit` help convey intent without having to supplement code with comments.
> > 
> > No they don't. For example, if I saw "isOdd" in code, I'd wonder what the heck that was doing. I'd go look up its documentation, implementation, test cases, etc., find out "oh, it's just doing the obvious thing", and be annoyed at the waste of my time.
[...]
> > I call this sort of stuff the "Illusion of Progress".
> 
> Sorry to bump an old (hijacked) thread, but I have just discovered something hilarious that absolutely needs to go here:
> 
> The same author of the is-odd npm package also has a package called
> 'is-even'.
> Now that, I'm sure we can all agree, is bullshit.

What would be actually useful is a package called is-prime.

Unfortunately, its usefulness would be obscured by the proliferation of packages like is-even, is-odd, and others of their ilk.  Just like comments that repeat what the code already says, thereby obscuring the actual intent of the code while giving an illusion of being well-documented.

	/* Look, Ma! I'm so well-documented! */

	// loop from 0 to len
	for (i = 0;		// set i to zero
		i < len;	// check that i is less than len
		i++)		// increment i
	{
		if (i & 2) {	// if bit 0 is non-zero
			writeln("How odd!");
		} else {	// otherwise
			writeln("But even so...");
		}
	}

Blecch.


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly

On Thursday, 25 April 2019 at 23:40:31 UTC, H. S. Teoh wrote:
> On Thu, Apr 25, 2019 at 10:49:47PM +0000, Terry Arkson via Digitalmars-d wrote:
>> On Friday, 12 April 2019 at 02:29:38 UTC, Walter Bright wrote:
>> > On 4/11/2019 4:24 PM, Mike Franklin wrote:
> [...]
>> > > Creating functions like `isOdd` or `GetLeastSignificantBit` help convey intent without having to supplement code with comments.

Probably one reason D is not gaining much adoption (at least for beginners) is because the maintainers are so smart that they ignore some basic (or less cognitive load) details.

Like functions that might appeal to beginners...but Andre and Walter overlook them...thinking its so obvious (in their experience). If true, they'll have problem teaching beginners programming.

Another example is Ali's book, may seem normal to someone with some programming experience but definitely not a beginner's book...I have personally seen that with some folks.

LOL

On Thursday, 25 April 2019 at 23:40:31 UTC, H. S. Teoh wrote:
> ...
>   Just like comments that repeat what the code already says, thereby obscuring the actual intent of the code while giving an illusion of being well-documented.
> ...
> 		if (i & 2) {	// if bit 0 is non-zero
...

Q.E.D.

JR