Having completed an earlier project, my colleagues and I sat down to review the team performance and what we could do better next. My colleague proposed an intriguing idea and we decided to randomly pick two components of our past projects that could be implemented independently from the rest of the projects and were easy to test. We rewrote the components from using OO (object oriented) to using PP (procedural). I was surprised with the result. The number of lines was reduced by about 30%. We were able to see things that were hidden behind the complex interaction of objects before, and simplified the codes considerably. Performance was improved by about 5%. This was no surprise because I always knew that OO has a bit of an overhead and the code simplification also helps. Maintainability is a bit subjective, but my colleagues and I think that the PP codes are easier to read and simpler to understand. The main obstacle in OO is with understanding the model employed. In our case, we has components that were outsourced to some offshore developers before, and we often had to rely on external documentation to understand the model they use. What was intuitive to them was not very intuitive to us. With PP, my other colleague who was not involved with rewriting the codes thinks that our PP codes can be understood by reading the source codes alone. However, the main selling point to me is the reduction in loc. For every 1000 lines of OO codes, we can save about 300 lines of codes with PP.
This experience makes me question many things and wonder whether the advances in programming for the past 40 years are really improvements over earlier methodologies. Everything I was taught of in college now seems questionable. Some people may argue that -in my case- it is probably a case of bad OO design and that if they get it right, OO should yield substantial benefits, especially when it comes to maintainability. The key phrase here is *'if they get it right'*. OO allows abstraction, including over-abstraction, that is limited only by imagination. How do you know when you reach the right design? Returning to the topic, instead of arguing about hypothetical uses of generics, we should test it in real projects and see whether the benefit of generics outweighs its cost. There are other languages that support generics and may be used to test this. I personally have doubts over the necessity of generics. I think *if they get it right*, generics should be beneficial. The key here again is '*if they get it right*'. The room for potential abuse of generics which leads to incorrect design probably outweighs its benefits. On Wednesday, June 22, 2016 at 8:28:01 PM UTC+7, Sean Russell wrote: > On Tuesday, June 21, 2016 at 10:29:37 AM UTC-4, Henry wrote: > > You still haven't provided any argument why generics is indispensable. > > That can't be the litmus for language feature inclusion; if it was, Go > would resemble ASM. > > In my personal experience, something North of 50% of my non-trivial > applications could have been more simple with some form of generics > allowing me to reduce code duplication. In particular, any application > dealing with demarshaling of data from a large set of similar functions > (e.g. web calls) are good examples. Have 30 functions to make the same web > calls and perform the same demarshaling calls -- especially where the web > call may be more complex, as in a SOAP call -- does not make the code > cleaner, easier to cognitively parse, or more safe. Indeed, in almost every > such case, generics reduce code duplication and make the code safer from > bugs, and easier to maintain. > > Indispensable? That's subjective, and very few language features satisfy > that requirement. For me, the strongest argument against it is that if the > core Go team can't think of a way to implement it cleanly and efficiently, > then I trust it's a hard problem. I'm sure they've looked at it; it must be > the single most commonly requested, hashed-over, and proposal-backed > feature. > > --- SER > > -- 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.
