FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
83% Positive
Analyzed from 2263 words in the discussion.
Trending Topics
#brief#code#more#basic#programs#windows#still#editor#emacs#used

Discussion (44 Comments)Read Original on HackerNews
Coding was different back then.
Hope the tape recorder works to save my work every hour or so. Switch on my Epson fx80 to dump hard copy.
Simpler, happier times.
In the late 90s, I wanted to learn x86 assembly and sent an email to Intel asking for their reference manuals. They sent four huge volumes to me for free. I've no idea whether that was a mistake, but I was very grateful.
I still can't believe any of us were able to write programs just from reading books, and I'm not sure to what extent that's even possible today. Even online documentation now seems really crappy compared to those old manuals.
It slowed work down a lot but was totally fine - the bank was paying us tons of money hourly.
Possible but very inefficient way of doing things.
Also very secure.
Failed the 301 Systems Programming class because C on my NeXT Cube was sufficiently different from the compiler in the labs and I never managed to work out how to bridge that gap mentally....
AI tools can write mlog but there’s not much of it out there so they frequently make errors, making it even more of a “you’re on your own” experience. i recommend the game anyway (it’s libre) but the opportunity to code this way has considerably added to the enjoyment for me.
[1] https://anuke.itch.io/mindustry
I sat at a non-internet-connected terminal in the back of the TechED room and typed examples from the provided book into a very simple editor. Sometimes they compiled and worked. Sometimes they did not work despite being to all appearances character for character the same as the book, and I was often left with no idea why.
It was not an entirely unfamiliar experience. I had a Mattel Aquarius as a young child and spent countless hours typing games in from the back of the manual before attempting to save them to cassette.
For deeply thought intensive tasks like “why did the system crash” I printed out pages of C code and hand-executed code to find places with invalid memory access. For example a null pointer wouldn’t segfault and print a nice stack trace, it’d just overwrite the in memory code itself.
It was laborious but lots of fun. I learned a ton about C and embedded programming
There were BBSes back then where you could often find help from others or share code. Not just mail and magazines.
Not really sure what got "lost" here. But fundamentally nothing has really changed much, except for deeper abstractions, more powerful tools and the cost of "generating" (or producing) code approaching near zero (if you discount the cost of subscriptions to Claude/Codex, etc and the underlying costs of running those st scale).
You still have to understand, and read every line. Although now we just get tools to do so for us. But the understanding is still a requirement.
The good times...
Was only BASIC, but needed as there wasn't any way to save...
It had a completely configurable auto-complete, which I rewrote to insert big code templates in the languages that I was using (C, C++, Fortran, Basic, assembly), covering almost all boilerplate that I encountered at that time.
The BRIEF editor for programmers was one of the best software products that I have ever used. Nothing that I encountered later on Windows approached it in customizability. Actually I find it strange that I cannot recall any Windows program that I would consider as a high-quality software product, while there are a handful of programs for MS-DOS that I consider as examples of high-quality, even decades later (e.g. the programming editor BRIEF, the file manager XTree, the spreadsheet Lotus 1-2-3, the technical drawing program AutoCAD for MS-DOS; all these were extremely customizable).
Nowadays Emacs may have even more customizable features, but it has always been more opaque for newbies. BRIEF was instantly usable on an IBM PC clone, even if discovering its advanced features could require some time.
Despite having used continuously for 3 decades various UNIX-derived operating systems, including Solaris, FreeBSD and Linux, only this year I have switched to Emacs, in order to recreate the great programming experience that I had with BRIEF many years ago. Emacs includes all that is necessary, but it requires a much longer initial study in comparison with BRIEF, before becoming able to master it, which is why I hesitated for a long time before trying it.
I recall him trying to convince me to switch to it a few times, from vim. I never found it as advanced as vim, but I could see the capabilities. I recall being impressed by some macro he had that improved navigation, both within a file and opening new files.
I also recall him being impressed when I showed him vim's ctags commands.
Good times. Pity he was a mean SOB.
Its strength was its embedded scripting language, which may have been inspired by Emacs LISP.
With the scripting language, you could change everything, including the behavior of any key press or of any combination of keys.
Thus you could create a personalized editor that had no resemblance with BRIEF as originally delivered and you could parse the source text of the edited programs and do arbitrary transformations or analyses and you could invoke any external tools for building a software project and it handled the compiling error messages, so it could work as a complete IDE. It also included a tiled windows manager.
Therefore, it is likely that there have been as many different BRIEF editors as BRIEF users, as long as they hacked the set of scripts originally delivered with it.
The only editor that I am aware of and which has a so powerful scripting language is Emacs and its derivatives. Because Emacs is even older than BRIEF, I assume that it was the source of inspiration for BRIEF. I have used vim for many years. I was satisfied with it, but it was not so easy to customize as BRIEF was.
I have not used BRIEF for Windows, so I do not know if it was as good as BRIEF for MS-DOS. Unfortunately, most of the great MS-DOS programs had versions ported to Windows that were quite disappointing.
This allowed Microsoft to create competitive Windows products that grabbed the market from the former MS-DOS market leaders, like with Microsoft Office. Of course, Microsoft cheated in many cases, because its internal developers frequently used Windows OS interfaces that were not yet known to outsiders because they were planned for the next Windows release or interfaces that were undocumented and which remained undocumented, unless someone reverse engineered them.
No blogs, no SO, no autocomplete, crappy IDEs, no AI, etc...
I miss that difficult focused learning. The smallest successes felt like huge accomplishments.
And the 0 and 8. And this was used by some copy-protection to try to prevent reverse engineering. Back then real debuggers (by "real debugger" I mean not just "debugging in your head": but an actual, although very minimal, debugger) were very simplistic too, and so you'd read everything line by line, keeping in your head what the program was doing, was the register contained, what subroutines would do etc. And then you'd have "tricks" by the copy protection where that line with a '0' you just analyzed a few commands before would turn, sneakily, into a '8' (maybe by a function or a side effect of a command etc.).
And when we'd spot it we'd be: "Wait dude, did you notice how sneaky it is, this actually turns the 0 into an 8, so the next this execute, everything shall be corrupt" (or something like that).
And so debuggers got enhanced: for example if anything on screen got modified, the modified value would flash than stay in green. Stuff like that.
Our tools were much more basic.
But then we learned to eat 68x00 and x86 opcodes for breakfast.
But alongside these machine-language programs, they published a short BASIC editor, and this is how you typed in the machine code. It was all numbers, and the editor program would calculate the CRC, and it could flag typos, so you could re-enter the bad lines. That was way better than arduously entering DATA statements in BASIC, or just having a malfunction because of a typo in those programs.
This stuff was all rather magical for me. At first I didn't even have a storage device. I'd type in short BASIC programs, shut off the machine, and they'd be wiped: gone forever. Of course, with the Commodore computers, there was always an option to purchase cartridge-based software that was durable.
Eventually I had a Datasette cassette recorder, so I could save those programs I'd typed in. It was quite amazing to be able to finally save my own stuff, or the magazine programs.