Sure, but the needle has moved. The thing that took you two weeks to write in 1987 isn't even considered anything useful by today's standards. The parsing needs to happen in real time, it needs to provide machine learning assisted auto complete, it needs a web UI and UI needs to show you an animated graphic of the scene you're describing, etc.
Knowledge was also extremely unevenly distributed.
I had a Commodore 64 in the early 90s and I wanted to understand more about machine code. But I had no documentation about the opcodes and didn't know how to get any, beyond a basic intro in an Usborne children's programming book (I think it was this one: https://archive.org/details/machine-code-for-beginners). I was able to write a loop and was amazed by the speed, but couldn't get much further.
If a book wasn't in my local library or bookshop, it essentially didn't exist to me. I had no means of search or discovery.
In the late 70s the Apple ][ came with a manual with a terse but just good enough description of the 6502 and its opcodes, especially when combined with the source code for the machine's ROM. At least it was good enough for 17 year old me, who had never seen a computer before, to write some useful programs in 6502 machine code. One of the first was something that replaced ("shimmed") the standard keyboard input function with code that fed text to the printer from a file on floppy disk whenever the computer was waiting for user input. Given the usual small buffer in the printer that meant the printer hardly ever stopped.
The Oric Atmos is still a wonderful machine! Still got yours in the attic somewhere?
Join the crew at DF [1] and Oric.org [2] to bring that thing back to life.
Some truly astonishing software [3] for the Oric has been written in the 21st century - including last years winner of the "10-line Basic Competition", which is pretty awesome if you're an Oric fan and haven't seen it yet [4]. Just imagine what it would have been like for Oric fans if rax and folks like Twlighte (RIP) had been active in the 80's, pushing these machines to their limits as they do now ..
I had a lot of the Usborne books. I knew of the existence of the machine code one from the backs of the ones I had, but no bookshop ever had a copy. I finally bought a copy in a second hand shop a few years ago (I haven't actually read it though!)
I had a Spectrum in the late 80s. I learned the basics of Z80 programming from An Introduction to Z80 Machine Code by R.A. and J.W. Penfold - published by Bernard Babani, well known for their electronics books. A family friend (more into electronics than programming) who had given me the Spectrum, also gave me some Babani BASIC books. I guess that's how I knew about the existence of the Z80 book, and got a copy of that.
I wrote a simple text editor for the Spectrum in BASIC, but all the checks as to whether you had pressed a key (combination) with a special meaning (arrow keys etc.) meant that it couldn't keep up with even fairly slow typing. (The code in question was a big sequence of lines of the form IF <this key was pressed> THEN <GOTO or GOSUB (can't remember which) to somewhere>. I'm wondering now whether you could make a faster dispatch mechanism in Spectrum BASIC instead of this naive solution.)
So I wrote an assembly routine just to deal with this bit. I didn't have an assembler. But, the wonderful Spectrum manual contained this table:
which I used to hand assemble my program. (I don't think I'll ever forget that ret is 201). When I gave away all my Spectrum stuff a few years ago, I kept the manuals.
Oh, man! I remember sitting by the fireplace one evening, as giant picture-perfect snowflakes floated down outside. My wife was sitting in an armchair nursing our newborn child, and I was hand-transcribing assembler into hexcode for one of my class assignments, using a printed lookup table. By candlelight.
It felt like a scene out of some retro-future sci-fi movie.
This is a nice chart (though arranged for disassembly/decoding rather than assembly) and shows how accessible 8-bit architectures really are. You could probably memorize the opcodes and program directly in machine code!
It's also interesting how the core (presumably 8080) instructions are one byte.
That Usborne book series was amazing - it seems amazing nowdays that there were books explaining machine code targeted at children, young me was so glad that they existed. I can remember writing machine code for my spectrum with it (and the spectrum owners' manual also had an appendix with what I remember was just a plain 0-255 list of bytes => instruction mnemonics!)
This. I remember forking out... $50?... to buy the Commodore 64 Reference Manual from a specialist bookstore (we had to drive there). I was so excited when I brought it home and could finally write programs in assembly (to put sprites on the border using raster interrupts!).
On the other hand we were much more creative, as there weren't anyone cargo culting what best practices were supposed to be.
System programming in BASIC doing PEEK and POKE across all memory map, writing machine code loaded from DATA statements, no one telling that the one letter language was the only way of doing such endevours.
Later on, the same kind of low level programming with Pascal and Basic compilers on 16 bit computers thanks to some books on the local library.
It was diverse, instead of current monoculture of c c++ c# rust nim zig js typescript python Perl or go , we could use both languages: Basic OR raw assembly!
Ehhhn, there's nothing new under the sun. There may not have been as many language religious wars among most people back then, but there were definitely machine religious wars.
I didn't have a computer in the 80s. I started learning programming in the mid-90s. There were huge religious wars over languages at the time, and it was basically C versus anyone who dared try anything that wasn't C. I remember being told I wasn't a "real" programmer because I would often use VB, Java, and--heaven forbid--JavaScript for things that didn't require the All The Speed. I still did C, but I wasn't singularly dedicated to it, thus I was apparently just a "scripter".
From my perspective, I didn't care if I was a "programmer" or a "scripter". I was "productive".
In terms of dogma in my own time, things have gotten a lot better. You do still occasionally find people who will make wild claims like "HTML isn't a real programming language", insisting that there is some definition of "real programming languages", despite PLT specialists telling them there isn't. But they are very few and far between these days, and they tend to be hold-overs from the old times.
>insisting that there is some definition of "real programming languages"
An interesting claim when programming is full of people who literally invent the most bizarre language they can for the sole purpose of challenging the definition of a programming language.
Yep, this was the limiting factor in doing anything.
Not being able to get information, and not having anyone to communicate to about problems (as in stackexchange now.. where you're able to ask a specific problem, and someone from the other side of the globe can answer in a matter of minutes).
Also, hadware was really limiting... which i kinda wish was still a fact for web developers, but we're too far for that, sadly.
I was lucky to get a slightly improved Apple II+ clone (in Brazil we couldn't import computers, so local manufacturers didn't reinvent too many wheels) and to grow up in São Paulo, a very large city with a thriving industry and tech scene in the 70's and 80's.
The most valuable resource was the community. We'd put free ads in classified papers (a bit like Craigslist, but on paper) for trading pirated software (legally buying software was pretty impossible too - you could pay, but you'd be paying a pirate, so we decided to short-circuit those). This formed communities that ended up meeting on various early BBSs. I got tons of photocopied documentation (yep - buying books was also quite impossible because the military dictatorship controlled payments and made paying a foreign entity painful) that really helped me getting up to speed with both BASIC and the tooling (these names may be unfamiliar to most people, but I edited BASIC programs with Beagle Bros' GPLE and another tool I can't remember the name, that did line renumbering and some in-memory source-code optimizations (compressing multiple lines into a single one when syntax allows).
My work desk had two computers - a tricked out Apple II+ clone where I edited the code (which had an 80-column Videx - clone, of course - connected to a second monitor), and an Apple //e clone where I tested the program after I saved the original, ran all the optimizers (which reduced memory footprint significantly), and created the program disk (all floppies back then) to be run on the //e clone. Occasionally I had a third one, one identical to the classroom computers (because my //e was a "//e enhanced" clone and the classroom ones weren't)
> Knowledge was also extremely unevenly distributed.
Absolutely. Your comments about how hard it was to find even basic info was completely different to my experience in 1985 with a BBC Micro Model B, the manual [1], was a very comprehensive introduction to programming, starting with BASIC and going into 6502 assembly: it was and is the reason I'm a software engineer (I was 10 years old at the time).
The reason for the difference was probably due to the BBC Computer Literacy Project [2], which aimed to make the UK the most computer literate country on Earth at the time.
Even with this awesome introduction, learning programming required a brute-force-of-will approach. Much trial and error, and not much help from the machine (and no tools).
One thing I still have slight PTSD over is that if you wrote anything in assembly and it crashed, then you'd have to reset the computer, losing the typed in program. So if you didn't save, you lost your work. But saving meant recording to a cassette tape, hardly CTRL+S!
I blew up my C64 poking at the chips on the board inside, a spark one day and it died. It booted up fine and showed the READY prompt but the cursor block never appeared and it froze before it could accept keyboard input.
I then got a second-hand Amstrad CPC464, but this time I got a manual (I didn't get a manual with the C64, it was a gift from a family friend) and a non-functional tape drive, which, unlike the C64, was integrated. It also came with a monochrome monitor!
Every program I wrote I had to erase before I could write a new one. I wrote an alarm-clock program which made an air-raid siren noise that woke me up every morning, and I had to rewrite it again every night.
The BBC project was hugely worthwhile, IMO. It had side-effects in Ireland, I had a couple of friends with BBC computers, and of course there were all those Usborne books, though Vic-20, TRS-80 and friends (before my time) probably helped too.
Mine had an output port that would allow you to save programs to an external cassette recorder (cassette recorder not included). I had a pile of unlabelled cassette tapes with programs I was sure I was going to want to reuse some day.
>The reason for the difference was probably due to the BBC Computer Literacy Project [2], which aimed to make the UK the most computer literate country on Earth at the time.
How the mighty have fallen, now we have MPs calling to ban encryption in complete seriousness.
Quite. The Computer Literacy Project was a real example of long-term thinking by politicians. There was no way it was going to pay-off in a big way before the end of the parliament.
It’s still paying off today. I employ ~100 people because of it. And there are many others like me. Pretty awesome vision (and from a political party I normally despise!)
100% this. I tried to get started as a kid in the early 90's, but there were no resources available for me. Even trying to reverse engineer Gorillas was too much for me at the time, and I didn't have any documentation to help. I got to loops and reading strings, but that was as far as I could go on my own. Rural Alberta sadly also didn't have any libraries or bookshops I could draw from. Back then it really required being in the right place to have an opportunity to learn. Now you just need an internet connection.
That was one of the great things about Amazon back in the mid-late 90s, they had a huge selection of computer books at just the right time in computing. I spent hundreds of dollars on those things and still have a bookshelf full of mid-late 90s programming books.
I needed to write screen addressing routines in assembler for the Apple II in 1983. I went to my local bookshop in Sheffield and bought "Apple II Assembly Language by Marvin L. De Jong". This was for my undergrad project and I pretty much have a degree because of that awesome book.
> I had a Commodore 64 in the early 90s and I wanted to understand more about machine code.
The problem was that you were too late. Machines like the C64, the TRS-80 Model I, the CoCo, etc. all had specialist magazines dedicated to them ... back in the early to mid 80s. These were really good for distributing knowledge.
Unfortunately, the ascendancy of the IBM PC by the early 1990s wiped this stuff out. And most libraries got rid of those periodicals if they had even carried them at that point.
That feeling when your first assembly programme ran was magical, it was so much faster than BASIC it felt unreal. One of the first assembly programmes I ever wrote just filled the first 256 characters of the screen with the letter 'A'. I expected it to print one character at a time till it was done, like the BASIC equivalent would but maybe a bit faster. When I ran my little bit of asm code the top of the screen instantly became 'A's before my finger had even left the return key, my brain couldn't quite wrap around what happened and I thought something went wrong, after a second I realised, no, assembly is just that fast compared to BASIC I was kinda stunned.
I find it pretty hilarious that he's picking Perl as a prototypical example of "today's" technology and the article is also blatantly advertising Perl books.
Yes, late December, 1987, after the events I describe. It was released on Usenet, as I recall. I didn't even know what Usenet was back then. For me, it was pretty exciting to dial up a BBS, crash their software, and read through the code that the BBS was written in (and later contact the sysop to tell them how to replicate it).
I doubt I could have even compiled the software onto a COCO 2 computer.
Sure, it's just funny that your example of "thirty years later" is code that someone could in principle have written in the same year (well, almost - I imagine Perl 1 might require some changes from the Perl 5 version).
If I had to show how far we've got since then, and how different the experience could be for a novice programmer, I think I would display a .GIF where I press F12 in the browser, and write two lines of Javascript in the console, something like:
var words = await fetch("some online JSON dictionary").json();
var lexed = "insert sentence".split(/punctuation regex/).map(w => words.indexOf(w));
I don't write JS habitually and I'm on my phone so it's probably got some mistakes, but you get the idea!
Well, duh :) Perl's still more popular than people think. I saw on the Board of Directors for the Perl foundation for years, regularly speak at conferences for it, have released tons of open-source software for it, and currently am working on the Corinna project to improve the core OOP for the language: https://github.com/Ovid/Cor
Given that this site, like so many others, is to help me get work, I think it's natural I'd use Perl in my examples.
Perl 6 was announced a long time ago, but it took many years of development and planning and I (like others) used to joke that Duke Nukem Forever was going to be written in Perl 6. And then we got egg on our face when Duke Nukem Forever was released first. (And it turned out to be a turkey).
However, many clients I spoke to at that time were telling me they wouldn't upgrade their Perl code because they were waiting for the new version ... which was seemingly never going to arrive. Worse, it became clear that Perl 6 was a new language, with common roots, but it wasn't like the Python 2/3 split: a wholesale rewrite of code would be necessary, or try to use a Perl 5 compatibility mode that may or may not have proven useful.
So companies weren't upgrading, Perl developers were fighting, people were leaving the community and the Osborne Effect (https://en.wikipedia.org/wiki/Osborne_effect) could be renamed the Perl 6 Effect (I'm aware that the Osborne Effect is more complicated than it's often portrayed).
Worse, Perl 5 couldn't upgrade to Perl 6 because that version number was taken. Perl looked, to the outside world, like it wasn't upgrading any more. I even had one guy screaming at me at a Linux Conference about how Perl is shit, hadn't updated in 20 years, and ticked off a bunch of "facts" about Perl, most of which were objectively incorrect at the time, but Perl could no longer get its message out.
There was discussion about leap-frogging the version number and going straight for Perl 7, but that caused even more fights, more people dropping out of the community, and we fractured. We tried saying "the name of the language is Perl 5 and we're upgrading every year—we're currently on version 34—but that didn't satisfy anyone, either.
Eventually, Perl 6 was renamed to Raku (http://blogs.perl.org/users/ovid/2019/10/larry-has-approved-...) and that freed us to upgrade our version number, but to what? Sawyer X, the former Perl Pumpking (development manager) proposed the Perl 7 project, but for many reasons, that also caused much anger.
So today, we have Perl. There are ideas of moving to Perl 7, but much work needs to be done. My Corinna OOP project is likely part of that work and the Perl Steering Committee has met with me to say they'd like Corinna in core, but slowly, step-by-step, to ensure that we don't push too much into the core and make mistakes we can't easily back out of.
I have more ideas about what is needed to get to Perl 7, but they'll largely wait until after Corinna is in core and fleshed out. It's a lot of work and the team working on Corinna (making great suggestions and also helping me not make boneheaded errors), have put in a lot of effort to create something we can turn into a proper RFC. Paul Evan's Object::Pad (https://metacpan.org/pod/Object::Pad) is a testbed for many of these ideas.
So, we're getting there, but slowly. However, it appears to be moving along more smoothly than other efforts in the past. The fact that the goal is more modest helps.
> Well, duh :) Perl's still more popular than people think.
There is no way to define the word "popular" that makes this a true statement with regard to Perl 5 or any future development thereof shooting for backwards compatibility. -- I hate to be the negative nancy in this regard, but I seriously think that this is a cold and hard truth that is causing a lot of suffering because of people who fail to acknowledge it. (Disclosure: I work in a shop that forces me to do Perl, and I hate it with a passion).
One definition of "popular" would be: You ask programmers "Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?" [1]. 48.2% will then answer Python compared to 6.75% who will answer Ruby and 2.46% who will answer Perl.
Another definition of "popular" would be: Drilling down into those 2.46%, you ask them whether they love doing Perl or dread having to do Perl. 64% will answer they dread it [2]. This definitely agrees with my own experience working in a Perl-shop. Most people say they'd rather be doing something else. The company just feels that it doesn't make economic sense, so we're stuck with it.
For the other ones, I seriously suspect a case of Stockholm syndrome or something of the sort. -- Those would be the ones corresponding to the 0.86% (0.0246 x 0.36 = 0.00855) who say they do Perl and they actually like it.
The Perl code that's currently out there is literally sitting on top of an ecosystem that is rotting away beneath it [3]. For legacy code, the argument can sometimes be made that the situation is not bad enough yet to warrant moving away from Perl. But starting a new greenfield project in Perl 5 is, in my opinion, nothing short of professional malpractice.
So Perl is pretty much relegated to the hobbyist sphere, with Perl 5 maybe being of interest to retrocomputing aficionados. In that sense 80s-BASIC is very much the proper comparison class. Not modern-day Python or Ruby.
With Perl 6 / Raku not offering a viable migration path, one has to look at it the same way one would look at any other modern-day programming language upstart, with all the problems that entails (like lack of ecosystem, etc.)
Introspecting my own psychological experience now, I would go as far as to say that the open source developer community keeping Perl alive is perhaps the only group of people who truly meet the definition of giving the world something for free out of the goodness of their hearts (even in a way that ends up putting money in my own pockets), but who I actively dislike because of that. I feel like: If only Perl 5 would die a sudden death instead of this slow creeping demise, then, maybe, for me too this torture could finally come to an end.
FWIW, the Raku Programming Language nowadays *DOES* offer a valid migration path in the form of the Inline::Perl5 (https://raku.land/cpan:NINE/Inline::Perl5) module. This basically allows you to use all of CPAN that doesn't do source filters.
This allows you to gradually move your code into Raku, replacing Perl 5 modules by Raku ones as needed.
As we're about to reach the 2000 modules in the Raku ecosystem mark, it should be noted that many modules from CPAN are not needed, as they're builtins in the Raku Programming Language. And many CPAN modules have outlived their usefulness in any programming language.
Thanks for the pointer. I will look into this with great interest and get a discussion going within my company about whether this implies that we would want to start permitting Raku into our codebase. But I very much doubt that this permission will be granted in the end.
Arguably, there is pre-Internet and post-Internet programming.
Perl is a quintessential example for the Internet era of programming. It was developed via USENET and email and FTP, with a global base of open source coders to drawn on. Got a question? Ask the mailing list. CPAN, Perl's automatic module system, dates to the early 90s. This is very different from programming alone on a micro, or on a mini or mainframe in an office environment. Much more like how we still do it today.
Just because a kid was programming with bundles interpreted BASIC and POKEing machine code into RAM in 1987 doesn't mean that professionals were.
Unlike the earlier 6502 and z80 machines, the COCO's 6809 CPU was a perfectly fine compilation target for C or Pascal. I never had a COCO so I don't know what was actually available for it, but some friends and I wrote a BCPL back end for 6809 in 1984, for a wire-wrap 2 MHz computer we'd designed ourselves.
People using big computers were of course using compiled languages earlier. I was using a native Pascal compiler for the PDP-11 in 1981. But the end of BASIC on microcomputers started in 1984 with the release of the amazing Turbo Pascal 1.0 for CP/M and MS-DOS for $49.95. There had been compilers for the PC before this but they were huge, slow, and cost $500+. The similar in concept Lightspeed Pascal and C for the Mac arrived in 1986.
By 1987 I was programming in optimised Pascal compiled to m68k machine code on a machine with a 16 MHz full 32 bit CPU (with FPU) and 4 MB RAM. I had a Unixy command line (MPW), proper debuggers, could link with assembly language etc etc.
I'd already been reading about C++ and in late 1988 bought the Zortech C++ compiler to experiment with (in a DOS emulator). Apple had their own C++ for MPW a few months later.
Even Perl, which he uses as the example of modern programming, first appeared in 1988.
Really, the programming language landscape has changed little since 1987.
The main difference is just the capacity and speed of computers, and the rise of the open source Linux OS and much more recently the open source RISC-V instruction set (we haven't seen the full impact yet).
> Really, the programming language landscape has changed little since 1987.
This is probably true as written, the languages that we know today are similar to what existed back then in the way you tell the computer what to do. Things like functional already existed. Not sure about garbage collection, when did that become a thing?
But what's really changed is:
- You can download a huge amount of libraries from someone else really easily.
- You can ask questions and someone else has already answered, or you will find a language expert and they'll help you. This is almost entirely StackOverflow, I suppose also a number of previous sites that have gotten outcompeted.
- Tools for coding are miles better. Intellisense, extensible IDEs, Version control, CI/CD.
I remember as a kid in the 90s trying to learn how to code, and as soon as there was a problem, there was no help. I knew zero people who definitely knew the answer and maybe one or two who might know the answer. So after a few blockages, I just gave up.
Nowadays I can jump into a new language just with the internet available. I'm pretty sure I could write a simple program in just about any widely known language that's new to me, just with a bit of time. I've done it a few times now, and each time I've seen problems like what I hit as a kid, and overcome them with a bit of searching.
Garbage collection is from around 1960, invented for the first Lisp. 1987 is actually around the high-water mark of the entire Lisp world; its the year the Lisp machine market crashed as the AI winter set in.
> - Tools for coding are miles better. Intellisense, extensible IDEs, Version control, CI/CD.
True, but since projects/libraries were smaller themselves, I think the overall the effort here remained roughly the same. I remember I was directly "diving in" in the header files of the major libraries I was using at the time without too much effort. Doing the same in something like Qt5 today would make my head spin.
I agree about the rest. My local library at the time was completely useless, so I went by local bookshops and bought whatever titles they had on the shelves, which (looking back) was usually rather poorly written garbage. The true change for me was the discovery of early amazon, where I could buy the most obscure untranslated technical titles I wanted and get them shipped overseas at reasonable cost. Local bookshops generally didn't give a crap about my requests.
In 1999, I took home the book that came with the ColdFusion install disks, and learned pretty much the entire language in a week. Now there are Ruby Gem or Node modules with as much or more complexity.
I wonder if another major change was the rise of the web browser. Making websites do cool things was what really got me into it, after a couple minor forays into things like C++ when I was in grade/high school. Obviously programming for a virtual machine and the concepts in Javascript are nothing new, but having the execution environment and useful programming tools like Firebug a click away for anyone by default seems like it would've been a paradigm shift in piquing the curiosity of people who otherwise would've never thought twice about say what the jvm installed on their machine actually did.
This was before my time though, and I could be confusing correlation (explosion in pc/web usage) with causation.
(Also I'm kinda jealous of people who were programmers in the 80s, it sounds so cool lol.)
It was cool. First, most of us were kids, so we looked at computers as tools for expressing our youth, not just programming. Programmers were also not many and hacker culture was everywhere. Also, many of the famous programs/games by that time were done by one person, so as a young kid, you thought : "I can do it too". Then computers were new and their impact on our imagination was tremendous (now everybody has a computer and nobody cares). There was not much to help you to start, so (I don't want to sound elitist, it's not the point), ending up programming was acting like becoming a wiz kid (there were many stories of people who were coding assembly with opcodes using the computer on display at some shop 'cos they couldn't afford it). Then you had Wargames and Tron where the wiz kids were ruling the world. Moreover, EULA were not a thing, you were free to do what you wanted to.
So basically, for the teenagers, it was dreams, dreams, dreams. Not because of the technology, but because technology was so primitive.
Now, it's different: you have mindblowing technology all of the place, so you can build things like hell. But that came with the price of sophistication: only a handful understand sorting, databases, neural nets technologies... The lego boxes have become fatter.
I learned to program before Google and Stack Overflow, but we had no idea those were gonna be created. It's way easier to learn how to program these days and the field is better for it. Fewer fiefdoms run by toxic little people, and more actual engineering of a quality product, consisting of code reviews. That doesn't mean things are perfect today, far from it, but there's far less YOLO.
On the one hand it was more difficult because of the lack of sources.
On the other hand you had one or two sources and you had to spend a great deal of your time to actually understand things and not copy paste with fingers crossed.
The frameworks were easier (there were none :)) and everyone was using the same thing.
The community you find on SO today is sometimes vastly more toxic that back then (especially in Go). I felt the toxicity only maybe 8 years ago, before that the interactions were normal.
So it probably depends on your language, need for speedy learning, etc.
I am an amateur so I love the fact that there are opiniated frameworks, IoTs you just use without the need to build them first, etc. It is just that the amount of information and possibilities can be overwhelming
Having written my first program (6800 Machine Code) in 1983, I can definitely say what a long, strange, trip it’s been.
I wrote test automation host software in BASIC (HP BASIC), but embedded stuff in 8085 ASM, in 1986-7.
Taught me a lot about debugging (I especially liked ICEs), but, for the most part, I miss those days like I miss a dysentery attack.
These days, I write mostly frontend stuff in Swift. I use symbolic debuggers, runtime instrumentation, GUI IDEs, and a whole stack of ridiculously powerful little handheld devices for testing. My low-end test device (a first gen iPhone SE) is a gazillion times more powerful than the million-dollar mainframe we used to program in my days, working for a company that provided email, before email was really a thing.
My main concern is needing to have a complex development environment before writing the first line of code. Even if it is a comment ;-) Docker, dependency incompatibilities, different versions, building process mammoths (Say hi Google Chrome), configuration files that give more headaches than complex algorithms, etc.
My first programming experience was setting up an AMP stack (Apache, MySQL, PHP). That was already a deep, deep rabbit hole for someone who was barely aware of things like configuration files. That was early 2000's iirc.
Yeah, I remember not too fondly trying to juggle python code to run with fastcgi under shared hosting in the late '00s. PHP was bit easier because it was more popular so there were more guides and it was more tested path overall. VMs were still a new thing, so testing stuff locally was generally a pain too.
I actually don't mind that. If you do this stuff every day, you learn to appreciate having proper tools. I had my first programming experience on a commodore 64 in 1987. There was nothing to choose for me. It was Basic or nothing. I probably had more choices but since I had no way of learning about those I really didn't.
I had that machine, a manual, and some printed material my uncle gave me, a tape drive and about six tapes with games on them. That was it. My local library was useless for learning more. I had few friends and none that even remotely understood anything about computers. I had no modem or any form of information other than what came with that computer. So setting up the development environment was: turn the thing on and start typing. Everything you needed to know fit in a very thin manual.
These days, there's a lot of stuff to deal with of course and a lot of choices to make. New developers get overwhelmed with choices and material to read that they have to cherry pick from. However, there are plenty of ways to get started and helpful people that will help you to get started both with active support, tutorials, documentation, etc.
Not having any of that is not better. I too feel nostalgic sometimes but the games were meh, especially after playing them too often and Basic wasn't that great either. I've seen high school kids get into machine learning and building games with unity. 2022 is an awesome time to start learning how to program. So much to learn. So much to explore. So much to do. The only limitation is your own creativity.
Good point, there helps fingerpointing. Bad programmers are not hearing enough that they are bad. Slow, bloated software is just accepted somehow. Even in the dev community. That needs to stop. Start naming the people behind all those electron crap.
I look forward to you posting the link to your tutorial on HN. I was fiddling with assembler in 1987, but I am probably fifteen years older than the author. I suspect that I am still teachable; I am confident the author is.
Hmmm, I started programming in 1982 on a TRS80 Color Computer, and am still at it building web and desktop apps. I agree if you were out of the scene for a while it'd be a hard task to get to grips with things, but otherwise some of us can still understand and maybe even use some of the newfangled stuff.
Huh, I was writing BASIC code (and even some 6502 Assembler) back in 1980. Somehow I manage to get my feeble brain to comprehend the modern web stack. I guess I must be exceptional.
Full stack dev checking in (Django on the backend, Angular on the frontend). Also have no difficulty with modern development (web or otherwise) despite having cut my teeth on 8-bit BASIC. ;)
We want to get hyper technical, I'd argue with Flutter web and Firebase I could even teach a non-programmer how to build a basic web app with about 3 months .
A lot of times these more experienced programmers are able to plan things better, versus folks from our generation who just jump in and start writing JavaScript until it works.
It's funny you say this because just last night I was reading a 1985 copy of UNIX Review [1] and there was an article specifically having a go at C developers who didn't use library functions and rolled their own(!) Not entirely related to the modern practice of using a "library" but close enough to make me chuckle.
I think there's a difference between ignoring stdlib stuff and not using some 3rd-party library of questionable provenance to parse strings in the format of YYYYMMDD into date objects.
I learned to program in the 80's: BASIC on a Commodore PET and Apple, and C on an Amiga. In 1987 I took my first programming class in high school, and it was in Fortran which they told me was what "professionals used".
Coding was in Wordstar, and I remember being outraged that code had to start on column 7. Isn't this simple bookkeeping what computers were for?
I ended up going to college as a math major and avoiding the engineering degree because they coded in Fortran.
BASIC programming in those spartan REPL environments sucked, but it was a great entry to programming for kids.
There were also "proper" IDE-like macro assembler development tools for 8-bit home computers in ROM modules with an integrated text editor, assembler, disassembler, debugger etc... which made programming quite comfortable and not all that different from today, especially with the luxury of a floppy disc drive (which I didn't have).
> I remember that very distinctly because it was at that moment that I knew my dreams of writing a grand text adventure were dead if I couldn’t get that working...
I remember I started writing an adventure around that time (maybe 1985, I was 12 back then) game using 3D wireframe (only lines, no filled surface). The adventure started in an hotel, I drew the stairs / doors etc. I found out I could use "graph paper" / coordinate paper: I'd take real pictures, use a glass table, put lighting underneath the table, then lay the graph paper on top of the real picture and draw my lines to reproduce the picture. Then I'd manually input the coordinates into my Atari 600 XL.
It was looking gorgeous but... After three screens, maybe not even that, I ran out of memory. That's how I discovered computers had a limited amount of memory to work with (it was 16 KB of RAM for the Atari 600 XL IIRC).
A bit disappointed I decided to do "single screen" graphics and had lots of fun doing that. I then remember using graph paper to reproduce a totally badass Porsche 1959: it was looking gorgeous for its time (probably 1986, when that Porsche came out, for I remember the magazine with an article about it, where I took the picture from).
I taught myself to code around that time, pre-internet, pre-Internet#, and pre-Compuserv. BBS's weren't very searchable and their chats were primitive. Only by chance did I discover the Computer Literacy Bookshop - San Jose location, which was a mecca of computer books. [0] It was one of only a few times I ever used VTA's Light Rail. [1] I spent most of my high-school employment income on computer books.
If you had a 1,000 line BASIC program and a syntax error on line 793, you often wouldn’t find out unless that line executed.
BBC Basic would check each line for syntax errors as you typed it in, so you didn't need to wait for that line to execute in the program. But ... all it would tell you if it found a syntax error was: "Syntax Error"
edit: And why didn't it give a more helpful message? Because the BBC Basic interpreter was squeezed into a 16kb ROM and so everything was pared down. It was written by Sophie Wilson, who a bit later co-designed the first ARM chip.
edit: Sometimes if it could make no sense of the line at all, it would also just say "Mistake at line 40" and looking back at that now, thats quite bold and to the point. Todays computers rarely tell their users that they have made a mistake in such a blunt way.
> BBC Basic would check each line for syntax errors as you typed it in
From memory, I think that's because BBC basic tokenised each line as they were entered. This also made it deceptively efficient with memory. BBC Basic was really quite a neat thing back then (especially the built-in 6502 assembler).
It would surprise me if any interpreted basic would store keywords as strings in memory. Replacing them by single bytes is more efficient on memory and makes interpreting the program simpler and faster (if you see a P, you won’t know yet whether that’s part of PRINT, PEEK, POKE, or of an assignment to P or P$). Memory and cycles where so expensive that you couldn’t afford not to make such optimizations.
I think this was a feature common to all the Microsoft BASICs of the era. I don't remember if the TRS-80 BASIC did it or not since most of the screen time I got on one of those was standing up at the display computer at the Radio Shack about a mile from my house, while I had a lot of time with Apple Computers.
Apple's original Integer BASIC (written by Woz, natch) did not tokenize its input. I don't recall if it did any syntax checking at input because it was hard to get a hold of in the post AppleSoft BASIC era (I did eventually get a hold of a pirated copy on floppy disk that could be loaded into the himem region on a 64K Apple ][+ or //e but that was useful mainly for Woz's MiniASM that was in the part of ROM that was left over when he had Integer BASIC loaded).
Sinclair ZX BASIC actually checked for syntax errors as you typed. Because they abused the character table to "pre-tokenize" all the BASIC statements, you couldn't actually misspell anything either. (ZX80 and ZX81 at least.)
It's a bold statement to say things are easy now. I am able to write games in 6502ASM. It's tricky, but I often find it easier than dealing with the vast network of software I need to do web development these days. Having to deal with a large amount of different devices, browsers, screen sizes and having to do automated testing etc. is a big challenge for today's developers I think. Sometimes it seems like my head is full and I will not be able to keep this up forever.
You kids have it so bad these days, I feel sorry for you. (no sarcasm intended... I shudder at thinking of what it's going to be like if I manage to get back into the world of programming)
Things change on a moments notice and break things. Python 2-->3 for example. Everything was broken because of a Unicode fetish. You're always getting blamed for insecurity, when actually its your bad operating systems. The lack of a simple model for getting things on the screen when there's the entire internet, and vendors who care about profit in multiple layers between you and the user. It must really suck to write full stack applications with iOS or Android clients.
Onward with the story of how it used to be:
I had Turbo Pascal by 1987. If you wanted to learn how to use it, the manual was usually sufficient to get you started. If you were really stuck, you could head over to Krochs and Brentanos, your library, or ask questions at the next user group meeting. Documentation was stand alone, well written, and well edited.
Compiles were always fast, the IDE had a pretty good debugger with watches, and stepping, so if you got stuck, you could see exactly what was going on.
We didn't have GIT, that's the worst of it... I always Zipped my source into numbered archives, and pushed them to floppy, to guard against hard drive loss.
Computers got fast, so much faster, but the basics haven't changed. When Windows came along, so did Delphi, with a really good GUI toolkit that was object oriented, and perfectly impedance matched to Pascal. It was glorious.
Then Borland got stupid, and started trying to beat Microsoft, instead of playing to their base. They made a C++, but it wasn't anywhere as good. The GUI tools made a lot of boilerplate that you couldn't tweak without breaking things. Strings were no longer sane.
I stayed with Delphi until Version 7. I've used other languages since, but nothing is as productive today for me as Lazarus, its open source replacement.
GIT, big RAM, and Terabyte SSD are all amazing, they make it trivial to deploy a Windows program to a desktop. You can make programs that are less than 3 Megabytes with GUIs and help, etc. Just plop into a directory, and run it. Or use the installer generator.
The main differences are speed, RAM, and disk space. The bigger screens aren't as nice for me as they used to be, once you hit 50, things blur, and the small fonts just stop being useful.
I do miss the simplicity of MS-DOS, and especially the security of of floppy drives with write protects. A dual floppy drive machine was simple enough that there wasn't anywhere for malware to hide. You could run anything on your machine, and restore it to a known working state by rebooting with your system disk (write protected, of course).
I also miss well written, complete documentation with working examples for each feature.
I don't miss those sequentially numbered archive files for "version control".
So, it was simpler, and far more manageable, even if the machines and screens sucked.
On the other hand, people in the late 80s were running impressive Lisp machines, whose level of integration and interactivity makes current systems look like a (cruel) joke.
In 1986 I started a new job. My manager sat me down at a vt102 connected to a PDP-11, pointed to a shelf of orange 4-inch binders and said "That's the system documentation. Log in by typing "HELLO [7,1]". You're now the PDP expert. Good luck."
There was also always the scent of rosin-core in the air because you always needed cables for things. People smoked at their desks in the office, the only place in the office with AC was the server room (backups to tape became more frequent in the summer months for some reason), there was a social protocol to how you handled someone else's listings left on the line printer, and the photocopier was perennially jammed.
Building an executable was usually an overnight job run in the batch queue.
> My manager sat me down at a vt102 connected to a PDP-11, pointed to a shelf of orange 4-inch binders and said "That's the system documentation. Log in by typing "HELLO [7,1]". You're now the PDP expert. Good luck."
ngl, this sounds a hell of a lot more fun than sitting in back to back meetings and dealing with dumb blockers from business related issues.
OTOH, it was decades before I had a 26" monitor again ;-)
Most of the time I used a 12" white phosphor screen (soft-switched between board video and a Videx card) and a 16" color TV attached to motherboard color/graphics of the Apple II+ clone.
You couldn't do that on the Apple //e with native 80-column video, sadly.
The Videx was cool. I had one in my Plus for a while, and remember missing that when I scored my favorite machine, which was the Platinum. I have one today, and it's still my favorite. :D
What end up doing was just chain the video together. Run both screens.
The other 8 bit machines with a similar capability ended up being the Commodore 128. It's a real two display machine along with the original PC 5150? One could install both monochrome and a color display adapter and get use out of both displays independently.
What I would LOVE today is a modern clone of the UltraTerm. Extra points if it has an input for the motherboard video that can be overlaid or obscured by the UltraTerm, and outputs via VGA and HDMI.
I never saw an MDA/CGA PC, but I saw a couple with Hercules and CGA and a few with an [CG|MD]A and a high end something paired with a gigantic screen fed with 4 BNC connections. Normally the card with the BNC outputs would have more memory and a faster CPU than the PC.
You got me to go looking at Videx stuff this morning.
I keep an Apple //e on my workbench, just like it was so many years ago. I use it for some light gaming, and the current games are whatever INFOCOM text adventure I am poking at and Nox Archaist. I bought that one new, and it was developed as a labor of love. Fantastic! ULTIMA style game as if it were seriously developed today, and I suppose it was, but I digress.
I also use it for writing and calculations and quickie tasks.
So, I just learned the Videx cards work in the //e machines just fine. I could have kept mine back then, but I let it go with the Apple 2 Plus I sold off a while back.
About 10 years ago, I decided to get a Platinum because the retro scene was heating up and I just miss having a good 8 bit workstation around for the occassional fun project.
Given the Videx cards work in all Apple 2 8 bit machines with slots, a clone makes sense! I would use it myself, ideally with CP/M and or Appleworks for writing.
But, it would also be cool to have it to do dual screen development too. So yeah, could be a fun project. Making an apple card and doing something with it is on my retro project list. Who knows? Next time I free up, I may look at this. I have been looking for a video related project for a while. Neat idea!
Just for fun, I am sharing my current setup.
FastChip 65C802 / 65C816 accelerator card. This one runs any clock from about 0.3Mhz up through a little over 16Mhz! Absolutely great card. Works reliably and comes with a little control and cable for you to adjust in real time, while programs are running! It does the job glitch free.
CFFA 3000 Storage emulation. This one makes modern storage available for use with the Apple.
Super Serial card, stock, unmodified.
Got a CP/M card in the mail due to arrive sometime this month.
These Apple machines are fun to just tinker with, and slowly build up to an interesting computer.
Hardware demand is actually respectable enough to support projects like this. I wonder how many others would be interested in a similar card?
Indeed, and that experience was one of my first exposures to display factors leading to eye strain.
I started on an Apple ][ connected to one of those nice green screen monitors. Never felt eyestrain. Everything was sharp. But green.
Got a machine at home, and it was an Atari. On a color set, the white on blue worked pretty well. Moderate eye strain. Moved that computer to a smaller blak and white TV, and it was all much better. White on grey mostly.
Brought an Apple home, and the white on black was harsh on TV screens, a bit better on the black and white TV.
Turns out the color set was just not sharp and that was the primary driver of eyestrain. The right colors helped. Atari picked that white on blue because it made the most of a 70's era color TV. And it mattered.
After a time, I got hold of a newer smaller color set and tweaked it to the max, going for as monitor like as I could get it. Everything was improved and I ended up using that set for a number of years, until I got myself a green screen suitable for 8 bit computers.
My first PC was a CGA unit, and those were a little rough for text, and it was due to a poor CRT with a coarse phosphor layout.
Life got much better when I could get hold of basically any VGA screen. Was sharp enough, good color selection, good resolution. 640x480 seemed so damn roomy for longer than it should have, but it was the 8 bit experiences contributing to that.
My programming experiences were similar to many here. 8 bit basic, 6502 assembly, and the Apple was luxurious with a fast disk drive and included monitor / assembler. Was great to develop a piece of something in assembly, BSAVE it, then BLOAD it into the main BASIC program.
Compared to cassette it was awesome! I did use a cassette for about two years and ended up making custom tapes, just the right length for programs I used frequently. Could just LOAD, and do the thing, flip the tape over, and do that again. Also used the shorter ones for assembly bits, and a similar process.
Didn't even know what a linker was. I would map out the RAM, plan out what was going to happen, then develop in pieces, each thing written where it's going to live, saved off, and then combined with the main program, until at one point, it all gets loaded in for a master save and then run to check.
1983, high school, programming Ataris. Final projects.
My friend and I did Monty Python’s Flying Quadratic Equation Solver. The hardest part was getting the timing right so that the music on the cassette lined up with the action on the screen.
Other projects were similar. Except.
Two of our friends wrote a scrollable periodic table, navigated via joystick. Press the button, get info on the element.
There most of were messing about in BASIC and these two went full assembler. It was a great result.
This reminds me of my first foray into useful programming, which was on a TI-83 in high school circa 2000 - I wrote all the code on the calculator! Didn't do anything crazy, learned from modifying games and wrote some programs to do some of my math homework for me. I do have a funny story:
I wrote a program to calculate between orders of magnitude and gave it to a few classmates. Before the test, the teacher noticed people I think transferring programs and asked what was going on, and one dude said something like "We've got a program Andy made to do the test for us!" The teacher responded, "Well then you better know how to do the work so you can make sure Andy knew what he was doing!"
That program worked, but since becoming a dev a decade ago there's definitely been instances where that would've been good advice lol.
I'm sitting at my desk using emacs in a terminal, running tests using "^X^E" via 'make', and seeing the results beside my code -- literally exactly like I did in 1987. It was "Gosling Emacs" then, and "cc" on a shared VAX-11/780 instead of Rust, Python, Nix, on a 16-core Xeon, etc.
Still the most productive programming environment that I know of.
In 1987 it was possible to have a printout of the sum total of all of the software on your machine on your desk and it would be less than 1" of paper (remember green lined fanfold?).
It was possible to actually know all the software that you had at your disposal at the byte level.
If you were so inclined you could change any part of it.
You could hook up hardware and access it immediately without any intermediaries, drivers, security or other barriers.
If it didn't work, it was likely your fault, which meant you could fix it.
Bugs in production software were fairly rare because people would test their stuff properly and spend the time required to do so because fixing bugs in production was either hard (or impossible), expensive, or both.
If you wanted speed on a regularly available machine you were programming in assembler.
You probably had access to only two programming languages, a high level one and assembly. If you were lucky you could call the one from the other.
There was no internet, you needed to either find a more knowledgeable buddy or you had to go to the library, read magazines or book.
> it would be less than 1" of paper (remember green lined fanfold?)
I must have been writing very verbose code then. The frame-based reasoner I was coding in C (long story) was at least an inch thick itself (it's in my loft or I'd measure it).
> It was possible to actually know all the software that you had at your disposal at the byte level
I don't think this was true of the dev tools I was using on the Vaxen I had access to.
> There was no internet, you needed to either find a more knowledgeable buddy or you had to go to the library, read magazines or book.
Well, pedantically, there was an internet but you are right about the need to use dead-tree reference material - and the man pages.
What was missing compared with today was software libraries and frameworks. My development environment was vi and cc. If I needed a hash table or a queue, it was a case of reading an algorithms book. The journal of the British Computing Society was still happily publishing papers presenting new sorting algorithms.
[Edit] - the other big thing missing was deployment tooling, VMs, containers, etc. Admittedly I was coding in academia, but at no point was I introduced to version control tooling.
> it would be less than 1" of paper (remember green lined fanfold?)
I had a book, an extremely useful one, "What's Where in the Apple II" which contained a full commented ROM disassembly with all known entry points, what their inputs were and where they stored their output. It was about 2 inches thick when printed. My copy (of course it was photocopied - it was almost impossible to get imported books in Brazil back then) had an extra inch from all the post-it notes, markers, paper notes and so on I added to it.
If you had a VAX then you were in a very small extremely lucky segment. For most people 8 bits was all they had, unless they were involved professionally.
Yes, I was very impressed by the Vax and aware of how lucky I was. This was at Leeds University, and I got to use it as a post-grad. I think most undergrads were limited to timesharing on an Amdahl 470 and / or DEC-10. I can't remember now whether the Vax was a 750 or 780 - I suspect the former. The Vax had perhaps five users so it was fine for our needs.
If the Vax wasn't impressive enough, I recall that sometime in 87/88 I was developing a quadtree visualiser on a Sun workstation - perhaps a Sun-2? This was a really mind-blowing graphical environment after being stuck with curses [0] on the Vax.
But still reliant on the man pages, coming back to the original topic. I hadn't yet discovered usenet and the comp.sci FAQs.
> In 1987 it was possible to have a printout of the sum total of all of the software on your machine on your desk and it would be less than 1" of paper (remember green lined fanfold?).
The Apple II+ (running DOS 3.3) was the last computer I completely understood from the board-level and up.
Bugs in production software existed in all generations. In the mid 80s I worked on DEC Vax VMS systems. Our code was mostly written in FORTRAN and Assembly Language. Our group dealt with the failures of the dev tools and bugs in the OS.
Once we eliminated the fault was in our code (non trivial effort) we brought the proof of the problem to the vendor who responded in a not unreasonable time.( We did buy millions of dollars of equipment from them)
Bugs existed in the early 90's DOS and Windows environments and we worked around them with no vendor support. Bugs existed in the mid 90's web dev and we worked around them.
Yes, they existed. Yes, they were fairly rare. The two are not mutually exclusive. For instance, for the BBC Micro BASIC interpreter there was exactly one bug, which was found only by inspecting the assembler and someone realizing that this was an erroneous implementation.
The simple fact that fixing bugs was hard and costly put such a premium on them that bugs were rare. Move fast and break stuff was an attitude that simply would not have worked back then. You tried your level best to get it right.
144 comments
[ 3.8 ms ] story [ 199 ms ] threadSure, but the needle has moved. The thing that took you two weeks to write in 1987 isn't even considered anything useful by today's standards. The parsing needs to happen in real time, it needs to provide machine learning assisted auto complete, it needs a web UI and UI needs to show you an animated graphic of the scene you're describing, etc.
I had a Commodore 64 in the early 90s and I wanted to understand more about machine code. But I had no documentation about the opcodes and didn't know how to get any, beyond a basic intro in an Usborne children's programming book (I think it was this one: https://archive.org/details/machine-code-for-beginners). I was able to write a loop and was amazed by the speed, but couldn't get much further.
If a book wasn't in my local library or bookshop, it essentially didn't exist to me. I had no means of search or discovery.
Join the crew at DF [1] and Oric.org [2] to bring that thing back to life.
Some truly astonishing software [3] for the Oric has been written in the 21st century - including last years winner of the "10-line Basic Competition", which is pretty awesome if you're an Oric fan and haven't seen it yet [4]. Just imagine what it would have been like for Oric fans if rax and folks like Twlighte (RIP) had been active in the 80's, pushing these machines to their limits as they do now ..
[1] - http://forum.defence-force.org/ [2] - http://oric.org/ [3] - https://defence-force.org/index.php?page=games [4] - https://bunsen.itch.io/moon-landing-by-rax
I was going to visit it before the apocalypse started. Can't wait for it to end.
I had a Spectrum in the late 80s. I learned the basics of Z80 programming from An Introduction to Z80 Machine Code by R.A. and J.W. Penfold - published by Bernard Babani, well known for their electronics books. A family friend (more into electronics than programming) who had given me the Spectrum, also gave me some Babani BASIC books. I guess that's how I knew about the existence of the Z80 book, and got a copy of that.
I wrote a simple text editor for the Spectrum in BASIC, but all the checks as to whether you had pressed a key (combination) with a special meaning (arrow keys etc.) meant that it couldn't keep up with even fairly slow typing. (The code in question was a big sequence of lines of the form IF <this key was pressed> THEN <GOTO or GOSUB (can't remember which) to somewhere>. I'm wondering now whether you could make a faster dispatch mechanism in Spectrum BASIC instead of this naive solution.)
So I wrote an assembly routine just to deal with this bit. I didn't have an assembler. But, the wonderful Spectrum manual contained this table:
https://worldofspectrum.org/ZXBasicManual/zxmanappa.html
which I used to hand assemble my program. (I don't think I'll ever forget that ret is 201). When I gave away all my Spectrum stuff a few years ago, I kept the manuals.
It felt like a scene out of some retro-future sci-fi movie.
It's also interesting how the core (presumably 8080) instructions are one byte.
System programming in BASIC doing PEEK and POKE across all memory map, writing machine code loaded from DATA statements, no one telling that the one letter language was the only way of doing such endevours.
Later on, the same kind of low level programming with Pascal and Basic compilers on 16 bit computers thanks to some books on the local library.
I didn't have a computer in the 80s. I started learning programming in the mid-90s. There were huge religious wars over languages at the time, and it was basically C versus anyone who dared try anything that wasn't C. I remember being told I wasn't a "real" programmer because I would often use VB, Java, and--heaven forbid--JavaScript for things that didn't require the All The Speed. I still did C, but I wasn't singularly dedicated to it, thus I was apparently just a "scripter".
From my perspective, I didn't care if I was a "programmer" or a "scripter". I was "productive".
In terms of dogma in my own time, things have gotten a lot better. You do still occasionally find people who will make wild claims like "HTML isn't a real programming language", insisting that there is some definition of "real programming languages", despite PLT specialists telling them there isn't. But they are very few and far between these days, and they tend to be hold-overs from the old times.
An interesting claim when programming is full of people who literally invent the most bizarre language they can for the sole purpose of challenging the definition of a programming language.
Not being able to get information, and not having anyone to communicate to about problems (as in stackexchange now.. where you're able to ask a specific problem, and someone from the other side of the globe can answer in a matter of minutes).
Also, hadware was really limiting... which i kinda wish was still a fact for web developers, but we're too far for that, sadly.
The most valuable resource was the community. We'd put free ads in classified papers (a bit like Craigslist, but on paper) for trading pirated software (legally buying software was pretty impossible too - you could pay, but you'd be paying a pirate, so we decided to short-circuit those). This formed communities that ended up meeting on various early BBSs. I got tons of photocopied documentation (yep - buying books was also quite impossible because the military dictatorship controlled payments and made paying a foreign entity painful) that really helped me getting up to speed with both BASIC and the tooling (these names may be unfamiliar to most people, but I edited BASIC programs with Beagle Bros' GPLE and another tool I can't remember the name, that did line renumbering and some in-memory source-code optimizations (compressing multiple lines into a single one when syntax allows).
My work desk had two computers - a tricked out Apple II+ clone where I edited the code (which had an 80-column Videx - clone, of course - connected to a second monitor), and an Apple //e clone where I tested the program after I saved the original, ran all the optimizers (which reduced memory footprint significantly), and created the program disk (all floppies back then) to be run on the //e clone. Occasionally I had a third one, one identical to the classroom computers (because my //e was a "//e enhanced" clone and the classroom ones weren't)
Absolutely. Your comments about how hard it was to find even basic info was completely different to my experience in 1985 with a BBC Micro Model B, the manual [1], was a very comprehensive introduction to programming, starting with BASIC and going into 6502 assembly: it was and is the reason I'm a software engineer (I was 10 years old at the time).
The reason for the difference was probably due to the BBC Computer Literacy Project [2], which aimed to make the UK the most computer literate country on Earth at the time.
Even with this awesome introduction, learning programming required a brute-force-of-will approach. Much trial and error, and not much help from the machine (and no tools).
One thing I still have slight PTSD over is that if you wrote anything in assembly and it crashed, then you'd have to reset the computer, losing the typed in program. So if you didn't save, you lost your work. But saving meant recording to a cassette tape, hardly CTRL+S!
[1] http://bbc.nvg.org/doc/BBCUserGuide-1.00.pdf
[2] https://www.bbc.co.uk/taster/pilots/computer-literacy-projec...
I then got a second-hand Amstrad CPC464, but this time I got a manual (I didn't get a manual with the C64, it was a gift from a family friend) and a non-functional tape drive, which, unlike the C64, was integrated. It also came with a monochrome monitor!
Every program I wrote I had to erase before I could write a new one. I wrote an alarm-clock program which made an air-raid siren noise that woke me up every morning, and I had to rewrite it again every night.
The BBC project was hugely worthwhile, IMO. It had side-effects in Ireland, I had a couple of friends with BBC computers, and of course there were all those Usborne books, though Vic-20, TRS-80 and friends (before my time) probably helped too.
Mine had an output port that would allow you to save programs to an external cassette recorder (cassette recorder not included). I had a pile of unlabelled cassette tapes with programs I was sure I was going to want to reuse some day.
How the mighty have fallen, now we have MPs calling to ban encryption in complete seriousness.
It’s still paying off today. I employ ~100 people because of it. And there are many others like me. Pretty awesome vision (and from a political party I normally despise!)
The problem was that you were too late. Machines like the C64, the TRS-80 Model I, the CoCo, etc. all had specialist magazines dedicated to them ... back in the early to mid 80s. These were really good for distributing knowledge.
Unfortunately, the ascendancy of the IBM PC by the early 1990s wiped this stuff out. And most libraries got rid of those periodicals if they had even carried them at that point.
Happy memories
I doubt I could have even compiled the software onto a COCO 2 computer.
If I had to show how far we've got since then, and how different the experience could be for a novice programmer, I think I would display a .GIF where I press F12 in the browser, and write two lines of Javascript in the console, something like:
I don't write JS habitually and I'm on my phone so it's probably got some mistakes, but you get the idea!Given that this site, like so many others, is to help me get work, I think it's natural I'd use Perl in my examples.
Perl 6 was announced a long time ago, but it took many years of development and planning and I (like others) used to joke that Duke Nukem Forever was going to be written in Perl 6. And then we got egg on our face when Duke Nukem Forever was released first. (And it turned out to be a turkey).
However, many clients I spoke to at that time were telling me they wouldn't upgrade their Perl code because they were waiting for the new version ... which was seemingly never going to arrive. Worse, it became clear that Perl 6 was a new language, with common roots, but it wasn't like the Python 2/3 split: a wholesale rewrite of code would be necessary, or try to use a Perl 5 compatibility mode that may or may not have proven useful.
So companies weren't upgrading, Perl developers were fighting, people were leaving the community and the Osborne Effect (https://en.wikipedia.org/wiki/Osborne_effect) could be renamed the Perl 6 Effect (I'm aware that the Osborne Effect is more complicated than it's often portrayed).
Worse, Perl 5 couldn't upgrade to Perl 6 because that version number was taken. Perl looked, to the outside world, like it wasn't upgrading any more. I even had one guy screaming at me at a Linux Conference about how Perl is shit, hadn't updated in 20 years, and ticked off a bunch of "facts" about Perl, most of which were objectively incorrect at the time, but Perl could no longer get its message out.
There was discussion about leap-frogging the version number and going straight for Perl 7, but that caused even more fights, more people dropping out of the community, and we fractured. We tried saying "the name of the language is Perl 5 and we're upgrading every year—we're currently on version 34—but that didn't satisfy anyone, either.
Eventually, Perl 6 was renamed to Raku (http://blogs.perl.org/users/ovid/2019/10/larry-has-approved-...) and that freed us to upgrade our version number, but to what? Sawyer X, the former Perl Pumpking (development manager) proposed the Perl 7 project, but for many reasons, that also caused much anger.
So today, we have Perl. There are ideas of moving to Perl 7, but much work needs to be done. My Corinna OOP project is likely part of that work and the Perl Steering Committee has met with me to say they'd like Corinna in core, but slowly, step-by-step, to ensure that we don't push too much into the core and make mistakes we can't easily back out of.
I have more ideas about what is needed to get to Perl 7, but they'll largely wait until after Corinna is in core and fleshed out. It's a lot of work and the team working on Corinna (making great suggestions and also helping me not make boneheaded errors), have put in a lot of effort to create something we can turn into a proper RFC. Paul Evan's Object::Pad (https://metacpan.org/pod/Object::Pad) is a testbed for many of these ideas.
So, we're getting there, but slowly. However, it appears to be moving along more smoothly than other efforts in the past. The fact that the goal is more modest helps.
Also, I'd prefer a language with slow incremental changes because it eases the maintenance burden.
There is no way to define the word "popular" that makes this a true statement with regard to Perl 5 or any future development thereof shooting for backwards compatibility. -- I hate to be the negative nancy in this regard, but I seriously think that this is a cold and hard truth that is causing a lot of suffering because of people who fail to acknowledge it. (Disclosure: I work in a shop that forces me to do Perl, and I hate it with a passion).
One definition of "popular" would be: You ask programmers "Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?" [1]. 48.2% will then answer Python compared to 6.75% who will answer Ruby and 2.46% who will answer Perl.
Another definition of "popular" would be: Drilling down into those 2.46%, you ask them whether they love doing Perl or dread having to do Perl. 64% will answer they dread it [2]. This definitely agrees with my own experience working in a Perl-shop. Most people say they'd rather be doing something else. The company just feels that it doesn't make economic sense, so we're stuck with it.
For the other ones, I seriously suspect a case of Stockholm syndrome or something of the sort. -- Those would be the ones corresponding to the 0.86% (0.0246 x 0.36 = 0.00855) who say they do Perl and they actually like it.
The Perl code that's currently out there is literally sitting on top of an ecosystem that is rotting away beneath it [3]. For legacy code, the argument can sometimes be made that the situation is not bad enough yet to warrant moving away from Perl. But starting a new greenfield project in Perl 5 is, in my opinion, nothing short of professional malpractice.
So Perl is pretty much relegated to the hobbyist sphere, with Perl 5 maybe being of interest to retrocomputing aficionados. In that sense 80s-BASIC is very much the proper comparison class. Not modern-day Python or Ruby.
With Perl 6 / Raku not offering a viable migration path, one has to look at it the same way one would look at any other modern-day programming language upstart, with all the problems that entails (like lack of ecosystem, etc.)
Introspecting my own psychological experience now, I would go as far as to say that the open source developer community keeping Perl alive is perhaps the only group of people who truly meet the definition of giving the world something for free out of the goodness of their hearts (even in a way that ends up putting money in my own pockets), but who I actively dislike because of that. I feel like: If only Perl 5 would die a sudden death instead of this slow creeping demise, then, maybe, for me too this torture could finally come to an end.
[1] https://insights.stackoverflow.com/survey/2021#section-most-...
[2] https://insights.stackoverflow.com/survey/2021#section-most-...
[3] https://perlancar.wordpress.com/2019/08/01/dwindling-cpan-re...
This allows you to gradually move your code into Raku, replacing Perl 5 modules by Raku ones as needed.
As we're about to reach the 2000 modules in the Raku ecosystem mark, it should be noted that many modules from CPAN are not needed, as they're builtins in the Raku Programming Language. And many CPAN modules have outlived their usefulness in any programming language.
http://modernperlbooks.com/books/modern_perl_2016/
It explains many of Perl's "quirks" to a modern audience.
Perl is a quintessential example for the Internet era of programming. It was developed via USENET and email and FTP, with a global base of open source coders to drawn on. Got a question? Ask the mailing list. CPAN, Perl's automatic module system, dates to the early 90s. This is very different from programming alone on a micro, or on a mini or mainframe in an office environment. Much more like how we still do it today.
Unlike the earlier 6502 and z80 machines, the COCO's 6809 CPU was a perfectly fine compilation target for C or Pascal. I never had a COCO so I don't know what was actually available for it, but some friends and I wrote a BCPL back end for 6809 in 1984, for a wire-wrap 2 MHz computer we'd designed ourselves.
People using big computers were of course using compiled languages earlier. I was using a native Pascal compiler for the PDP-11 in 1981. But the end of BASIC on microcomputers started in 1984 with the release of the amazing Turbo Pascal 1.0 for CP/M and MS-DOS for $49.95. There had been compilers for the PC before this but they were huge, slow, and cost $500+. The similar in concept Lightspeed Pascal and C for the Mac arrived in 1986.
By 1987 I was programming in optimised Pascal compiled to m68k machine code on a machine with a 16 MHz full 32 bit CPU (with FPU) and 4 MB RAM. I had a Unixy command line (MPW), proper debuggers, could link with assembly language etc etc.
I'd already been reading about C++ and in late 1988 bought the Zortech C++ compiler to experiment with (in a DOS emulator). Apple had their own C++ for MPW a few months later.
Even Perl, which he uses as the example of modern programming, first appeared in 1988.
Really, the programming language landscape has changed little since 1987.
The main difference is just the capacity and speed of computers, and the rise of the open source Linux OS and much more recently the open source RISC-V instruction set (we haven't seen the full impact yet).
This is probably true as written, the languages that we know today are similar to what existed back then in the way you tell the computer what to do. Things like functional already existed. Not sure about garbage collection, when did that become a thing?
But what's really changed is:
- You can download a huge amount of libraries from someone else really easily.
- You can ask questions and someone else has already answered, or you will find a language expert and they'll help you. This is almost entirely StackOverflow, I suppose also a number of previous sites that have gotten outcompeted.
- Tools for coding are miles better. Intellisense, extensible IDEs, Version control, CI/CD.
I remember as a kid in the 90s trying to learn how to code, and as soon as there was a problem, there was no help. I knew zero people who definitely knew the answer and maybe one or two who might know the answer. So after a few blockages, I just gave up.
Nowadays I can jump into a new language just with the internet available. I'm pretty sure I could write a simple program in just about any widely known language that's new to me, just with a bit of time. I've done it a few times now, and each time I've seen problems like what I hit as a kid, and overcome them with a bit of searching.
True, but since projects/libraries were smaller themselves, I think the overall the effort here remained roughly the same. I remember I was directly "diving in" in the header files of the major libraries I was using at the time without too much effort. Doing the same in something like Qt5 today would make my head spin.
I agree about the rest. My local library at the time was completely useless, so I went by local bookshops and bought whatever titles they had on the shelves, which (looking back) was usually rather poorly written garbage. The true change for me was the discovery of early amazon, where I could buy the most obscure untranslated technical titles I wanted and get them shipped overseas at reasonable cost. Local bookshops generally didn't give a crap about my requests.
This was before my time though, and I could be confusing correlation (explosion in pc/web usage) with causation.
(Also I'm kinda jealous of people who were programmers in the 80s, it sounds so cool lol.)
So basically, for the teenagers, it was dreams, dreams, dreams. Not because of the technology, but because technology was so primitive.
Now, it's different: you have mindblowing technology all of the place, so you can build things like hell. But that came with the price of sophistication: only a handful understand sorting, databases, neural nets technologies... The lego boxes have become fatter.
On the one hand it was more difficult because of the lack of sources.
On the other hand you had one or two sources and you had to spend a great deal of your time to actually understand things and not copy paste with fingers crossed.
The frameworks were easier (there were none :)) and everyone was using the same thing.
The community you find on SO today is sometimes vastly more toxic that back then (especially in Go). I felt the toxicity only maybe 8 years ago, before that the interactions were normal.
So it probably depends on your language, need for speedy learning, etc.
I am an amateur so I love the fact that there are opiniated frameworks, IoTs you just use without the need to build them first, etc. It is just that the amount of information and possibilities can be overwhelming
I wrote test automation host software in BASIC (HP BASIC), but embedded stuff in 8085 ASM, in 1986-7.
Taught me a lot about debugging (I especially liked ICEs), but, for the most part, I miss those days like I miss a dysentery attack.
These days, I write mostly frontend stuff in Swift. I use symbolic debuggers, runtime instrumentation, GUI IDEs, and a whole stack of ridiculously powerful little handheld devices for testing. My low-end test device (a first gen iPhone SE) is a gazillion times more powerful than the million-dollar mainframe we used to program in my days, working for a company that provided email, before email was really a thing.
I had that machine, a manual, and some printed material my uncle gave me, a tape drive and about six tapes with games on them. That was it. My local library was useless for learning more. I had few friends and none that even remotely understood anything about computers. I had no modem or any form of information other than what came with that computer. So setting up the development environment was: turn the thing on and start typing. Everything you needed to know fit in a very thin manual.
These days, there's a lot of stuff to deal with of course and a lot of choices to make. New developers get overwhelmed with choices and material to read that they have to cherry pick from. However, there are plenty of ways to get started and helpful people that will help you to get started both with active support, tutorials, documentation, etc.
Not having any of that is not better. I too feel nostalgic sometimes but the games were meh, especially after playing them too often and Basic wasn't that great either. I've seen high school kids get into machine learning and building games with unity. 2022 is an awesome time to start learning how to program. So much to learn. So much to explore. So much to do. The only limitation is your own creativity.
Don't worry, the industry finds a way to overcomplicate everything.
If we tried to write anything that original in 2022 we'd be berated for not using a library.
Perhaps you didn't mean it that way, but I found your comment demeaning.
We want to get hyper technical, I'd argue with Flutter web and Firebase I could even teach a non-programmer how to build a basic web app with about 3 months .
A lot of times these more experienced programmers are able to plan things better, versus folks from our generation who just jump in and start writing JavaScript until it works.
[1] https://twitter.com/peterc/status/1478520632765784072
Coding was in Wordstar, and I remember being outraged that code had to start on column 7. Isn't this simple bookkeeping what computers were for?
I ended up going to college as a math major and avoiding the engineering degree because they coded in Fortran.
There were also "proper" IDE-like macro assembler development tools for 8-bit home computers in ROM modules with an integrated text editor, assembler, disassembler, debugger etc... which made programming quite comfortable and not all that different from today, especially with the luxury of a floppy disc drive (which I didn't have).
I remember I started writing an adventure around that time (maybe 1985, I was 12 back then) game using 3D wireframe (only lines, no filled surface). The adventure started in an hotel, I drew the stairs / doors etc. I found out I could use "graph paper" / coordinate paper: I'd take real pictures, use a glass table, put lighting underneath the table, then lay the graph paper on top of the real picture and draw my lines to reproduce the picture. Then I'd manually input the coordinates into my Atari 600 XL.
It was looking gorgeous but... After three screens, maybe not even that, I ran out of memory. That's how I discovered computers had a limited amount of memory to work with (it was 16 KB of RAM for the Atari 600 XL IIRC).
A bit disappointed I decided to do "single screen" graphics and had lots of fun doing that. I then remember using graph paper to reproduce a totally badass Porsche 1959: it was looking gorgeous for its time (probably 1986, when that Porsche came out, for I remember the magazine with an article about it, where I took the picture from).
# HTTP/0.9 was conceptualized in 1989.
0. https://en.wikipedia.org/wiki/Computer_Literacy_Bookshops
1. https://en.wikipedia.org/wiki/Santa_Clara_Valley_Transportat...
BBC Basic would check each line for syntax errors as you typed it in, so you didn't need to wait for that line to execute in the program. But ... all it would tell you if it found a syntax error was: "Syntax Error"
edit: And why didn't it give a more helpful message? Because the BBC Basic interpreter was squeezed into a 16kb ROM and so everything was pared down. It was written by Sophie Wilson, who a bit later co-designed the first ARM chip.
edit: Sometimes if it could make no sense of the line at all, it would also just say "Mistake at line 40" and looking back at that now, thats quite bold and to the point. Todays computers rarely tell their users that they have made a mistake in such a blunt way.
From memory, I think that's because BBC basic tokenised each line as they were entered. This also made it deceptively efficient with memory. BBC Basic was really quite a neat thing back then (especially the built-in 6502 assembler).
The Commodore Basics certainly replaced keywords by tokens (https://www.masswerk.at/nowgobang/2020/commodore-basic-renum...)
Apple's original Integer BASIC (written by Woz, natch) did not tokenize its input. I don't recall if it did any syntax checking at input because it was hard to get a hold of in the post AppleSoft BASIC era (I did eventually get a hold of a pirated copy on floppy disk that could be loaded into the himem region on a 64K Apple ][+ or //e but that was useful mainly for Woz's MiniASM that was in the part of ROM that was left over when he had Integer BASIC loaded).
Things change on a moments notice and break things. Python 2-->3 for example. Everything was broken because of a Unicode fetish. You're always getting blamed for insecurity, when actually its your bad operating systems. The lack of a simple model for getting things on the screen when there's the entire internet, and vendors who care about profit in multiple layers between you and the user. It must really suck to write full stack applications with iOS or Android clients.
Onward with the story of how it used to be:
I had Turbo Pascal by 1987. If you wanted to learn how to use it, the manual was usually sufficient to get you started. If you were really stuck, you could head over to Krochs and Brentanos, your library, or ask questions at the next user group meeting. Documentation was stand alone, well written, and well edited.
Compiles were always fast, the IDE had a pretty good debugger with watches, and stepping, so if you got stuck, you could see exactly what was going on.
We didn't have GIT, that's the worst of it... I always Zipped my source into numbered archives, and pushed them to floppy, to guard against hard drive loss.
Computers got fast, so much faster, but the basics haven't changed. When Windows came along, so did Delphi, with a really good GUI toolkit that was object oriented, and perfectly impedance matched to Pascal. It was glorious.
Then Borland got stupid, and started trying to beat Microsoft, instead of playing to their base. They made a C++, but it wasn't anywhere as good. The GUI tools made a lot of boilerplate that you couldn't tweak without breaking things. Strings were no longer sane.
I stayed with Delphi until Version 7. I've used other languages since, but nothing is as productive today for me as Lazarus, its open source replacement.
GIT, big RAM, and Terabyte SSD are all amazing, they make it trivial to deploy a Windows program to a desktop. You can make programs that are less than 3 Megabytes with GUIs and help, etc. Just plop into a directory, and run it. Or use the installer generator.
The main differences are speed, RAM, and disk space. The bigger screens aren't as nice for me as they used to be, once you hit 50, things blur, and the small fonts just stop being useful.
I do miss the simplicity of MS-DOS, and especially the security of of floppy drives with write protects. A dual floppy drive machine was simple enough that there wasn't anywhere for malware to hide. You could run anything on your machine, and restore it to a known working state by rebooting with your system disk (write protected, of course).
I also miss well written, complete documentation with working examples for each feature.
I don't miss those sequentially numbered archive files for "version control".
So, it was simpler, and far more manageable, even if the machines and screens sucked.
I already could write and compile C programs from floppy with just a few disk swaps, into native 8080.
RB-trees, Btrees on disk (floppies), etc. Not all that primitive. In some areas, pretty much the same as today.
There was also always the scent of rosin-core in the air because you always needed cables for things. People smoked at their desks in the office, the only place in the office with AC was the server room (backups to tape became more frequent in the summer months for some reason), there was a social protocol to how you handled someone else's listings left on the line printer, and the photocopier was perennially jammed.
Building an executable was usually an overnight job run in the batch queue.
That's what programming was like in 1987.
ngl, this sounds a hell of a lot more fun than sitting in back to back meetings and dealing with dumb blockers from business related issues.
It was. Damn I miss it too.
Most of the time I used a 12" white phosphor screen (soft-switched between board video and a Videx card) and a 16" color TV attached to motherboard color/graphics of the Apple II+ clone.
You couldn't do that on the Apple //e with native 80-column video, sadly.
What end up doing was just chain the video together. Run both screens.
The other 8 bit machines with a similar capability ended up being the Commodore 128. It's a real two display machine along with the original PC 5150? One could install both monochrome and a color display adapter and get use out of both displays independently.
I never saw an MDA/CGA PC, but I saw a couple with Hercules and CGA and a few with an [CG|MD]A and a high end something paired with a gigantic screen fed with 4 BNC connections. Normally the card with the BNC outputs would have more memory and a faster CPU than the PC.
I keep an Apple //e on my workbench, just like it was so many years ago. I use it for some light gaming, and the current games are whatever INFOCOM text adventure I am poking at and Nox Archaist. I bought that one new, and it was developed as a labor of love. Fantastic! ULTIMA style game as if it were seriously developed today, and I suppose it was, but I digress.
I also use it for writing and calculations and quickie tasks.
So, I just learned the Videx cards work in the //e machines just fine. I could have kept mine back then, but I let it go with the Apple 2 Plus I sold off a while back.
About 10 years ago, I decided to get a Platinum because the retro scene was heating up and I just miss having a good 8 bit workstation around for the occassional fun project.
Given the Videx cards work in all Apple 2 8 bit machines with slots, a clone makes sense! I would use it myself, ideally with CP/M and or Appleworks for writing.
But, it would also be cool to have it to do dual screen development too. So yeah, could be a fun project. Making an apple card and doing something with it is on my retro project list. Who knows? Next time I free up, I may look at this. I have been looking for a video related project for a while. Neat idea!
Just for fun, I am sharing my current setup.
FastChip 65C802 / 65C816 accelerator card. This one runs any clock from about 0.3Mhz up through a little over 16Mhz! Absolutely great card. Works reliably and comes with a little control and cable for you to adjust in real time, while programs are running! It does the job glitch free.
CFFA 3000 Storage emulation. This one makes modern storage available for use with the Apple.
Super Serial card, stock, unmodified.
Got a CP/M card in the mail due to arrive sometime this month.
These Apple machines are fun to just tinker with, and slowly build up to an interesting computer.
Hardware demand is actually respectable enough to support projects like this. I wonder how many others would be interested in a similar card?
I will ask around. Just curious at this point.
A Hercules card would be superior.
Maybe the BNC one was the Professional Graphics Adapter.
Amazingly, IBM did setup things to allow all three devices to un together and offer independent addressable displays!
Someone showed a setup like that at the Midwest retro computing show last year.
I started on an Apple ][ connected to one of those nice green screen monitors. Never felt eyestrain. Everything was sharp. But green.
Got a machine at home, and it was an Atari. On a color set, the white on blue worked pretty well. Moderate eye strain. Moved that computer to a smaller blak and white TV, and it was all much better. White on grey mostly.
Brought an Apple home, and the white on black was harsh on TV screens, a bit better on the black and white TV.
Turns out the color set was just not sharp and that was the primary driver of eyestrain. The right colors helped. Atari picked that white on blue because it made the most of a 70's era color TV. And it mattered.
After a time, I got hold of a newer smaller color set and tweaked it to the max, going for as monitor like as I could get it. Everything was improved and I ended up using that set for a number of years, until I got myself a green screen suitable for 8 bit computers.
My first PC was a CGA unit, and those were a little rough for text, and it was due to a poor CRT with a coarse phosphor layout.
Life got much better when I could get hold of basically any VGA screen. Was sharp enough, good color selection, good resolution. 640x480 seemed so damn roomy for longer than it should have, but it was the 8 bit experiences contributing to that.
My programming experiences were similar to many here. 8 bit basic, 6502 assembly, and the Apple was luxurious with a fast disk drive and included monitor / assembler. Was great to develop a piece of something in assembly, BSAVE it, then BLOAD it into the main BASIC program.
Compared to cassette it was awesome! I did use a cassette for about two years and ended up making custom tapes, just the right length for programs I used frequently. Could just LOAD, and do the thing, flip the tape over, and do that again. Also used the shorter ones for assembly bits, and a similar process.
Didn't even know what a linker was. I would map out the RAM, plan out what was going to happen, then develop in pieces, each thing written where it's going to live, saved off, and then combined with the main program, until at one point, it all gets loaded in for a master save and then run to check.
My friend and I did Monty Python’s Flying Quadratic Equation Solver. The hardest part was getting the timing right so that the music on the cassette lined up with the action on the screen.
Other projects were similar. Except.
Two of our friends wrote a scrollable periodic table, navigated via joystick. Press the button, get info on the element.
There most of were messing about in BASIC and these two went full assembler. It was a great result.
Surprisingly, neither went on in CS.
I wrote a program to calculate between orders of magnitude and gave it to a few classmates. Before the test, the teacher noticed people I think transferring programs and asked what was going on, and one dude said something like "We've got a program Andy made to do the test for us!" The teacher responded, "Well then you better know how to do the work so you can make sure Andy knew what he was doing!"
That program worked, but since becoming a dev a decade ago there's definitely been instances where that would've been good advice lol.
Still the most productive programming environment that I know of.
It was possible to actually know all the software that you had at your disposal at the byte level.
If you were so inclined you could change any part of it.
You could hook up hardware and access it immediately without any intermediaries, drivers, security or other barriers.
If it didn't work, it was likely your fault, which meant you could fix it.
Bugs in production software were fairly rare because people would test their stuff properly and spend the time required to do so because fixing bugs in production was either hard (or impossible), expensive, or both.
If you wanted speed on a regularly available machine you were programming in assembler.
You probably had access to only two programming languages, a high level one and assembly. If you were lucky you could call the one from the other.
There was no internet, you needed to either find a more knowledgeable buddy or you had to go to the library, read magazines or book.
I must have been writing very verbose code then. The frame-based reasoner I was coding in C (long story) was at least an inch thick itself (it's in my loft or I'd measure it).
> It was possible to actually know all the software that you had at your disposal at the byte level
I don't think this was true of the dev tools I was using on the Vaxen I had access to.
> There was no internet, you needed to either find a more knowledgeable buddy or you had to go to the library, read magazines or book.
Well, pedantically, there was an internet but you are right about the need to use dead-tree reference material - and the man pages.
What was missing compared with today was software libraries and frameworks. My development environment was vi and cc. If I needed a hash table or a queue, it was a case of reading an algorithms book. The journal of the British Computing Society was still happily publishing papers presenting new sorting algorithms.
[Edit] - the other big thing missing was deployment tooling, VMs, containers, etc. Admittedly I was coding in academia, but at no point was I introduced to version control tooling.
I had a book, an extremely useful one, "What's Where in the Apple II" which contained a full commented ROM disassembly with all known entry points, what their inputs were and where they stored their output. It was about 2 inches thick when printed. My copy (of course it was photocopied - it was almost impossible to get imported books in Brazil back then) had an extra inch from all the post-it notes, markers, paper notes and so on I added to it.
If the Vax wasn't impressive enough, I recall that sometime in 87/88 I was developing a quadtree visualiser on a Sun workstation - perhaps a Sun-2? This was a really mind-blowing graphical environment after being stuck with curses [0] on the Vax.
But still reliant on the man pages, coming back to the original topic. I hadn't yet discovered usenet and the comp.sci FAQs.
[0] https://en.wikipedia.org/wiki/Curses_(programming_library)
I'd have probably given a kidney for access to a machine like that, it would have moved my skills and career forward by a couple of years in one shot.
The Apple II+ (running DOS 3.3) was the last computer I completely understood from the board-level and up.
Bugs existed in the early 90's DOS and Windows environments and we worked around them with no vendor support. Bugs existed in the mid 90's web dev and we worked around them.
The simple fact that fixing bugs was hard and costly put such a premium on them that bugs were rare. Move fast and break stuff was an attitude that simply would not have worked back then. You tried your level best to get it right.