Why append to list is not the same as +=

NevemTeve · 05-30-2024, 02:31 AM

How about this: in non-trivial cases properly named functions are better than obscure symbols, eg AddSecs/AddMicroSecs/AddNanoSecs vs +/+u/+n

(Which is an idealization, as you can only use + without qualification, so it's up to you to decide what units are actually used, lightyears or woodys)

EdGr · 05-30-2024, 04:22 AM

pan64 - Suit yourself.

I have not found a case in my code in which an overloaded operator would be clearer than a named function.
Ed

pan64 · 05-30-2024, 05:32 AM

Quote:

Originally Posted by EdGr

pan64 - Suit yourself.

I have not found a case in my code in which an overloaded operator would be clearer than a named function.
Ed

overloading is quite normal, it means the given class has its own implementation to realize an operation or functionality. You can name that function (like add) or you can use an already predefined operator for the same (operator +) which will do exactly same. Choosing an operator or function is one thing, overloading (replacing an inherited "feature") is another, completely different thing.
In some languages you can even see the connection between them, the operator actually calls the associated function.

Code:

class A: a(p), b(q);
class A: c = a + b;
class A: c.sum(a, b);
class A: c.assign(a).add(b);

I can't see the named function makes it better or clearer (even if you call it copy instead of assign).
You will still have no idea what is it all about, if you don't know if A is just an integer, a complex number, or a circle (with a radius), a polygon (with number of sides) or something completely different.

sundialsvcs · 05-30-2024, 07:52 AM

As long as you know that the overload is being done, and what it is doing, overloading (as a concept ...) is just fine.

But, in my consulting business, I very-commonly encounter software that is "brand-new to everyone who is [still ...] working there." And, one of the problems is that the present staff doesn't entirely understand how the software works – although they might well think that they do. "Overloading" is certainly one of the nastiest surprises.

It cannot be over-emphasized how often a programmer finds (him)(her)self wandering into entirely-unfamiliar territory. They rely upon their highly-refined diagnostic "spidey senses" to enable them to understand what the source-code in front of them means. And, "overloading" can definitely be a curve-ball. This is why I generally prefer not to use it, except as the built-in language already does. "Dumb-Obvious Clarity" is always most-important to me.

This is also why comments are so vitally important. The source-code that I write is "positively 'chatty.'" When I write something, I talk to myself about it at the time. This has been very important when I then encounter my own source code, many years (or sometimes, just weeks or months ...) later. No, I don't remember a thing. It is by then "the work of a complete stranger."

pan64 · 05-30-2024, 08:46 AM

Quote:

Originally Posted by sundialsvcs

But, in my consulting business, I very-commonly encounter software that is "brand-new to everyone who is [still ...] working there." And, one of the problems is that the present staff doesn't entirely understand how the software works – although they might well think that they do.

Yes, I totally agree with it. And comes the good old suggestion: never assume anything, you will fail.

Quote:

Originally Posted by sundialsvcs

"Overloading" is certainly one of the nastiest surprises.

This is an interesting question and offtopic here.
Assuming you are a professional developer and also you are familiar with the current code/product/software/language/environment.
What do you think, are you allowed to use all the language elements to implement a feature, or you need to avoid using the parts which are not-so-obvious for the not-so-professional programmers? Do you write code for dummies or for efficient/optimal operation?

Quote:

Originally Posted by sundialsvcs

It cannot be over-emphasized how often a programmer finds (him)(her)self wandering into entirely-unfamiliar territory. They rely upon their highly-refined diagnostic "spidey senses" to enable them to understand what the source-code in front of them means. And, "overloading" can definitely be a curve-ball. This is why I generally prefer not to use it, except as the built-in language already does. "Dumb-Obvious Clarity" is always most-important to me.

The law: make something idiots can use and only idiots will use it. https://en.wikipedia.org/wiki/Idiot-proof

sundialsvcs · 05-31-2024, 09:30 AM

@pan64: That seems to be a bit of a “loaded question.” A little bit too theoretical for my taste.

I routinely encounter software which is brand-new to me, and to the programming teams I am trying to help. “Custom overloads” are sometimes used. And these can be confusing. Because: you have to, first, be aware that they are there. And, second (perhaps), know which one(!) applies to the statement you are looking at. Yep, sometimes the now-long-gone predecessor LUVED(!) custom overloads!

In general, “they’re not my favorite.” I like source code to be “painfully explicit.” I want to look at the source-code sentence in front of me and immediately understand what it means, without reference to anything else that is not directly in front of me.

“There’s more than one way to write it.” In the end, it doesn’t matter to the optimizing compiler. But it does matter to people. “Innocent mistakes” can be hideously expensive in real money. So: “please don’t be ‘clever.’”

You can of course write “very clever” code. Which is fine … until you get smooshed by a bread truck or move on to greener pastures. (I usually arrive after one or the other of these possibilities has just taken place.)

pan64 · 05-31-2024, 10:20 AM

You know in my team (it is not my own team, but I'm just a member), we developed a python library for ourselves. And we have difficulties to use it. No overloading, nothing special. Better to say a library written for our own purposes. We, the team cannot use it because we, the team don't know about it. And we, the team reimplement it again and again. Nightmare.
But this is how we, the human being works (or doesn't work). And this is not related to overloading.

From the other side I think there is a 10/90 rule: 10% of the people own the 90% of the money, 90% of the people own the 10% of the money. Or the knowledge.
In general

Quote:

I want to look at the source-code sentence in front of me and immediately understand what it means, without reference to anything else that is not directly in front of me.

it does not exist any more. Every line of code, every call travels around the world, goes to the cloud and through databases.