Note: The code of Visicalc for Go is available here: https://github.com/ms1963/visicalc
PART I: THE REVOLUTION THAT STARTED IT ALL
In the autumn of 1979, a quiet revolution began in the world of personal computing. Two young programmers, Dan Bricklin and Bob Frankston, released a program called VisiCalc for the Apple II computer. This seemingly simple application would fundamentally transform how businesses operated and, in doing so, would justify the purchase of personal computers for the first time in corporate history.
Before VisiCalc, financial modeling was a tedious affair. Accountants and financial analysts would spend hours with calculators and ledger paper, laboriously computing projections and budgets. If a single assumption changed, the entire calculation had to be redone by hand. This process was not only time-consuming but also prone to human error.
Dan Bricklin, a Harvard Business School student at the time, envisioned a better way. He imagined an electronic spreadsheet where numbers would automatically recalculate when you changed an input. The idea came to him during a lecture when he watched his professor erase and recalculate an entire financial model on a blackboard after changing a single assumption. Bricklin thought to himself: "Imagine if my calculator had a ball in its back, like a mouse."
Together with his friend Bob Frankston, who handled the technical implementation, Bricklin brought this vision to life. VisiCalc, short for "Visible Calculator," was born. The program displayed a grid of cells, each capable of holding a number, text, or formula. When you changed a value, all dependent calculations updated instantly. This simple concept was revolutionary.
The impact was immediate and profound. VisiCalc became the first "killer app" for personal computers. People bought Apple II computers specifically to run VisiCalc. Sales of the Apple II skyrocketed. Within a year, VisiCalc had sold over 100,000 copies. By 1983, that number had grown to over 700,000 copies across multiple platforms.
VisiCalc transformed the personal computer from a hobbyist's toy into an indispensable business tool. It paved the way for Lotus 1-2-3, which dominated the DOS era, and eventually for Microsoft Excel, which continues to dominate today. Every modern spreadsheet application owes its existence to the pioneering work of Bricklin and Frankston.
PART II: VISICALC FOR GO - A LOVING TRIBUTE
VisiCalc for Go is a heartfelt homage to this groundbreaking software. It is not merely a clone or a port, but rather a reimagining of VisiCalc's core concepts using modern programming techniques while preserving the spirit and elegance of the original.
This implementation serves multiple purposes. First, it honors the legacy of Bricklin and Frankston by demonstrating that their fundamental design decisions remain sound even forty-five years later. Second, it provides an educational resource for programmers who want to understand how spreadsheet engines work under the hood. Third, it offers a functional, terminal-based spreadsheet for those who appreciate the simplicity and directness of text-based interfaces.
The choice of Go as the implementation language is deliberate. Go combines the performance of compiled languages with the clarity and simplicity that made the original VisiCalc comprehensible. Go's strong typing helps prevent the kinds of errors that plagued early spreadsheet implementations, while its standard library provides robust tools for parsing and computation.
Unlike the original VisiCalc, which was written in highly optimized 6502 assembly language to squeeze every ounce of performance from the Apple II's 1 MHz processor and 48 KB of RAM, VisiCalc for Go can afford to prioritize clarity and maintainability. Modern computers have millions of times more memory and processing power, allowing us to focus on elegant algorithms rather than micro-optimizations.
PART III: ARCHITECTURAL OVERVIEW
The architecture of VisiCalc for Go follows a classic Model-View-Controller pattern, though adapted for a terminal-based application. The system consists of several key components that work together to provide spreadsheet functionality.
At the heart of the system lies the Cell structure. Each cell in the spreadsheet is represented by an instance of this structure, which maintains all the information necessary to display and calculate that cell's value. The Cell structure contains the original formula entered by the user, the computed numeric value, the text to display on screen, and various flags indicating whether the cell contains a formula, text, or an error.
Surrounding the Cell structure is the Spreadsheet structure, which manages the entire grid of cells. The Spreadsheet maintains a map of cell references to Cell objects, tracks the current cursor position, manages the visible viewport into the larger grid, and coordinates the calculation of formulas. This structure serves as the central coordinator for all spreadsheet operations.
The formula evaluation engine represents one of the most sophisticated components of the system. This engine must parse user-entered formulas, resolve cell references, handle mathematical operations with proper precedence, detect circular references, and manage function calls. The engine implements a recursive descent parser that breaks down complex expressions into manageable components.
The display system handles all user interaction and visual presentation. It renders the visible portion of the spreadsheet grid, highlights the current cell, displays cell contents in the status bar, and manages the command-line interface for user input. The display system must also handle text overflow, allowing long labels to spill into adjacent empty cells just as the original VisiCalc did.
PART IV: THE CELL - FOUNDATION OF THE SPREADSHEET
Every spreadsheet begins with the humble cell. In VisiCalc for Go, the Cell structure encapsulates everything needed to represent a single cell in the grid. Let us examine this fundamental building block in detail.
The Cell structure contains six fields, each serving a specific purpose. The Formula field stores the original text entered by the user, preserving it exactly as typed. This preservation is crucial because users need to see and edit their original input, not the computed result. For example, if a user enters the formula "+A1+B1", that exact string is stored in the Formula field.
The Value field holds the numeric result of evaluating the formula. When the cell contains a formula like "+A1+B1", the Value field stores the sum of cells A1 and B1. When the cell contains a plain number like "42", the Value field stores 42.0. This separation between formula and value allows the system to display different information depending on context.
The DisplayText field contains the formatted string that appears in the spreadsheet grid. For numbers, this might be "42" or "3.14159". For text labels, it contains the label itself. For formulas that produce numeric results, it contains the formatted result. This field represents what the user actually sees when looking at the cell.
The IsFormula flag indicates whether the cell contains a formula that needs to be recalculated when dependencies change. A cell containing "+A1+B1" has IsFormula set to true, while a cell containing just "42" has it set to false. This flag allows the recalculation engine to skip cells that don't need computation.
The IsText flag distinguishes between numeric values and text labels. In VisiCalc, text labels begin with a quotation mark. A cell containing "Revenue" is text, while a cell containing "100" is numeric. This distinction affects how the cell is displayed (left-aligned versus right-aligned) and whether it participates in calculations.
The Error field stores any error message that occurred during formula evaluation. If a formula references a non-existent cell, divides by zero, or contains a syntax error, the Error field contains a descriptive message like "DIV/0" or "CIRCULAR". This field allows the system to display helpful error information to the user.
Here is how the Cell structure is defined in Go:
type Cell struct {
Formula string
Value float64
DisplayText string
IsFormula bool
IsText bool
Error string
}
This structure is deliberately simple. It contains only the essential information needed to represent a cell, with no unnecessary complexity. This simplicity makes the code easier to understand and maintain, following the philosophy of the original VisiCalc designers.
PART V: THE SPREADSHEET - MANAGING THE GRID
While the Cell structure represents individual cells, the Spreadsheet structure manages the entire grid and coordinates all spreadsheet operations. This structure is the central hub of the application, maintaining state and orchestrating interactions between different components.
The Spreadsheet structure uses a map to store cells rather than a two-dimensional array. This design decision reflects a key insight: most spreadsheets are sparse, meaning most cells are empty. Storing every possible cell (254 rows times 26 columns equals 6,604 cells) would waste enormous amounts of memory. Instead, the map only stores cells that actually contain data. An empty spreadsheet consumes minimal memory, while a full spreadsheet uses memory proportional to the number of populated cells.
The map uses cell references as keys. A cell reference like "A1" or "B5" uniquely identifies a cell's location. The GetCellRef function converts row and column numbers into these references, while the ParseCellRef function performs the reverse operation. This bidirectional mapping allows the system to work with both coordinate systems seamlessly.
The Spreadsheet structure maintains several pieces of state related to the user interface. The currentRow and currentCol fields track the cursor position, indicating which cell the user is currently editing. The topRow and leftCol fields define the viewport, determining which portion of the larger grid is visible on screen. As the user navigates, these fields update to keep the current cell visible.
The calculation engine uses two fields to prevent infinite loops and manage recursion. The calculating map tracks which cells are currently being evaluated, allowing the system to detect circular references. If cell A1 contains "+B1" and cell B1 contains "+A1", the system can detect this circular dependency and report an error instead of recursing infinitely. The evalDepth field limits recursion depth, preventing stack overflow even in complex formula chains.
Here is the complete Spreadsheet structure definition:
type Spreadsheet struct {
cells map[string]*Cell
currentRow int
currentCol int
topRow int
leftCol int
mode string
inputBuffer string
colWidths map[int]int
calculating map[string]bool
filename string
modified bool
evalDepth int
}
The NewSpreadsheet function creates a new spreadsheet with sensible defaults. It initializes the cells map, positions the cursor at cell A1, sets the viewport to show the top-left corner of the grid, and prepares the calculation tracking structures. This initialization ensures that every spreadsheet starts in a consistent, predictable state.
PART VI: CELL REFERENCES - THE ADDRESSING SYSTEM
Cell references form the foundation of spreadsheet formulas. When you write "+A1+B1", those "A1" and "B1" strings must be converted into actual row and column coordinates. This conversion process is more subtle than it might first appear.
The GetCellRef function converts numeric coordinates into text references. Given row 1 and column 0, it produces "A1". Given row 5 and column 2, it produces "C5". The function performs bounds checking to ensure coordinates fall within the valid range of 1 to 254 for rows and 0 to 25 for columns. If coordinates are out of bounds, it returns an empty string to signal an error.
The implementation is straightforward but important:
func GetCellRef(row, col int) string {
if col < 0 || col >= MaxCols || row < 1 || row > MaxRows {
return ""
}
return fmt.Sprintf("%c%d", 'A'+col, row)
}
The column letter is computed by adding the column number to the ASCII value of 'A'. Column 0 becomes 'A', column 1 becomes 'B', and so forth. The row number is simply appended as a decimal integer. This simple formula generates the familiar spreadsheet notation that users expect.
The ParseCellRef function performs the reverse operation, converting text references back into coordinates. This function must handle various edge cases and validate its input carefully. The reference must contain at least two characters (one letter and one digit). The letter must be uppercase A through Z. The number must be a valid integer between 1 and 254.
The parsing process proceeds in several steps. First, the function trims whitespace and converts the reference to uppercase, ensuring consistent processing regardless of how the user typed the reference. Second, it scans through the string to find where letters end and digits begin. Third, it validates that the letter portion is exactly one character (this implementation doesn't support multi-letter columns like "AA" or "AB"). Fourth, it converts the letter to a column number and the digits to a row number. Finally, it validates that both coordinates are within bounds.
Let’s see the complete implementation:
func ParseCellRef(ref string) (int, int, error) {
if ref == "" {
return 0, 0, fmt.Errorf("empty reference")
}
ref = strings.TrimSpace(ref)
ref = strings.ToUpper(ref)
if len(ref) < 2 {
return 0, 0, fmt.Errorf("reference too short")
}
colEnd := 0
for colEnd < len(ref) && unicode.IsLetter(rune(ref[colEnd])) {
colEnd++
}
if colEnd == 0 {
return 0, 0, fmt.Errorf("no column letter")
}
if colEnd >= len(ref) {
return 0, 0, fmt.Errorf("no row number")
}
colStr := ref[:colEnd]
rowStr := ref[colEnd:]
if len(colStr) != 1 {
return 0, 0, fmt.Errorf("multi-letter columns not supported")
}
col := int(colStr[0] - 'A')
if col < 0 || col >= MaxCols {
return 0, 0, fmt.Errorf("column out of range")
}
row, err := strconv.Atoi(rowStr)
if err != nil {
return 0, 0, fmt.Errorf("invalid row number")
}
if row < 1 || row > MaxRows {
return 0, 0, fmt.Errorf("row out of range")
}
return row, col, nil
}
This careful validation prevents many potential errors. If a user types an invalid reference like "A0" or "ZZ999", the function returns a descriptive error rather than producing garbage results or crashing.
PART VII: FORMULA EVALUATION - THE CALCULATION ENGINE
The formula evaluation engine represents the intellectual heart of VisiCalc for Go. This component must parse arbitrary mathematical expressions, resolve cell references, handle function calls, and produce correct results while detecting and reporting errors. The engine implements a recursive descent parser, a classic technique that breaks complex expressions into simpler components.
The EvaluateFormula function serves as the entry point to the calculation engine. When a user enters a formula like "+A1*2+B1", this function coordinates the entire evaluation process. It manages recursion depth to prevent stack overflow, tracks which cells are currently being evaluated to detect circular references, and delegates to specialized functions for different types of expressions.
The function begins by incrementing the recursion depth counter and setting up a deferred function to decrement it when evaluation completes. This ensures the counter stays accurate even if an error occurs partway through evaluation. If the depth exceeds a predefined maximum, the function returns an error to prevent stack overflow.
Next, the function checks for circular references. It maintains a map of cells currently being evaluated. If the current cell is already in this map, it means we've encountered a circular reference. For example, if cell A1 contains "+B1" and cell B1 contains "+A1", evaluating A1 will attempt to evaluate B1, which will attempt to evaluate A1 again. The function detects this situation and returns a "CIRCULAR" error.
The function then examines the formula to determine what type of expression it contains. If the formula is a simple cell reference like "A1", it retrieves that cell's value. If the formula begins with "@", it contains a function call like "@SUM(A1...A10)". Otherwise, it contains a mathematical expression like "2+3*4".
Here is the structure of the main evaluation function:
func (s *Spreadsheet) EvaluateFormula(formula string, cellRef string)
(float64, error) {
s.evalDepth++
defer func() {
s.evalDepth--
}()
if s.evalDepth > MaxFormulaDepth {
return 0, fmt.Errorf("TOO DEEP")
}
if s.calculating[cellRef] {
return 0, fmt.Errorf("CIRCULAR")
}
s.calculating[cellRef] = true
defer func() {
delete(s.calculating, cellRef)
}()
formula = strings.TrimSpace(formula)
// Check if it's a cell reference
// Check if it's a function call
// Otherwise evaluate as expression
return s.evaluateExpression(formula, cellRef)
}
The evaluateExpression function handles mathematical expressions using operator precedence. In mathematics, multiplication and division have higher precedence than addition and subtraction. The expression "2+3*4" should evaluate to 14 (not 20) because multiplication happens first. The function implements this precedence by parsing operators in a specific order.
The function scans the expression from right to left looking for addition and subtraction operators. When it finds one, it splits the expression at that point and recursively evaluates both sides. This right-to-left scan ensures that left-associative operators like "5-3-1" evaluate correctly as "(5-3)-1" rather than "5-(3-1)".
After handling addition and subtraction, the function scans for multiplication and division. These operators have higher precedence, so they are evaluated in a second pass. Finally, the function handles exponentiation, which has the highest precedence of all binary operators.
The function must also handle parentheses correctly. If an expression is wrapped in parentheses like "(2+3)*4", the function strips the outer parentheses and evaluates the inner expression. This allows parentheses to override the normal precedence rules.
Here is a simplified version showing the precedence handling:
func (s *Spreadsheet) evaluateExpression(expr string, cellRef string)
(float64, error) {
// Scan for + and - (lowest precedence)
for i := len(expr) - 1; i >= 0; i-- {
if expr[i] == '+' || expr[i] == '-' {
left := s.evaluateExpression(expr[:i], cellRef)
right := s.evaluateExpression(expr[i+1:], cellRef)
// Combine results
}
}
// Scan for * and / (medium precedence)
for i := len(expr) - 1; i >= 0; i-- {
if expr[i] == '*' || expr[i] == '/' {
left := s.evaluateExpression(expr[:i], cellRef)
right := s.evaluateExpression(expr[i+1:], cellRef)
// Combine results
}
}
// Scan for ^ (highest precedence)
for i := 0; i < len(expr); i++ {
if expr[i] == '^' {
left := s.evaluateExpression(expr[:i], cellRef)
right := s.evaluateExpression(expr[i+1:], cellRef)
// Combine results
}
}
// Base case: parse as number
return strconv.ParseFloat(expr, 64)
}
This recursive approach elegantly handles arbitrarily complex expressions. The expression "2+3*4-5/2" is broken down into smaller pieces, each piece is evaluated, and the results are combined according to precedence rules.
PART VIII: RANGE PARSING - HANDLING CELL RANGES
One of VisiCalc's most powerful features is the ability to operate on ranges of cells. Instead of writing "+A1+A2+A3+A4+A5", you can write "+@SUM(A1...A5)". This range notation is more concise and less error-prone. The parseRange function handles the conversion from range notation to a list of individual cell references.
The function accepts a string like "A1...A5" and returns a slice of cell references: ["A1", "A2", "A3", "A4", "A5"]. The implementation must handle several cases. If the string contains "...", it represents a range. If it doesn't, it represents a single cell.
The function begins by checking for the "..." separator. If found, it splits the string into start and end references. Both references are parsed using ParseCellRef to obtain their coordinates. The function then validates that the start coordinates are less than or equal to the end coordinates, swapping them if necessary. This allows users to specify ranges in either direction: "A1...A5" and "A5...A1" both produce the same result.
With valid start and end coordinates, the function generates all cell references in the rectangular region. It iterates through rows from start to end, and for each row, iterates through columns from start to end. Each combination of row and column produces one cell reference, which is added to the result slice.
The function includes a safety check to prevent generating enormous ranges. If the range would contain more than 10,000 cells, the function returns an error. This prevents users from accidentally creating ranges like "A1...Z254" that would consume excessive memory and processing time.
The complete implementation:
func (s *Spreadsheet) parseRange(rangeStr string) ([]string, error) {
rangeStr = strings.TrimSpace(rangeStr)
if rangeStr == "" {
return nil, fmt.Errorf("empty range")
}
// Replace ellipsis character with three dots
rangeStr = strings.ReplaceAll(rangeStr, "…", "...")
if strings.Contains(rangeStr, "...") {
parts := strings.Split(rangeStr, "...")
if len(parts) != 2 {
return nil, fmt.Errorf("invalid range format")
}
startRef := strings.TrimSpace(parts[0])
endRef := strings.TrimSpace(parts[1])
startRow, startCol, err := ParseCellRef(startRef)
if err != nil {
return nil, fmt.Errorf("start cell error: %v", err)
}
endRow, endCol, err := ParseCellRef(endRef)
if err != nil {
return nil, fmt.Errorf("end cell error: %v", err)
}
if startRow > endRow {
startRow, endRow = endRow, startRow
}
if startCol > endCol {
startCol, endCol = endCol, startCol
}
cells := make([]string, 0)
cellCount := 0
for row := startRow; row <= endRow; row++ {
for col := startCol; col <= endCol; col++ {
if cellCount >= MaxRangeCells {
return nil, fmt.Errorf("range too large")
}
ref := GetCellRef(row, col)
if ref != "" {
cells = append(cells, ref)
cellCount++
}
}
}
return cells, nil
}
// Single cell reference
_, _, err := ParseCellRef(rangeStr)
if err != nil {
return nil, err
}
return []string{strings.ToUpper(rangeStr)}, nil
}
This function enables all range-based operations in VisiCalc for Go. The SUM, AVG, MIN, MAX, and COUNT functions all rely on parseRange to convert their arguments into lists of cells to process.
PART IX: BUILT-IN FUNCTIONS - EXTENDING FUNCTIONALITY
While basic arithmetic operations form the core of spreadsheet calculations, built-in functions dramatically extend what users can accomplish. VisiCalc for Go implements a comprehensive set of statistical, mathematical, and trigonometric functions, each following a similar pattern but serving a distinct purpose.
The SUM function exemplifies the pattern used by all range-based statistical functions. It accepts a range like "A1...A10", expands it into individual cell references, evaluates each cell, and combines the results. The function must handle several edge cases: cells that contain text (which are skipped), cells that contain errors (also skipped), and cells that contain formulas (which must be evaluated recursively).
The implementation begins by extracting the argument from between the parentheses. It uses string manipulation to find the opening parenthesis after "@SUM" and the closing parenthesis at the end. The text between these parentheses is passed to parseRange to obtain a list of cell references.
With the list of cells, the function iterates through each one. For each cell, it checks whether the cell contains an error or text. If so, the cell is skipped. If the cell contains a formula, the formula is evaluated recursively. If the cell contains a plain number, that number is used directly. All valid numeric values are accumulated into a running sum.
Let‘s look at the complete SUM implementation:
func (s *Spreadsheet) evaluateSUM(formula string, cellRef string)
(float64, error) {
startIdx := strings.Index(strings.ToUpper(formula), "@SUM(")
if startIdx == -1 {
return 0, fmt.Errorf("@SUM not found")
}
openParen := startIdx + 5
if openParen >= len(formula) {
return 0, fmt.Errorf("missing range")
}
closeParen := strings.LastIndex(formula, ")")
if closeParen == -1 || closeParen <= openParen {
return 0, fmt.Errorf("missing )")
}
rangeStr := formula[openParen:closeParen]
rangeStr = strings.TrimSpace(rangeStr)
cells, err := s.parseRange(rangeStr)
if err != nil {
return 0, err
}
sum := 0.0
for _, targetRef := range cells {
row, col, err := ParseCellRef(targetRef)
if err != nil {
continue
}
cell := s.GetCell(row, col)
if cell == nil || cell.Error != "" || cell.IsText {
continue
}
if cell.IsFormula && len(cell.Formula) > 0 {
val, err := s.EvaluateFormula(cell.Formula[1:], targetRef)
if err == nil && !math.IsNaN(val) && !math.IsInf(val, 0) {
sum += val
}
} else if !math.IsNaN(cell.Value) && !math.IsInf(cell.Value, 0) {
sum += cell.Value
}
}
return sum, nil
}
The AVG function follows a similar pattern but also counts how many cells contributed to the sum. After accumulating all values, it divides the sum by the count to produce the average. If no cells contained valid numeric values, the function returns zero rather than attempting to divide by zero.
The MIN and MAX functions track the minimum and maximum values encountered while iterating through the range. They initialize their tracking variables to extreme values (positive infinity for MIN, negative infinity for MAX) to ensure that any real value will replace them. They also track whether any valid value was found, returning
zero if the range contained no numeric values.
The COUNT function simply counts how many cells in the range contain non-empty, non-text, non-error values. It doesn't care about the actual values, only whether cells contain valid data.
Mathematical functions like SQRT, ABS, and INT operate on single values rather than ranges. They follow a simpler pattern: extract the argument, evaluate it as an expression, apply the mathematical operation, and return the result. The SQRT function includes validation to ensure its argument is non-negative, returning an error if given a negative number.
The IF function implements conditional logic, allowing formulas to make decisions. It accepts three arguments separated by commas: a condition, a value to return if the condition is true, and a value to return if the condition is false. The implementation must parse the three arguments carefully, handling the fact that arguments themselves might contain commas.
The condition is evaluated by the evaluateCondition function, which handles comparison operators like "=", "<", ">", "<=", ">=", and "!=". This function splits the condition at the operator, evaluates both sides as expressions, and performs the comparison. If the condition doesn't contain a comparison operator, it's evaluated as an expression and treated as true if non-zero.
PART X: TEXT OVERFLOW - HONORING THE ORIGINAL
One of VisiCalc's distinctive features was how it handled text labels longer than the cell width. Rather than truncating the text, VisiCalc allowed it to overflow into adjacent empty cells. This behavior made the spreadsheet more readable and user-friendly, allowing descriptive labels without requiring wide columns.
Implementing this feature correctly requires careful coordination between the display logic and cell content management. When rendering a row, the display system must look ahead to determine how much space is available for overflow. If adjacent cells are empty, their space can be borrowed. If an adjacent cell contains data, the overflow must stop at that boundary.
The Display function maintains a skipUntilCol variable that tracks which columns have been consumed by overflow from previous cells. When rendering each column, the function first checks whether that column should be skipped. If so, it doesn't print anything, because the overflow text from a previous cell has already filled that space.
For cells containing text longer than their width, the function looks ahead to find empty adjacent cells. It accumulates the width of each empty cell, adding to the total available space. When it encounters a non-empty cell or reaches the edge of the visible area, it stops accumulating. The text is then truncated to fit the available space.
Here is the key portion of the overflow logic:
skipUntilCol := -1
for col := s.leftCol; col < s.leftCol+ScreenCols && col < MaxCols; col++ {
width := s.GetColWidth(col)
if col < skipUntilCol {
continue
}
cell := s.GetCell(row, col)
display := cell.DisplayText
actualWidth := width
textToPrint := display
if cell != nil && cell.IsText {
if len(display) > width {
totalSpace := width
checkCol := col + 1
for checkCol < s.leftCol+ScreenCols && checkCol < MaxCols {
if !s.isCellEmpty(row, checkCol) {
break
}
totalSpace += s.GetColWidth(checkCol) + 1
checkCol++
}
skipUntilCol = checkCol
if len(display) > totalSpace {
textToPrint = display[:totalSpace]
} else {
textToPrint = display
}
actualWidth = totalSpace
}
}
// Print the cell with actualWidth
}
This implementation faithfully recreates the overflow behavior of the original VisiCalc, allowing users to create readable spreadsheets with descriptive labels that aren't artificially constrained by column width.
PART XI: FILE PERSISTENCE - SAVING AND LOADING
A spreadsheet is only useful if you can save your work and return to it later. VisiCalc for Go implements a simple but effective file format that preserves all cell formulas and allows spreadsheets to be saved and loaded reliably.
The file format is deliberately human-readable. Each file begins with a header indicating the file version and creation timestamp. Following the header, each populated cell is represented by a line containing the cell reference and its formula. This simple format is easy to parse, easy to debug, and resilient to minor corruption.
The SaveVC function iterates through all cells in the spreadsheet, writing each non-empty cell to the file. It uses a buffered writer for efficiency, accumulating output in memory before writing to disk. This reduces the number of system calls and improves performance when saving large spreadsheets.
The save implementation looks as follows:
func (s *Spreadsheet) SaveVC(filename string) error {
file, err := os.Create(filename)
if err != nil {
return err
}
defer file.Close()
writer := bufio.NewWriter(file)
fmt.Fprintf(writer, "# VisiCalc File v%s\n", Version)
fmt.Fprintf(writer, "# Created: %s\n",
time.Now().Format("2006-01-02 15:04:05"))
for row := 1; row <= MaxRows; row++ {
for col := 0; col < MaxCols; col++ {
ref := GetCellRef(row, col)
if ref == "" {
continue
}
if cell, exists := s.cells[ref]; exists &&
cell != nil && cell.Formula != "" {
fmt.Fprintf(writer, "C:%s:%s\n", ref, cell.Formula)
}
}
}
writer.Flush()
return nil
}
The LoadVC function performs the reverse operation, reading a saved file and reconstructing the spreadsheet. It reads the file line by line, skipping comment lines that begin with "#". For each data line, it splits the line at colons to extract the cell reference and formula. It then calls SetCell to populate that cell, which triggers formula evaluation.
After loading all cells, the function calls Recalculate to ensure all formulas are evaluated with current data. This is necessary because cells might have been loaded in an order that caused some formulas to reference cells that hadn't been loaded yet.
The file format's simplicity makes it easy to create VisiCalc files with external tools or to inspect saved files with a text editor. This transparency aids debugging and allows advanced users to manipulate spreadsheets programmatically.
PART XII: THE USER INTERFACE - BRINGING IT ALL TOGETHER
The user interface ties together all the components we've discussed, presenting them in a coherent, usable form. VisiCalc for Go uses a terminal-based interface that echoes the simplicity of the original while taking advantage of modern terminal capabilities.
The Display function renders the entire screen, including the column headers, row numbers, cell grid, status bar, and command prompt. It uses ANSI escape sequences to clear the screen and position the cursor, ensuring a clean display on each refresh.
The grid display shows nine columns and twenty rows at a time, representing a viewport into the larger 26-by-254 spreadsheet. As the user navigates, the viewport scrolls to keep the current cell visible. The AdjustView function handles this scrolling, updating the topRow and leftCol fields to maintain the current cell within the visible area.
Each cell in the grid is displayed with appropriate formatting. Numeric values are right-aligned, matching the convention used in accounting and financial applications. Text labels are left-aligned, matching the convention used in word processing. The current cell is marked with a "►" symbol, making it easy to see which cell will be affected by the next command.
The status bar at the bottom of the screen shows the current cell reference, the operating mode, and the cell's contents. This information helps users understand the current state of the spreadsheet and see the actual formula behind computed values.
The command system uses a simple slash-based syntax reminiscent of early text editors. Commands like "/S filename" save the spreadsheet, "/L filename" loads a file, and "/Q" quits the application. This syntax is easy to type and easy to remember.
Navigation uses single-letter commands: "w" moves up, "s" moves down, "a" moves left, and "d" moves right. This WASD scheme is familiar to gamers and requires only one hand, leaving the other hand free for the numeric keypad or mouse.
The main loop reads user input, interprets commands, updates the spreadsheet state, and refreshes the display. This simple loop structure makes the program's flow easy to understand and modify.
The structure of the main loop:
for {
spreadsheet.Display()
input, err := reader.ReadString('\n')
if err != nil {
break
}
input = strings.TrimSpace(input)
if input == "w" {
spreadsheet.currentRow--
spreadsheet.AdjustView()
} else if input == "s" {
spreadsheet.currentRow++
spreadsheet.AdjustView()
} else if input == "a" {
spreadsheet.currentCol--
spreadsheet.AdjustView()
} else if input == "d" {
spreadsheet.currentCol++
spreadsheet.AdjustView()
} else if strings.HasPrefix(input, "/") {
// Handle commands
} else {
// Enter data into current cell
spreadsheet.SetCell(spreadsheet.currentRow,
spreadsheet.currentCol, input)
spreadsheet.Recalculate()
}
}
This loop continues until the user quits the application or an error occurs. Its simplicity makes the program's behavior predictable and easy to debug.
PART XIII: LESSONS FROM THE PAST, INSIGHTS FOR THE FUTURE
Implementing VisiCalc for Go has provided numerous insights into software design, both historical and contemporary. The original VisiCalc designers made remarkably sound decisions that remain valid today. Their choice to separate formulas from values, to use text-based cell references, and to support ranges all proved to be enduring design patterns.
The recursive descent parser used for formula evaluation is a classic technique that remains relevant. While modern parser generators can automate much of this work, understanding how to write a recursive descent parser by hand provides valuable insight into how programming languages and domain-specific languages are processed.
The sparse storage approach, using a map instead of a full array, demonstrates the importance of choosing appropriate data structures. This decision reduces memory usage by orders of magnitude for typical spreadsheets while adding minimal complexity to the code.
The careful error handling throughout the codebase reflects modern best practices. Rather than crashing or producing incorrect results, the program detects errors early and reports them clearly. This defensive programming approach makes the software more robust and user-friendly.
The implementation also highlights the value of simplicity. By focusing on core functionality and avoiding unnecessary features, VisiCalc for Go remains comprehensible and maintainable. The entire program is less than 1,500 lines of code, yet it provides genuine spreadsheet functionality.
Looking forward, this implementation could be extended in numerous ways. Support for multi-letter column names would allow larger spreadsheets. Additional functions could provide more analytical capabilities. A graphical user interface could make the program more accessible to modern users. Support for importing and exporting Excel files could improve interoperability.
However, these extensions should be approached carefully. Each addition increases complexity and maintenance burden. The original VisiCalc's power came not from having every possible feature, but from doing a few things exceptionally well. This lesson remains relevant for modern software development.
PART XIV: CONCLUSION - HONORING THE LEGACY
VisiCalc for Go stands as a tribute to one of the most influential programs ever written. By reimplementing VisiCalc's core concepts in a modern language, we gain appreciation for the elegance and foresight of its original designers. Dan Bricklin and Bob Frankston created something that transcended their era, establishing patterns that persist in every spreadsheet application used today.
The journey of implementing this homage has been both educational and humbling. Educational because it requires deep understanding of parsing, evaluation, and user interface design. Humbling because it reveals how much careful thought went into the original design, and how challenging it is to recreate even a simplified version of that functionality.
For programmers learning about language implementation, data structures, or user interface design, studying this implementation provides concrete examples of these concepts in action. The formula parser demonstrates recursive descent parsing. The cell storage demonstrates hash maps and sparse data structures. The display system demonstrates terminal control and text formatting.
For historians of computing, this implementation preserves knowledge about how early spreadsheets worked. As the original VisiCalc fades into history, implementations like this one keep its concepts alive and accessible to new generations of programmers.
For users who appreciate the directness and simplicity of terminal-based applications, VisiCalc for Go provides a functional tool that eschews the complexity of modern spreadsheet applications. Sometimes you don't need pivot tables, macros, and cloud synchronization. Sometimes you just need to add up a column of numbers.
The spreadsheet revolution that began in 1979 continues today. Every time someone opens Excel, Google Sheets, or LibreOffice Calc, they benefit from the vision that Dan Bricklin had during that Harvard Business School lecture. VisiCalc for Go honors that vision by demonstrating that its core concepts remain sound and valuable, even in an era of vastly more powerful computers and sophisticated software.
In the end, VisiCalc's greatest legacy is not the specific program, but the idea it embodied: that computers could be tools for thought, amplifying human capability rather than merely automating existing processes. This idea transformed personal computing from a hobbyist pursuit into an essential business tool. It justified the purchase of millions of computers. It launched an industry.
VisiCalc for Go is our small way of saying thank you to Dan Bricklin and Bob Frankston for their vision, their skill, and their contribution to the world of computing. May their legacy continue to inspire programmers for generations to come.
No comments:
Post a Comment