Archive for the ‘good thoughts’ Category

Dialogue’s Guiding Principles, or a Healthy Hatred of OOP two chain links

Dialogue’s Guiding Principles, or a Healthy Hatred of OOP two chain links

Well, it will be interesting to read the post.
However, I found out that problems among US programmers in terms of C++ is that they follow C++ techniques or new syntax etc, which are just supplemental rather than keeping philosophy of OOP and meta-programming.
Syntax-sugar is good. But problems of C++ is that ( don’t misunderstand that. As you can see I’m a long-time C++ programmer and I liked its initial paradigm a lot. ) a lot of features have been added to C++ for the sake of convenience ( with difficulty of using it ) or more power. People, who just judge others’ knowledge on C++ just by asking terminology and features, thus missing core values, love to use any new features.
Knowing such things are good and beneficial, but not always.
I’ve worked on pSosystem at Samsung and other systems where the greatest and the latest C++ features were omitted intentionally for the purpose of the system or unintentionally (just old C++ compiler). If people just stick to the greatest and latest feature and when exposed to such system, they are embarrassed often.
So, I’m always in the attitude of choosing common ground, which maximizes compatibility of source code and your knowledge compatibility.

Anyway, folks. Knowing more terminology and new features will make look more knowledgeable person especially here in the US due to its culture, but actually it’s not. What is more important is to know why you need to use this or that, philosophy behind of a language you choose, etc.

Here I see Objective-C code which is not written by people who understand Objective-C philosophy. They argue that they know, but if you see such code, ou will be able to see that they don’t understand the philosophy.
They oppose Objective-C or any other language without understanding their philosophy. Criticism can be good only and only if people criticize after understanding philosophy or background history on why this language/system is designed as such.

So far, my experience here in the US is that when interviewers were too picky and just judges people by asking if the interviewee knows(memorizes) one thing, I usually found out that their source code were dirty and messy in every angle.
If an interviewee is not a liar or a salesperson who wants to sell himself rather than an engineer, they tend to memorize terminology etc. But if they are engineers, they know but at the moment of being asked, they may not answer the interviewers question. It’s not because they don’t know about the answer, but they can guess something else.

For example, I’ve been asked like “implement this thing using STL.”
Well, I use Win32 collection APIs, Cocoa/Core Foundation collection APIs and also STL. Also I use boost. They are similar. If you happen to use Win32 collection API for the week when you are interviewed, you can temporarily forget STL. But if you look up document, you can quickly write in STL. Then doesn’t he know the STL?

Here in the US, although they say they are Objective-C programmer, they write in C++ and STL mostly. So, they can remember STL syntax.

I’m different. When I implement Win32 code, I stick to Win32 stuffs mostly. When I implement Cocoa/Core foundation code, I stick to them.
If I need to implement something common code, which I may need to use on Window / Mac / iOS/ Unix, I write with pure C/C++/STL. Then, I can temporarily forget one syntax. But does it mean that I don’t know about it?

I’m versatile person. However, the way US people interview others are not like that and they stick to one thing and say they are “the other” programmer.

Another example is … I’m asked how to implement XOR in C++ while being asked about bit-wise operations. So, I told him it’s ^ operator.
He said “No.”
Actually in the conversation, he jumped from logical operation and bit-wise operation. So, I wonder why he said “No.”
Well, what he wanted “DeMorgan’s law” to express logical XOR.
Damn.. then he must be clear on that.
In Korea, DeMorgan’s law is taught in middle school. Everybody knows DeMorgan’s law. Well, actually what is taught here in the US are mostly taught in middle school or high school like calculus, probability etc. Well. some are taught in here too in high school. But compared to the level of things taught in Korea, well here.. I understand why Obama mentioned education in Korea, although I oppose to his intention.
Anyway, then he treated me like a person who doesn’t know C++.

What the..

commenting or documenting…

When I got interviewed, people tended to ask me, “Can you use Doxygen?”, “Can you use ‘some other document generator’?”.
Usually, when I am asked like that, it turned out that their documentation or whatever stuff they asked was not good in the company.

Commenting, or documenting in source files should be part of architecture, design or planning.
It’s not something you are to write after you implement something. It should be written before you start implementing something and while implementing.

What I mean is this. Commenting/Documenting is for maintainability or help for easier understanding of code.
If people make fun of you when you say “How bad it is! There is no comment!!”, then it’s Ok to treat them as non-professional people.
They will say “Real S/W engineers should be able to figure out without comment.”

Well.. they are only half-right. Sure. If you are a person who can think. Sure.. you can figure it out. However, just to use something and maintain, if you need to spend too much time, it’s not good. Commenting is to help that case. If it gives you an idea what the code part is for, you can get a pre-image to the code block. Then you can figure out things even quicker. Also, you can understand the original authors’ intention, suffering or odd situation they were in.

However, another very important reason for commenting is this.
It helps you to plan things better.
For example, even before writing, you can use your IDE/source code editor as a scratch paper like this.

void MyClass::doSomethingGreat( void )
{
// 1. Retrieve data from twitter

// 2. Check if there is user object in the response data

// 3. ...
}

Then, those commenting can plays very important role to aid you to organize your idea and split big task into small chunks.
You can get more rigid idea on what you are going to do. Sometimes by writing as such, something ambiguous can be clearer.
Also, after you write code, it can help you to locate interested portion of code quickly.
Then, it becomes great comment and documentation for itself. You don’t waste your time in writing comment/document. Your design time becomes your documenting time naturally.

Another very important point i would like to address is… Please use and pick terms others can use. Don’t use your own abbreviation and explain things really.

Here is a good example from twitcurl project.

/*++
* @method: twitCurl::mentionsGet
*
* @description: method to get mentions
*
* @input: sinceId - String specifying since id parameter

Especially take a lookat @input: sinceId line.
What is ‘sinceId’? that will be the question when you first confront the line.
Does “String specifying since id parameter”  really explain what sinceId is?
How about this?

/*++
* @method: twitCurl::timelineHomeGet
*
* @description: method to get home timeline
*
* @input: sinceId - the post ID for the last retrieved post.
*                                  Post with IDs after sinceID will to be retrieed

Isn’t that better? Anyway you should refer Twitter’s API documentation, but even without it, you can figure out what the sinceId means in that context.

I don’t count comment like the one in the mentionGet method.
You should not say you write comment if you write as shown in the mentionGet method.

창조는 어떻게 교육되나? ( how creativity is taught )

The title can sound weird, because creativity is not to be taught. Creative people look to be born with it.
However, creativity can be found, cultivated and strengthen by training or education.
By saying “education”, it doesn’t mean education at schools here. It means some chances to learn things through them in your life.

This fabulous article on it talks about it in easily readable way. I’m sorry that it’s written in Korean. ( google translation across different family of languages is not good at all. )
Sometimes I wish people write in English as well as their mother tongue for wider audience. )

If you can read and understand Korean, it will be fun to read this article.
http://blog.gorekun.com/1607

%d bloggers like this: