@OderWat > "This is so bad that several bigger c++ projects completely abandoned > templates. " ... is still not backed by even one example. You gave pointers > to Templates are very useful but are advanced and should not be overused > (google) and I personally don't like templates, but it is fine if you can > handle them (C. Muratori). Of course templates make stuff more complex and > can harm if you use them wrong or overuse them in general. Thats merely true > for everything though as Paracelsus pointed out a long time ago. Then you > imply that the reason why c++ templates are "bad" they also "may" make Nims > generics bad too. Something which you didn't experienced yourself (yet) and > nobody else did afaik.
You are completely right here, and I should change my words in my original post. But you should also accept my experience that I had with templates. I worked in a project that grew since 2001 I think, and it is based on a lot of c++ template programming everywhere. It is a university project where a lot of Students work for about a year, and then leave the project again. This inherent overuse of templates encouraged the students to adapt the style of template programming, and they were used even more. Basically every function and datastructure that used a double was templated on the floating point type, because maybe one might want to compile it one day with `float`. So basically everything was templated. Compilation time exploded, and compilation was only possible on the cluster. My computer at home could not build the project I was working on at university, because it did not have enough RAM, and the cause was the overusage of templates. Since this day my perspective towards templates has changed, and I am very careful on the decision wheather I should use templates or if it is possible without. And I have not seen anything in the nim programming language that promises me that the same thing would happen the same way in the Nim world. There are simply no projects in Nim that have grown over 15 Years. > At the same time you promote a feature which could be seen much as a "patch" > for the missing generics in Go. In fact I remember that I read complaints > about Go not having a real generics implementation and have to copy code > eventually even with interfaces and delegates at hand. I do miss generics in Go. It somewhat works to live without them, but it is not nice. Just look at the [sorting example](https://gobyexample.com/sorting-by-functions) and you know what I mean. But I do not think that the interface type in Go is an afterthought to patch anything. The whole language is designed around the interface type, and I truely thing the go interface is a better solution to polymorphism than the vtable at the beginning of a class in languages like c++ C# and Java. > Then you prove (in my eyes) how ugly and cumbersome it is in the "black box > cast ptr macros" implementation you gave, while later you discard a real > elegant "see everything" functional approach to the problem as "cheating". I am sorry I don't understand than sentence. I don't think functional programming is cheating or bad. I really like and encourage functional programming. But it misses the point in what I tried to show. > You write: "I just don't like implicit conversions, I think they are scary, > because they hide procedure calls from the code reader, and could therefore > decrease code maintainability." but isn't this exactly what Go is doing in > its implementation? Yes it is. I will change it to use implicit converters. > Interfaces may be the best and elegant solution for Go programmers. But I > think that I would like to trade them for real generics and templates (which > I actually did). That is completely OK. But maybe you want to be open for an alternative for certain use cases. > EDIT: Using your macros together with a converter to hide the ugly details is > cool and may proof being useful. Thanks a lot.
