Pragmatic EntropyProud Purveyor of Bytes and Pixels Since 1980

In the interest of furthering my knowledge of Ye Olde Computer Science, I’ve taken a slight interest in Functional Programming. For the neophyte, this is a different paradigm than what is generally standard programming, mostly relegated to boring university papers and phd students. However, it can have some benefit in the real world, and I’m a proponent of “knowing more” rather than “knowing less.”

I’ve still only seen the tip of the iceberg, but one thing that I have found is that my own programming as of late has been geared more to the functional side, rather than traditional Object Oriented approach, without even knowing it! For example, I’ve never really had long chains of inheritance and complex design patterns running amok.¹ Most of my classes don’t generally keep their own internal state; other “helper” classes do that. This always made more sense to me, and was much easier to test and maintain, as well as explain to other developers (especially new ones).

Even more as I have been writing a bunch of database interaction code recently, I kept thinking there has got to be a better way to do this, since it was very repetitive, but not enough that it would have been easy to simply make a method or base class or something. Turns out that a Functional approach would have solved all my problems relatively cleanly and easily.

So, maybe I’ll actually become another one of those annoying converts. One of the neat things about C# (2.0 anyways) is that it has the capabilities to do both standard Procedural programming as well as Functional. 

1. Not that there is anything necessarily wrong with those things; in fact sometimes they are very helpful.

1. Comments:Be the first to add a reply.
2. Find more like this: Programming
3. Get FREE updates: Subscribe to RSS feed: