5 ms·

I've lost the original reference, but Joe Marshall once wrote in comp.lang.lisp: Here's an anecdote I heard once about Minsky. He was showing a student how to

I've lost the original reference, but Joe Marshall once wrote in comp.lang.lisp: Here's an anecdote I heard once about Minsky. He was showing a student how to use ITS to write a program. ITS was an unusual operating system in that the 'shell' was the DDT debugger. You ran programs by loading them into memory and jumping to the entry point. But you can also just start writing assembly code directly into memory from the DDT prompt. Minsky started with the null program. Obviously, it needs an entry point, so he defined a label for that. He then told the debugger to jump to that label. This immediately raised an error of there being no code at the jump target. So he wrote a few lines of code and restarted the jump instruction. This time it succeeded and the first few instructions were executed. When the debugger again halted, he looked at the register contents and wrote a few more lines. Again proceeding from where he left off he watched the program run the few more instructions. He developed the entire program by 'debugging' the null program.

userbinator 5y ago
Many PC magazines of the late 80s/early 90s had program listings (in Asm) for small utilities that you created by typing them into DEBUG, the very basic debugger that came with DOS. The C64 and ZX ones had similar listings, although I believe they were more commonly in the platform's variant of BASIC. Unfortunately, I don't think this culture existed around Apple's machines since the Macintosh and the Lisa that came before it.
- deckard1 5y ago
  the way to low-level format early MFM drives was to run DEBUG and enter assembly and call some special routine in the controller chip on the drive. These were instructions that came in the manual with the drive. Pretty wild times. We've come a long way.
  - lproven 5y ago
    DEBUG g=c800:5 From 30-year-old memory. Yes, we actually had to do stuff like this. When I started my first job in the late 1980s, it was normal for hard disks to have a little label with a list of the (known) bad blocks on the drive. (Hand-written by someone at the factory on the first (circa 15-20MB) disks I used; later, on things like big ESDI disks, dot-matrix printed.) In some formatting tools, you had to manually enter them; formats took a long time, so eliminating retries on bad blocks could save half an hour. Novell Netware came with its own low-level formatter called `COMPSURF`: COMPrehensive SURFace analysis. Dozens of people would be sharing a server's hard disk, so data losses would be extra-bad -- and might well bring down the server, losing everyone's work. Note: the assumption in the early days of Novell was that workstations didn't have hard disks of their own and booted off the server too, making a LAN tens of thousands of £/$ cheaper than giving everyone their own HDD. Running COMPSURF before you installed took hours. Server HDDs were big -- hundreds of megabytes! Scanning all that took ages.
Stratoscope 5y ago
This is how I write code today! Everything needs a catchy name, so I call it Debugger Driven Development. I write the first few lines of a function, however much I feel sure about, then add a dummy statement at the end and set a breakpoint there. When the code stops at the breakpoint, I can see exactly what my code did and what data I now have on hand. I use that new knowledge to write the next few lines, again until I get to something I'm unsure of or where I'd just like to get a better view of the data. Set a breakpoint there and view that new data. Repeat as needed until the function is done. At my work we have many internal APIs that are "documented" but the documentation is fairly lacking. With the debugger, I can see not only what the API claims to do, but what it really does with my actual input. I am bummed that so many developers today eschew debuggers. I even read an article recently along the lines of "These famous programmers don't use debuggers, and you shouldn't either". Why would anyone want to talk people out of using such a useful tool? It makes no sense to me.
- saagarjha 5y ago
  It’s sadly fallen victim to the “if you’re not using a debugger you’re not a real programmer” reversal.
- jamesfinlayson 5y ago
  I'd love to use a debugger more, but in my day job at least, the use of Docker makes it a hassle to set up. For standalone Java applications, or when using Visual C++ though, it's so much better than printing out state.
