Ask HN: What was better in the past in tech?
Not that progress should be denied entirely, but I often think that the past gets discarded too quickly and many good ideas got lost with the bath water. I'm certainly not the only one to feel that way.
So I'm wondering what such good ideas that have disappeared can other HNers remember.
I'll start:
In the golden age of sun stations, the BIOS was written in forth, and the ROM contained a forth interpreter. Not only all extension cards ROM was interpreted and therefore all extension cards were architecture independent, but you were given a Forth REPL to tinker around the boot process, or in fact at any later point once the system had started with a special key combination.
That was in my opinion way ahead of the modern BIOSes, even taking into account OpenBIOS.
Your turn?
143 comments
[ 6.2 ms ] story [ 231 ms ] threadToday's consumer products are made with the expectation that they should always "just work". The result is that users reactions to problems have a tendency to range from frustration to panic and rage, rather than an inquisitive curiosity aimed at solving the problem.
I guess you could still tinker with most products, even if some brands make it increasingly hard. The real difference is in the expectations of the users.
To be fair, a lot more people now (many of whom are not tech nerds) are forced to use computers in order to do things that didn't require a computer 30 years ago.
I'm sure the average HN user's reaction would be closer to frustration than inquisitive curiosity if they were forced to navigate a complex and banal social system in order do something like sign up for a phone plan or watch a movie.
Technology is terrible, it barely works, and when you work at the edges of it (like we do), you hit the "barely" very often.
This is definitely a contributing factor. Forcing non-technical people to use computers is a rather daft idea, but it saves money since the majority know just about enough about computing to manage to do things after a bit of trial and error. Any bump in the road is sure to cause tears and shouting though.
Consumer devices are made for consumers - people who don't know how to create. If they follow some messed-up tutorial on YouTube and brick their device, they don't see that that's their fault. They complain to the manufacturer and expect a replacement or a refund.
So manufacturers have to protect themselves from these people, by locking the device down so you can't mess it up. It's not to stop us from tinkering with it. It's to stop the consumers from breaking their stuff "accidentally".
The availability of documentation enabled the porting of Linux and BSD systems in the 1990s without wasting a lot of time on reverse engineering the hardware details from the original OS.
Writing those things must have been an enormous endeavor.
"One of the questions that comes up all the time is: How enthusiastic is our support for UNIX? Unix was written on our machines and for our machines many years ago. Today, much of UNIX being done is done on our machines. Ten percent of our VAXs are going for UNIX use. UNIX is a simple language, easy to understand, easy to get started with. It's great for students, great for somewhat casual users, and it's great for interchanging programs between different machines. And so, because of its popularity in these markets, we support it. We have good UNIX on VAX and good UNIX on PDP-11s.
It is our belief, however, that serious professional users will run out of things they can do with UNIX. They'll want a real system and will end up doing VMS when they get to be serious about programming. With UNIX, if you're looking for something, you can easily and quickly check that small manual and find out that it's not there. With VMS, no matter what you look for -- it's literally a five-foot shelf of documentation -- if you look long enough it's there.
That's the difference -- the beauty of UNIX is it's simple; and the beauty of VMS is that it's all there." -- Ken Olsen, president of DEC, DECWORLD Vol. 8 No. 5, 1984
[0] http://www.anvari.org/fortune/Miscellaneous_Collections/3696...
We listened to the radio with the tape paused to record computer programs!
It's a tiny niche right now, but that's what people said about LPs not so long ago.
Some of my favorite bands now release cassette tapes. I don't have a player at the moment, but soon!
https://theconversation.com/audio-cassettes-despite-being-a-...
Apparently this is due to a shortage of raw materials as well as market size?
I wonder if the problem could be solved by using other tape formats that might be more readily available, i.e. record audio to proper "good" tape in some other format and then figure out the rest later.
* Getting information and help was difficult. At best there was c.l.c and such if you had a modem, but there was so much gatekeeping going on that it was hard to get a straight answer on anything.
* Source code was hard to come by. Everyone was so damn bent on keeping their precious code secret that you could only learn best practices if you happened to be in a job with good leadership.
* Hobbyist embedded systems were all but impossible unless you rolled your own. Working on an embedded platform meant using crappy tools, expensive and clunky in-circuit-emulators, and proprietary toolchains. Otherwise it was time for a homebrew etching tank.
* Storage, backups, and code versioning were a problem. Sure, we had CVS and eventually SVN and sourcesafe, but man did they suck!
* Hardware was super expensive. Software was super expensive. Getting anything done on a tight budget required a lot of creative thinking.
* Spending all day squinting at a small monitor sucked.
* Software (especially development environments) was chock full of sharp edges and required arcane knowledge and incantations. They were called UNIX wizards for a reason.
* Data communications and interchange formats were TERRIBLE (and always proprietary)
* Multilingual support was an exercise in madness.
* Bash was one of the nastiest undead languages ever invented. Oh wait, it it still is...
* "If it was hard to write, it should be hard to read and understand" was the mantra of the day.
Bash is absolutely wonderful as CLI driver. It's truly an awful scripting language).
And yet, I see many, many projects with huge, enormous shell scripts. It beggars belief.
Bash is really difficult to write well (if at all) and too many people don't appreciate this. Of course this leads to instability in shell scripts. Offender number 1? Dockerfiles!
Quite simply I don't think you should ever start using shell scripts in your code base in any capacity
Eventually you're going to reach something you just don't want to do in Bash, and suddenly now you've got two scripting languages in your codebase?
Don't think you want that trouble. Start with a scripting language with decent control structures on day 1 and never have to worry about refactoring.
I wrote software for in-circuit emulators from Applied Microsystems back in the late 80s and early 90s. I was fortunate to be able to work with some really talented people.
Our high-end ICEs were expensive, maybe $40K at the time. I can think of at least one company that bought 120 of them from us, although most of our customers only bought a few.
A lot of NRE went into building such systems. And yes, I think they probably were clunky yet capable of some amazing things when it came to debugging embedded systems.
Just to clarify, by c.l.c, you mean comp.lang.c on Usenet, right?
I've worked in game development for 25 years so YMMV: a few years ago I had an internet outage for a week or so and had to work on the engine just using my library of books. It was definitely slower and more cumbersome BUT it was a much more rewarding experience. I produced substantially better ideas with better documentation and with MUCH better execution. I don't think it was just because of the quality of my library. I think it was because I was afforded the space to think, something that had not happened for quite some time.
I now make a point to investigate my library before blogs, forums and the pitiful stack-overflow. Slower learning has lead to deeper thinking.
Software-wise, everything was enabled by default. You had to disable services. Which meant your machine was remotely exploitable right after install.
As time goes on, I don't see this as the benefit I used to. When Google supplanted Altavista as my go-to engine for technical docs, and then when StackOverflow come to the scene, I initially thought these were great developments. But I was wrong.
Yes, it took much longer to both obtain and read the Intel/Microsoft/VESA/Cisco/IETF/etc documentation, but at the end of that process I always had a very solid understanding of what I was doing, why I was doing it, and where to look if X or Y goes wrong. Engineering coworkers and managers understood the process, understood the time delays involved, and accepted what were typical turnaround times for both programming and debugging iterations.
Nowadays? I solve the problem much more quickly, but within a range of zero to very little understanding of why it works, what is above and below me in the abstraction hierarchy, what the hardware is actually doing, what the performance tradeoffs are, etc. And then to speak to engineering culture, if you ever step out to do it the old-fashioned way, impatience often sets in and you're told to just Google it, bro.
If something goes horribly wrong, would you prefer your engineering team to have developed a deep understanding of what's actually going on under the hood, or would you rather have a pile of stackoverflow answers patched together?
I think the old way was better. My brain is dumber and lazier than before, and I'm uncomfortable with this feeling. It's just sad.
In fact, one of the most striking things I encountered in Github issues, Stack Overflow, etc... is the amount of people who simply try something, works for them and they share it like some sacred solution, but when asked why that works, they shrug and cannot provide an answer. And there is a sea of validated answers just like that in those platforms.
My fear is that we are slowly rolling down a hill in which IT ultimately becomes less of an empirical industry and everything comes down to trying until it works (without the proper understanding), because it is magic.
Yes, sometimes (if not most of the time) developers are in a rush and have no extra time to spend on understanding a solution, so it is much better to slam a copy-pasted code and move on. Still, this should not be the way to go...
Not always. We had Kermit (https://en.wikipedia.org/wiki/Kermit_(protocol)) and NCSA Telnet (https://en.wikipedia.org/wiki/NCSA_Telnet) years before we had CVS (https://en.wikipedia.org/wiki/Concurrent_Versions_System) (1981, 1986, 1990)
To be fair, the pixels were bigger back then.
NCSA Mosaic and Server (that started the web) were free. The web was free and a huge percentage of it informative / labor of love free from commercial interest.
There was a lot of free/gratis but not free/libre software as well.
But also, you had to pay for a lot more things than you do today. WYSIWYG Word processors and spell checkers, for example, were expensive, and there was no free alternative (TeX was, it was superior in quality but with abysmal UI)
I would gladly return the net, and possibly the software world, back to that state. A lot of people assume that without ads the net cannot exist - but it did, it was informative, and useful.
There obviously was a mainstream tech industry that charged for its products. Often these were unaffordable to amateurs. But, since SaaS was infeasible, the software had to be shipped on physical media and run on isolated computers, which meant that it could be pirated. That got a lot of people into the industry.
There was also the hybrid model of "shareware", where you were encouraged to make copies and give to your friends - but if you liked it you were asked to mail some money to the author. Possibly the last great shareware product was the original DOOM - the demo version fit on four floppy disks, and you could mail off for the release version with more levels/weapons.
Today, even electron is reserved for the experienced web dev. See roadmap.sh
I believed we've lost a lot when we transitioned from desktop apps to web and mobile apps and JavaScript won.
Even ActionScript was way ahead of JS during its time!
Something in the class of VB6 or early Delphi is not commonly available. Everything today is comparatively clunky and bureaucratic. They can do a ton more, but take a lot more effort to produce the first usable thing.
(Similar to the simplicity of old rom basics in micros is now unavailable. You can do a lot more, and more easily, but you can’t just 10 print “hello” / 20 go to 10
With RAD apps, the barrier to entry is low. You install the IDE from this thing called a CD-ROM, drag some components, add some code to make it reactive (Yes we have reactive components in 1998!). Compile and run.
If I had free time and enough dedication I'd re-learn Pascal just to write desktop apps with Lazarus. Alas, that will probably never happen.
I am a recent graduate, but I think UI development has always been hard, whether mobile, web or desktop. Web seems to have had the least barrier to _entry_ (because HTML and JS, I think).
I have had classmates who tried flutter tell that it's so much easier than doing the same thing on web. While it was UI builders then, UI-as-code is new trend. There are some exciting directions now too (Flutter, Jetpack compose, svelte with its first-class reactivity).
In terms of simplicity a lot has to do with the capabilities of the hardware. The computers were much more limited, so the ceiling was lower as compared to today.
Example would be something like making a game. When I started coding, having just text on screen was far from being the best, but it was not totally out of place. These days 3D or nice looking pixel art is basically the baseline.
Xerox PARC Alto workstation: GUI, TCP networking and Smalltalk 72 OO programming system, all in 1973! This wheel has been reinvented in part many times since by Apple, MS and others. How much real progress has there been in the last ~50 years?
Any link to some overview of how this work would be greatly appreciated.
As such, the barriers to start exploring programming on your own were low: the development environment was already there, you were familiar with the interface, and it booted in an instant. I haven't seen any modern day technology replicate that ease of access for beginning coders.
But the beauty of that was that there was nothing more complex. There are simple devices and environments around today, but they pale in comparison to the more complex environments. You can totally code a game up in a BBC emulator, for example, but it looks shit in comparison to the Unity tutorial game.
I was forced to learn Assembler because it was the only way of writing a video game on the BBC micro. And there was nothing better out there. If I was 14 again and trying to create video games to sate my urge now, I'd be learning Unity. Even though there are simpler environments available.
And your user interface was all in PostScript!
https://donhopkins.medium.com/hyperlook-nee-hypernews-nee-go...
This kind of empty nostalgia is the epitome of intellectual laziness.
I guess my point is that it was more easily understandable and hackable and it wasn't a 10 GB install if all you need is SOME version of windows to run your games on.
Also zero phone home or mandatory/dark patterned Microsoft accounts.
There was some terrible product I reviewed that allowed you multiple versions of Win9x side-by-side on a PC with gigs of RAM (mid-1990s): it booted DOS, created a big RAMdisk, copied your entire OS into the RAMdrive, switched drive letters, and then your PC ran very fast...
But you had to do the special shutdown procedure, or you lost everything. And Win9x tended to crash relatively easily.
It was like someone came up with the most dangerous possible way to use lots of RAM to make Win9x go faster.
I gave it such a negative review that my editor refused to run it and wrote his own. Never happened before or since.
But I'm pretty sure a lot of things were handled with some autostart-link to a special batch file on d: :P As I said, it was fun - not sure I would've wanted this kind of stuff for a work machine, yeah.
It was easy enough to make a website that anyone could. There were services to build a page (Geocities, Angelfire), and if you wanted a bit more control you could host something on a shared server as simply as FTP'ing some HTML files to a remote directory. Expectations were low. People rarely criticised. That meant some truly whacky and creative things got built. Taking payments online was relatively hard work. That meant no one really expected to make much money online. Even ads were only just starting really, and most people didn't bother. People made fan sites for things they were passionate about, just to say they have a website. It was never a "side hustle", it was a just hobby. That was nice.
It was also the era of Flash, which lead to some brilliant and creative sites.
Languages like Perl and PHP were taking hold of server side generation so real SaaS business were starting to take shape as well.
I miss it a little. I have no doubts that the web of today is better, especially given the fact it's the basis of my 25 year (so far) career, but there are definitely aspects of it that I'd bring back if I could. The web should be more fun.
Just for what it's worth, this web still exists! Free hosting sites are still around, as is (S)FTP and plain ol' HTML.
Just a couple of weeks ago, I wrote a python script that generates + uploads webpages to help my wife with her work using nothing more than print() statements and an SFTP command.
I wrote a python script that generates + uploads webpages...
This is the problem in a nutshell. I'm aware that it still exists technically, but my own experience mean that as soon as I start I think "I'll be doing this more than once, I'll automate it!" and I dive in to a thorny bush of build scripts and dependencies and questions like "How will I notify myself if the script fails?" which takes a lot of the fun away.
My expectations of what a website is, and how it should work, and my awareness of the pitfalls of the Old Ways means I can't really go back to how it was before. I don't want to. I miss the good bits, but I know there were lots of bad bits as well.
Mainly because now you can run your own VPS cheaply and install whatever exotic tech stack you want on it.
Being a mischievous teenage hacker didn't land you in prison.
Software makers gave a shit about how much RAM and how many CPU cycles they were using. Disk space was sacred.
The technocrats weren't always a given. At least hacker-hippies that resented corporate control gave us an alternative; we could be living in a completely proprietary world. Compilers and even languages used to cost money, I shudder now when I see a proprietary language.
Once upon a time, computers did what you told them to without reporting you to the stasi, Google, or a number of marketing firms. Now that kind of freedom is obscure and hard to access for most people.
Software used to not hide all the options to "protect me from myself".
Computers used to be bigger. I love my office computer, but you gotta admit, fridge size and even room size 1401 style computers are pretty damn cool. I'm planning to buy a fiberglass cooling tower for a big-ish computer for a project this summer...
There used to be killer apps and amazing innovations but now its just ads and single function SaaS leases. At least open source projects are incredible, still. There are a few amazing commercial software products though. It's the future, after all.
Thats enough grumpy ranting for the minute, I'm sure I'll have to append this.
(P.S. remember when computers didn't have an out-of-band management system doing God knows what in the background?)
But overall much easier than the old days of having to manually remove malware and/or reinstall the OS.
On this note: Hacking, cracking and phreaking were done purely for curiosity sake. Even virus developers did it just because they could.
There was a sense in the community of pushing the technology to its limits.
Nowadays hacking, cracking and all the 'black arts' are for pure profit. Being it private or government...
This is describing a time before many readers of HN were alive, let alone programming. The https://en.wikipedia.org/wiki/The_Hacker_Crackdown documents when the US started cracking down in the 80s.
The UK had a similar incident in which a PRESTEL account belonging to Prince Charles was hacked in the late 80s, resulting in the Computer Misuse Act 1990.
Remember when you could note the number of sent/received packets in your network connection properties before going to bed, and wake up in the morning and see exactly the same number?
Varoufakis answers the question here[^1]. Use subtitles, translation is acceptable.
Yanis pointed out any new "successful common" (e.g. building societies) gets privitized. The most widely known example he points at, is the internet.
He also point out, that this is nothing new. Happened in the 19th century as well.
[^1]: https://youtu.be/JfGgRf0JPr8?t=1761
[^2]: https://en.wikipedia.org/wiki/Kratos_(mythology)
In the 1990s, a lot of desktop software was Windows-only, and used the Windows toolkit directly, so they supported the OS theming [1] including high-contrast options.
The idea you'd avoid the OS widgets, or that you'd want a touchscreen-but-no-keyboard UI on desktop software for consistency with a mobile version simply hadn't become mainstream. (Java had started testing the waters with cross-platform applets embedded in web pages but that's another story)
Of course, this was in the days of 1024x768 so large fonts were for the partially sighted, not like today's "high DPI mode" for people with 13" 4k screens. And most developers didn't test with different OS themes, so large-font settings could mean labels too big for their widgets, vital buttons getting pushed off screen and suchlike.
Other applications (well, MP3 players at least) would come with their own 'skinning' system allowing you to style them completely independently of the OS. And many games had their own full-screen menu systems that ignored OS theming, just like they do to this day.
[1] https://blog.codinghorror.com/a-tribute-to-the-windows-31-ho...
[0]https://github.com/wjakob/nanogui/tree/master/src
[1]https://github.com/ryankurte/micro-gui
[0] https://www.lazarus-ide.org/
If you want to make a native app, the first question has to be "native to what platform?"
Also, obviously, because browsers and the web stack are already ubiquitous. Electron is basically just shipping a web app with a standardized runtime (a Chromium instance) which is exactly what many other apps do (eg, most game frameworks and anything written in Python, Java, etc,) but Electron still needs a platform specific binary to distribute. TANSTAAFL. At the end of the day, nothing is truly cross platform.
Windows + Visual Studio Community + C# + WinForms = you can drag a button on to a panel, double-click it and edit the code behind, and start gluing a native app together in minutes.
The install is large, and the limitation of WinForms is that it's not dpi-aware and tends not to be resizable either, but the development experience is still pretty great. And if you somehow like the Windows 3.1 experience, all the C code from that era should still compile and run on a 2022 system. You can learn what a window procedure is; I believe people call this "immediate mode" GUI these days.
Oh, and as always, you can have native XOR portable.
Windows wasn't alone in providing this. Most desktop operating systems of the day did, including MacOS 8/9, BeOS, OS/2 Warp...
Of course, you're right that there never was a utopia of consistency where everything looked and worked the same and always respected user prefs, but the mid to late 90s was about as close as we ever got.
I use linux with GTK and if there is a choice of applications I'll try the GTK one first because of that consistency.
Which is fine as far as it goes but a lot of the proprietary apps I have to use for work I can't do much about.
IMO the classic WIMP desktop peaked with Win2000 from a UI/UX point of view (and I say that as someone who has run Linux since that era...)
Firstly, you don't really mention when the golden age of tech is for you. The answer can be quite different depending on the technological niche you are thinking of[1]. I'd argue that it's not over yet, and we are probably only at the beginning.
Although I agree that many lessons were learned then forgotten to the past, and we keep re-discovering those.
Only this time open source and free software is a thing, hopefully this will help us build on a common and expanding base, instead of reinventing everything all the time.
[1] especially as tech is so vague. The golden age of siege engines was probably the time of the Roman Empire. We keep building on previous technological bases though, so technology is moving forward, you'd also have to define "golden age".