Dream Maker Design Ethics 1: Computational Thinking

ID:1098148
 
Dec 25 2012, 3:14 pm (Edited on Dec 26 2012, 3:12 pm)
Hello everybody!
Dream Maker Design Ethics 1: Computational Thinking


{ In this topic I am hoping to share some Software Designing Ethics, or in less informal/inaccurate term: code designing principles. The main two aims of this topic are first to provide a clear structure that you may take into consideration when designing your code, and bringing it to life in a very consistent form, or manage your already existing code and increase its efficiency. The other aim is to hopefully suggest possibly commonly shared ideas that perhaps can take Dream Maker one step ahead, and yes, I am pointing at the core. This topic is just the introduction to these ethics. It is just some effort based on my studies experience, and when it comes to designing expect tense debate - this provides good example of how each programmer is unique from one another -obvious but amazing fact-. Please help me in making this topic a helpful one by fixing any mistake you spot, and excuse my describing style if it's weird for you. }


The interesting part starts from here, and first things first. BYOND engine's language is just another language, one of hundreds of languages out there, some are main languages and some are literal jokes. This powerful engine provides you with many many options to drive your software to its early form. This system is not responsible for shouting at you nor interfering with your logic, no code following the system's structure is considered "correct" nor "wrong". Now you go out there and 'Design' your work's form, whether it is good looking or tempting, ugly or sad, as long as the system-bio brought it to you as you wanted, that is it. Many people are simply blinded from their code's form, which is just like a baby - it needs attention and continuous effort, otherwise it is your child 'who' went wild, explanation follows.



Logic, Algebra and Thinking

These three are the Space, Materials and Sun in this 'galaxy'. The definition behind it all, and what actually make Algorithms (Earth) a prosper land. A quick look at the history of this galaxy: in the 9th century, a man called Al-Khwarizmi (an Iraqi mathematician) had discovered, or rather set clear/invented Algebra. Skipping details, this has evolved to mean all processes for solving tasks. "Algorithms" are sequence of finite instructions, step-by-step problem-solving procedure, it accomplishes some end. Now many languages nowadays disagree with some details here, but nothing made that possible except this galaxy, to begin with - it is part of this galaxy after all.



Elegance = Simplicity + Convenience + Effectiveness

You may be questioning this, and why on earth would you list an english dictionary to start talking about specifically DM coding.. I am trying to set the frame for you before starting to draw. What we are concerned about is the characteristic of Algorithms: performance, reliability and Elegance. Software designing is nothing but a paranoia based on this "Elegance" noun.. I would say 'theory' if you agree. Programming your code and making sure it works as I mentioned, is like bringing this form of thing to life. Just the first step into it. Designing however is concerned about how this form will grow up: scalability, how it will continue living: reusablity and most importantly the characteristic balance of this form: neatness and understandability.



No matter how much humans share with one another, they remain Unique!

Imagine baking a cake, think of the steps needed to do that, what could they be? In circumstances like this one, one would assume resources, skip obvious steps, and achieve same goal with different taste and decor. A pro cook may explain that in one large procedure (and I know a mom who can say it in two words when I ask her to make one myself.."bake cake-dough"!). Let us consider these steps: firstly mix flour milk and two eggs, secondly add the desired amount of sugar, then stir and as an option add nuts, finally bake for 30 minutes. These steps taken will indeed result in a baked cake, but how did we managed to do it? That is the question. We have suggested fixed number of eggs. Why bother with nuts if we wanted a sponge cake? And in this case, will it be a cake assuming we have added very little milk or sugar? It is not as clear or efficient as it could be. Algorithm as we said is a sequence of steps, just like the step-by-step procedure that resulted in the cake being baked, it is straight-forward and give the wanted result, however these steps might not be the best way to do it, there may be flaws which could be dealt with and a more efficient technique to do it. A good algorithm would optimise the solution, and is much more convenient. It does not go through general steps whenever it is possible to avoid doing so. This is what is called Algorithm's naïve-ness and complexity*. Now that is what software designing suggests, the evaluated procedural approach, quality code. In DM, an object oriented, good design is not just about a rarely buggy game (or say perfectly working system/game engine), it is also about the code which players will almost never see or touch. It is all about You, and your future You, most likely people who will take and work with your code too. You sure do not want to permanently delete your source code once you have written it and got people play your game do you? Sad story, many 'programmers' shoot their game right on its release day, some programmers abandon their desperate child on the day of its birth.



My Fully-Functioning Game is Soulless, Starting from Release Date!

Why.. why you ask? Game designing might look like tweaking and tiding your code but it is more than that. Remember what I said about the 'system-bio form'? Ok, this needs to evolve, live healthily, and have a reasonable spoken language. Game or Software Designing specifically makes sure your game's code can be reused, can be extended or can be replaced/totally deleted, without affecting the whole form - if this form had an accident, taking off the arm for a surgery will not kill it. What will happen to your game, if a certain aspect in BYOND has been changed.. how far will it suffer? Well.. as much as it is dependent on that (something like that will hopefully not happen). Do not misunderstand the idea, no code is totally independent, however designing the code is much about making it all "manage itself without much interference". For this, I have many points that I will hopefully demonstrate later on, critisising some aspects in our beloved engine (no promises with my tight schedule though..).

"No worries, my code came alive and would keep walking even if I took its stomach out.. and is maintainable, living a happy long life.", ummm.. not yet. We have only discussed a small portion of the magical word, Elegance. Although I am considered a beginner in Dream Mak-ing, I have seen much and many desperate forms flying around, with source codes for games here and there, I rarely found one which meets my designing principles and schemes standards. Some of the nightmares I have seen include a dirty form which lists every happy-together-code-chunks in one place, another one generalise some or most of its code parts' characteristics, a code that lives on CPU and virtual registers, the worst so far is.. (a pause here and a leap of faith).. is a code which creates a weird library, just another sub-sub-away-language that it is almost encrypted, before using it for the actual game. I would confront the developer and mention that in future, he might never be able to tell what his code does, no, not with his decent comments.. not with possible future updates.

Elegance.. and what is with all that fuss behind it. An important aspect derived from this magical word is how neat/lovely/cute is your code. Would others understand it? Love it? or just deal with it as an acquaintance form? Would our lonely form stay single forever..? *scratching eyelids*.. It all depends on your designing skill - how good are you with code decoration.

This leads to mentioning many many.. never ending designing views and principles, and how people would deal with their own form's character. Pointing on topics that hopefully, will be discussed, such as Duplication, Cohesion, Re-factoring, Coupling and the thing I wanted to talk about so badly: Encapsulation, Visibility and Responsibility-Driven Coding.



{ If you are reading this without having skipped, congratulations! I hope this was a fairly explained introduction to Computational Thinking, analysing Software Designing from logical perspective (with my decent describing scheme), and the principles which have been the sole topic for Software Designers. I wanted to achieve the second aim of this topic, but perhaps the right time is not just yet.. I did not expect myself to introduce the idea of 'Design Ethics' topics in such a long topic, but I hope it was worthwhile and I really wish to have the opportunity to continue writing, in my tight schedule, and would be honoured, if managed to help developing the engine, even with the very least idea. I appreciate all fair comments and if there is something specific you would like me to talk about in detail later on, I will try my best.}

* Thanks to Magnum2k for suggesting this to be added.
Dec 25 2012, 3:29 pm
Very interesting. Thank you for the post.
Dec 25 2012, 4:34 pm
In response to Kidpaddle45
Glad to hear that. Thank you.
Dec 25 2012, 4:48 pm
Ok, so now you have me waiting for the next installment.
Dec 26 2012, 3:40 am
In response to Yusuke13
You will like it :)
Dec 26 2012, 9:29 am
Please don't take my criticism personally, but I find this incredibly hard to read, not very organized, and you seem to be throwing around abstract design philosophies without actually explaining their implications.

