Additional profile information on Alfred Thompson at Google+
What's that old line about if all you have is a hammer all your problems look like nails? There are some programmers who only have one programming language in their tool box. They way they look at programming problems is colored by what can be done in that language and how things are done in that language. As regular readers of this blog well know I am an advocate of programmers learning several languages. One of the reasons for that is so that they can consider using other languages when they run into problems using one language.
One of the things that get me excited about the .NET Framework and Visual Studio .NET was the ability to mix programming languages in a project. With the addition of dynamic languages like Python and Ruby into the mix more and more options allowing different programming paradigms are now permissible. If the language in use doesn't meet the needs of a specific problem changing the language may be an option. In fact changing languages has never been easier.
I think that a lot of thought should go into selecting a programing language for each projects. No one should assume that one programming language is perfect for all projects. And in fact some project, especially larger ones, may involve more than one language. I don't think teams should involve multiple languages just for the sake of using them of course. There is some complexity especially when you consider additional maintenance and enhancements over time. But at least people should have an open mind about the issue.
[Note: I am away on vacation this week so I decided to finish up this series and have these posts show up while I am away.]
This is the twenty-fifth of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.
I've been telling students and others that "reading the manual is the shortcut" for years. I really believe it. When a program isn't working out the way one expects re-visiting the manual is often a great short cut. Sometimes the manual in question is really the documentation for the project or the program. Often the manual in question is the language manual for the programming language being used or the documentation for the class/function libraries that are being used.
Often times there are functions/methods/classes that have already been created that can be used. Lots of shortcuts can be found that way. Manuals, in today's world the word manual often means online documentation of course, can also be a great way to understand error message as well.
No one knows it all. Manuals, online or old-fashioned paper books, can be a great source of information. I have a whole bookcase of programming books and I refer to them often. Real life is an open book test and knowing how and when to use books can be a huge advantage in life.
This is the twenty-fourth of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.
This proverb is a corollary to the last post in this series. While getting the program correct and the right results is the first priority that doesn't mean that the results can be tossed out in any old way. A programmer's program, a program written only to be used by the person who wrote it, can get away with output that looks random or is roughly formatted. But a program that is used by non-programmers really has to pay some attention to output.
I was once called in to update a report program that created a report with lots of data. All the data was correct. The problem was that it was all run together. There were no visual breaks between grouping. There were no sub-totals either. As correct as the results were the report was barely usable because of formatting problems.
Sometimes specific information should be highlighted. Are some numbers far above or below average? Are there warning messages that need to be produced when inventory falls below some level? Those things may require something special in the output. What about fonts? Are the sizes right? Did you pick a font type that is easy to read? What about spacing? Do numbers run together when they get large? Are negative numbers formatted in ways the customer expects? There is a lot to think about.
A report or screen that can't be read or that is disorganized or makes important information difficult to find is only marginally useful. If there has been a lot of work involved in getting the program correct you don't want to waste it by creating unusable output.
This is the twenty-third of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.