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.
