Programming language evolution has always been the pursuit of abstractions that enable expressiveness and simplicity.
replyYour 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.
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.
replyPlease. 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.
replyNo need to insult JavaScript. In two out of three times the "JavaScript" written will be something like:
reply interface Box<T> { value: T }
function map<T, U>(input: Box<T>, func: (value: T) => U): Box<U> {
return { value: func(input.value) }
}In terms of tooling, Go is one of the few languages which remembers that we are in STEM.
replyI wish it was arts & humanities.. those are some actually clever folks.
replyPeople should stop using these simplified high level programming languages with low cognitive weight, like Go. I only write assembly. ;)
reply(b Box[T]) Map[U any](f func(T) U) Box[U] _is_ for the Arts and Humanities.
replyUnless 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?
reply