Scientific Programming

1. When to program: Program only when the time taken to write and debug the code is less than the time you'll save by not having to do the calculations by hand.
• The amount of time saved depends on how repetitive the task is.
• The time savings depends on the language you program in - the more appropriate the language to the problem, the more you'll save.
• Don't assume your program will be any more accurate than your hand calculations - you can make errors in either with equal ease.
  • Debugging takes at least as much time as programming.
  • By hiding intermediate steps, computer calculations make errors less obvious.
2. Leaning to program: The first programming language you learn requires major effort because you must learn a new framework of knowledge. Each subsequent language comes much faster as you pigeonhole new facts into your existing conceptual framework.
   • When you learn your first language expect two learn two things:
   • How to program
   • And the syntax details for that language.
   • Either take a course that covers both or download a language package with good tutorials and work your way through them.
• When you learn another language you need only focus on the syntax details and the mechanics of compiling and running programs.
  • You can usually do this by just reading the users guide
  • And then skimming the section and subsection headings in the reference manual.
• There are only about three approaches to doing any one thing on computers.
• Figure out which one your language uses and you're set.
• If you're using too many languages to remember which language uses which approach, don't sweat it, just try all three approaches and see which one works. The error messages will guide you through fixing the remaining syntax errors.
• Sources of knowledge
  • Textbooks - good for your first language because they cover the programming thought process as well as the syntax.
  • Reference books - better for your later languages because they focus on language-specific topics.
    • Level of detail and readability depends on the author, publisher, and product line.
      • O'Reilly "animal" books are popular because they generally start at a level basic enough for any programmer and yet are comprehensive in their coverage. O'Reilly's "nutshell" books are too terse to learn from but can be nice for looking up details you've forgotten.
      • Peach Pit Press' Visual Quickstart books get you off to a gentler yet faster start but don't go as far as the corresponding O'Reilly books.
      • "... for Dummies" books are about halfway in between.
  • Web sites
    • Many languages have "official" web sites
      • Those for public domain languages tend to be more complete than those for commercial languages.
      • Expect them to contain instructions for acquiring the language, tutorials on how to use it and libraries of useful subprograms (i.e. functions, classes, etc.) for extending the language's capabilities.
      • You can find these web sites doing a web search - Enter just the language name. If that doesn't work, use the language name and the word "language" - example: pike or pike language.
    • To find more specific information add key phrases to the language name
    • To find subprogram libraries - Enter the language name followed by the phrase virtual library.
    • To find tutorials to help you learn a language - Enter the language name followed by the word tutorial.
    • To find syntax help and example code for a particular language feature - Enter the language feature you want followed by the word statement - example: if then else FORTRAN.
3. Picking a language
   • Compiled languages - Your program is converted to machine language once and then run when needed.
     • Programs tend to run faster than in interpreted languages.
     • Debugging tools are more complicated to use than in interpreted languages.
     • Examples:
       • FORTRAN - designed for doing calculations - powerful math and graphics libraries are available.
       • C - designed for general purpose computing - a hybrid combining the features, strengthens, and weaknesses of second and third generation languages - libraries are available for almost anything.
   • Interpreted languages - Your program is converted to machine language anew each time it runs.
     • Examples:
       • Perl - a general purpose scripting language good at text manipulation, running other programs, and interacting with the Internet. - libraries are available for almost anything although graphics and computations are not its strong points - free
       • Matlab - designed for doing calculations - powerful math and graphics libraries are built in.
   • Procedural languages - access data through functions
     • Each function does one task.
     • Multiple functions may modify one piece of data.
     • Examples: FORTRAN, C, Matlab
   • Object-oriented languages - access functions through data.
     • Program design takes more thought than in procedural languages.
     • Program maintenance and debugging are easier though.
     • The choice between procedural and object-oriented languages depends on program complexity.
       • Simple programs (<1000 lines) can be coded faster in a procedural language.
       • Complex systems (>10,000 lines) can be coded faster in an object-oriented language
     • Examples:
       • C++ - all the power and faults of C along with optional use of objects
       • Ruby - a fully object-oriented equivalent of the Perl scripting language - decent collection of libraries available on-line - free
   • Functional languages - data moves between functions solely via their parameters
     • Eliminates bugs associated with multiple functions inadvertently modifying the same data.
     • Makes input and output awkward though.
     • Example: Haskell
