Ask HN: Could early 80s computers have had better software given today's CS?

https://news.ycombinator.com/item?id=41360030

by amichail • 2 years ago

37 78 2 years ago

news.ycombinator.com

For example, could they have had a better built-in language using the same hardware?

throwaway48540• 2 years ago

Yes: https://en.m.wikipedia.org/wiki/SymbOS

digitalice• 2 years ago

deleted

robbiewxyz2• 2 years ago

No offense meant, but this reads a lot like LLM speak. Very wordy, light on specific details.

mitthrowaway2• 2 years ago

It's a relief to know that the Turing Test apparently still has a few more years left in it.

grepLeigh• 2 years ago

I have a feeling the feedback on this post is being used in a training loop. Otherwise, what would be the point?

rjsw• 2 years ago

Atari 8 bit machines had Action! [1].

[1] https://en.wikipedia.org/wiki/Action!_(programming_language)

spacephysics• 2 years ago

Guess it depends what you mean by better. Also, in today’s context we have exponentially more complexity thats abstracted away. OS, drivers, user land software, heck even browsers alone.

Given this, I do think we have a lot of glue and duct tape fastening our digital world together.

But some of the low level stuff done today is probably just as good as would be done in the 80’s if not more, given the now easier access to information, and complexity requirements to even participate in low level development being higher.

I imagine a dev from the 80’s (like my professor from college) may be dismally annoyed at the amount of abstractions some languages have.

Spring boot for Java? So much ‘magic’. He’d say “just write it in PHP” lol

jmclnx• 2 years ago

I doubt it, in the early 80s, 16bit minis were common, so there were memory limits and segment sizes we do not have to worry about at all these days.

I did not get to program on 32 bit minis until maybe around 1988 or so. By then, minis were just starting to be replaced by PCs.

PCs kind of stopped companies from developing better minis. Where I was, by the late 80s, the high-end mini from the vendor I worked for was a borderline mainframe, maybe even a mainframe. But sales were falling at that point.

robbiewxyz2• 2 years ago

I'd love to hear from someone who's used both e.g. MicroPython and e.g. COBOL.

Both are resource efficient but probably have fascinating differences in what they're like to use.

Finnucane• 2 years ago

We had WordStar. What more did you really need?

surfingdino4• 2 years ago

brief

https://en.wikipedia.org/wiki/Brief_(text_editor)

amszmidt• 2 years ago

Lisp Machines had high resolution displays, loads of disk space, a language that was mostly type safe, with built in editor with capabilities that modern IDEs still often lack, email, etc ...

Here is a pretty brochure for the LM-2 (a relabelled MIT CADR): http://www.bitsavers.org/pdf/symbolics/brochures/LM-2.pdf

