The only caveat to that is: if it's a pattern that is used frequently. For example, the tons of auto-generated gRPC code. First go around, sucks. You have to dive & read a lot. 2nd-3rd go around, you might remember more bits of it so you can use it with only a few lookups of defs. More than that? You likely don't need to dive into it at all to understand.

So perhaps this tool would be very useful, if you're going to use it a ton. Or use it only once and not really have to access the internals. But if it's something that is bespoke, and you update it infrequently, that's ripe for frustration on re-reads.

The more code I need to READ to understand what I'm looking at, the less optimized for maintenance it is. If it takes 5 lines to understand that the map I'm looking at is effectively used as a set, it's worse than if I had a Set abstraction.

Of course now I do, 20 of them, because when there's no built in, there will be packages made by the community.

Congrats, you just inherited this code and have to fix it:

    Mercury 0.378,2439.7,3.3e23,57910000,88,0.0000000001,0,false

There is no way to infer what any of the values are. They are practically magic numbers. How do you know if you swapped a pair of numbers there and what that will do to the application? You have to mentally map all those things.

It is vastly, overwhelmingly more new-dev friendly to use:

    MERCURY: Planet{
  planet:              mercury,
  Gravity:             0.378,
  RadiusKm:            2439.7,
  MassKg:              3.3e23,
  OrbitKm:             57910000,
  OrbitDays:           88,
  SurfacePressureBars: 0.0000000001,
  Moons:               0,
  Rings:               false,
 },

the values are specified in the definition of the iota type.

``` type planet int // Gravity[float64],RadiusKm[float64],MassKg[float64],OrbitKm[float64],OrbitDays[float64],SurfacePressureBars[float64],Moons[int],Rings[bool] ```

yeah, and now, mentally count how many values you are in, don't lose count now! Why offload that to your brain where you could miscount instead of using structured data?

Because your whole argument is misconstructed. There are cases where longer code is better, but there are many cases where longer is worse too. Because the tools the language provide, on top of being more succint, make the intent more obvious.

I’m wondering why we don’t use any type and definition-aware IDEs that could render the first line as a proper table (especially once there is a list of items of the same type involved). With headers and aligned fields. Similar to how Word would do it with inline tables.

Ideally of course with a switch to change to the second, more verbose definition.

Rider (and probably all JetBrains IDEs?) have inlined parameter names and types as hints.

https://www.jetbrains.com/help/rider/Inline_Parameter_Name_H...

That would tie languages to language tools and IMO be a downgrade from having a slightly more verbose language that is independent of tooling.

Maybe this data should be stored in a CSV and edited in Google Sheets/Excel.

I've got a job for you, mine at my previous company!

Huh, for me its opposite, I`m ok with reading/fixing/updating few pages of code if its easy to read and easy to update.

Short code with multiple levels of abstractions, with dynamic inheritance, and with a lot of dependency inversion, etc. etc... I don't like it. I will spend a lot more time (probably) just digging into code while trying to understand it.

But if you want brevity you could just use types!

https://go.dev/play/p/uUNHxM8zqY9

Not sure I understand what this adds over a list of plain old types.

This is the right answer - there should be a planet type.

If you're working in an environment that categorically requires all high-level concepts (say, iterating over a collection or representing mutually-exclusive data) to be encoded using low-level mechanics, your productivity will suffer.

But don't be confused: this is not the lost productivity of a missed optimization. We're enabling orders of magnitude of change by giving the developers tools for thinking rather than a mere code to grunt at the machine.

I like short code, but exactly for the opposite reasons. I can write long stretches of code; I won’t be very happy doing it, but all it takes is to start and keep going.

Reading vast plains of mostly-obvious code, though, attempting to extract the author’s insights from them—tgat can be genuinely difficult. It’s also very taxing, because it’s never going to be all obvious, you see? Only mostly so. At some point somebody, somewhere, needed to tweak something just a bit to avoid a momentary difficulty, or their brain slipped, or they were new and didn’t know a subtlety of how things are supposed to be done. Whatever the reason, I now need to remain in a state of constant vigilance for the entire journey.

Give me two pages of code to stare at for an hour until they click any day. As funny as this sounds, that is just plain less effort (and less perception of wasted effort as well, if we’re being honest).

(Now, I wouldn’t object to having both options—a concise description and its long and borung expansion for when I’m just not smart enough to get it—but that’s a language design problem that has for the most part remained unsolved for several decades now. So I’m not holding my breath.)

That's the reason why I chose to focus on Go instead of Rust after immersing myself in it for a while.

Rust invites you to aim for brevity and crafting smart solutions whenever you can. Don't get me wrong, sometimes this leads to beautiful code. It can be super satisfying to write. But there is only so much fun in reading yet another 10-step iterator method chain which works due some arcane edge case in the middle of it.

I vastly prefer reading dumb and obvious Go code. It's just easier to understand and to work with.

This is one of the reasons for why I prefer C over Rust for reference implementations. I look at the code and I understand it much better than the Rust version.

I think I agree with this. C is, if nothing else, very simple to read and understand (generally). For reference code, it seems like a good choice. I think you need a stronger argument to use C over any other language for something that is meant to be bullet proof or run in production though.

“Go is a language for people who like to ship more than they like to code.”

Low cognitive load is the biggest thing Go got right. That being said it doesn’t get it perfectly right and there are a few places it overdoes it.

this sort of comment is extremely common from people using languages that don't allow for abstractions that reduce LOC, like Go and Python.

cause or effect? who knows.

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?