cafm
Newbie level 2
Hi,
Please read thru these posts that I have written. They are put up at my blog and if you find any suggestions /corrections please add.....
http://olympusmons.blogsome.com/2007/08/01/before-you-start-scripting/
Before you start Scripting………
If you can get your job done with tr don’t use SED
If you can do it with SED don’t use AWK
If you can do it with AWK don’t use perl
One of the basic powers of UNIX based systems comes from the fact that there are a gazillion ways of doing even the simplest of tasks. With the combined philosophies of KISS and “Small is beautiful” implemented beautifully along with the pipelining and I/O redirection, the power can actually be overwhelming at times. This is exactly a stumbling point for a person new to this world, especially if he’s coming from the “click-click-click” philosophy of windows. Agreed, the latter philosophy is best suited for a general user who uses computer sparingly or for tasks such as browsing and chatting. The typical “Non-IT” portfolio. But for an EDA engineer (like me) or a power user to think of a world without these tools is blasphemy. Still with so many choices available, a lot of people who would love to have the power dither away from the “right” path due to a sense of vastness.
I have held the view that languages are just means to end. Writing a program is not the hard part, its just the unavoidable detail.Any person with reasonable intelligence can use the IT industry mantra of {“CTRL+C-CTRL+V”} and write reasonable code. This is particularly true in the case scripting as the “hard” part such as memory management etc is removed. Hence we see that in the scripting mindset the focus is to get the job done and ask questions about efficiency etc later (unless it’s a heavily executed script and the current implantation is VERY bad). So the most important part of scripting boils down to the language/tool selection which can be a daunting task, taking the amount of choices available. Even though there can never be hard and fast rules , I thought I would pen down some thumb rules that can be applied to make this daunting task easy.
Never start with NO!
First thing to understand is that -: always be open to change…..but with intelligence. Don’t choose a language just because you’re comfortable with it. Even though there are exceptions to this rule like when time is playing a very important parameter in determining the value of the current solution or the complexity reduction offered to your with the new language does not justify the extra effort to be spent to get the thing implemented(Remember that the product of this first effort can be later used if the code is modularised) . I know this sounds vague but the idea I want to convey is that always consider other languages before committing to a particular language.A general flow for choosing a language is given at the end.
Visualize the Solution
Get a grip of the capabilities of the language rather than spend too much time learning the each and every syntax. More often than not, the time difference between when you learn the language and when you have to solve a practical problem would be too much that the intricacies that you spend hours learning would seen as distant to you as the basic syntax. Instead if you get the capabilities they it will help you visualize the solution in a particular language and the dirty stuff can be dealt with later. Chances are that most of the “challenges” that you have to face while implementation would have been faced by hundreds before and would be well documented so just GOOGLE!
Modularize it!
This is something I try to implement all the time. Once you visualize your solution, split it into independently implemental chunks. Not only does this help you write code that’s easily understandable/maintainable/modifiable but it also helps reduce your work when you are writing another script if you can reuse some of the modules.
Hybrids/ Genetic engineering is good.
Ever read about the plants that have insecticide genes engineered into them? Similarly , it might make sense to implement a part of the solution in one language and the other in another. As long as you can easily understand the way the data is to be transferred between the two parts, Go for it!
The following rules/questions can be used as a guideline while choosing the language.
It’s a simple solution involving a lot of individual UNIX commands / executables
Can I see the solution in Shell?
It involves rudimentary text processions, like single character substitution and some character removal
Can I see the solution with Shell along with cut and tr commands?
It involves more complex text manipulations
Can I see the solution in Shell and SED?
(AWK can do a log of things SED can do, but complex stream editing is something SED is better at (faster, the code is terser, etc.) but SED has no function and no arthemetic)
I also want some multilevel text manipulations and with support for variables during these complex text manipulation steps.
Can I see the solution in Shell and AWK?
It involves large scale text manipulation and reports parsing.
Can I visualize the solution in PERL? (or Python?)
It involves automation of interactive software like ftp, ssh etc
Can I see the solution with Expect along with a host language like TCL?
Please do leave a comment if you feel that there is anything else that you have come across that can make this more helpful.
Please read thru these posts that I have written. They are put up at my blog and if you find any suggestions /corrections please add.....
http://olympusmons.blogsome.com/2007/08/01/before-you-start-scripting/
Before you start Scripting………
If you can get your job done with tr don’t use SED
If you can do it with SED don’t use AWK
If you can do it with AWK don’t use perl
One of the basic powers of UNIX based systems comes from the fact that there are a gazillion ways of doing even the simplest of tasks. With the combined philosophies of KISS and “Small is beautiful” implemented beautifully along with the pipelining and I/O redirection, the power can actually be overwhelming at times. This is exactly a stumbling point for a person new to this world, especially if he’s coming from the “click-click-click” philosophy of windows. Agreed, the latter philosophy is best suited for a general user who uses computer sparingly or for tasks such as browsing and chatting. The typical “Non-IT” portfolio. But for an EDA engineer (like me) or a power user to think of a world without these tools is blasphemy. Still with so many choices available, a lot of people who would love to have the power dither away from the “right” path due to a sense of vastness.
I have held the view that languages are just means to end. Writing a program is not the hard part, its just the unavoidable detail.Any person with reasonable intelligence can use the IT industry mantra of {“CTRL+C-CTRL+V”} and write reasonable code. This is particularly true in the case scripting as the “hard” part such as memory management etc is removed. Hence we see that in the scripting mindset the focus is to get the job done and ask questions about efficiency etc later (unless it’s a heavily executed script and the current implantation is VERY bad). So the most important part of scripting boils down to the language/tool selection which can be a daunting task, taking the amount of choices available. Even though there can never be hard and fast rules , I thought I would pen down some thumb rules that can be applied to make this daunting task easy.
Never start with NO!
First thing to understand is that -: always be open to change…..but with intelligence. Don’t choose a language just because you’re comfortable with it. Even though there are exceptions to this rule like when time is playing a very important parameter in determining the value of the current solution or the complexity reduction offered to your with the new language does not justify the extra effort to be spent to get the thing implemented(Remember that the product of this first effort can be later used if the code is modularised) . I know this sounds vague but the idea I want to convey is that always consider other languages before committing to a particular language.A general flow for choosing a language is given at the end.
Visualize the Solution
Get a grip of the capabilities of the language rather than spend too much time learning the each and every syntax. More often than not, the time difference between when you learn the language and when you have to solve a practical problem would be too much that the intricacies that you spend hours learning would seen as distant to you as the basic syntax. Instead if you get the capabilities they it will help you visualize the solution in a particular language and the dirty stuff can be dealt with later. Chances are that most of the “challenges” that you have to face while implementation would have been faced by hundreds before and would be well documented so just GOOGLE!
Modularize it!
This is something I try to implement all the time. Once you visualize your solution, split it into independently implemental chunks. Not only does this help you write code that’s easily understandable/maintainable/modifiable but it also helps reduce your work when you are writing another script if you can reuse some of the modules.
Hybrids/ Genetic engineering is good.
Ever read about the plants that have insecticide genes engineered into them? Similarly , it might make sense to implement a part of the solution in one language and the other in another. As long as you can easily understand the way the data is to be transferred between the two parts, Go for it!
The following rules/questions can be used as a guideline while choosing the language.
It’s a simple solution involving a lot of individual UNIX commands / executables
Can I see the solution in Shell?
It involves rudimentary text processions, like single character substitution and some character removal
Can I see the solution with Shell along with cut and tr commands?
It involves more complex text manipulations
Can I see the solution in Shell and SED?
(AWK can do a log of things SED can do, but complex stream editing is something SED is better at (faster, the code is terser, etc.) but SED has no function and no arthemetic)
I also want some multilevel text manipulations and with support for variables during these complex text manipulation steps.
Can I see the solution in Shell and AWK?
It involves large scale text manipulation and reports parsing.
Can I visualize the solution in PERL? (or Python?)
It involves automation of interactive software like ftp, ssh etc
Can I see the solution with Expect along with a host language like TCL?
Please do leave a comment if you feel that there is anything else that you have come across that can make this more helpful.
