The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Tuesday, July 20, 2021

There are reasons for operators

One particular area of software complexity is the degree to which unclear code can have unnoticed side effects, an effect that in his most recent blog post, Drew DeVault coins "Spooky code at a distance". Of the two example he gives its the first, of operator overloading, that I think is of greater interest and raises the question about what even the point of operators is and whether they make the code unnecessarily ambiguous.

All this is to say, do we really need them? Would it not be better to avoid mutation and to be explicit. If you want to add two numbers then call an add function. If you want to concatenate strings then call a concatenation function. If you want to define your own conditional subroutines, I guess use a lazy language, but then name them. I think its [sic] important to be explicit about the intent of code even if the behaviour is the same as it is easier for others to read and understand and will ultimately lead to fewer bugs. That seems to make sense, right?

Are Operators Even Necessary?

There's a reason why languages have operators—it makes the code easier to reason about. For instance, is this bit of code:

/* Why yes, the "=" is an operator as well */
fassign(&xn1,fmul(fmul(fadd(fmul(A,yn),B),xn),fsub(1.0,xn)))
fassign(&yn1,fmul(fmul(fadd(fmul(C,xn),D),yn),fsub(1.9,yn)))

or this?

xn1 = ((A * yn) + B) * xn * (1.0 - xn);
yn1 = ((C * xn) + D) * yn * (1.0 - yn);

(also, spot the bug!)

Drew comes down on the “no-operator overloading” camp because he finds it harder to debug potential issues, performance or otherwise. But that's a trade-off he's willing to make—others might make the trade-off the other way. For instance, I found it much easier to implement the Soundex system in LPeg, which uses (or maybe abuses?) Lua's operator overloading capability. I traded development time (well, minus the time it took me to get used to LPeg) for a bit of runtime and potential difficulty in debugging. There is something to be said for conciseness of expression. I can't find a source for this, but I have heard that the number of lines a programmer can write per day is constant, regardless of language. The above equation is two lines of C (or really, any higher level langauge) but in assembly?

	movss   xmm0,[yn]
	mulss   xmm0,[A]
	addss   xmm0,[B]
	mulss   xmm0,[xn]
	movss   xmm1,[const1]
	subss   xmm1,[xn]
	mulss   xmm0,xmm1
	movss   [xn1],xmm0

	movss   xmm0,[xn]
	mulss   xmm0,[C]
	addss   xmm0,[D]
	mulss   xmm0,[yn]
	movss   xmm1,[const1]
	subss   xmm1,[yn]
	mulss   xmm0,xmm1
	movss   [yn1],xmm0

Eight times the lines of code, which seems about right for assembly—not hard, just tedious. I would think if Robert wants to use functions over operators, it's easy enough to just do it. I do wonder though, how long until he goes back to using operators?


A most persistent spam

I'm wondering what's up with this spam?

From
Aleksandr <info@s9.mirengo.ru>
To
info@conman.org
Subject
Предложение
Date
Tue, 20 Jul 2021 22:39:01 +0000

Здравствуйте. Вас интересует продвижение сайта? Напишите мне в Skype пожалуйста WhatsApp/Viber владельца сайта и передайте мое предложение. Мой Skype для быстрой связи: mayboroda_aleks Преимущества при сотрудничестве со мной:

Я предоставляю отчетность, какие и где были куплены ссылки на Ваш сайт, какие есть ошибки на сайте, которые нужно исправить, увидеть реальный рост позиций сайта и многое другое. С уважением, Aleksandr, SEO специалист в области продвижения сайтов. Мой Skype для быстрой связи: mayboroda_aleks

I mean, yes, it's spam. It's in Russian. And I've been receiving this exact email for well over a year now. Usually two or three times a week. I tried rejecting it via the IP address (via my greylisting daemon) but to no avail—the source IP changes too often. I'd reject the domain, but that changes constantly too. The name? Always “Aleksandr.” The subject line? Always “Предложение.” Yes, I could just automatically delete the email upon receiving it, but I'd much rather reject it as soon as possible rather than accepting it to then just delete it.

But all that aside, I can't figure out the angle here. Is Aleksandr really that hard up for work that he'll spam anybody for work? (yes, I ran the email through Google Translate) Even people who don't speak Russian? Or is this a smear campaign against Aleksandr? Trying to drive him (her?) out of business? I can't tell.

There's no virus in the email. And even though there's an HTML version of the message included, there are no malicious links, as there are no links.

So I'm at a complete loss as to the game going on here.

Update on Wednesday, Debtember 22ND, 2021

Wisdom of the AncientsI did find a solution, but it might not be one you can use.

Obligatory Picture

An abstract representation of where you're coming from]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

Obligatory AI Disclaimer

No AI was used in the making of this site, unless otherwise noted.

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.