Taking an interest

Working with 'while' loops made me think about an old problem that still requires a brute force solution even with all the advances in math and computer science. There are simple formulas for determining the interest generated by a certain amount of money over x years, but compounding is a much more complex problem. If interest is compounded every year, then the principal is changing in an exponential way and simple formulas no longer suffice because they do not take into account the necessary information. In order to find out the total balance 15 years in the future, for example, you need not only the initial balance and rate but what the balance was in each of the previous 14 years (since each year's balance depends on the previous year's balance plus the interest earned). While working with 'while' loops, I decided to apply them to a brute force problem like compound interest. The result is below:

Future Balance Calculator

What was your balance at the end of 2012? $ For what year do you want to know your end of year balance? What is your interest rate? %
You will have a balance of $ at the end of

Objects are the objective

Started exploring the use of objects in Javascript, something I had heard of before when referring to computer programming languages but hadn't really been exposed to while learning them. At first I wasn't sure how to employ objects, and then I learned about the ability of objects to contain variables and functions in a single container. I was surprised to hear that objects could contain variables and functions in the same data structure. Then I remembered that I had written functions in AutoLISP that executed other functions. Some of my programs for AutoCAD were built on smaller programs that I wanted to be self-contained instead of piled into one large block of code. For example, a program that organizes a raw text file into a usable list in AutoLISP...
(defun prog04a () (c:vt) ; file to read (setq fh1 (open "I:/LISPDATABASE/StatesID.txt" "r")) ; Ignore first line (setq stnmlist (list )) ; Begin transcribing (while fh1 (setq nline (read-line fh1)) (if nline (progn (setq d1 (atoi nline)) (setq d2 (read (read-line fh1))) (setq d2 (atoi d2)) (setq d3 (read (read-line fh1))) (setq d4 (read (read-line fh1))) (setq d4 (atoi d4)) (setq d5 (read (read-line fh1))) (setq d6 (read (read-line fh1))) (setq stnmlist (append stnmlist (list (list d1 d2 d3)))) ) (setq fh1 (close fh1)) ) ) (princ) )
...is executed in another program with a call after the list it feeds data into is created.
(defun prog04 () ; file to read (setq stnmlist (list ))
(prog04a)
(setq fh1 (open "I:/LISPDATABASE/States.txt" "r")) ; Ignore first line ; Begin transcribing (setq ncolor 0) .......
Going through some other AutoLISP programs I created I found that I had often created small programs to do some kind of prep work, usually preparing data, that I then used in another program. Most of the time the end program still executed a large amount of code, but the combination of variables and program references stored in a single block reminds me of an object. I have noticed that objects are different in the sense that they are not executable themselves. My master programs that relied on executing smaller programs first were still programs. They had to be run in order to be useful, whereas I am discovering that an object can be a very complex container of data that is both executable (functions) and static (variables).