OMVIF - Oh my version is FASTER !!

Let's imagine you have a legacy system. Lets call it Dragon. Legacy in the sense, no one knows whats going on in Dragon. Let's say the code base is *horrible* and millions of LOCs. So no one understands it.

But..Dragon juussst works fine...!

However, no one is brave enough to fight dragon (extend it? or just to be with it), because the moment you make a change, earth just stops spinning then starts spinning the opposite direction until you roll back your changes. And you have no clue how your change in dragon messed with earth's spin.

Some times you hate dragon, some times you respect it, love it ! wish you could understand it more.

But this is certainly not a good position to be. You know it better than me. So in such situations, there are many interesting things happening around you. One such thing is “OMVIF” or “Oh my version is FASTER”. This happens, when you decided *not* to touch the Dragon but do a part of Dragon in your own language/technology. You take a part, a very simple part, understand it, and re-implement it in your favourite technology. “Oh” you say. My version is FASTER than Dragon.

Now at this point. Long story short. Ask this question from you.

“What did I do *SPECIAL* (optimisations) to make it faster ?”

IF the answer is *NO*,  and you just did it the most obvious way, straight forward implementation, no optimisations !

Unfortunately if thats the case, 90% of the time, you are simply missing something in your implementation, which means your implementation is *FAST* because it is *NOT* what dragon does.

Or in other words, your implementation is *FAST* because it is incomplete.

So Dragon Winks.


Just think, If you didn’t do any *SPECIAL* optimisations, and even after that your version is faster, is that mean, Dragon is just plain dumb ? Can be.. But sadly it is very very very rare !

So next time when you feel “OMVIF” ! Just.. look at the dragon.

Are you a Clojure man ? here is a test.

Clojure is a fantastic language to learn and work with. This is a simple test you can do to figure out whether you are made for Clojure. When you first learn Clojure you think..

"Wow Cool !! Very little you have to remember ! So simple.. (+ 1 2 3 ) = 6"

Then after reading some Clojure code or learn more..you think.

"Mmmm.. Actually you have to remember certain forms and little tricky flags to do *cool* stuff. But its worth it..Very little"

Then after some time..one day you find this *new* directive (say ^).. you think

"Wow what the hell is this one ? Let me check the Clojure docs..mm nothing make sense (lot of ^s in different contexts)..let me do a text search in that my killer Clojure book (search for ^)..mmm nothing"

Then.."I should google, but how ? by this =  ^, Clojure or ^ + Clojure ??"

Then at this point, you usually do two things. You say..

1) "Clojure is not my cup of tea, I love you Scala."
or
2) "Wow this is getting more interesting..Lets keep digging,ask in Clojure forums, friends"

If you did 2) then you are a Clojure guy.
If you did 1) I suggest give it a another try..! It's worth to dig more given the mine is full of gold.

FP- Functional Programming.

I do value FP, respect FP , learn FP and admire FP every day. This is merely how I reason the 'Satus Quo' of current software development landscape.

These days (2000+) people use FP a lot. The reason ? It is easy to develop much correct (less bugs) code with FP. The reason ? FP is backed by pure mathematics. Some math theories related to FP are form 1800s.

On the other hand, OOP with non FP (object oriented programming) is called an old paradigm. The problem with the *old* OOP style is, bugs (less correct codes) and issues related to parallel programming.

FP has a strong mathematical background (Category theory..etc). OOP not. FP's success is based on the math behind the scene, which leads to develop correct code. If you use a FP language without adhiring to FP principals or mathematical concepts (rules), you still can produce inferior code. So, no FP language (Scala, Clojure..) will save you from a writing *BAD* code. What saves you is the math behind FP.

So now. Think of this. How wonderful it will be If we find OOP's mathematical theory. Currently GOF and other design patterns  are the saviour of OOP. But non of those are based on math. I think the reason we couldn't find a mathematical backing for OOP is not OOP's fault. OOP is much closer to how humans think (Object and skeuomorphism), so certainly, if there is any mathematical theory which backs OOP, it should not be from 1800s (as such - Category theory for FP). Such theory should be a complex or may be not yet even devised (Quantum Mathematics ?)

So, Is our decision to switch to FP from OOP for correctness based on our lack of knowledge about modern mathematics ?