- Annatar 5y ago
  We did that in the 1980’s and the 1990’s on the Commodore 64 and the Amiga, only then the debugger was called a monitor and it was quickly discovered that programming in them was slow and error prone because they lacked the ability to recompute. That is how assemblers were invented: Turbo Assembler on the Commodore 64 and ASM-One, TRASH’M-One, Seka and MasterSeka on the Amiga. ASM-One and TRASH’M-One include an excellent debugger built natively into the integrated development environment, and stepping through the code after assembling it is a joy.
protomyth 5y ago
I know a few Smalltalk programmers who did the same thing. They basically wrote their programs in the debugger. It was an interesting technique.
- saagarjha 5y ago
  I do a limited form of this with C/C++ projects that take forever to compile, with many conditional breakpoints that alter control flow to my liking that I then "solidify" into actual code when I have it looking like I want.
  - pjmlp 5y ago
    With VC++ you can solidify them directly.
    - saagarjha 5y ago
      Oh, really? I'm not very familiar with it, do you have the name of the feature so I can look it up?
      - pjmlp 5y ago
        Before VS 2022, it used to be called edit-and-continue, now they are doubling now on it improving the use cases that are actually supported, and it got renamed as hot reload. https://devblogs.microsoft.com/cppblog/c-edit-and-continue-in-visual-studio-2015-update-3/ https://devblogs.microsoft.com/cppblog/c-edit-and-continue-i... https://docs.microsoft.com/en-us/visualstudio/debugger/edit-and-continue-visual-cpp https://docs.microsoft.com/en-us/visualstudio/debugger/edit-... https://docs.microsoft.com/en-us/visualstudio/debugger/hot-reload?view=vs-2022 https://docs.microsoft.com/en-us/visualstudio/debugger/hot-r... Here is a demo of its latest state from the VS 2022 launch event, https://youtu.be/8SP1w7i8r-Y?list=PLReL099Y5nRc9f9Jpo1R7FsdHGQwqoHLn&t=63 https://youtu.be/8SP1w7i8r-Y?list=PLReL099Y5nRc9f9Jpo1R7FsdH...
larsbrinkhoff 5y ago
I tried to recreate such a session: https://www.youtube.com/watch?v=7Ub36q03vkc https://www.youtube.com/watch?v=7Ub36q03vkc
msravi 5y ago
That's how I learnt x86 assembly using MS-DOS and "debug" - which was a program that came with DOS. The proper assemblers at that time were Microsoft's MASM and Borland's TASM. With no access to those, the only option was to use the one bundled in DOS. Fun times, where you had to compute relative addresses of JMPs, based on the address where the JMP instruction sat. And then, you could even write to a particular cylinder/sector/offset on the hard disk and replace the boot sector with your own code.

userbinator 5y ago

Many PC magazines of the late 80s/early 90s had program listings (in Asm) for small utilities that you created by typing them into DEBUG, the very basic debugger that came with DOS. The C64 and ZX ones had similar listings, although I believe they were more commonly in the platform's variant of BASIC. Unfortunately, I don't think this culture existed around Apple's machines since the Macintosh and the Lisa that came before it.

deckard1 5y ago
the way to low-level format early MFM drives was to run DEBUG and enter assembly and call some special routine in the controller chip on the drive. These were instructions that came in the manual with the drive. Pretty wild times. We've come a long way.
- lproven 5y ago
  DEBUG g=c800:5 From 30-year-old memory. Yes, we actually had to do stuff like this. When I started my first job in the late 1980s, it was normal for hard disks to have a little label with a list of the (known) bad blocks on the drive. (Hand-written by someone at the factory on the first (circa 15-20MB) disks I used; later, on things like big ESDI disks, dot-matrix printed.) In some formatting tools, you had to manually enter them; formats took a long time, so eliminating retries on bad blocks could save half an hour. Novell Netware came with its own low-level formatter called `COMPSURF`: COMPrehensive SURFace analysis. Dozens of people would be sharing a server's hard disk, so data losses would be extra-bad -- and might well bring down the server, losing everyone's work. Note: the assumption in the early days of Novell was that workstations didn't have hard disks of their own and booted off the server too, making a LAN tens of thousands of £/$ cheaper than giving everyone their own HDD. Running COMPSURF before you installed took hours. Server HDDs were big -- hundreds of megabytes! Scanning all that took ages.

