Programming in 1987 versus Today
ovid.github.io
ovid.github.io
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
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.
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 had 1980's BASIC books in 1992 along with a 386SX running QBASIC. I learned what I could from GORILLAS and NIBBLES. I looked through some books at the mall bookstore, but I didn't know anything about Microsoft C, dBase, and what the hell was CLIPPER? I didn't understand how computers 'worked' until much later. A C64 and an assembly language book might have built a real solid foundation.
I didn't know any adults or older kids when I was a kid who did anything with computers. I think that if my mom could have taken me to any kind of computer or programming class at the local community college, that would have been huge. Computer class in school was mostly typing, Oregon Trail and putting any kids who tried to run BASIC, go online, or bring programs from home into detention. Of course, we played pranks like swapping CTRL and ALT on the IBM keyboards, or running the PEEK/POKE command on the Apples to change the refresh rate of the monitor.
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.
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.
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.
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.
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).
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.
Well into the 90's every developer office was adorned with the 6" thick Borland box, proving they had their license. Opensource toolchains and languages took time to mature, but are ultimately responsible for the today's prolific programmer.
The machine then had 16MB of RAM instead of the 16GB today but the experience was pretty much the same.
My first job was programming PASCAL, FORTRAN, and BASIC on a VAX. This was a seminal time as I got to cut my teeth on ISAM. By 1987 I was on the brink of going to a new job that was BASIC and ISAM on a mini computer. BASIC is an unsung hero of the mini computer data processing age of the late 70's and 80's. I did all sorts of unspeakable things in BASIC. As weak as BASICs were, I never had to say "No" to a request to do something on our systems because "BASIC wouldn't let me". Just fan the fire hotter and hit it harder, BASIC would do the job, if, perhaps, inelegantly.
Takeaways from porting a 1987 foxpro application:
The fact that this still works - If not hanging on by a thread, it's pretty incredible that it still has seen something like 34 years of usage, well more than my years on this planet. The guy who originally wrote it died though, and the CD with the code lost, so I'm stuck reversing old formats.
Format encoding - No unicode back in the day. If you read file formats from back then, make sure you get this right and figure out what encoding it was using or you will end up with muntzed data. This was regionally based back in the day.
Tooling - I found great use of perl in this mission because it's also good at handling ancient 1980s file formats, it itself being a language from around the same year. Check this out [1]
Database typing - Haha guess what format they were using for dates? Well it sure as hell wasn't Y2K compliant. The now-dead original programmer had to go and monkey wrench that in there.
The 1990s in IT in Czechia were a time of several competing encoding standards. Normal ASCII does not cover most Czech accentuated characters, so we had to choose from:
a. ISO 8859-2, typical for *nixes and often found on the web
b. CP852, an IBM-based DOS standard
c. Windows-1250, a Microsoft standard for Windows; therefore, programs localized for pure DOS (with CP852) would have malformed Czech resources when running under Windows 95 or so
d. Mac CE, for Apple only
e. so-called Kamenický kód, a very clever local encoding (could still be somewhat readable even when switched to ASCII), but with zero institutional support, so doomed to insignificance
f. KOI8-CS, a Cold War Czechoslovak standard for a line of computers that could not compete with the Western ones.
I've seen Turbo Pascal programs trying to deal with all of them...
TGIUnicode.
Still the most productive programming environment that I know of.
# 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...
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:
var words = await fetch("some online JSON dictionary").json();
var lexed = "insert sentence".split(/punctuation regex/).map(w => words.indexOf(w));
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.
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.
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 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.
Except for C, none of those things are likely to be found outside a museum. Also, I am old.
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).
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
But, I remember thinking back then, "Why would I want one of those at home?". Little did I know those "little things" would eventually kill the company I was at in about 7 years plus all of its competitors except for 1. That one almost went down 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.
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.
Books and magazines were great for learning at home. Our teacher was pretty good at introducing "proper" programming concepts at school.
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.