aberrate_junior_beatnik@midwest.social
on 01 Sep 2023 12:03
nextcollapse
If this is the worst you can come up with, 100% worth the price, would recommend ad-hoc polymorphism 10 times out of 10.
armchair_progamer@programming.dev
on 01 Sep 2023 13:27
collapse
Plus the issue remains if the author replaced Vec with Vec of Vec instead of Option of Vec, or if iter().count() meant something completely different than “count # of iterated elements” (both pointed out in HN comments).
davawen@programming.dev
on 01 Sep 2023 16:57
nextcollapse
???
I fail to see the point of this blog post.
The example given makes no sense (maybe because it’s very simplistic, and a more complicated one would show the point better?), you would NEVER use .iter().count() if you had direct access to the Vec. The iterator is more general in this sense.
You would use it if, say, your Settings struct was generic over an Iterator type, and in that case it’s the whole point, isn’t it?? Like what???
Plus, I wouldn’t say this erodes type safety, it’s a lot more like a logic error.
armchair_progamer@programming.dev
on 02 Sep 2023 01:35
collapse
Yeah this one’s a miss on my end. I saw “ad-hoc polymorphism is UNSAFE?” and well, it does a better job reinforcing that ad-hoc polymorphism is not unsafe.
Author should have wrote a piece “how even type-safe programs can fail” and used his example to show that. Because what this really shows is that type-safety doesn’t prevent programs with the correct types but bad semantics. But that’s not ad-hoc polymorphism; it can happen anywhere (sans ultra-specific types) including even the author’s workaround if he used Vec<Vec instead
tram1@programming.dev
on 01 Sep 2023 18:04
collapse
threaded - newest
If this is the worst you can come up with, 100% worth the price, would recommend ad-hoc polymorphism 10 times out of 10.
Plus the issue remains if the author replaced
VecwithVecofVecinstead ofOptionofVec, or ifiter().count()meant something completely different than “count # of iterated elements” (both pointed out in HN comments).???
I fail to see the point of this blog post.
The example given makes no sense (maybe because it’s very simplistic, and a more complicated one would show the point better?), you would NEVER use
.iter().count()if you had direct access to the Vec. The iterator is more general in this sense.You would use it if, say, your Settings struct was generic over an Iterator type, and in that case it’s the whole point, isn’t it?? Like what???
Plus, I wouldn’t say this erodes type safety, it’s a lot more like a logic error.
Yeah this one’s a miss on my end. I saw “ad-hoc polymorphism is UNSAFE?” and well, it does a better job reinforcing that ad-hoc polymorphism is not unsafe.
Author should have wrote a piece “how even type-safe programs can fail” and used his example to show that. Because what this really shows is that type-safety doesn’t prevent programs with the correct types but bad semantics. But that’s not ad-hoc polymorphism; it can happen anywhere (sans ultra-specific types) including even the author’s workaround if he used
Vec<VecinsteadI think the author does not deserve Haskell