For example, you said you saw projects that "lists every happy-together-code-chunks in one place, another one generalise some or most of its code parts' characteristics"

What the heck do you mean? How are these "happy-code-chunks" listed? What are code part's characteristics, and how can they be generalized? Can you show actual code as an example?
Dec 26 2012, 10:13 am
Interesting post. Though, I did render some segments trivial. I think some examples(i.e., code snippets), especially the ones where you tackled algorithms, should have been present. I just don't mean providing a simple psuedo-code to a snippet, either--I mean step-by-step evaluation('naive-ness', and complexity) of said algorithm.
Dec 26 2012, 2:16 pm
In response to Magicsofa
Magicsofa wrote:
Please don't take my criticism personally, but I find this incredibly hard to read, not very organized, and you seem to be throwing around abstract design philosophies without actually explaining their implications.

For example, you said you saw projects that "lists every happy-together-code-chunks in one place, another one generalise some or most of its code parts' characteristics"

What the heck do you mean? How are these "happy-code-chunks" listed? What are code part's characteristics, and how can they be generalized? Can you show actual code as an example?

I appreciate your post and reply. I am sorry for this confusion, I have not intended to explain much here and yes, I admit I have thrown many abstract design philosophies without actually explaining them, but this is because as I have mentioned in the topic just an introduction to the ethics I am wishing to explain.. I was surprised I could mention much for an introduction to be honest. But I do not know why you found this hard to read and rather unorganised, excuse my clumsiness however and I would appreciate it if you suggest other way to introduce the topic, it is just a 'frame'.

