Introduction - what this is not

This is not an introduction for those who are absolute beginners at programming. Neither is it an introduction for those who are absolute beginners at cryptography. What it is is an introduction to some basic concepts of organizing code, and of applying them to the problem of cracking certain classical ciphers. If you know nothing of programming, are unfamiliar with Python, or do not know how to crack a simple substitution cipher, there are other tutorials out there for you. But if you have read those tutorials, have gotten your feet wet with Python, and have succesfully cracked at least a few simple substitution ciphers, this may be a good next step.

The basic premise of this tutorial is that writing software for your own use as a part of solving your own problems is a very different thing than writing software for others.

When writing software for others, there are necessarily trade-offs ease of use, flexibility, capability, error handling, etc., for which the proper balance is very different than when writing software for your self.

There is an old Unix joke that the only necessary error message is "Segmentation fault: core dumped". Generally, this sort of error "handling" is a very unfriendly thing to inflict on an innocent user, but if you wrote the software, and have the source code, simply letting the system error messages tell you what line of code the error happened on may well be the appropriate choice.

Creating intuitive user interfaces takes work, robust error handling even more work. If it's a program you wrote for yourself, that work may not be necessary, particularly if it's a program that was written to solve one particular problem, and which may well never be used again. The trick to using custom programming in your work in an effective manner is to develop toolsets with which you can easily construct programs to solve the problems that face you.

Decades ago, when most computer users were programmers, a number of books were written with guidance in this area. Unix, in particular, was designed with the aim of making programmers more productive. A number of groundbreaking books were written by the Unix design team at Bell Labs exploring these concepts: The Unix Programming Environment [Brian W. Kernighan and Rob Pike. Prentice Hall, Inc., 1984. ], Software Tools [Brian W. Kernighan amd P. J. Plauger, Addison-Wesley, 1976. ] Programming Pearls [Jon Bentley, Addison-Wesley, 1986. ]. Since then, there has been little discussion of it, as the emphasis in programming has shifted to writing software for others to use.