As I said, it's not because something sophisticated exists in a language that you have to use it.
It's quite the opposite. But indeed, with Go you don't have the problem, because these features were removed from the language to avoid the temptation to use them. I can understand that, because many developers have no enough discipline or taste for simplicity, but the unfortunate price to pay is that in the few cases where it REALLY helps in making clear code that is easier to understand and to maintain, that is sad. There are many possibilities in D which are not needed in Go, but I don't think why you think that genericity (ex: Pool<SomeType>, etc) and polymorphism (same method name for a similar argument of a different type) are considered as evil. Properly used, they have their use place in any modern language like Go. I personally that using interfaces when genericity was a simle and obvious solution is what requires more cleverness. And I'm not saying that using interfaces for this is a bad solution, I'm just saying that I don't see the simplicity advantage in it. Because everytime I have to use interfaces or duplicate implementation for such situations, I don't feel at all that Go is helping me implementing easier or simpler code. On Wednesday, August 2, 2017 at 10:47:36 AM UTC+1, Chris Hopkins wrote: > > > > On Wednesday, 2 August 2017 09:46:08 UTC+1, ecstati...@gmail.com wrote: >> >> And btw, this doesn't mean that just because there are genericity and >> polymorphism in D, that I must use them. >> >> No, but the person reading your code must understand them. Not only that > but they must understand the "clever" way you have used them. > I came to go for the concurrency, I stayed for the fact that I have yet to > come across a piece of code I can't quickly understand. > > Every other language I come across that has "advanced" features seems to > be an exercise in programmer vanity showing off how clever they are. I > spend way more time & brain power trying to reverse engineer someone either > showing off their "clever" use of an obscure part of the language than they > could ever save with a few less keystrokes. > The trouble with gerericity and polymorphism and operator overload and all > the others are they hide functionality which is great from an academic > perpective; when it comes down to debugging what on earth is going wrong > they are IME a nightmare. > > I think this is why this is turning into a holy war on this list, they are > without a doubt great ideas that in theory hide complexity and provide > better abstraction and lots of other good things that we should all strive > for. The trouble is, in practice many find them to be too powerful for real > world use except in certain carefully controlled examples. > > I get the impression you want them to make writing code quicker, do you > not then share the opinion that in practice for large poorly understood 3rd > party systems they make comprehension harder? > > Regards > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
