Command Line Interface Guidelines
get help from Usenet—an early internet community filled with other people who were just as frustrated as you were
The toxically positive person deep inside me does not remember this as frustrating. Perhaps I romantisize the green screen a bit - but it was so thrilling to see the blinking cursor, inviting you to type out some commands and see what you could achieve.
But yes - maybe because it wasn’t easy to use the CLI - Norton Commander got really popular.
So popular that folks like (my former colleague) Miguel de Icaza created clones of it - Midnight Commander.
And of course - my favorite - Far Manager.
Turbo C for DOS
John Carmack has great pointers and his tweets are always good for thought.
Leaving a note here to remind me to resurrect Turbo C on FreeDOS (if possible) and practice some competitive programming with this IDE.
Here’s how to install C on FreeDOS
or try it in a browser
- MS-DOS Application: Borland Turbo C 2.01 : Free Download, Borrow, and Streaming : Internet Archive
- WinWorld: Borland Turbo C++ 3.x (DOS)
- Jeff from https://www.jeffgeerling.com has an “off-line corner” where he keeps his pre-Internet retro computers!!
linked lists versus slices or dynamic arrays
I decided to talk to chat GPT and ask it a hard and deliberately confusing question. I wanted to know how chat gpt4 thinks about linked lists which the programmer s of a bygone era were relying on and why they were not using golang slices or dynamic arrays.
great and “thoughtful” answer
The comparison you’re making between linked lists and slices in Go (Golang) involves looking at data structures from different programming eras and paradigms. Golang was created in 2009, well after the 1960s, 70s, and 80s. During those earlier decades, linked lists were widely used in programming for several reasons, especially in languages like C and assembly, which were prominent at the time. Here’s a brief overview of the benefits of linked lists compared to slices (dynamic arrays) in Go, and why linked lists were popular before data structures like Go slices became available:
- Dynamic Size: Linked lists provide a dynamic size, meaning they can grow and shrink at runtime. This was especially important in earlier computing environments where memory was limited and had to be managed very carefully. Slices in Go also provide dynamic size, but they abstract away much of the memory management involved.
- Ease of Insertions/Deletions: Linked lists allow for O(1) time complexity for insertions or deletions if you have direct access to the point of insertion/deletion, without the need to shift elements as in an array or slice. This makes them efficient for certain types of operations where elements are frequently inserted or removed.
- Memory Efficiency for Large Elements: When storing large elements, linked lists can be more memory efficient since they store elements non-contiguously in memory. This allows a program to make better use of fragmented memory spaces. In contrast, slices in Go are contiguous, which can sometimes lead to memory waste if the slice has to grow and no contiguous block of memory is available, requiring a larger memory allocation and copy of the entire slice.
The reason why programmers in the 60s, 70s, and 80s didn’t use Go slices (or arrays in the way we think of them in higher-level languages today) is because Go and its slice data structure didn’t exist yet. At the time, managing memory and data structures manually was a common practice, and linked lists offered flexibility and efficiency that matched the hardware and software constraints of the era.
In modern programming with Go, slices are often preferred for their ease of use, built-in support from the language runtime for managing dynamic resizing, and generally good performance for a wide range of applications. However, linked lists still have their use cases, particularly in scenarios where their specific advantages over slices or arrays apply.