Re:Go Enums Still Suck
by sethammons on Thursday March 28, 2024 @11:24AM
(#39852704)
Maybe I am naive. Help me out. My familiar languages are Go, Elixir, Python, Perl, Ruby, and some Javascript. I would have said all of these languages allow for abstractions that reduce lines of code.
What I don't want is abstractions that increase cognitive load.
The case presented in the article requires many mixed types in a list. The longer the list, the more you have to keep in your head. In Go, it is common to use table driven tests and you can get something like:
cases := struct{
wins int
losses int
is_eligible bool
}{
{23, 13, true},
{34, 1, true},
{3, 0, false},
}
Each case is abstracted and minimal. But it is very clear as you read that what each is because there are few items in the list. If it was a dozen properties, like in the post, you visually cannot parse that as fast. When the list of properties gets long, you are now mentally counting "ok, the 9th parameter is a float, oh, hm, the 9th param is showing an int... oh, I forgot the 7th param."Abstractions should be clear and make understanding easier. With so many parameters, labeling them makes them clear. Abstractions are not just for reducing line count.
Where am I going wrong? What is the better alternative?
cause or effect? who knows.