In the late 70s and early 1980s, computer magazines and books usually distributed program codes via program listings, which the user then had to type into his computer. Today these are also known as type-in-program or type-in-listing programs. Source: WP article about type-in-programs

Are there any scientific studies and results of the studies on if this was just tedious work, or if the user did learn something about programming just by typing it in the computer?

I assume that the program code had to be adapted due to different BASIC dialects, for example, so that the code not only had to be typed in, but also understood. But is there any scientific evidence on this?

  • Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on Retrocomputing Meta, or in Retrocomputing Chat. Comments continuing discussion may be removed.
    – Chenmunka
    Commented Jul 21, 2023 at 15:15
  • 1
    Current answers are opinion-based - or personal-experience based. But the question as now edited asks for objective evidence, e.g., studies, that provide the answer. (I doubt there were any, but I'm often surprised by what's out there.) Voted to reopen, after the edit.
    – davidbak
    Commented Jul 24, 2023 at 1:10
  • @davidbak Personal recount is objective evidence. Maybe not sumarized but adding up due sheer number. Information doesn't get more reliable just because of pointing to someone else as source.
    – Raffzahn
    Commented Jul 24, 2023 at 16:59
  • "Information doesn't get more reliable just because of pointing to someone else as source." <- wikipedia disagrees with you ... they think "second source" is a magical way to get ground truth. IOW: I do agree with you. "objective" was probably not the word I wanted. The OP asks for "scientific" - I felt that was too constrained.
    – davidbak
    Commented Jul 24, 2023 at 19:10
  • 2
    Obligatory xkcd reference: citogenesis.
    – dave
    Commented Jul 24, 2023 at 19:49

15 Answers 15


The typing didn't. The subsequent debugging did.

  • 5
    100% this. Many an Acorn Electron listing in Electron User magazine got me to where I am today - Senior Software Developer. I am entirely self-taught and typing those programs in sparked my initial interest. It is worth mentioning that the debugging was fixing bugs that were 50% my own typos and 50% errors in the printed listings! Commented Jul 20, 2023 at 12:11
  • 10
    I would add modifying in addition to debugging. Sometimes I wanted things to work slightly differently so I had to deconstruct how the type-in worked to learn where and how to change it. Commented Jul 20, 2023 at 14:19
  • As someone who typed in quite a few programs from the various David H. Ahl books in the 80s, I will say that the typing part was very tedious (more so when you two finger hunt and peck). However, once I had those programs typed in and saved, the real fun began when I'd start tweaking them to make them more specific to my computer, like adding color or sound. Later, I'd start changing how the games worked, and sometimes even extending them. It was a good way to learn at the time, but I would have been happy to skip the typing part. Commented Jul 20, 2023 at 20:41
  • 2
    As a kid of around 12 or 13 I was taken to visit a friend of my father, who had an Apple II. He had typed in a long Applesoft BASIC program from a magazine that was some sort of file manager. It didn't work. At the beginning of the program was something like: 30 D$="" : REM TYPE CTRL-D IN HERE. So this guy had even typed in the comment without following the instruction, and so didn't learn anything until I debugged it. Hence my upvote of this answer. (Yes, I realize the author of the program should've used CHR$(4) etc.) Commented Jul 21, 2023 at 1:21
  • 2
    I owe my entire career to a bug in the listing in a magazine back in 1980, when I was 8 years old. My teacher had typed it in but it did not work. I looked at the listing, never having seen code before, but I was an avid reader and and saw an open quote mark with no closing quote mark - I suggested that could be the problem and tried the fix. It worked, and my course in life was set...
    – kpollock
    Commented Jul 21, 2023 at 8:36

TL;DR: Yes

Reading those listing was a major way of learning to program.

In the late 70s and early 1980s, computer magazines and books usually distributed program codes via program listings,

Printing listings is still a thing, isn't it? Of course they nowadays are usually only printed in full if reasonable short.

which the user then had to type into his computer.

Or could buy on magazine disks/cassettes, depending on magazine offers of course.

Today these are also known as type-in-program or type-in-listing programs.

As they were back then.

Was this just tedious work, or did the user learn something about programming just by typing it in the computer?

Of course, I would see no difference from an example in a book, isn't it? Not to mention that many people did just read such listing without ever typing them in. I for sure haven't typed any during all the years, but read a lot.

Same way I spend countless hours to read the Monitor listings of several machines (KIM, Junior, Apple II), or later the PC/XT-BIOS.

This may be somewhat less true for programs presented in compressed form of or hexcode(*1).

I assume that the program code had to be adapted due to different BASIC dialects

Usually less than one may assume. For one, Listings intended for multiple dialects were usually written in a common subset - not at least as it makes no sense to port a program relaying on specific hardware features (*2). This was especially true during early times when publications tried to cover a wide area. Second, many magazines were system specific (CPC, C64, Atari, etc.), featuring fitting programs.

but also understood.

Hard to avoid. When typing them in, one had to read it first, which naturally creates understanding - not to mention that typing errors were common (*3) and we all know debugging without understanding is a game of luck.

Then again, I can imagine some people only keen to get the typing done, so they can play the game. Then again, those were usually the ones not interested in programming at all.

If so, is it possible to conclude that one learned to program through these type-in program listings?

Guess I can go as proof - like many other :)) We were reading those listings like other profession read drawings, formula or diagrams.

