I considered writing a program to do the above for websites I only intend to use for short-term use.
Yes, there's a very good reason, it's called KeePass. It's a free and open source password management application. It can automatically generate a rock-solid password for you, pair it to certain website, and store it in a securely encrypted database for which you have the key in a form of a master password.
Other than for learning purposes, don't play a crypto pro and write your own security-related programs.
If the webmaster of any site you visit knows the algorithm above, it becomes possible for them to mount a brute force attack on your master password from the generated password. So for this to be a viable scheme the master password would probably have to be a long string of randomness (which would probably defeat the purpose of the scheme), or the device generating the passwords would have to have a long random key that was unlocked by the master password.
It is unclear how the "salt" fits in this - if it is random, how do you know what salt to use for a particular site? If it isn't (ie it is a fixed secret), how does it differ from the master password in nature?
If you have random salt and you are storing it on the generating device, you might as well be generating the whole password randomly and storing it protected on the device (like Keepass et al). As a practical matter this has an advantage that you have a record of all the site names you have keys for. Without that, it becomes difficult to remember what the canonical name for a site is. For example are you going to refer to this site as "IT Security Stack Exchange", "Security StackExchange", "Security", "security.stackexchange.com", "www.security.stackexchange.com", or "user29349.openidprovider.com"...?
There are several good reasons not to do that:
A single SHA-1 instance is too fast; when deriving things from passwords you want to apply proper password hashing. The salt is a good thing, but it is only part of the equation.
Cryptographic algorithms should not be improvised; there are many ways to botch it. Reuse an existing password hashing algorithm which has been published and analysed and which resisted attacks for some years.
If you want to change your master password you lose all your site passwords. If you want to change one site password you have to change your master password. This is inadequate. For that, you need an indirection layer; say, the master password is used to encrypt a local database of stored per-site passwords (and these per-site passwords can then be completely random, or chosen by the site, or whatever). This is more crypto, so again don't do this at home.