Stratoscope 5y ago

This is how I write code today! Everything needs a catchy name, so I call it Debugger Driven Development. I write the first few lines of a function, however much I feel sure about, then add a dummy statement at the end and set a breakpoint there. When the code stops at the breakpoint, I can see exactly what my code did and what data I now have on hand. I use that new knowledge to write the next few lines, again until I get to something I'm unsure of or where I'd just like to get a better view of the data. Set a breakpoint there and view that new data. Repeat as needed until the function is done. At my work we have many internal APIs that are "documented" but the documentation is fairly lacking. With the debugger, I can see not only what the API claims to do, but what it really does with my actual input. I am bummed that so many developers today eschew debuggers. I even read an article recently along the lines of "These famous programmers don't use debuggers, and you shouldn't either". Why would anyone want to talk people out of using such a useful tool? It makes no sense to me.

saagarjha 5y ago
It’s sadly fallen victim to the “if you’re not using a debugger you’re not a real programmer” reversal.
jamesfinlayson 5y ago
I'd love to use a debugger more, but in my day job at least, the use of Docker makes it a hassle to set up. For standalone Java applications, or when using Visual C++ though, it's so much better than printing out state.
Annatar 5y ago
We did that in the 1980’s and the 1990’s on the Commodore 64 and the Amiga, only then the debugger was called a monitor and it was quickly discovered that programming in them was slow and error prone because they lacked the ability to recompute. That is how assemblers were invented: Turbo Assembler on the Commodore 64 and ASM-One, TRASH’M-One, Seka and MasterSeka on the Amiga. ASM-One and TRASH’M-One include an excellent debugger built natively into the integrated development environment, and stepping through the code after assembling it is a joy.

protomyth 5y ago

I know a few Smalltalk programmers who did the same thing. They basically wrote their programs in the debugger. It was an interesting technique.

saagarjha 5y ago
I do a limited form of this with C/C++ projects that take forever to compile, with many conditional breakpoints that alter control flow to my liking that I then "solidify" into actual code when I have it looking like I want.
- pjmlp 5y ago
  With VC++ you can solidify them directly.
  - saagarjha 5y ago
    Oh, really? I'm not very familiar with it, do you have the name of the feature so I can look it up?
    - pjmlp 5y ago
      Before VS 2022, it used to be called edit-and-continue, now they are doubling now on it improving the use cases that are actually supported, and it got renamed as hot reload. https://devblogs.microsoft.com/cppblog/c-edit-and-continue-in-visual-studio-2015-update-3/ https://devblogs.microsoft.com/cppblog/c-edit-and-continue-i... https://docs.microsoft.com/en-us/visualstudio/debugger/edit-and-continue-visual-cpp https://docs.microsoft.com/en-us/visualstudio/debugger/edit-... https://docs.microsoft.com/en-us/visualstudio/debugger/hot-reload?view=vs-2022 https://docs.microsoft.com/en-us/visualstudio/debugger/hot-r... Here is a demo of its latest state from the VS 2022 launch event, https://youtu.be/8SP1w7i8r-Y?list=PLReL099Y5nRc9f9Jpo1R7FsdHGQwqoHLn&t=63 https://youtu.be/8SP1w7i8r-Y?list=PLReL099Y5nRc9f9Jpo1R7FsdH...

larsbrinkhoff 5y ago

I tried to recreate such a session: https://www.youtube.com/watch?v=7Ub36q03vkc https://www.youtube.com/watch?v=7Ub36q03vkc

msravi 5y ago

That's how I learnt x86 assembly using MS-DOS and "debug" - which was a program that came with DOS. The proper assemblers at that time were Microsoft's MASM and Borland's TASM. With no access to those, the only option was to use the one bundled in DOS. Fun times, where you had to compute relative addresses of JMPs, based on the address where the JMP instruction sat. And then, you could even write to a particular cylinder/sector/offset on the hard disk and replace the boot sector with your own code.