On Thursday, 23 June 2016 07:59:16 UTC+3, Henry wrote: > > > 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? >
I've seen similar reduction or increase in readability, in multiple ways, i.e. going from PP <-> OO; OO <-> PP, PP <-> FP, FP <-> LP, of course the reverse as well etc. I've even gotten into a habit of prototyping critical parts in multiple languages. I suspect the major contributor in rewrites isn't the new paradigm, but rather the paradigm shift itself. You notice new ways of compressing/cleaning the code, but at the same time you can retain ideas from the previous iteration. The new paradigm/language gives you new constraints and at the same time relaxes some -- resulting in easier creative thinking. In essence you combine the "good design from OO" and "good design from PP". *Obviously, some of these translations will be lossy and make code larger -- so you will hit a limit eventually.* When you talk about OO, it's useful to mention what language you were using, as there is no gold-standard what OO is. Even in a particular language you could write it in multitude of ways. I've noticed, that the major contributors to complexity in OO, are inheritance and displaced methods *(e.g. multiple objects interact and the method describing interaction is put into one of those objects)*. Both cause fragmented artifacts - in one case the inherited type is scattered around several places, in the other case the interaction code is scattered between objects. With PP you tend to use your instincts more (rather than some principles), and end up putting related pieces together. However it doesn't mean you cannot fragment the code in PP (http://number-none.com/blow/john_carmack_on_inlined_code.html). Now, sure, you might not agree about how big issue inheritance/methods are in OO. What I'm trying to get here is that there are deeper properties than the paradigm, language or a feature that causes problems. It's the same with generics approaches -- there are underlying forces that cause these bad-designs, and one of the questions is, how to minimize the bad-design while still keeping the benefits. 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.
