4 ms·

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 langua

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.)

frogulis 3y ago
> and are incentivised not to Could you elaborate on that?
- bitwize 3y ago
  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.
  - exe34 3y ago
    Gotta keep that velocity up!
  - snvzz 3y ago
    Or copy-paste from stackunderflow.
- 13of40 3y ago
  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.
  - kqr 3y ago
    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.)
    - ale42 3y ago
      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...
      - kqr 3y ago
        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.
        ale42 3y ago
        > 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)
- boffinAudio 3y ago
  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...
- GuB-42 3y ago
  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.
  - pizza234 3y ago
    > 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.
    - GuB-42 3y ago
      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.
commandlinefan 3y ago
> "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.
- renewedrebecca 3y ago
  Things turned out to be a lot less fun than I thought they would be, just for what you've mentioned.

frogulis 3y ago

> and are incentivised not to Could you elaborate on that?

bitwize 3y ago
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.
- exe34 3y ago
  Gotta keep that velocity up!
- snvzz 3y ago
  Or copy-paste from stackunderflow.
13of40 3y ago
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.
- kqr 3y ago
  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.)
  - ale42 3y ago
    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...
    - kqr 3y ago
      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.
      - ale42 3y ago
        > 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)
boffinAudio 3y ago
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...
GuB-42 3y ago
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.
- pizza234 3y ago
  > 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.
  - GuB-42 3y ago
    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.

commandlinefan 3y ago

> "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.

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