• Application specific languages - a language that focuses on one type of problem (e.g. database access)
  • Faster to code because they're tailored to the task.
  • There is a higher level of abstraction (i.e. the nitty gritty details are taken care of automatically)
  • Examples:
    • R - a statistical language - built in functions and libraries available on-line cover most statistical procedures and some graphical needs. - free
    • MySQL - a database access language - free
    • Prolog - a logic language - built for artificial intelligence problems - free
• Visual programming languages - include both general purpose and specialized languages with "integrated development environments".
  • Coding and debugging are done from with an integrated editor/compiler/debugger so they take less of your time.
  • Most of the user interface code is written by the environment in response to the programmer's "painting" the interface
    • This is a real time saver if your program needs a graphical user interface.
    • Otherwise it's a big time sink.
  • Examples:
    • Matlab - an application specific language for numerical analysis and graphing
    • Visual Basic/C++ etc. - general purpose languages from Microsoft - Borland and other companies have roughly equivalent products often using Java as a base.
4. Acquiring the software - most programming languages are now available for most operating systems.
   • Commercial
     • Buy it on-line for shrink-wrappeddelivery (mail-order company or the software's publisher)
     • Buy it on-line for download (the software's publisher)
   • Public domain
     • Download from the language's official site or an official mirror site.
     • GNU - a general source for LINUX software.
     • SourceForge - a general source for LINUX, Windows, Apple software.
     • Fink - a general source for Apple software.
5. Designing a program
• Formal methods of systems analysis and design are worthwhile only for complex systems.
  • If your programs are all <1000 lines, don't bother getting too formal about this, you can probably hold it all in your head.
  • If some of your systems are >10,000 lines, invest the time to read an analysis and design book and learn a simple CASE (computer aided software engineering) tool. If you're using and object-oriented language make sure your CASE tool is based on the Unified Modeling Language (UML).
  • If you lead a programing team, you should have some knowledge of project management as well as systems analysis and design.
• Keep each piece of code short enough to understand and debug easily.
  • If a sketch of what a function does takes more than one page, it's too long and should instead call other functions for some of the details.
  • Ditto if the code of a function is more than a page long.
• Make your code readable.
  • Use a formal naming convention for your functions, variables, and files so you can figure out what anything is at a glance.
  • Document what each of these names means anyway because your naming convention is never so enlightening as you thought it was.
  • Document where you got the algorithm for each function. Referring to the exact page number in a book is NOT overkill, you'd be surprised what you can forget in 3 months.
6. Writing a program
• Code so as to save whatever is most valuable to you: your time, computer time, or computer memory.
  • Use this criterion to pick the language AND the the algorithms.
  • If you're only going to run the program once, your time is probably the most valuable commodity so aim for fast coding/debugging at the price of a slow/bloated program.
  • If you're going to run the program operationally, computer time and memory become much more important.
• Build your program one function at a time.
  • If you write too much code at once, it's really hard to figure out where the inevitable logic errors are hiding.
  • Test each function before you go on.
• Document your code as you go.
  • Assume you'll be interrupted and forget your train of thought.
  • Suspect that you'll come back and reuse parts of a program long after you thought you were done with it.
• Look up the syntax you need on the fly.
• Use the error messages to guide you through finding and fixing the syntax errors.
7. Debugging a program
   • There is no such thing as having too many well placed print statements.
     • Print out the variables that are causing the problem AND those the variables they're derived from.
     • Do it both before and after every step that could possibly have changed anything relevant.
   • If your program becomes too complicated, learn to use the language's built in debugger.
     • Yes it's harder to use than print statements, but it gives you an efficient way to look at lots of information.

This page was last updated by George Young on December 1, 2004