jj já varoval hned v perexu, ze je to hack :)
ale popravdě - zrovna skalární součin si takto dělám, to je v naší doméně nutnost (ale ne nad seznamy).
máme vlastní řešení přes AVX-512 intrinsic. Je to rychlejší, než NumPy (což nevím proč, protože NumPy by mělo umět AVX taky). Ale i tak bych si z toho udělal operátor :-) [tedy v tomto případě @]
Přetěžování operátorů je obecně zlo. V Go není vůbec. Ale i když je to obecně zlo, tak by se to občas hodilo. Třeba na velké krysy (math/big.Rat), nebo operace s maticemi apod. Jazyk bez "podpory matematiky" bude vždy zaostávat oproti ostatním, alespoň v datovém světě.
Ideální by bylo vydávat certifikáty, které lidi budou opravňovat k přetěžování operátorů, tvorbě C++ šablon apod. A když to bude někdo dělat bez certifikace, zatkne ho programovací policie.
jak pises, pokud to Go mit nebude, nebude se pouzivat v teto oblasti tak, jako Julia nebo Numpy. A Gonum to nezachrani :(
Všeobecné zlo alebo všeobecné dobro neexistuje, podstatný je vždy kontext.
Preťaženými operátormi sa dajú vytvárať zaujímavé DSL, u ktorých je výsledok použitia je výrazne jednoduchší a prehľadnejší ako kód písaný štandardným spôsob.
A je samozrejmé, že ich nepíšu bežní programátori a že ich môžu používať iba tí, ktorí sa to naučia.
Zdá se, že k "pořádným" operátorům má Python ještě daleko…
https://docs.raku.org/language/operators
To je fakt hodne zajimava metoda. Nezavidim tomu, kdo takovy program ma pochopit, prijit na to, jak ten operator funguje. Ale pak takovy operator pak velmi zjednodusi psani i cteni programu.
Zajimava finta.
No právě. Je to nástroj. Užitečný ale nebezpečný.
Přemýšlím, kde stanovit tu hranici. Protože zneužít se dá všechno. Tak možná "pokud to stroj udělá líp, nechat to stroji, pokud je to věc sémantická, tak to musí člověk".
a pak přijde LLM :-)