Savvy

This has to be one of the worst languages I have had ever worked with. Still there are some highly customized programs in the wild written with this language. It was created for the Apple II computer, ported over to DOS in 1986. I have two clients who still use custom programs written in this language that I have to maintain. I do not recommend this language but I am posting in case you are like me and have a system with a Savvy program you are required to maintain.

One interesting fact about Savvy is that it has it's own internal command line that you can drop down to. The people who created this program wanted to make it appear more friendly to the user by using more of a sentence structure to communicate. The command prompt is What would you like me to do now? When you type a command word in, you usually hit the [ENTER] key afterwards and it then it fills out part of a sentence and then prompts you to fill in the blank(s). An example would be the following.

This is because the TEMP variable currently had the number 45 stored in it. When it was copied over to the NAME variable, the original value was overwritten by the number 45.

This syntax was made to look more like a normal human language. This gave it a more personal feel to it. The downside is it made it more limited as what you can do.

(Images was created by running a program written with Savvy in a DOS emulator on my Linux Box. The tiny partition was created by repartitioning an old flash drive which I use for diagnostic purposes. I then used the Gimp to grab snapshots.)

Here are some of the problems with this language.

• • It is a hybrid database/programming language that is ran through a interpreter. There is hardly no documentation on this language to be found. I don't believe there is anyone who is supporting this anymore. I believe the company behind this is gone too. Fortunately I have acquired the main book years ago on this. Main reason I thought I would put something down on this. For posterity? :-P

  • The program is saved as a binary file with a svy extension, which Savvy calls the Data Environment File. When executed, this file is fed into the interpreter named savvy.com For example if I had a Savvy file named test.svy I would type at the DOS prompt savvy test.svy

  • The problem with the svy file is that both the program code AND ALL the user data is stored within this same file. I believe this to be the worst of the Savvy's sins. This means that all upgrades have to be sync with any data changes. For example if you wrote upgrades to the code and then try to copy it back to the main computer after someone had updated some data, then when you install the upgraded program the updated data will be overwritten and be lost. You may want to block any use of the program until after the upgrade was finished. Also always backup backup and backup Can't say it enough. (Bad memories) The same is true for the programmer. If the user was to go back to an earlier backup before your upgrade, then all your changes are lost. And the users have been known to do this when they run DIAGNOSTICS and it fails the integrity of the data. I notice this don't happen much anymore. I believe it is because they now use other media besides floppies for the backup purposes.

  • Savvy WILL NOT run on a partition with more than 40 megabytes of free space. Not sure why but I think it runs some kind of an automatic disk check on the program's start up. When it sees a large partition size it chokes requiring a hard reboot.

  • I remember it would not run on MS DOS version 4. It did ran on earlier versions and later versions. Used MSDOS 6 for years and found it to run on the Windows XP DOS just fine. Currently using FreeDOS and it works good.

  • It has a Y2K bug. The bug is where the GetDate command returns garbage instead of the year after 1999. I managed to write a patch that is able to analyzes the "garbage" (I found a pattern that correlates to the ASCII table order) and returns the correct year.

  • It is case sensitive and all commands have to be in all caps. (This tends to lead to the user getting into the habit of activating his caps key and doing everything in caps.)

  • Subroutines can not exceed 1,024 bytes. This means a lot of jobs end up cascading through several subroutines. When debugging, this can be a pain as you jump down through them looking for the source of the problem. To do this you have to first exit out of the subroutine before editing another. Also you may have to look through a dozen subroutines just looking for the name of the subroutine with the problem.

  • There is no mouse support.

  • There is no cut and pasting in the native environmental You can cut/paste some using a windowed execution within Linux. I suspect the same is true in Windows. But you can't paste multiple lines or a whole line where the [Enter] key is expected to be press to step through the sentence prompting.

  • Has a weird proprietary naming scheme. subroutines are called tasks, variables are called items, Tables are called Files (and are internal to the svy file.) etc.

  • Variables (Items) are declared only once from the internal command line and all are global. There is not integer or string variables etc. They all are of the Variant type. So the variable TEMP may have a number in it and math functions can be performed on it. Later the same TEMP variable may have a person's name stored in it and operations like append, compare etc may be performed on it. Another "feature" good or bad is all variables are static. If you put the number 21 into the TEMP variable and then shut everything down for a week, when you come back, boot the computer up and start your program, you will find that the TEMP variable will still have the number 21 in it.

  • If you run a Savvy program in a window within windows, the temptation is great to click the X in the title bar to shut it down. If you do shut it down with using the shutdown command then you stand to badly corrupt the data. If this happens, go to the command line (within the program.) You will see: What would you like me to do now? for your prompt and type DIAGNOSTICS which will cause it to check all the data and pointers. If it fails, you must go back to a backup. This is why you want to run DIAGNOSTICS and back up your upgraded version just as soon you are finished. If they go back to a backup before your upgrade then you have to retype all your code back in. Below is a snapshot after DIAGNOSTICS was ran.