Between Spaghetti, Pasta and Sandwich which one would you choose if you are writing and maintaining code, how it should be like? Definitely not the spaghetti right? I have come across spaghetti code and detest it to the core.; but I have also observed that wrong understanding of OO or TOO (too much object orientation) and obsession with modularization leads to pasta like code. This makes us go through multiple files and sections of code to understand simple functionalities. Cannot we translate most of the software requirements into code like how a well prepared sandwich can be nutritious and filling too?
I don’t have an answer to this question but my readings like Worse is better (talks about less and useful features) make me infer that like every person’s hunger can be satisfied with cost-effective, tasty, nutritious and simple to make food; most of the software requirements should also be delivered with simple to write and maintain code. Aesthetics, modularization and other bells & whistles should not come at a cost.
I was very curious whether the way you think and act is directly related to the language you speak. I did some Bing search and stumbled on few blogs which mentioned about the lack of left or right in a language called Kuuk Thaayorre. They have to refer everything in terms of cardinal/ordinal directions. There were interesting examples in Scientific American. I was impressed by the fact that in the language Kuuk Thaayorre it is impossible for someone to refer something without knowing the direction. This forces them to be oriented always and that is because of the language they speak. It even affects the way people think about time and space, the English say the future is ahead and Chinese say the future is down there or the English say it is a long day and the Chinese say it was a big day. So a person’s thinking is influenced by the language s/he speaks.
Will these be applicable to programming languages? Is a programmer’s thinking influenced by the first language s/he learns? It seems it could be true. I observe that Java as a language did not change much (faster) but polyglot programmers have contributed to bring in efficiency and elegance which they learnt while using other languages. An example which I also stated in my older post (Don’t make me think) is LambdaJ, which helps in writing expressive code in Java when working with collections while not worrying about writing obvious for-loops. Frameworks like Roo help us to avoid mundane Java boilerplating and concentrate only on functionality. There should be many more out there which has helped Java developers but influenced by the features of other languages and frameworks.
A programming language has an option to keep growing through upgrades unlike the spoken languages. I am not sure why a spoken language need to be restricted from acquiring parts from other languages. I am the one who missed asking the question “How manyeth candy are you having?” when I started learning English. It took me a while to understand how to ask similar questions when I had to translate from Tamil to English.
Which developer thinks better? Java or Ruby or C#…..?
EDIT: Some bloggers pointed me to http://en.wikipedia.org/wiki/Sapir-Whorf_hypothesis and http://lambda-the-ultimate.org/node/1067#comment-11228
Is abstraction is what which makes code look smaller, simple and easy to understand? I was looking for the dictionary meaning of the word abstract and found that abstraction is some thing like “You flip the switch and light comes on”; as an end user I do not worry about the internals as long as I flip the switch the light comes on. While this is very applicable for the end user what about the electrician?; does he need to deal with this level of abstraction? The electrician needs to have an understanding of the internal wirings and the load the switch is capable of handling, in order to maintain or make repairs.
In software world I have observed something similar, whenever my peers refer to bring an abstraction, mostly they meant to find a word to compress the steps of doneness. Abstraction means you as a developer becoming an end user of a part of the solution, where you do not need to worry about the internal workings. Compression is finding a term to represent the entire process underneath which will be commonly understood by all the developers. An analogy of this to a restaurant kitchen is the word ‘marinate’ is not an abstract term, every one in the kitchen understands this and the chef merely has to say “marinate the meat for 20 mintues, use the secret sauce”. The situation would be different if the process of marination is automated and you have a machine to do that, in that case the staff is end user of that process and not part of it and hence s/he is abstracted from what marination is.
What holds good in a regular development life cycle, abstraction or compression?