Thoughts on Programing Paradigms
It’s been a while since I have posted here. That doesn’t mean I am inactive. iGreekNews needed an update, and my full day job is also taking me too much time. I have no regrets, however. This amount of work comes with a great amount of knowledge.
The last few months I have been able to tackle with many mainstream languages in addition to the ones I already knew. I have also been involved with some server-side technologies. That made me go back and rethink about the strategies I use while programming in any language. What makes a good code better? What makes a bad code inoperable and difficult to understand? It would be way too easy to just blame inefficient comments (or lack of any commenting whatsoever), repeated lines of code that could be put in a single function scattered all over the place, and implemented multithreading without being careful of the state of any object at the time the program access it (or before that).
No.
What really makes a bad program better, and a good program best is the programming paradigm a software engineer follows while developing the program/service. A programing paradigm is, according to Wikipedia:
… a fundamental style of computer programming. (Compare with a methodology, which is a style of solving specific software engineering problems.) Paradigms differ in the concepts and abstractions used to represent the elements of a program (such as objects, functions, variables, constraints, etc.) and the steps that compose a computation (assignment, evaluation, continuations, data flows, etc.).
But there is more to it. Programing paradigms we use while developing actually form our own programming characteristics while developing. It actually defines a good or bad programer and distinguishes him from the rest.
C-like languages exist for many years now, and many software engineers I have encountered tend to “port” language features from one language to another. Such an example is something like “static MyappDelegate * delegate” inside a class implementation in Objective C, or trying to do sequential multithreading operations in Java (like NSOperation in Objective C). And yes, I think Java is a C-like language, albeit a much simpler one. I have seen such code scattered all over the place, even by programmers who really believe they write code decently. And they are, but they just refuse to comply with the rules of the language they are writing in.
Part of improving one’s programming language skills is to try and adapt to different programing environments. Books will surely help ease the process of adaptation, but the most important thing is to always keep your eyes open. See another person’s code, question it, improve it, and use it.
Just to share some thoughts, nothing else.
By the way, I stumbled at a great article written by John Carmack himself, the head at ID Software, and perhaps the inventor of the most important aspects of today’s gaming technology in terms of programming. He speaks about implementing functional programing notions into traditional imperative programing. I think it gives plenty of food for thought.
http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/