Comment by baalimago
16 hours ago
This: "(b Box[T]) Map[U any](f func(T) U) Box[U]" is the type of cognitive weight I was happy that Go avoided.
16 hours ago
This: "(b Box[T]) Map[U any](f func(T) U) Box[U]" is the type of cognitive weight I was happy that Go avoided.
I think naming conventions might help:
Same in Python:
vs
and Java:
vs.
It's hard to avoid, because (naming aside) the cognitive load is caused by higher order functions, which are hard avoid without causing massive code duplication.
I understand the desire to keep things concrete and avoid high level abstractions, but it's a decision not to automate stuff that can easily be automated. It runs counter to the basic instincts and purpose of our field/industry. That's why it never sticks.
Honestly, I’ve written some applications that, on paper, should be the perfect candidate for generics. And yet I can still count on one hand the number of times generics have saved me from massive code duplication.
Most of the time generics might be useful, I’ve ended up needing reflection too anyway. And at that point, I’m really no better off for generics.
I understand that this is true for a lot of application code. It's not true for library authors though, and every language needs libraries.
4 replies →
Generics are supremely useful for containers. They are kind of one trick ponies in that sense in application code. Similar to reflection, I’d say, which is utilized for serialization 99% of the time.
The thing is that one use case is so essential, so foundational, that we really can’t just skip it. You need generic containers, for ergonomics and performance. I mean, compare C qsort to C++ std::sort.
The languages that “get around” generics, like PHP, include god containers in the runtime. The language I’m designing is also that way, I’d like to avoid generics preferably forever.
But there’s a tradeoff there. God containers are very flexible, and we’ve seen the ramifications of untyped PHP arrays.
Lisp manages it. Even if you do use type annotations.
No. This cognitive load is conceptual. You can't avoid it by using slightly different syntax.
2 replies →
I never understood the convention of using single letter names for generic parameters. I guess this started in C++ and every language has copied that convention.
I think that code would be a lot easier to read if the types were called IN and OUT or In and Out or TIn and TOut or something like that.
We all know letters are expensive ^^
I often use whole word for type annotation, when I can find meaningfull ones. I just type them in all caps to stay close to the convention.
I guess the single letter thing is laziness for a part. It's not simple to find words that represent the abstract idea behind the generic type without narrowing the possibilities. For array function, the Key Value from the sibling comment work but for more complex use case, it get complicated.
Swift generics tend to idiomatically use longer names, like Element or View or Content.
I’ve always done that in my typescript code bases too, and I’ve never regretted it
1 reply →
Completely agree and I personally name generic type parameters as I would name types and parameters. It helps a lot.
For maps, a convention is to use K and V for key, respectively Value.
I think that’s best as you’ll soon learn the “single-character capital letter ⇒ generic parameter” convention
Im pretty sure it came from the MLs, where you usually have a/b/c instrad of the T,U etc combo.
I dont find it confusing, as its pretty clear that it only an placeholder.
In generics the name usually does not matter or is REALLY hard to name so that it makes sense.
More specifically in Go where you have interfaces, concrete types and generics.
Fairly sure it would predate even that, and go all the way to lambda calculus, and predicate logic before that, and that's where my knowledge stops and somebody else can tell us where the current conventions around variables in logic and mathematics come from.
In ocaml (and I assume SML) it helps that the generic types have a `'` before them, so
What could be more idiomatic than:
for (int i=0; i<10; i++) { printf(”%d\n”, i); }
(Or the very similar Go equivalent)
If you having a hard time parsing that, due to the short variable name, i.e. if it’s a huge cognitive load for you, I suggest you switch career, b/c the IT industry is obviously not a good fit.
With that said, Go is explicit with suggesting short variable names for small scopes, and long variable names for bigger scopes. This a good practice in all languages.
In C# this is the convention.
It's a mix, because some stuff tends to just use `T`, but there's better descriptors elsewhere.
There's IList<T> but Task<TResult>
There's Action<T1, T2, T3, T4, T5, T6> but also Dictionary<TKey, TValue> and Map<TIn, TOut>
This stuff kind of "makes sense" once you're used to it, because it's difficult to say what IList<T> ought to have been called otherwise, IList<TContainee> is a mouthful, and Action<T1,...> simply suffers from the inability to specify an unknown number of generic parameters.
https://learn.microsoft.com/en-us/dotnet/api/system.collecti...
https://learn.microsoft.com/en-us/dotnet/api/system.action-2...
https://learn.microsoft.com/en-us/dotnet/api/system.collecti...
I believe Haskell did that for decades before C++.
Haskell was created in 1990, five years after C++.
3 replies →
We often forget that our profession (computer programming) belongs to STEM. Some (like Go 1.0 :)) wish to think it is Arts & Humanities. The sooner we realize that yes, it is OK and actually expected to bear a cognitive weight of "(b Box[T]) Map[U any](f func(T) U) Box[U]" the sooner we get back to reality... :)
Just because we can, doesn't mean we have to. I'd prefer to have some more brain-cache free to concentrate on the problem I'm trying to debug rather than doing type resolution in my head.
Please. I’m sorry, but you kind of can’t avoid needing to think about types unless you use a language like JavaScript which is super loose with its type conversions, and you especially can’t avoid in a language like Go. With generics in Go you don’t even need to prefill the types like you go with a lot of other cases, so I’m dubious about the cognitive overhead.
1 reply →
Programming language evolution has always been the pursuit of abstractions that enable expressiveness and simplicity.
Your comment boils down to "I'm smart", which in the end, isn't terribly smart.
Having simplicity and expressiveness as a goal, and a general direction of achieving things through lazy means is at the heart of mathematics and engineering.
Celebrate laziness and a want for simplicity. True simplicity is hard, but worth going after even where it threatens the notion that you're the smartest person in the room.
In terms of tooling, Go is one of the few languages which remembers that we are in STEM.
I wish it was arts & humanities.. those are some actually clever folks.
People should stop using these simplified high level programming languages with low cognitive weight, like Go. I only write assembly. ;)
(b Box[T]) Map[U any](f func(T) U) Box[U] _is_ for the Arts and Humanities.
Unless you're writing assembler in vim you're not STEM.
Why should I, as fallible human of limited short and long term memory, bear that cognitive weight when I have a perfectly good compiler on a computer to offload that particular cognitive weight to?
It's not good Go code anyway. In Go you would use a for loop. Just because Go has generics nowadays doesn't mean you should abandon good taste and write ML/Haskell/Rust/C# in it.
Sure it's a bad example. But you can't simplify something like this without losing type safety:
Maybe it's just familiarity, but I think it would look a lot more comprehensible with some punctuation. Just because a syntax is formally unambiguous doesn't mean it looks that way to humans.
Indeed, we're now one step away from monads. I know https://go.dev/doc/effective_go hasn't been updated for while, but it also seems to have been forgotten. "Go is an open-source programming language that focuses on simplicity ..." the page begins.
You've already been able to badly implement monads in Go for 10+ years. Why wouldn't you be able to implement them in a way that the compiler can enforce correctness of?
If you don't want it don't use it. It's that simple.
No it’s definitely not that simple. Code are read more often than written, no one works in a vacuum, especially not in open source. Also, when in Rome...
1 reply →
Apparently the people responsible for the simplicity retired. Since it's Google, some new people want to be promoted for adding features to Go.
I really understand your feeling, I escaped from C++ years ago when I was overwhelmed by meta programming (initially i loved it).
But anyway I find this in Go much more bearable.
As a C++ (including modern) developer for more than 20 years, I had written a "template" keyword only for a handful of times. Maybe once in every 5 years on average... :)
Unless you are a compiler/stdlib vendor or contributing to Boost, there are features that you just don't use it daily.
It looks more reasonable (literally lol) with syntax highlighting though.
Luddites don’t use syntax highlighting though.
Right? Sigh. I really dislike this.
There are 37000 programming languages, stop forcing every single one that gets popular to look like this.
Is it worse than having to create endless functions for each type pair?
Etc etc etc?
The T, U, and f names are the cognitive load here, because they are meaningless variables. For a specific solution, those would have meaningful names that would make it easier to understand.
> (b Box[T]) Map[U any](f func(T) U) Box[U]
Eh... I think you'd need to avoid generics altogether.
Map/Filter/Reduce is a bad example for an imperative language. But look at slices and maps packages, or the new proposal for container types. There are many good examples how generics are like salt to food. Another example is errors.AsType.
that's literally what Go was supposed to do! If I want a language like C++, I know where to find a language like C++ (it's C++).