Bottom line: We were reading them like any other article in those magazines.

*1 - Some magazines published lengthy programs in hex code with checksum to be entered using a custom utility. That way error rate could for long programs be drastically reduced.

*2 - It was common to have tables published (some had it in every issue) which listed equivalent commands for different machines, so one could 'translate' it from the machine it was presented to what was sitting on your desk.

There were also attempts to go beyond by having system specific 'libraries' for complex functions, intended to be loaded in combination, covering variations in sub programs.

Notable here also BASICODE, which allowed automated adaption to different systems - except it wasn't about manual type in handling but loading from common cassette formats or other media like bar code.

*3 - That's why some mags also introduced checksum utilities for BASIC.

  • 2
    I don't know anybody who learned anything about programming from typing in the listings in magazines.
    – JeremyP
    Commented Jul 19, 2023 at 12:46
  • 2
    @JeremyP Learn from scratch, certainly no. But the "That's how it works!" moments were plenty, be it some programming trick or some specific poke address/value combination. Commented Jul 19, 2023 at 13:10
  • 1
    @JeremyP Well, what about a pint or two, next time I'm in England? Would be a chance to get to know at least one guy who learned a lot about programming from reading listings.
    – Raffzahn
    Commented Jul 19, 2023 at 13:31
  • 1
    @Raffzahn OK ping me.
    – JeremyP
    Commented Jul 19, 2023 at 13:52
  • 1
    @Raffzahn This is one of them en.wikipedia.org/wiki/Datastrip_Code I recognise the name. Surprisingly, the article and links put it even later: very short-lived in the '85-6 timeframe. Commented Jul 20, 2023 at 12:13

Speaking as a person who used to type the listings into his parents' Commodore PET, the answer is no. I learned BASIC by being taught it by my Dad. Understanding BASIC helped with the typing and inevitable debugging, but doing the typing did not help my programming.

In any case, sometimes the programs were really just machine code loaders consisting of lots of pokes of magic numbers.

  • 2
    Thanks for sharing your personal experience.
    – Coder
    Commented Jul 19, 2023 at 11:42

Yes, and...

... I still do it today, but now from YouTube videos instead of magazines.

During the 2020 lockdown, I finally taught myself Python and OpenCV this way (and more recently 6502 assembler). I watch YT tutorial videos, and even though the author may (or may not) have a Github repository, I won't take the easy way out and just download it (as you won't learn as much or as quickly).

Instead, I will type out manually the code shown on screen as the presenter scrolls through their code - it will require split-second video pausing skills. Sometimes some pages will be missing, and this will either require educated guess-work, or waiting for a later video instalment where they go over the old code again and you can go back and fill in the missing lines.

For me, this method works best: Repeatedly typing out the same blocks of code (especially the initial skeleton framework that is required for each program) somehow forces it into my head (sort of similar to muscle memory I guess).

Also, after having hurriedly manually typed out the code, there will obviously be a myriad of typos, and/or missing lines, that prevent the code from working, and then debugging skills come into play

Rote-learning versus research

It should be noted that this rote learning approach is really only any good for hammering home the syntax of the language concerned and the general program structure.

However, the real learning of the actual language actually comes from having to look up the definitions of the commands (and their parameters/arguments) in references/documentation - be that the accompanying ZX Spectrum BASIC programming manual back in the 80's, or the online hypertext documentation of today.

