💾 Archived View for nytpu.com › gemlog › 2021-07-21.gmi captured on 2023-01-29 at 03:22:17. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

operators part 5(?)

july 21, 2021

In response to:

rlamacraft's post “Are Operators Even Necessary?”

Sean Conner's post “There are reasons for operators”

Sandra Snan's post “RE: There are reasons for operators”

JBanana's post “My turn to operate”

And also indirectly in the overloading section:

Drew DeVault's post “Spooky action at a distance”

Relevant Quote of the Day:

Opinions are like assholes, everyone has one but they think each others' stink.

— Simone Elkeles

Or in my case when writing this:

Opinions are like nipples … some are displayed at every opportunity regardless of whether the audience has stated, “I am interested in your nipples,” or not.

— David Thorne

overloading

First to get it out of the way, operator overloading is absolutely no, not ever, never. If I see code using what looks like language builtins or stdlib stuff and it does something unexpected because it was overloaded, I'll be very angry. Overloading operators is equivalent to `#define while if` in a header that's included in half of the files but not all, because that's literally what overloading is, replacing an operator with your own crap that can do whatever it wants (context-sensitively, so it's even more unexpected when some usages work normally while others don't).

For an example, Idiomdrottning's defineᵃ (which is a type of overloading, it replaces a built-in form with a custom one) would be so confusing to me if I was to jump into and try to contribute to a program using it. It works like a normal define all throughout, and then all of a sudden it does something totally unexpected. I don't want to read every single piece of code in something, I want to be able to get a good overview of the program and then thoroughly read /just/ the sections relevant to my contribution without being surprised when something is overloaded in some obscure file—or in this case an imported library, so it's even more hidden unless you go read the entire documentation for every library being used.

She even wrote about the unexpected and subtle pitfalls of the alternate define, which someone looking at some subsection of a codebase would never expect until their modifications mysteriously don't work as expected.

[a]: “The fanciest define of all time”

operators

Back to the topic at hand, I think (as in everything), there's a middle ground. I think the existence and syntax of operators is heavily dependant on the language's syntax as a whole. `define(x, add(add(4, mul(2, 3)), 2))` feels as out-of-place in C as `(x = 4 + (2 * 3) + 2)` would feel in Lisp. Lisp is designed around functional programming (yes, you can do other styles, but it's designed based-off of functional programming), so special-case operators feel out of place. C is designed around procedural programming without first-class functions, so having everything be a function feels out of place. And, despite many people's claims otherwise, different languages are good at different things, and sometimes one way makes sense while another way doesn't. Same thing with operators, sometimes they make sense, other times it'd be better without them. rlamacraft's original post seems to be from a functional programming perspective, and says “[it would] be better to avoid mutation and to be explicit.” And yet, this:

for (int i = 0; i < 10; ++i) printf("%d\n", i);

is not made any more readable like this:

for (let(int, i, 0); less_than(int, i, 10); set(i, add(int, i, 1))) printf("%d\n", i);

Not to say that

(define (fib n)
  (if (<= n 2)
      1
      (+ (fib (- n 1)) (fib (- n 2)))))

is made more readable as

(define (fib n)
  (int t1 = 0)
  (int t2 = 1)
  (int t3 = t1 + t2)
  (for ((int i = 0) (i < n) (++i))
    (t1 = t2)
    (t2 = t3)
    (t3 = t1 + t2))
  (return t3))

either though (Before people get angry, both examples are fake code that's not possible in their respective languages). Again, which style is better than the other depends on the problem context and the language's syntax style. Arguing about this is seeming like a veiled version of the standard Lisp-C debate that's been happening forever (for the record I like both C and Lisps for different reasons).

Quoting an anonymous wiki editor:

This entire [conversation] is a hovel of smug weenies calling other people smug weenies.

Way not to disappoint, guys.

an aside on reverse polish notation

JBanana's post talked prefix operations for math, and while I agree that prefix looks better when writing out stuff, I think reverse Polish notationᵅ (RPN) is the best when calculating (by hand or via calculator). In calculators, RPN is literally the best thing ever and makes calculations and more advanced programming super easy. My HP 48G is my favorite calculator, and I maintain that the HP 48GX is the best calculator ever made, and they both use RPN. I regularly use rofi-calcᵝ configured in RPN mode and clacᵟ for calculations at my computer too. I whole-heartedly recommend RPN, although it's getting harder and harder to find calculators that use it.

[α]: “Reverse Polish notation, also known as … simply postfix notation, is a mathematical notation in which operators follow their operands”

[β]: rofi-calc — Do live calculations in rofi!

[δ]: Command-line, stack-based calculator with postfix notation (notice how the docs refer to ‘+’, ‘-’, etc. as “operations” even though they're postfix!)