embracing retro 'puters

[AnotherDilbert]

Developers will learn how to code better ...

I fear history is not on your side.

Better tools will more likely lead to higher productivity and lazier developers, just like now.

 

[nobby-w]

[ . . . ]
Real men use Assembler.

I have an imaginary compnent, which makes me complex. This also means I'm allowed to eat quiche.

 

[kilemall]

I have an imaginary compnent, which makes me complex. This also means I'm allowed to eat quiche.

I never said I was a 'real man'. Just I that I recognize the hierarchy of ability.


I've heard tales of people writing in binary raw, but have my doubts.

 

[nobby-w]

I never said I was a 'real man'. Just I that I recognize the hierarchy of ability.


I've heard tales of people writing in binary raw, but have my doubts.

I have done hand assembly on old (1970's vintage) single board machines with MC6800 and RCA1802 processors. The instruction sets are quite small, so it's quite easy to remember the key opcodes. When I got a BBC Micro with an assembler built into the BASIC interpreter I felt like I was in the lap of luxury.

At one point I was going to do some postgrad work under a chap called Keith Hopper, who had worked on the Manchester Mk I as a summer job while he was doing his masters. That was wire wrap work programming the machine, ones and zeros.

https://en.wikipedia.org/wiki/Manchester_Mark_1

Uphill both ways etc.

 

[agorski]

I have done hand assembly on old (1970's vintage) single board machines with MC6800 and RCA1802 processors. The instruction sets are quite small, so it's quite easy to remember the key opcodes.

I've still got my 6502 and PDP-11 pocket reference cards with the instruction sets and opcodes.

 

[whartung]

I never said I was a 'real man'. Just I that I recognize the hierarchy of ability.


I've heard tales of people writing in binary raw, but have my doubts.

I'm sure if you do it enough, the numbers are all you need and you can skip the mnemonics.

I've hand toggled in programs via the IMSAI 8080 front panel.

I did it enough to note it's a terrible experience and the minimal amount you need to do in order to enable some kind of real keyboard/output is worth your time to never have to go back and do that again.

Keying in hex codes on to a KIM-1 is no big deal. It's no worse than using a programmable calculator back in the day when the instructions were essentially the row/column index of the keys you entered.

Obviously having to deal with all this limited the scope of what kind of programs you could make, so you instead you wrote programs that let you write bigger programs easier.

 

[wellis]

Regarding "retro computers", do you figure they should be as slow to boot up as well?

Or have interfaces like keyboards or monitors that are bulky or heavy and such? And have not great interfaces as well, like they're not as clear or sharp as say a modern 2018 computer would have?

 

[Ulsyus]

I never said I was a 'real man'. Just I that I recognize the hierarchy of ability.


I've heard tales of people writing in binary raw, but have my doubts.

My first sceptical thought was "0, that 1"

 

[Straybow]

The '77 edition programming rules are in JTAS1, as Mike pointed out. The roll to succeed is 12+ and the minimum time is at least two months + a week.

No. Those are the JTAS rules, not published until mid '79 and never included as erratum or addendum in LBB1-3 box sets, nor in a supplement. I, for example, never knew JTAS existed in my playing years and have never seen one copy since.

It is a far more reasonable model of programming effort, but note that this particular mechanic, written by MM, was not used by MM in '81. He regressed to a lousy model, for unknown reasons.

Nope, we believe the code works when we have succeeded on the roll. Critical Flaws may still exist.

Fourth wall, friend. The player rolls dice. The character only knows that success has been achieved. It's so safe that, on the other side of the fourth wall, the hidden bug only shows up "when used in space combat," which means it never shows up in some characters' lifetimes. Which means there was no error. The Schodinger wave resolved itself without the dice on the far side of the fourth wall.

Again, it generally takes extremely skilled people a month or two on average. Why would it take months if it was so trivial?

Because MM wasn't trying to simulate the actual process of programming. He was merely creating a mechanic that would fit in the game mechanism of one week in jump and one week to/in/from port, and that would be vague about how the process is done and how big programs are.

It may, possibly, under a lucky star, be completed in a week. In my experience, the most common cause of such lucky early completion is that the people involved have done this, or something similar, before and already knows the problem with any potential pit-falls. This does not necessarily make the problem trivial.

In that case, a player whose character has Comp-3 and Nav-4 can just say, "My character included a Generate program as part of his Doctorate program (it is Appendix VI in his published dissertation about designing errors to cause controlled misjumps of 7-12 parsecs)."

Possibly, or possibly not, we don't know. All we know is that we absolutely need a post-doc specialist to handle it. That does not spell trivial to me.

See above. It can be done in a week, trivial. It takes post-doc level work, not trivial... to anyone who hasn't reached post-doc Nav skill.

The context seems to be lost. You seem to consider any activity after the first week debugging. I was merely pointing out that other problems were possible.

If the program can be completed in one week, then by definition anything done after that is debugging. It isn't working, and you're either trying an alternate approach to eliminate the bug without actually finding it, or you're sifting through the code to find it. Makes no difference, the end result is the removal of the bug. If you didn't finish the first draft after the first week, you're supposed to be debugging but you're behind schedule.

I would only call it debugging if it involved finding the exact flaw in the code and fixing it.

I know which section of code was removed, and therefore the bug has been found. I wrote new code that doesn't include the bug, so, by definition, I've debugged the program. I could, at my leisure and for my own elucidation, go back and sift through the abandoned code to find, isolate, analyze, and correct the specific code. But that work is not necessary to the finished product.

It's a game. It's even one of the fist wave of role playing games written by minimal staff in the seventies, when programming was even less generally understood by most people.

You're the one defending it like some holy text...

So you agree that we can still produce flawed models or code, even when using well-tested libs?

I said the programming was done in the first week using libs. Everything after that was debugging.

So you agree that trying to make sense of decompiled code is much more difficult and time consuming than using well documented libs?

I'm saying that hacking a working code might be how it can be done in a week but leave a hidden flaw.

 

[nobby-w]

Regarding "retro computers", do you figure they should be as slow to boot up as well?

Or have interfaces like keyboards or monitors that are bulky or heavy and such? And have not great interfaces as well, like they're not as clear or sharp as say a modern 2018 computer would have?

Depends. A BBC micro took about a second to boot including clearing its memory. Some vintage mainframe or mini systems could take half an hour, although that would typically involve starting up a lot of stuff or running many diagnostics. It really depends what the computer was doing on boot up.

Terminals or other hardware might be more bulky. Displays might have lower resolution. Other features might be less sophisticated.