As regards your question, I have meant the expansion and generalisation of code, perhaps duplication too. "code part's characteristics" were not the best choice for words, but I meant treating different code parts similarly and vice verse.

Overall, I just wanted to say that it was hard to actually show all of this in code examples, ten examples would not be satisfying at all so I decided to give examples when I write about specific terminologies and design theories. My humble theory experience and english contributes, so I welcome suggestions and criticising.
Dec 26 2012, 2:26 pm (Edited on Dec 26 2012, 3:10 pm)
In response to Magnum2k
Magnum2k wrote:
Interesting post. Though, I did render some segments trivial. I think some examples(i.e., code snippets), especially the ones where you tackled algorithms, should have been present. I just don't mean providing a simple psuedo-code to a snippet, either--I mean step-by-step evaluation('naive-ness', and complexity) of said algorithm.

Thanks for the good point, I have totally forgotten to actually talk about it when I was talking about the cake example, which in first place supposed to explain the step-by-step evaluation.

I have edited the paragraph explaining the cake example. But I would not add code snippets at this stage - it is better to talk about each case separately.
Dec 27 2012, 3:12 am
I dunno what you're trying to explain or convey, if I'm honest. There is kind of a vague air of 'one should try to create elegant code', but with no real sense if how, or what elegant code is.

In your defence, you can't easily explain what elegant systems look like or how they come to be, as it's an experience thing mostly.

I went over the post briefly with Alathon, as oft happens with these things. There is a lot of words, not really a lot on content, in my opinion. Could you put each point into a sentence for me, and point to each paragraph that tries to cover it? That would probably be a good start for me to provide you with feedback.
Dec 27 2012, 4:16 am
In response to Stephen001
Stephen001 wrote:
you can't easily explain what elegant systems look like or how they come to be, as it's an experience thing mostly.

That is true, design ethics are much about theory, philosophy and 'words', and it only prove efficient when put into practice, in my opinion. It is not easy to explain, but at least I would try to explain it.

Could you put each point into a sentence for me, and point to each paragraph that tries to cover it? That would probably be a good start for me to provide you with feedback.

Yes sure. I firstly tried to introduce Algorithms and describe its nature and definition, some of its characteristics that design ethics are concerned of. Through out the topic, speaking generally most of the time about these characteristics, with only brief explanation (eg. Efficiency, Elegance). Then speaking about problem-to-solution and the possibilities/manners of losing efficiency, with examples of design ethics abuse.. Headings 3 and 4.

An expert programmer such as yourself would immediately understand that this is nothing but general ideas, and not much detail. However I believe lot of new programmers find these concepts new to them, so just speaking about little detail would create the frame as I mentioned over and over.
If only 20% of this topic was informative, then that is an achievement for me, especially in this philosophical aspect which is much about 'words'.

Dec 27 2012, 4:56 am
A historical approach is usually better.

Take for example, coupling. Coupling is basically how closely dependent one piece of code is on another. If they are very dependent, we call them tightly coupled. If they aren't very dependent, we call them loosely coupled.

Now, the reason we care about coupling is because back in the 80's, we used to right blocks of code that shared variables. Then, as you were making your programming, you'd decide one of these variables needed a new possible value, or even changing entirely. This means that you'd need to change every block of code using that variable.

Which was fine, except that meant you usually duplicated error checking code, maybe missed handling some values, and so introduced bugs, some very hard to detect by running the code. Similarly, the bigger the codebase got, the longer it took to make changes. Basically, things were usually tightly coupled. We discovered depending on variables between areas of code tended to do this.

So what was the solution? How could we reduce that dependence, reduce that chance for bugs, make new features and changes to existing features less time consuming to add on bigger code bases? Basically, how could we make our code loosely coupled?

Well, some clever sods found our answer (part of it, anyway) in the early 90's, by introducing this idea if having objects in code. At first this didn't change a lot, people just put variables on objects and depended on those. We still basically had the same variable change issues.

But then we started to use procedures defined on objects, and use those to access the data we wanted, instead of just accessing variables. The difference is subtle, but the effect is massive.

You see, you can make quite complicated changes to the code in a procedure, and as long as it takes in the same data as before and returns the same type of values, code that depends on it doesn't usually have to change, or even be looked at in some cases.

Suddenly you can make variables on an object change values, even remove them or add new ones, and you only need to change the procedures on that object. Not the 200 different places the object is used.

Want green programming? Make the variable null, and make the procedure on your object set it when needed and return that set value. Code calling it is none the wiser about whether the data existed when they wanted to access it. Better still, they don't care. If you access data via procedures on an object and not their variables, you could make this change to any variables you want, and it is a 10 minute job, even if your project is 10000+ lines.

That's pretty cool. That is loose coupling.
Dec 27 2012, 11:30 am
I have no much more to say about Coupling :P good explanation.