Nonetheless, after thirty-five years of shoving problems under the rug, I decided the best way forward was to review everything and rewrite it from the ground up.Ĭ++ is and always has been an effective language for managing complexity in large projects, so why did I change languages? I was incredibly impressed with Apple’s Augmented Reality technology. With a complete rewrite, everything is new. In a typical dot release, focusing testing on new features is easy. While a fresh start can be aesthetically satisfying, it creates an enormous surface area for bugs. Legacy code embodies decades of hard-learned lessons which the current developers never experienced, and even the original developers, if they are still around, have long since forgotten. Rewriting everything from scratch, aka taking off and nuking the entire site from orbit, is almost never a Good Idea. Graphing Calculator still uses the Classic Mac OS 9 cooperative threading APIs in order to run code frozen in the 1980s which is not thread-safe. Eventually, decades of accumulated technical debt make new development fraught. It is easier to write new code adding new functionality and hide ancient legacy code under layers of abstraction. It was originally written to the classic Mac API of Inside Macintosh, then Carbon, then Cocoa, AppKit & UIKit, and now SwiftUI. It has seen the CPU change from the Motorola 68K to the IBM PowerPC family, to Intel, and to ARM. I have long adhered to the philosophy of “If it ain’t broke, don’t fix it”, so the code carries many vestiges of its past – design choices which made sense at the time, but no longer serve.
Graphing Calculator began in 1985 in C for the 128K Macintosh in the days of 16-bit ints, black & white Quickdraw, and the 0 CPU with no MMU, FPU, nor GPU.
This post is authored by Ron Avitzur, author of the Pacific Tech Graphing Calculator. Ron Avitzur is the author of the Pacific Tech Graphing Calculatorĭeveloper Spotlight is a series highlighting interesting Swift developers from around the world.
0 kommentar(er)
