Hacker News Reader

Comment by userbinator | Hacker News Reader

The fact that this debugger program is always available with MS-DOS or Windows 98 system means that these systems are ready for some rudimentary assembly language programming without requiring any additional tools.

PC magazines from the 80s through the 90s took advantage of this, publishing listings of "source code" that could be typed into DEBUG to create tiny but useful utilities, mostly under 1K in size. It was an era when "power users" or even moderately advanced users would often know some actual programming too and many grew into full-time developers; a stark contrast from these days when many "real" developers barely understand anything about their environment (and are incentivised not to.)

View on HN

> "source code" that could be typed into DEBUG

Oh, wow - I remember doing something similar on my Commodore 64. The C64 came with a BASIC interpreter, but no built-in assembler. There was a magazine called Compute's Gazette that included, in the back of every issue, a simple assembler of sorts written in BASIC. So if you wanted to run any of the programs included in the magazine, you'd first type in the code for the assembler and use that to "bootstrap" your assembler programs. They were long (pages and pages) of listings of hexadecimal, with a checksum at the end of each line to make sure you didn't make a tiny mistake toward the beginning that rendered the whole thing useless.

It was actually pretty amazing how sophisticated some of these programs would end up being, considering the entire hex dump could realistically be printed on four or five A4 standard pages.

Man, I spent a lot of time typing those things in - I still remember off the top of my head, almost 40 years later, that the opcode for LDA was A9 and STA was 8D, because I typed those in a _lot_. Back then, I thought that this was more or less what a career in computer programming would be like - honestly, with the JIRA tickets and Sprint retrospectives and standups and planning sessions that it's turned out to be, I'm a little disappointed.

Things turned out to be a lot less fun than I thought they would be, just for what you've mentioned.

> and are incentivised not to

Could you elaborate on that?

Not much time for in-depth learning when you have sprint commitments to make. Just have Copilot generate the boilerplate and tests and fix them as you go.

Or copy-paste from stackunderflow.

Gotta keep that velocity up!

Example: Everyone knows how to use a Dictionary. It's not worth anyone's time to know how it works under the hood, because only a fool would actually implement one from scratch in production code. Niche embedded cases possibly excepted.

I would argue this is because we've raised the bar for what counts as a computational primitive, and not a qualitative difference.

A modern developer can ignore the details of a dictionary in the exact same way a programmer of the past could ignore the details of the mov instruction. (And be more productive for it.)

The problem is when developers having virtually no background in actual computer science (e.g. algorithm complexity) start implementing their own algorithms because what thy want is not directly available as a primitive. I have the impression that this tendency to use more and more complex software primitives, while at the same time introducing further levels of indirection in the actually run machine code, is one of the reasons that many applications are now as slow (or slower) than they were 10 years ago despite the hardware being much faster. Just compare the performance of an Electron-based application (which seems the go-to solution of most developers nowadays for desktop app implementation) with a native one...

I think you're embedding a value judgment in this (slow execution = bad) that is probably not shared by the people using the primitives you think are inappropriate.

In other words, when people don't care for speed they use Electron. What part of that indicates that people have no background in algorithm complexity? We have traded off run-time speed against other things for ages -- even in computing science.

> I think you're embedding a value judgment in this (slow execution = bad) that is probably not shared by the people using the primitives

Can be... because I'm also a user, and it's frustrating to have the PC bloated by dozens of Electron-based apps using huge amounts of RAM, draining the battery more than necessary, and for part of them, actually slow to use. Perhaps some users don't care because they are either not sensitive to small delays or resource usage, or because they have never seen anything else.

I see also an environmental question arising here. More CPU cycles = more energy used. Makes no difference for applications used by small groups of people, but for software used in millions of copies, I'm wondering how many MWh we are wasting (I wouldn't care much —except for battery life— if energy was only from renewable sources... but it's not the case)

I'm guessing, just guessing, that most of the people who don't think slow execution is bad are probably not that interested in what the machine actually has to do to execute their code, and hence, are not actually well educated in making those tradeoffs.

> It's not worth anyone's time to know how it works under the hood

Knowing (at a high level) how your programming language implements dictionaries has relevance to questions like time complexity of various operations, potential security vulnerabilities (a hash table might succumb to hash collision denial of service, especially if the implementation isn’t hardened against that possibility; a tree-based implementation probably won’t have that vulnerability), likely impact of different bugs (e.g. a buggy hash method can cause much more problems on a hash table than on a tree, while for a buggy comparison method it is the other way around), concurrency, etc

> because only a fool would actually implement one from scratch in production code

I’ve implemented a dictionary before in C. Not for work (only wrote C code for work one single time ever, and it was only a page worth of code that was called from Java, no complex data structures needed), just for my own learning/amusement. That said, C is probably the one context in which people still commonly “roll their own” basic data structures, even in production code, just because C’s standard library is so weak in that regard (and C’s lack of generics/templates doesn’t help either)

> only a fool would actually implement one

No, only a fool would let his boss know that he did.

You need permission to write software and distribute for modern platforms. This is very disincentivizing .. not so when you've got a compiler/assembler onboard everywhere and can just ship without permission from MegaCorp...

You are incentivized to user higher abstractions, sometimes for good reasons (portability, productivity, etc...).

But the higher you go, the more magic there is. On a DOS machine when x86 processors actually ended with "86", or on home computers like C64s and Amigas, everything was simple. No concurrency, no security, no networking, you had a processor and it ran instructions. You go from a character displayed on screen and with a little research, have a good idea about everything that happened down to the transistor. Now, it is impossible, most of the hardware components of a modern computer are made of little computers, each one orders of magnitude more complex than these early systems, many of them run encrypted software.

It means that now, software development is more about trying to get an idea of what the people who made the layer under yours were thinking about. It is becoming harder to go with first principles, too complex, it is therefore discouraged, as it is more likely to hurt productivity.

> on home computers like C64s [...], everything was simple

Simple? I take you've never had to implement a division on the 6502. Or write complex code due to the limitations of 8 bits (which couldn't even directly address the pixels on the X axis) and/or 3 registers.

I didn't mean that using or programming the machine was simple, far from it. But the machine itself was simple.

If some pixel doesn't light up right on your C64, you can follow the path from your code to the electron beam in the monitor. That entire path could fit in a single person head. It is a puzzle but you have all the pieces in front of you.

Now, it is not a puzzle anymore, you just call some drawText() function and then some magic happens and there is text on the screen. If the magic doesn't happen, monitoring the output of your GPU won't help you, there is too much in between, some of it deliberately obfuscated. So you try random stuff that don't make much sense except that because of your experience, you know they work. Or more likely, someone with experience already did it, posted it on StackOverflow, and you found it using Google.

Reply on news.ycombinator.com