2 ms·

Amazing. From the very first issue, page 6: > In my job I work with professional programmers working on personal computers. I have met hundreds of such program

Amazing. From the very first issue, page 6: > In my job I work with professional programmers working on personal computers. I have met hundreds of such programmers and have developed a good feeling for their characteristics as a group. I can say with sad certainty that the average programmer is not sharp enough to write good wargame programs. Very few programmers in this business are bright enough to handle the task. Most programmers work in BASIC, a language for beginners. Even among programmers producing commercial software for personal computers, fluency in assembly language (the most powerful language) is rare. It is impossible to fully realize the power of a personal computer without using assembly language.

gota 5y ago
To the folks that were around - was that statement true at the time, in a reasonable/charitable interpretation? Or is it just a early form of gatekeeping that got written down?
- hakfoo 5y ago
  I think there was a big "missing middle". You were all but guaranteed a BASIC in most late 70s/early 80s home computers. It was frequently optimized for development cost and ROM size-- so "it fits into 4k or 8k" was more important than performance or quality of life features. The canonical example of this problem was Commodore's 2.0 BASIC-- incapable of accessing almost all of the machine's graphics and sound capacities without resorting to peeks and pokes. Even if you could fight through that, it wasn't going to be possible to maintain smooth animations or do cycle-precise operations. The other available option was assembly. Most platforms had some assembler/monitor package available for fairly cheap, or even built into ROM. The solutuons you'd expect to fill the gaps simply weren't there. You didn't see too many compiled languages (which could close the performance gap) likely because compilers of the time were typically expensive and commercial, and often required fairly big hardware (disc drives and more memory) to run on. If you had a VIC-20 or ZX80, there was barely room for any nontrivial code, let alone a compiler to toss around intermediary state.
  - zozbot234 5y ago
    FORTH was a valid alternative to BASIC on the 8-bit machines (it could easily have better code density than naïve raw asm) and some commercial software used it.

gota 5y ago

To the folks that were around - was that statement true at the time, in a reasonable/charitable interpretation? Or is it just a early form of gatekeeping that got written down?

hakfoo 5y ago
I think there was a big "missing middle". You were all but guaranteed a BASIC in most late 70s/early 80s home computers. It was frequently optimized for development cost and ROM size-- so "it fits into 4k or 8k" was more important than performance or quality of life features. The canonical example of this problem was Commodore's 2.0 BASIC-- incapable of accessing almost all of the machine's graphics and sound capacities without resorting to peeks and pokes. Even if you could fight through that, it wasn't going to be possible to maintain smooth animations or do cycle-precise operations. The other available option was assembly. Most platforms had some assembler/monitor package available for fairly cheap, or even built into ROM. The solutuons you'd expect to fill the gaps simply weren't there. You didn't see too many compiled languages (which could close the performance gap) likely because compilers of the time were typically expensive and commercial, and often required fairly big hardware (disc drives and more memory) to run on. If you had a VIC-20 or ZX80, there was barely room for any nontrivial code, let alone a compiler to toss around intermediary state.
- zozbot234 5y ago
  FORTH was a valid alternative to BASIC on the 8-bit machines (it could easily have better code density than naïve raw asm) and some commercial software used it.