But would you have paid 80k USD for one (http://www.bitsavers.org/pdf/symbolics/LM-2/LM-2_Price_List_...) -- and that is without monitor, disk, ...?

JohnFen• 2 years ago

No, I don't think so. Today's software engineering is optimizing for minimizing dev time, and this comes at the expense of using more resources than are necessary to accomplish our tasks. Yesterday's software engineering was optimizing for minimizing resource use rather than dev time. That mindset makes a tremendous difference in how you approach the engineering.

xeromal• 2 years ago

It's very similar to how mechanics now replace whole parts rather than machine or rebuild them. The cost now are man hours, not the components themselves

linuxrebe1• 2 years ago

I would agree, I would also add that generally programmers today are not used to dealing with the memory limits of '80s computers. What is now considered an embedded device, back then was a desktop. My smartwatch likely has more memory than a PC Jr.

fragmede2• 2 years ago

No idea what smart watch you have but the latest (series 9) Apple Watch has (up to) 2 GB of RAM and 5 Tflop of computing power, while the PC junior had 256 kilobytes of ram and .33 megaflops of computing.

nodejs' main binary on my laptop is 44 MiB.

The Apollo Guidance Computer (AGC) we put a man on the Moon with could do 4 kilo instructions per second and 0.43 megaflops and had 2KB of RAM. Apple watch is roughly 900x as fast as the AGC while being being .67 x as large and less than 1% of the weight.

Vs the PC Jr, it's almost 2000x the size of an Apple watch and like 150x heavier.

The_Colonel2• 2 years ago

That's a huge understatement. Galaxy Watch 7 has 5 cores, one of them 1.6 GHz A78 and 2 GB RAM.

In 2013 I bought Galaxy Gear which was one of the first smartwatches and even that one had 512 MB RAM. PC Jr. had a 64 KB RAM base in comparison.

Ekaros• 2 years ago

ESP32 has more memory and more ROM than 5,25" disk... Not to even talk about clock speed...

And that is considered very affordable chip.

advael2• 2 years ago

Software engineering is really distinct from computer science. The practices that are prevalent in an industry differ from the algorithms discovered in academia (or in industry)

viccis2• 2 years ago

Software engineering is really distinct from computer science

I think both phrases are floating signifiers in practice.

bee_rider• 2 years ago

I think it is not 100% obvious if the question is actually about CS or coding. They say CS, but then ask about built in languages. Of course, CS advantages must have impacted language design, but a lot of it is just improving conventions, right?

strangattractor• 2 years ago

Agreed: Most of the computers from earlier eras did not have the speed, memory or disk space to even remotely support most of the CS practices today. The raw speed, multiple cores and gargantuan memories of today's CPUs makes things like AI feasible. Many of the ideas we use today existed in the late 50s and 60s. They simply were not practical to implement.

RIMR• 2 years ago

Yes, absolutely. Look at the leaps and bounds the Demoscene has made in sizecoding for older computers. There's an upper limit, but things are already being done on older 70's and 80's computer that people didn't know how to do back then.

aidenn03• 2 years ago

Many of the more impressive demos rely on having a much more powerful computer to do the encoding of assets. I know that e.g. cubase-64 did.

thibaut_barrere• 2 years ago

I started programming in 1984. I have no doubt that if those computers were suddenly all we had, we would leverage them in surprisingly interesting ways.

A classic example is https://www.vogons.org/viewtopic.php?t=89435, which shows what can be done “today” with old hardware, which was thought impossible for all the years before.

taeric4• 2 years ago

There have undoubtedly been advances in algorithms that are hard to really communicate to people. However, I think it is also arguable that the advance in computing resources has enabled some of the algorithm advances that people would use in these discussions.

That said, the discussion on "better built-in languages" feels like it is aiming at something I don't understand. Older computers booting into a programming environment was something that worked really well for what it was aiming to do. You could argue that BASIC was a terrible language, but there were other options.

I think the current raspberry pi setup is quite a good example for what you are speaking to? Mathematica is preloaded with a free license and is near magical compared to the programs most of us are writing.

AnimalMuppet• 2 years ago

Basic was a terrible language. Truly.

It was also a language that was discoverable to a curious 10-year-old.

So for the purpose of making the machine accessible to those who didn't know how to program, Basic was actually pretty good.

taeric4• 2 years ago

Exactly my point. It was pretty bad in many ways. I also have very few bad memories using it. Quite the contrary.

edent2• 2 years ago

Yes.

I wrote about it at https://shkspr.mobi/blog/2020/11/what-would-happen-if-comput...

Look at early games on the Sega Megadrive / Genesis compared to the ones released towards the end of its run.

As we learn more about computer science, we can push systems further than their creators envisaged.

surfingdino4• 2 years ago

Sega did not ship with a programming language. Hardware was closed so it took a while to find and explore its limits. Nothing to do with advances in CS, but a lot to do with devs' curiosity.

smolder2• 2 years ago

Right, by far, most of the tricks learned that improved game quality later in the life of a given console weren't based on new comp sci, but better understanding of the systems limitations (e.g. get more colors on screen by rewriting the color palettes between horizontal scan lines on the CRT) and improvements in tooling. I would say a rare exception to this is once video encoding/compression techniques came into play, in the late 90s/00s era where full motion video in games was cutting edge.

mbreese2• 2 years ago

How many of the new games (that looked better) had better circuitry on the game cartridge? I didn’t have a Sega (NES!), but cartridge systems could potentially have a lot more options to work with than the base system. For example, the Pokémon cartridge for the gameboy had its own battery powered memory (IIRC).

Not to take away from your argument - the more you know a system, the better it can be exploited.

However, in those days, it wasn’t always as simple as it seemed. This was especially true when you were (effectively) plugging expansion boards in with every game.

Here’s an example from the NES side: https://en.wikipedia.org/wiki/Memory_management_controller_(...

The reason why Super Mario 3 looked so much better than the original has a lot to do with evolution of these chips (on the cartridge).

edent2• 2 years ago

Other than Virtua Racer, I don't think any Sega cartridges of that era had extra processing circuitry.

There were some with extra control-pad ports, and I think one with a modem. Of course, you could count the 32X & MegaCD as a large cartridge - but that's stretching it!

hnlmorg2• 2 years ago

Learning techniques to maximise the efficiency of games consoles isn’t CS in the traditional sense. But I can see where you’re coming from.

You also have to bear in mind that cartridge based systems you ship with larger ROMs and sometimes even additional chipsets in later years of a consoles life. So even if you knew all the hacks for a specific console from day one, you still might not have a large enough ROM to take advantage of some of them.

h2odragon• 2 years ago

there are more TCP/IP stacks for DOS than there were back when DOS was widely used. so, yes.

Leaving aside the evolution of language designs: we's gone through several "revolutions" since that time. object oriented, etc etc. say all you like about the subtle power of LISP. the fact that there's so much Python code out there doing stuff, and people can bend it to their own needs, says a lot for modern progress.

tourmalinetaco4• 2 years ago

I wouldn’t say we’ve entirely progressed, especially in regards to efficiency (which is paramount in older hardware). Python and similar easier to learn languages are fun and all but they’re not proper for efficient applications, however because it’s easy to work on, which means less human hours are spent on production, it’s shoved out the door because all we care about today is being the “first to market” and not the “best to market”.

surfingdino4• 2 years ago

They had the best software given the constraints of the architecture. Basic was the best fit for 8-bit systems with tiny amounts of RAM. The interpreter was easy to implement and port. As soon as we moved into the 16-bit era more languages became available, because the hardware became more powerful. It was also at that time when computers stopped being shipped with built-in languages and began to be shipped with a bundled programming language or without one.

mepian• 2 years ago

Honestly I'm more impressed by the early 80s software from the likes of Symbolics and Xerox than by modern mass-market stuff.

mrweasel• 2 years ago

The reverse question is what interests me. Modern computers are so much faster, yet we need an ever growing amount of them to solve "the same" problems.

If you could run a small bank or insurance company on a beefy mainframe back in the 80s, then why can't I do the same today with faster hardware? Sure there's more work for the computer to do, but it's also much much faster and as almost infinite more storage space.

How much hardware would you need to run something like HN, if you wrote the code with the same care and understanding of the underlying machine architecture as a 80s software developer? And HN is probably already a good example of how much you can do with very little software.

tonymet• 2 years ago

80s software was probably 10e5 times as efficient in terms of resources used per unit of functionality.

Most of the resources used today are for encode/decode (aka marshall/unmarshall), remote procedure calls (e.g. REST APIs), remote storage (API to DB writes), type checking and inefficient data structures and algos. In short, devs are lazy and the toolkits are sloppy .

100s of MB of code, RPCs , huge DOM manipulations , 100MB of ram just to run a basic CRUD app. It's 85% of the modern software experience.

similar crud app in the 80s/90s would take kBs of code & ram, 5ms UI latency, with deferred or no remote calls.

mysteria• 2 years ago

Considering how most of the action on HN happens on the front page this site should be runnable on a little ARM SBC with good use of caching. If a site is mostly static with content in RAM a weak VM or SBC can handle a lot of traffic.

I'm pretty sure HN already does this but each comment thread would basically be a pre-generated HTML file (served to all users) that is only updated by the server when people post or vote. If someone opens an old thread, then it would take longer to load since the system would have to query the DB, render the page, and put it in the cache.

The_Colonel2• 2 years ago

It's an organizational problem in its core - how to scale projects across people and teams is the most difficult problem in software engineering.

HN is a project which one person can pull off and therefore could be nicely optimized. One talented person can achieve surprisingly much, but there is a limit somewhere. At that point you need to start adding people, but the more people you add to the project, the more diminishing results you'll see.

fragmede2• 2 years ago

The question is what're the traffic stats for HN. The Apple watch has 2GiB of ram and can do 5Tflops, which means TLs encryption is no big deal (though the number of integer operations per second it can do is more relevant, those numbers aren't given, but we can estimate in the 7 billion Instructions per second range, so it should be well equipped to host an unpopular dynamic site in RAM, but without knowing the traffic patterns for HN, we can't really say if that's enough computing to run the site.

As far as running a bank, theres an IBM/360 emulator out there, I bet you probably could run a small bank' overnight batch job runs on a laptop if you had the code.

drewcoo• 2 years ago

Does that mean Apple ][ and Commodore 64 software or does it mean PLATO, everything from Xerox PARC, and Lisp machines?

outworlder• 2 years ago

Computer Science hasn't advanced all that much. Some algorithms have been improved but it is a very slow process, as one would expect.

When it comes to 'software engineering', such as it is, we have regressed. We are incredibly wasteful, in the name of productivity. Some of that trade-off makes sense, but a lot doesn't, and there's diminishing returns. The microservices trend, that's spread like wildfire, is a good example. It makes sense in some cases, but the additional resource consumption is astronomical, both in computer resources, and humans, which is something it's supposed to help with. But the culture moved to an extent that, if you say a particular system is better off served by a monolith, you are seen as an alien in the best case, and a an unskilled hack in the worst case.

Sure, your team can package a microservice in a container, using any language, expose an API, ship it to kubernetes and publish your API spec without having to talk to anyone. Now, you have a whole other team managing your K8s and AWS environments, a whole bunch managing the different database systems that are isolated per service, yet another dealing with whatever messaging mechanism you have probably added once direct API calls became an issue, and you have a full team of Secops people deploying the latest and greatest tools from CNCF to fix the problems the architecture created. While a lot of that would have been, in other times, been solved with a function call. Worse yet, any runtime environments are duplicated, and even then simplest service now demands multiple gigabytes to run. Add HA requirements and you have an enormous overhead, to the point that deploying multiple copies of the monolith would have been far simpler – and much cheaper.

In the 80s, we had Lisp Machines. Nothing has come close ever since. Maybe if we had stuck with S-Expressions, we wouldn't have to reinvent markup languages every 5 years (XML, JSON, YAML, etc). Even without them, the Lisp condition system is amazing.

tourmalinetaco4• 2 years ago

I couldn’t have said it better myself, thank you.

Animats3• 2 years ago

Try fixing someone else's LISP code. Especially if it uses macros. Not fun.

taeric4• 2 years ago

Maybe? I have poked around a ton of elisp code in my time with emacs. It isn't hard, necessarily. No harder than any other code.

taeric4• 2 years ago

This is probably referencing the same idea that seeded https://cstheory.stackexchange.com/questions/12905/speedup-f.... I remember the claim, as well. That stack exchange indicates that it was never actually quantified. My gut would be that some of the algorithm advances require far more space that was available on early machines. Still a neat idea to look into.

consteval• 2 years ago

Personally I don't think the resource usage of microservices is even their biggest issue - it's their complexity.

Developing a distributed system when you don't need it is a recipe for disaster.

aidenn03• 2 years ago

One thing to understand is that, for home computers, the processing power was nearly free, but the storage (RAM and disk) were brutally expensive. An 8 or 16-bit home-computer from the early '80s could execute more instructions per second than a PDP-10 from 10-15 years ago, but had less RAM (Most 8-bit systems had no more than 64k, and the original IBM 5150 maxed out at 256k[1]) and was probably limited to a cassette or floppy disk for storage (no hard drive).

So when you see e.g. demos of SymbOS[2] running on an MSX2 (which at 1985 barely qualifies as "early 80s") with a 1MB ram expansion, it's not really the sort of thing that people would have had at home in the early 80s.

1: The PC was offered in configurations as low as 16k, models with less than 64k were fairly quickly discontinued.

2: https://en.wikipedia.org/wiki/SymbOS

tourmalinetaco4• 2 years ago

I always feel hardware upgrades that aren’t realistic to the time are in a way “cheating” when working on older machines. Definitely cool, but far cooler to fit in your features in using the original limitations.

aidenn03• 2 years ago

Well "realistic" is always the question. If you paid $10k you could get a very beefy machine throughout the '80s, or you could get a new car.

tetrisgm• 2 years ago

It's a very blurry thing to answer as the other replies highlight.

If you accept data points from the 90s, the work that Kaze Emanuar is doing on Nintendo 64 engineering improvements is a good indicationthat it's possible. Improved compilers, more modern algorithms, rethinking rasterization and how everything happens on device.

There's a lot of "what if we had infinite time to optimize for this stack" for sure. His comparison of various approaches to solve fast inverse squaee root on N64 hardware is really impressive.

gizajob• 2 years ago

I don’t see how Elite on the BBC Micro could have been written any other way. Today’s CS couldn’t have got the job done. Same with Manic Miner on the ZX Spectrum. Both involved extremes of optimisation using assembly to totally max out the limited machines. I respect those two pieces of software as works of art a million times more than anything written in the past 20 years.

tourmalinetaco4• 2 years ago

The same goes for me and DOOM on the SNES, the amount of magic they had to do behind the scenes is incredible.

Animats3• 2 years ago

Yes.

Languages

* C should have had standard types comparable to Rust's Vec and String. Pascal did. Null terminated strings were a terrible idea, and are still a curse. Plus a sane set of string functions, not "strcat" and its posse. Didn't have to be part of a general object system. Should have happened early.

* Slices. Easy to implement in a compiler, eliminates most of the need for pointer arithmetic. Again, should have happened early.

Those two alone would have eliminated tens of thousands of pointer bugs and decades of security holes.

Operating systems

* UNIX should have had better interprocess communication. It took decades to get that in, and it's still not that good in Linux. QNX had that figured out in the 1980s. There were some distributed UNIX variants that had it. System V had something.

Networking

* Alongside TCP, there should have been a reliable message-oriented protocol. Send a message, of any length, it gets delivered reliably. Not a stream, so you don't have issues around "is there more coming?". There are RFCs for such protocols, but they never went anywhere.

Databases

* Barely existed. This resulted in many hokey workarounds.

With all of those, we could have had CRUD apps by the late 1980s. That covers a whole range of use cases. There were client/server systems, but each had its own system of client/server interconnection. With all of the above, it would have been much easier to write basic server applications.

nateglims• 2 years ago

How popular was C in the early 1980s though? I suspect BASIC and assembly where much more prominent until late in the decade.

msephton• 2 years ago

C was very popular throughout the 1980s, and was the first choice for systems programming.

C was created in 1972 by Dennis Ritchie. In 1973 he used it to rewrite the entire Unix kernel. The popularity of both C and Unix grew alongside eachother.

The preeminent C book by Kernighan & Ritchie was published in 1978, with 2nd edition coming in 1988 with ANSI-C staged. The book was the first use of "Hello, world!". So even that was very influential.

Great article for further reading: https://www.jakeo.com/words/clanguage.php

telotortium• 2 years ago

* Alongside TCP, there should have been a reliable message-oriented protocol. Send a message, of any length, it gets delivered reliably. Not a stream, so you don't have issues around "is there more coming?". There are RFCs for such protocols, but they never went anywhere.

HTTP works well enough for this for basic use cases, assuming Content-Length is set. That's probably one of the reasons it's become the default protocol.

jlarcombe2• 2 years ago

There are numerous projects completed today for "retro" computers that run on unmodified hardware that would have been almost unimaginable "back in the day" and the vastly more powerful development tools (running on today's hardware of course) is surely a big factor. The fact that you can debug a game for the BBC Micro, say, by emulating the entire system and seeing at a glance frame by frame what everything is doing makes some tricks feasible that would have been incredibly difficult to pull off in the machines hey day.

Animats3• 2 years ago

It wasn't hopeless back then. You just had to develop on bigger hardware than the target. Like most other engineering processes.

AutoCAD for the Macintosh was developed on Sun workstations and cross-compiled, for example.

jlarcombe2• 2 years ago

Yes as was famously The Hobbit for the ZX Spectrum and all the Psion software (on a Vax I think). Not so achievable for the lone developer though.

phkahler• 2 years ago

Yes. They could have had better software given the CS of the 80's too. My first computer was an Interact [1]. The best games for it came out after production stopped. Having fully dissected the ROM I can say filling the 2nd (empty) ROM socket would have allowed much faster implementations of the built-in functions and some additional ones. The machine was so short-lived nobody ever maximized its potential.

On the hardware side, the graphics were very low-res with each pixel being 3 scan lines high. Simply adding RAM (there was an upgrade available to go from 16K to 32K) to the base machine should have allowed higher resolution graphics by not re-using pixel data so much or at all (simple hardware changes). Higher horizontal resolution should have been possible but with more complex hardware changes.

I'm looking forward to the end of scaling. I'm hoping that leads to more efficient software at all levels over time.

[1] https://en.wikipedia.org/wiki/Interact_Home_Computer

eesmith• 2 years ago

Here's one clear "yes". Starting in 1979, Infocom developed the Z-machine for their text adventure games - a virtual machine which made it easier to port across different microcomputers.

During the 1980s, Infocom developers wrote games in ZIL, which was compiled to the Z-machine.

In 1993 Graham Nelson released Inform, which compiled to the Z-machine. Quoting https://www.filfre.net/2019/11/new-tricks-for-an-old-z-machi... :

This event is considered by most of us who have seriously thought about the history of text adventures in the post-Infocom era to mark the first stirrings of the Interactive Fiction Renaissance, and with them the beginning of an interactive-fiction community that remains as artistically vibrant as ever today. ...
It wasn’t until some years after Inform had kick-started the Interactive Fiction Renaissance that enough ZIL code was recovered to give a reasonable basis for comparison. The answer, we now know, is that Inform resembles ZIL not at all in terms of syntax. Indeed, the two make for a fascinating case study in how different minds, working on the same problem and equipped with pretty much the same set of tools for doing so, can arrive at radically different solutions. ...
Having been designed when the gospel of object-oriented programming was still in its infancy, ZIL, while remarkable for embracing object-oriented principles to the extent it does, utilizes them in a slightly sketchy way, via pointers to functions which have to be defined elsewhere in the code. ...
The Inform standard library, by contrast, was full-featured, rigorous, and exacting by the time the language reached maturity — in many ways a more impressive achievement than the actual programming language which undergirded it. ...
Because it was coded so much more efficiently than Infocom’s ad-hoc efforts, this standard library allowed an Inform game to pack notably more content into a given number of kilobytes.

jerf• 2 years ago

I think we could have had some better safety, especially as we get into the later 1980s. We could have eliminated nil earlier. We could have had strings with variable-encoded length prefixes, rather than either NULL-terminated strings or strings with a hard-coded 1 byte or 2 bytes of length. Using a bit smarter type-based approach so that the code always knows what type things are would have been pretty useful.

You might conceivably be able to run something like Go, without concurrency (thus eliminating the runtime), starting around the early 1990s on high-end computers, and that would have been a really, really nice system compared to most other things at the time. I pick Go because of its relative simplicity. A variant of D or something would probably also work well.

A practical more-functional language could probably also have been provided, but some careful work would be necessary. Sum types have some details that we can easily just throw power at nowadays but would take a bit more thought back then to keep performance up enough; you may have to trade down on a few details. Linked lists were not as relatively catastrophic back then as they are on modern systems but they still involved an extra pointer on everything if nothing else, a language more strongly focused on arrays might be able to help.

But it's important not to underestimate the resource poverty of the time. Rust is out of the question. People complain about how slow it is today as it is. The executables modern Rust produces may have run well (with appropriate bittedness changes and such) but the compiler is hopelessly complicated for the 1980s. Nothing even remotely resembling it would have worked. Most modern languages have moved on and are too complicated to fit on machines of that era in any recognizable state.

Modern dynamic scripting languages only began coming online in the late 1990s. Such examples that existed in that space before then were incredibly slow; people pine for the capabilities of the Lisp machines but nobody is sitting here in 2024 pining for their performance characteristics.

I've kind of rewritten your question to be about the 1990s. I think that's because honestly, in the 1980s, no there probably isn't a huge advantage we could give them. Pecking around the edges, sure. Avoiding some things that only hindsight could show were some traps, sure. Commodore could have used some assistance with building a platform that could expand into the future better; for all the advantages that Amiga had over the IBM world, IBMs ultimately expanded into the computers we run today more smoothly than the Amiga could have. There's some tweaks to graphics hardware we could suggest, especially in light of how they were actually used versus the designers thought they would be. But it's not like we'd be going back there with amazing genius techniques for running on their systems that they couldn't have conceived of.

signaru• 2 years ago

Maybe cheating a bit if we allow compilers to run on more powerful machines, different from where the program will run. It could be possible to utilize more modern or "ergonomic" programming languages or rely on convenient libraries (assuming they are also efficiently coded). Programming languages in the 80s would not be as fun as what we have today partly because they were designed for limited hardware and partly because there's not a lot of other languages to learn from yet. IDEs, tooling and libraries have also come a long way.

Knowledge access is also something that has improved significantly. Programmers back then may not have had all the information that could have improved their work.

hnlmorg2• 2 years ago

A lot of the decisions made in the 80s were more based around hardware limitations. For example BASIC was chosen not because it was the best programming language for home computers but because it was able to fit on tiny ROMs on systems with between 16 and 64 kilobytes (!!!) of RAM.

The reason we have DOS is because CP/M could run on those systems too. A Unix-like OS wouldn’t even come remotely close to running on early 80s micro computers.

And much has been said about the problems of UNIXs design but the reason it was designed they way it was is entirely due to limitations in the hardware of its era too.

Unfortunately once a standard has been set, it’s very hard to change. It’s why there is still DOS remnants in modern NT-based Windows, why Linux and macOS still have TTYs, and why C-based languages even though decades of CS have given us far better principles to build from.

chrismcb• 2 years ago

By "early 80s computers" if you mean home computers like the C64, Apple II, trs80, ibmpc and Sinclair, then the answer is no. Not really. Today's software is memory and power hungry. Which 80s computers didn't have very much of. It is possible we could have done a better job of switching paradigms earlier. But I think the 80s software was pretty good for what it was.

Ask HN: Could early 80s computers have had better software given today's CS?

Related Stories