The debugging aspect (once the copy-typing is complete), that others have mentioned, intersects both of the points above:

  1. Tidying up the rote copied code and polishing the copy - was the code copied accurately?
  2. Once the code has been verified that the copy was indeed correct, but if the code still doesn't work (be that due to a type-setting error in the magazine, or an error made by the author), then the research phase begins - looking up the commands in the reference material and ensuring that the arguments/parameters for each of the commands are indeed valid.
  3. If the program still isn't working, then there is possibly a third stage (assuming that the user doesn't throw in the towel at this point and just give up): Analysis of the program logic
    • This is neither part of the rote-learning, nor the research
    • This would seem to be more of an intuitive, analytic phase - possibly involving some lateral thinking.

Note: I haven't seen any academic proof of any of this, but it seems reasonable after careful self-analysis.


Adapting to your computer's dialect was a real experience!

Not every computer back then used Microsoft BASIC. I learned a lot by typing in a program written on one computer into my machine's dialect of BASIC, adapting as I went. Or Fortran, in one case. The more adventuresome one was adapting classic Star Trek to integer BASIC and making the photon torpedoes work anyway with no trig functions. Had to do fixed point arithmetic, so had to learn that. I just didn't bother supporting the thing where you asked it for the angle to the enemy, I would've done a lookup table in any case.

So yes, there's plenty to learn, if you choose to put yourself to the task.


From my experience: Yes.

But first: Sure, the typing was certainly tedious.

  • Typing in the code gives you familiarity with commands in the language you may have never learned or needed to use, for example BASIC's gosub call; knowing to seed the RNG srand(), etc.
  • Also undocumented things, like peeks and pokes to different memory regions that had interesting effects, or allowed you to read direct key-presses.
  • But the "best" thing for learning was fixing the syntactic errors you made while typing.
    • Leaving off a close-quote, or missing a colon : (which separates multiple commands in BASIC), typically always produce similar forms of weird error messages.
    • Recognising these errors and fixing them is a great help later when you make the same mistakes in your own code.
  • You also learned about other types of BASICs, each with their own specific hardware-related functions. For example, cross-platform graphics functions simply did not exist.

At the time programming books were near-impossible to find. Even your city library wouldn't have much. Learning to program was already in hard-mode, so any book was welcomed.

