AnotherDilbert
SOC-14 1K
I fear history is not on your side.Developers will learn how to code better ...
Better tools will more likely lead to higher productivity and lazier developers, just like now.
I fear history is not on your side.Developers will learn how to code better ...
I have an imaginary compnent, which makes me complex. This also means I'm allowed to eat quiche.[ . . . ]
Real men use Assembler.
I have an imaginary compnent, which makes me complex. This also means I'm allowed to eat quiche.
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.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.
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 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.
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.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.
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.Nope, we believe the code works when we have succeeded on the roll. Critical Flaws may still exist.
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.Again, it generally takes extremely skilled people a month or two on average. Why would it take months if it was so 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)."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.
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.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.
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.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.
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.I would only call it debugging if it involved finding the exact flaw in the code and fixing it.
You're the one defending it like some holy text...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.
I said the programming was done in the first week using libs. Everything after that was debugging.So you agree that we can still produce flawed models or code, even when using well-tested libs?
I'm saying that hacking a working code might be how it can be done in a week but leave a hidden flaw.So you agree that trying to make sense of decompiled code is much more difficult and time consuming than using well documented libs?
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.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?