11–20 of 80 posts
Worse nomenclature than any other big language I can think of, including Go and Python. Why should this package be called "algorithms"?
This is exactly what algorithms are at the level of almost any language's included libraries. The name seems spot on.
One issue with Go's lack of generics is exactly that it can't have such a package (and have it be type safe, fast, and work across all relevant types), except with repeated code.
Sounds to me like a job for a DSL that compiles down to Golang for the final output. That way, the repeated code only exists in the Golang output and not in the code that humans actually write.
One issue with Go's lack of generics is exactly that it can't have such a package (and have it be type safe, fast, and work across all relevant types), except with repeated code.
Sounds to me like a job for a DSL that compiles down to Golang for the final output. That way, the repeated code only exists in the Golang output and not in the code that humans actually write.
https://blog.golang.org/generate
Now I'm wondering if you joke was not actually a joke.
One issue with Go's lack of generics is exactly that it can't have such a package (and have it be type safe, fast, and work across all relevant types), except with repeated code.
One issue with Go's lack of generics is exactly that it can't have such a package (and have it be type safe, fast, and work across all relevant types), except with repeated code.
Yeah, though a solution is in the works, and looking pretty likely to happen. Here's the official draft design for generics or "type parameters" in Go: https://go.googlesource.com/proposal/+/refs/heads/master/des...
In all seriousness, it feels like go's reputation of simplicity is at odds with its design. Instead of making a simple and highly generalized core from which anything can be composed, it has a specialized, familiar core that engineers are comfortable with.
When I take this question further, I begin to wonder why we even use text syntax for programming. What if we just had a graph structured programming "language" that is edited indirectly through different projected syntaxes that aren't necessarily monospaced text. Almost like lisp, but translated into different frontend languages, potentially graphical. (Maybe off topic but whatever)
If you haven't seen it, check out the 2018 WWDC session "Embracing Algorithms" (https://developer.apple.com/videos/play/wwdc2018/223/). It's worth watching, even if you don't work with Swift.
One issue with Go's lack of generics is exactly that it can't have such a package (and have it be type safe, fast, and work across all relevant types), except with repeated code.
Sounds to me like a job for a DSL that compiles down to Golang for the final output. That way, the repeated code only exists in the Golang output and not in the code that humans actually write.