Generally the only programming books our city library (early 1980's) had were code-listing type books, that and there was probably only ever two or three of them. My high school library stocked a few of the same later in the decade.

  • 2
    Oh lol, I found interesting addresses by just looping through and poking addresses on my ZX Spectrum
    – JollyJoker
    Commented Jul 20, 2023 at 10:09

Mostly not but it was a valuable learning resource for those who wanted it. One thing to understand about the period for people who were born long after is that there were not many sources of information about programming. We didn't have the internet, we certainly didn't have a resource like StackOverflow to go and get answers from. We learned a few things from books, and figured out the rest by ourselves. Reading listings in magazines, and figuring out how they worked, was an immensely valuable means of learning new ways of doing things and improving your skills.

But... realistically? Most people just typed them in. Which probably seems weird now, but games were few in number, expensive for children of the era, and only a few shops carried them and those usually had a narrow selection. Spending time typing things in seemed a lot more reasonable in an era where people had less stuff, less distractions, and only three TV channels on the one TV that lived in the family living room.


Back then, I was a Sinclair Spectrum user. Magazines like Your Sinclair and Sinclair User tended to only print code using Spectrum basic, so no porting was needed.

One of the problems with learning from this kind of code is that it tends to be golfed to heck, to make it faster to type in, and take fewer column inches (and so be more likely to be published!), so they would generally be a great blob of raw numbers in DATA statements that would be POKE'd into memory. If you typoed... well, debugging wasn't going to be a thing for you there. If you were lucky, the code checked some checksums so it told you what line your error was.

Instead, you'd carefully go through everything you typed character by character, and see where you'd slipped up.

Sometimes, the program just didn't work, and you could find no problem. Perhaps you typoed. Perhaps there was a printing error. You never found out.

Edit: I hunted down some Spectrum type-ins. Found a couple of good archives at http://www.users.globalnet.co.uk/~jg27paw4/type-ins/typehome.htm and https://www.computinghistory.org.uk/cgi/archive.pl?type=Listing&platform=ZX%20Spectrum which let me nostalgically revisit my past.

I feel my memory has been tainted by remembering best the last few years before the magazines died and I got my first PC. In that period, the type-in code had almost disappeared from the magazines. Any interesting programs were included on the cover tape rather than devoting column inches to them, and in print they were mostly only publishing "pokes" to hack cheats in games, which were mostly just blocks of DATA statements. If debugging a program was hard, debugging a hack into another program was essentially impossible without a Multiface (an awesome dongle for the Spectrum that let you debug memory in real time). Eventually the pokes, too, made their way to the cover tape.

Looking at the archived type-ins, I realize that yes, I did learn a lot of my first steps of programming, and formed my first early opinions about things like programming style, from type-in games.

I wish I still had my old tapes and 3 inch floppy disks (not 3.5 inch!)

This all reminded me of another source of type-ins, and coding knowledge: books! These "teach yourself BASIC" style books were in most libraries, and DID have the traits that the OP described: you'd need to convert from whatever flavor of BASIC the book was written in, to Sinclair Basic. And they'd teach you, in some way, about the language as you went. Even once you were comfortable with BASIC, you could usually pick up a few good tips and patterns from paging through a book and reading the listings.

Here you can see a Spectrum type-in that illustrates some of those tricks. There's lots of DATA lines, for graphics, coordinates, audio, and at the end, Z80 ASM for the monster AI.

Other than the impenetrable monster AI, the code is densely golfed but makes sense. Reading and understanding it took me a few hours today.

Main game loop is 100-300.

100-150 user input (keys left=5, right=8, ladder=0), detect collision with monsters and screen edges, picking up barrels, and dropping them into goal in the bottom right. Call ladder climb, or call die, or handle timer.
200-260 animate ladder climb subroutine.
300-310 handle timer, then go to die, or loop back to user input.
400-510 capture barrel: update score, add more monsters, then go to level setup.
700-730 die by monster, wall, or timeout. Decrement lives then go to begin play, or restart program.
1000-1001 Game initial setup: init vars, call mem setup, then go to level setup.
1002-2270 Level setup: init timer, score, floors, barrels, monsters, then go to begin play.
2275-2500 Begin play from new level or respawn, then go to user input.
9500-9510 Mem setup subroutine. Remap user characters (A=ladder, B=player, C=monster, D=barrel, E=player with arms raised), and Load in monster AI Z80 code, then return to game initial setup.

Tricks I might pick up from reading code like that, are things like:

  • using -SGN(x) to cap the variable x between bounds (line 125);
  • using ATTR, the colors of the current coordinate, for item and collision detection, by ensuring the player is the only one with the default attributes (line 100)
  • using empty loops for delays (line 2405: tsk, very bad form!);
  • and using GOTO instead of GOSUB when the return from the subroutine could skip a few lines (lines 200-260 skip two lines of checks in the user input that can't happen on ladders).
  • Using the #1 and #2 params to PRINT so that the full screen can be used as a display (A Spectrum quirt: #1 prints to the bottom two lines of the screen, typically reserved for input).
  • It pulls a trick with DATA on line 410 that stores coordinates for a display of captured barrels. The DATA's read from line 400, but the ones that have already been captured are first read in the level setup code at line 2280, so the READ pointer becomes a method of tracking progress.
  • Massive reuse of variables, especially l=line, x=column and i=loop iterator.
  • Store the player's avatar in a variable (m$) so it needn't check the bf flag every time it's drawn.
  • Mark flags obviously with a Polish-like naming convention like bf/mf/lf (second character is f for boolean flag: monster flag, ladder flag). Not all vars use Polish, though: other vars are sc=score, ba=barrels, no=number of monsters.

Barrels and Ladders type-in


I typed many Basic programs manually into my TRS80 from the 80 Microcomputing magazine. If you had an interest, like I did, you could learn about programming from this. I also learned to touch type reasonably well (with all ten fingers!). Definitely learned to find typos, etc. but also enjoyed tinkering with the programs. This led to writing my own programs. Which ultimately led to a 40 year career as a programmer analyst.


The steepest learning curve for me was this (late 70s and all 80s):

  1. Extract the hex bytes of some not-too-long machine program, that is up to 8 kiByte. The most fun was the ZX81 ROM. :-D
  2. Write down all these bytes one after the other in a column on squared paper.
  3. Disassemble the bytes starting at the known or supposed entry point(s).
  4. In the course try to make sense out of the result.

There are so many assembly tricks I found this way.

Other than that, I can just back up the others. The learning took (and still takes) place by reading and trying to understand the source code, instead of typing. To insert debugging statements or to single-step through the code adds to this.

This is true for any language for me.

  • 1
    Thank you for your answer. About step 3. Have you also tried to write a disassembler to help you at disassembling instead of doing all the work manually?
    – Coder
    Commented Jul 20, 2023 at 4:26
  • 1
    @Coder Well, as a student in the early 80s, I had only the hex listing or the small machine connected to a TV set without any chance to print on paper. Think about a young man without money but a lot of time, sitting in front of a borrowed ZX81 (1 KiByte RAM) with a book of squared paper and a pen, and a xerox copy of the relevant chapters of Rodnay Zaks' book on Z80. :-D However, as soon as I could put my hand on a "real" computer (CP/M and later Atari ST), I actually wrote several disassemblers. One of them is even generic and table-controlled to use it for different instructions sets. Commented Jul 20, 2023 at 5:55
  • Thank you for your informative answer.
    – Coder
    Commented Jul 20, 2023 at 5:59
  • @Coder > Have you also tried to write a disassembler to help you at disassembling instead of doing all the work manually? I remember trying to do stuff manually, and getting frustrated, and grumbling "You practically need a COMPUTER to figure this stuff out!", then facepalming with a DOH! Commented Jul 21, 2023 at 6:46

From US perspective, there were multiple magazines my mother subscribed us to that included program listings (and at least one did have an offer to buy a gizmo that would do checksums as well as others that had a type in program that would do checksums in software). Nibble was, IIRC, purely Apple II focused and the listings that it included were awesome for learning by extending what they provided. The one I specifically remember was a short BASIC program that actually injected a machine language routine that used what they called an undocumented applesoft entrypoint to support efficient horizontal scrolling. They broke stuff down enough that I was able to then extend it to make it bi-directional scrolling (which meant understanding the assembly to add the reverse code, then looking up what ML hex value was used by each assembly op code, then getting very good at converting from hex to decimal because by injected, I mean they had a set of decimal values in a data region that they poked into place)

The other ones (whose name escape me at the moment) were multi-platform; most of the differences were pretty trivial, but programs that tried to do stuff with graphics or sound had a bit of an upword climb to support them (I feel like basic click type sound was mainly different hardware address for poking, vs graphics were pretty much limited to a few specific BASICs or used ASCII art type tricks) Most of those were less open-ended but still had some places you could mess with to learn some new tricks or what not.


It was much more a learning experience for me, as it was necessary to take those listings and translate them from the flavor of BASIC they were written in, to another programming language entirely.

Our online time-sharing system was WYLBUR, a line-editor/batch submission system, and CPS (IBM's "Conversational Programming System") running in PL/1 mode. (There was a BASIC mode as well, but the university didn't enable that.)

Anything that would have been a "type-in" on a BASIC system now became a "how do I translate this into this half-assed PL/1 variant" problem. Very much a learning experience, especially when program sizes pushed up against the limits of the fixed-size memory block each session ran in.


Was this just tedious work, or did the user learn something about programming just by typing it in the computer? Are there any scientific studies on this and if so, what was the result?

Most software in those type-in magazines was coded in assembler and you had to type in endless rows of numbers. There was nothing to learn from that.

Example page

You had to use a special program, a “Checksummer” to enter those. It would save you from the endless frustation of finding the one single byte you typed in wrongly by doing one check per row.

That said, sometimes there was BASIC listing with meaningful content you could learn from but it was an exception. Especially later in the 1980ies.

I assume that the program code had to be adapted due to different BASIC dialects, for example, so that the code not only had to be typed in, but also understood. Is this assumption correct? If so, is it possible to conclude that one learned to program through these type-in program listings?

No. Magazines were usually targeted to one single type of computer. There had been a few mags that had listings for different computers but they died out one after another because most people had only one computer and why they should buy a mag with only one listing for their particular machine?

The most popular magazine of that kind in Germany was “Happy Computer” and they turned into a pure gaming mag after a while, aside from specials, and eventually rebranded the mag as “Power Play”.

The only source of “type-in“ programs for several computers I remember was a colorful booklet series ”Spaß mit Computern” published by the CHIP magazine, which had BASIC program listings that would run on several popular computers with minor modifications, which were explained. That series was also intended to teach people programming and I devoured it as a kid.

(There had been of course books on programming which had lots and lots of example programs. But they were really teaching books. One I remember fondly was Sherlock Holmes themed. The authors even made thinking about databases and word processing fun.)

  • 2
    But what about clear text code listings?
    – Coder
    Commented Jul 19, 2023 at 8:09
  • 7
    Maybe after a while they were but there was a long period in UK computer magazines where it was all whatever dialect of BASIC.
    – Alan B
    Commented Jul 19, 2023 at 8:15
  • 13
    In my (considerable) experience, UK microcomputer magazines of the 1980-1985 era VERY RARELY published type-ins as assembly language or raw hex, instead replicating the BASIC listing provided by the author for the specific machine on which it was written. Half the challenge for a young whizz-kid was attempting to translate a foreign BASIC dialect to that of your own machine to try to get an interesting-looking program running - often only partially successfully (if at all) due to each machines' hardware differences. Happy days. Commented Jul 19, 2023 at 9:23
  • 3
    As with the others, I would strongly disagree with the ‘Most software…’ claim. Am happy to be proven wrong if anybody has metrics, but anecdotally I recall hardly any type-ins being in that form.
    – Tommy
    Commented Jul 19, 2023 at 19:20
  • 3
    @RobinElvin Towards the later days of the boom, 85-87ish when the Speccy, C64 and Beeb reigned supreme and the 16-bit machines were just gearing-up towards disk-mag software, yes - magazines were more inclined to publish extensive machine-code programs presented as a BASIC stub and a ream of DATA statements. I vividly recall typing SCRAM-20 into my VIC in exactly this way. But the earlier years were not like that, as C&VG, PCW, YC and numerous other magazines of the day catered for Commodore, Atari, Sinclair, Tandy, Dragon, Sharp, Apple and others predominantly in BASIC. I have detailed files. Commented Jul 20, 2023 at 15:01

Although I agree with other posters that the significant learning experience was in debugging, following transcription errors both on my part, and on the part of the publisher, note that yes, tedious copying is a well-known, though not highly efficient, method of teaching and learning.

Most of what tedious copying can teach you is just the control words and basic syntax of BASIC. That's actually rather important, difficult, and strange for a beginner. Of course, one of the advantages of BASIC was that it had a very simple syntax, and a very short list of control words, but on the other hand, beginners back then really were beginners: they knew nothing.


I grew up with an Atari 800 XL, and the same magazines as mentioned elsewhere here. When I got the machine, I had a thick booklet with a lot of simple little games (text-based, in the Atari BASIC dialect). I typed in a lot of those, and later from magazines. As most mentioned, the "cool" stuff from magazines mostly came in the form of hex code (i.e. machine code) which obviously did not teach anything.

That said, I cannot recall learning a lot from typing those BASIC listings either. First of all, programming was not like today. Very little resources were used by developers to make the code easy to understand, or didactic, in any way. There were few if not no comments; every precious byte was used as best as possible; variable names were mostly one character (and often even that was re-used); there were no recognizable "patterns" like today, and so on and forth. Sometimes they even went to the trouble to obfuscate the code even more, for reasons I cannot fathom.

Before the time of dial-up BBS'ses, dial-up mail networks, UseNet and eventually (privately accessible) Internet, I got my knowledge from plain old books - I was fortunate enough to live close to a state capital with a very big and relatively current library; they had shelves of books and magazines for exactly the machines I had before the internet came along. Also, those books were usually real gems... often reference manuals straight from the source; or from a very select handful of authors who lived and breathed that stuff. Very little junk - there was no "become a programer in 21 days" nonsense. ;)

Also, the technology was trivially simple back then. A young person could easily grok the complete hardware and software architecture of an 8-bit home computer in the course of a sweet summer holiday if they put their mind to it (much to the chagrin of the parents). BASIC was very accessible (I mean, it was literally the GUI of the computer, after switching it on), and the instruction set of the 6502 fits on a page or two.

Little rant: Being used to work with books (i.e., reference books where you had to learn to find and extract the required info) helps me today still - when I am about to learn a new programming language or other complex sysem, I find it very easy and efficient to pass all the well-meant "tutorials" and go straight to the reference docs. I find it fascinating how often I sit together with a junior developer who has not looked into official docs once in their life, taking all their info from tutorials as a shortcut, when it's often hit&miss whether the context of the problem at hand is even the same as the one in the tutorial/stackoverflow answer/etc. Many of them really light up when they are pointed to, say, the library docs of their programming language - and they are surprised that the info there is often much quicker to apply to the task at hand.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .