Chapter 1: Reflections on Programming in the 90s

Programming in the 1990s was a unique experience, distinctly different from today’s landscape, especially due to the lack of reliable Internet access.

This era saw the use of programming languages like Clipper 5, where the absence of graphical user interfaces posed both challenges and advantages. Early versions of Windows, like 3.0 and 3.1, were notoriously unstable, leading to frequent errors. Most programmers worked in DOS, and while I had limited experience with Macintosh systems, I began exploring Linux around the time Windows 95 was released.

The lack of graphical environments simplified programming; developers didn't need to navigate complex interfaces. The applications I created often featured basic graphics using text characters, with no sophisticated visual components unless specialized libraries were employed. Text editors were basic, with no syntax highlighting, autocompletion, or bracket matching.

Despite these limitations, some aspects of programming remain unchanged. A competent text editor and command line tools can still yield high productivity. I often used Q-Edit, a now-defunct editor, which was efficient for coding tasks.

Unlike today, where Integrated Development Environments (IDEs) like Visual Studio and Eclipse can take a while to load, programming in the 90s often meant instant access to development tools. For instance, Borland IDEs offered rapid startup times, allowing for immediate coding.

Sublime Text reflects a move towards efficiency, although it’s important to note that the object-oriented programming paradigm was still in its infancy during this period. Code was often unstructured, and practices like 'spaghetti' coding were common. The infamous ‘goto’ statement was still in use, despite being viewed negatively.

Programming at the assembly level was more prevalent, and knowledge of it was essential for certain tasks. Today, such skills are rare, as high-level programming has become the norm.

Documentation was primarily found in thick manuals, and while contextual help was limited, tools like Norton Guides provided instant assistance. The reliance on web-based help today can slow down development due to response times, especially when compared to the immediate access of resident documentation back then.

Memory constraints were a reality—having 4MB of RAM was considered luxurious. Tools like Qemm optimized memory usage effectively. The use of libraries was emerging, often sourced from Bulletin Board Systems (BBS) at slow modem speeds. The concept of APIs and web services was virtually nonexistent, and HTML was unheard of.

Version control was rudimentary; backing up code involved using tools like Pkzip or Arj, with no sophisticated versioning systems in place. The first code repository I encountered was SourceSafe with Visual Basic 5 in 1998.

The omnipresence of the Internet today can have a detrimental effect on developers, as it encourages reliance on quick fixes and 'cut-and-paste' coding practices, fostering complacency. To combat this, I recommend disconnecting from the Internet during challenging projects. This forces developers to rely on their knowledge and skills, leading to greater focus and problem-solving capabilities.

As I’ve tested this approach, I found that stepping back from distractions enhances my understanding of programming languages and syntax, allowing for deeper concentration on the task at hand.

Chapter 2: Insights from the Past and Present

In "Being a Programmer in the 90s VS Now," Jonathan Blow compares the programming landscape of the 90s to modern times, discussing the evolution of tools and practices.

The video "What A Day In A Programmers Life Is Actually Like" explores the daily realities of programmers today, highlighting the contrast with past experiences.