Programming Paradigms
nicholasjames
Posts: 154
If you asked me a week ago what programming paradigm I tried to follow, I'd probably answer, "Until it works", or more likely, "Until the error goes away." However, I've recently been discussing the different ways of handling general tasks in NetLinx and have been trying to solidify in my mind what my particular "style" is and, more importantly, how to explain it.
As far as a specific paradigms are concerned, I was only instructed on object-oriented programming during my java days. Though I learned through certification, and other AMX written code, how AMX prefers to handle certain concepts, there doesn't seem to be any specific technique they use.
To be honest, I've only recently been reading up on this subject and, let's be honest, it's been mostly on Wikipedia. So, as I get the ball rolling, I apologize if I use phrasing that no self-respecting computer scientist would. For example, on the subject of modules in general, I would describe them as code that does one simple thing (like talking to a display), blindly reporting out to whoever is listening, while blindly accepting commands from whoever happens to know their language. Want to put that info on a touch panel? Then make a new module that knows the same language and only reports to the touchpanel what the display module just said. See? Sounds more like I'm describing Lilliputians than elegant lines of code.
I've heard it said that programmers discussing their style of programming is akin to discussing politics and religion. I think some of the discussions I've read on this forum bear that out! Risky or not, I'd still love to discuss how you think about code and, if any, what technique (or mix thereof) you think works best for NetLinx.
As far as a specific paradigms are concerned, I was only instructed on object-oriented programming during my java days. Though I learned through certification, and other AMX written code, how AMX prefers to handle certain concepts, there doesn't seem to be any specific technique they use.
To be honest, I've only recently been reading up on this subject and, let's be honest, it's been mostly on Wikipedia. So, as I get the ball rolling, I apologize if I use phrasing that no self-respecting computer scientist would. For example, on the subject of modules in general, I would describe them as code that does one simple thing (like talking to a display), blindly reporting out to whoever is listening, while blindly accepting commands from whoever happens to know their language. Want to put that info on a touch panel? Then make a new module that knows the same language and only reports to the touchpanel what the display module just said. See? Sounds more like I'm describing Lilliputians than elegant lines of code.
I've heard it said that programmers discussing their style of programming is akin to discussing politics and religion. I think some of the discussions I've read on this forum bear that out! Risky or not, I'd still love to discuss how you think about code and, if any, what technique (or mix thereof) you think works best for NetLinx.
0
Comments
It's much easier to use modern design patterns into Duet, mainly because you'll find a lot of Java examples of design patterns out there, and if you're unfamiliar with the purpose of the pattern you will find it difficult to translate into a netlinx-language equivalent. But roughly think of modules as objects(even though they are not) that can be instantiated. It's not quite 1:1, but it gets us far enough.