food for thought - swift 5 released - bottom types, string interpolation, and stuff.

[Patrick Schluter]

On Friday, 12 April 2019 at 06:52:39 UTC, aliak wrote:
> On Friday, 12 April 2019 at 02:13:12 UTC, Walter Bright wrote:
>> On 4/11/2019 6:24 PM, Timon Gehr wrote:
>>>>    bool isOdd(int i) { return i & 1; }
>>>>
>>>> Filling the standard library with trivia is not a good idea.
>>> 
>>> Yes, if it is used often enough across many projects, adding 
>>> functions with a simple implementation can be a very good 
>>> idea. The main point is to standardize the function name and 
>>> avoid duplicated equivalent code in everyone's personal util 
>>> libraries.
>>
>> That would make sense if there was some application-specific 
>> higher level meaning to oddness, such as maybe the low bit 
>> being used as a flag. But there isn't when it is named "isOdd".
>>
>
> I've used n % 2 == 0 millions of times in GUI logic. Applying 
> properties to things that are row'ed-out. Games is another one 
> - very common. Fuzzy matching another one. isOdd would've made 
> the call site a lot more clear.
>
>>
>>>> Not knowing about a common operator is not a reason to add 
>>>> library functions.
>>> No, but there can be other reasons.
>>
>> That was the reason given. I'm open to hearing a better one.
>
> Using n & 1 has always been a hack for oddness. It says nothing 
> about what your code is doing. The average programmer would 
> look at it and have to think about what's happening there.
>
> I do understand what you mean about being a bit suspicious 
> about isOdd though when seeing it in code. But I think the same 
> would apply to abs if we had not grown up with it being in 
> math.h. We'd be doing "n>0?n:-n" or "(n+(n>>31))^(n>>31)" - or 
> the more saner would write their own. And then when someone 
> comes and tries to add abs to a standard library functions one 
> could also say "not knowing about [a] common operator[s] is not 
> a reason to add a library functions".

funny you mention abs(). My current job was enabled because the 
project leader was impressed with my optimisation skill. The 
first change I made in the code base (in the Levenshtein routine) 
was to replace the call to abs() by a macro doing nothing more 
fancy than "n>0?n:-n". The gain in performance was so massive, it 
completely floored me at that time. People underestimate the cost 
of a call, especially into a dynamic library (it is an indirect 
jump via the GOT), if it is in the hot loop it can be a massive 
cycle waster.


>
> But after all this time working on products as low level as 
> drivers to as high level as web apps, the three things that 
> have been the most important have been readability, 
> maintainability, and correctness.