[HN Gopher] Why bother with old technology? (2013)
___________________________________________________________________
Why bother with old technology? (2013)
Author : nickt
Score : 50 points
Date : 2021-06-14 04:36 UTC (2 days ago)
(HTM) web link (www.retrotechnology.com)
(TXT) w3m dump (www.retrotechnology.com)
| baus wrote:
| I don't know if "technology" is limited to digital tech, but I am
| having a lot of fun working on vintage analog gear, specifically
| tube amps. It helps me think about totally different types of
| engineering problems than my day-to-day work.
| cratermoon wrote:
| Typewriters, slide rules, abaci, film cameras, fountain pens,
| morse code, ham radio, vinyl records... what else?
| iamwil wrote:
| This article talks about hardware, but for me it raises software
| equivalents in mind. Lately, I've been looking at Datalog. It's
| an old ass query language that's found a slight resurgence in
| specific niches.
|
| Sometimes, old ideas are not fully known or understood, as our
| field is relatively new. Going back to the writings of Engelbart
| or Papert, I've discovered some new things about original intent
| that the first implementations missed.
| the_only_law wrote:
| For me: Because it's cool.
|
| I play around a lot with retro networking and have exposed myself
| to all sorts of old protocols, technologies, etc. that maintain
| my interest much more than the IP monoculture of today.
|
| Also I get to practice skills I otherwise wouldn't. I've done
| more hardware hacking reverse engineering in retro stuff than
| modern stuff, partially because it's simpler, partially because I
| actually have a real goal or objective, versus just doing
| something for rote.
| bear8642 wrote:
| > all sorts of old protocols, technologies, etc.
|
| Indeed - recently discovered the Transputer and Connection
| Machine and their attempts to build and code parallel machines!
|
| More modern examples of retro tech include Chuck Moore's GA144
| a forth based 144 core _asynchronous_ chip
| johnklos wrote:
| Every age, this age not excepted, has programmers who somehow
| find the energy to go out of their way to advocate for writing
| non-portable code.
|
| "Who cares if it doesn't run on 80386?"
|
| "Who cares if it doesn't run on PowerPC?"
|
| "Who cares if it doesn't run on 64 bit?"
|
| "Who cares if it doesn't run on ARM?"
|
| And now: "Who cares if it doesn't run on 32 bit?"
|
| They write code that makes assumptions about endianness, about
| sizes of pointers, about floating point formats, and then come up
| with rationalizations about why it shouldn't matter if their code
| only compiles and runs on one architecture.
|
| If we had taken all of them at their word, every architectural
| upgrade would require a rewriting of a majority of software
| instead of a recompile, and the open source world would be vastly
| different, and not in a good way.
|
| Old technology is a way to teach people about our roots, how our
| current path was informed by those roots, the lessons learned
| from mistakes, and the lessons learned from the successes.
| gwbas1c wrote:
| Well, do you really care if your web application or mobile
| application runs on an 80386?
|
| But, to get more practical: The wider your compatibility
| surface is, the harder and more time consuming your software is
| to write.
|
| I once worked on a C# desktop product in the early 2010s where
| we had a requirement to support Windows XP. This prevented us
| from using newer features in C#, like the task API, which added
| a lot of complexity to our UI code. (It's much easier to write
| UI code in C# when you can "await" in one line instead of
| dealing with callbacks.)
|
| Another drawback (of remaining compatible with Windows XP) was
| that we had to stick with an old version of .Net, which had
| bugs. Specifically, we were making a XAML UI, but XAML support
| in .Net for Windows XP was buggy.
|
| Furthermore, we had to _test_ our product on Windows XP, in
| addition to both 32-bit and 64-bit versions of Vista, 7, and 8.
|
| Eventually product management realized that it cost more to
| support Windows XP than the additional sales it would make, so
| they dropped the requirement.
|
| So, yes, "Who cases if it doesn't run on XYZ." Supporting
| "everything" often has real consequences and real costs.
| h2odragon wrote:
| Not disagreeing at all with your well expressed point, but: I
| wrote code to fully utilize the machines I had at the time.
| When new systems became available, the code needed to be re-
| written to fully exploit the new just as much as it needed to
| be de-crufted from the obsolete.
|
| Code that has been functional, untouched, for decades has a
| nobility; but a job that has been worth re-coding the solution
| every few years is actually important.
| mumblemumble wrote:
| I think you're maybe framing it the wrong way around. It often
| takes more energy to write portable code than non-portable
| code.
|
| "This isn't something I want to spend my time on" isn't a
| rationalization, it's a simple statement of preference. I
| personally feel absolutely no cognitive dissonance or regret
| about all the hand-coded PPC I wrote a couple decades ago, nor
| do I accept someone else wanting me to feel bad about it. It
| was (and needed to be) optimized for the machine I was working
| on at the time, and if I were moving it to a new platform, I
| probably would have wanted to do the same for it, too. As it
| turns out, though, the need never arose. The code was abandoned
| before the platform was. In short, YAGNI.
|
| Similarly, "This isn't a worthwhile expenditure of our
| company's resources," isn't a rationalization, it may be a
| simple statement of business reality. To take a simple example,
| a video game studio producing an exclusive title has very
| different incentives around code portability than an indie
| studio that plans to release on 5 different platforms. What's
| the point of developing your game to work on iOS if you have no
| plans to - and may even be contractually not allowed to -
| release it on that platform?
| hinkley wrote:
| Long ago I discovered that people don't get emotionally
| invested in your little perf- or platform-specific hacks if
| they don't have to look at them.
|
| With function inlining, you can often move your little weirdo
| bit of code into a function that is off the main call path
| and if people don't like it, they don't have to look at it.
| Also the fact that your change is in a single commit means
| they can always revert it if they don't like it (a bluff
| almost nobody calls).
|
| More importantly, when it comes time to port the code, the
| intent of your weird little code is both known and self-
| contained. They can decide what to do about it and have a
| path to do it.
|
| When your clever tweaks are peppered throughout your data
| architecture and half of the code base, then porting is a
| costly affair. And in some cases just updating your tools is
| hampered as well.
| mumblemumble wrote:
| It's true. Though I suspect that the proportion of code
| whose portability is hampered by clever code like this is
| vanishingly small compared to the volume of code whose
| portability is hampered by things like, "assumes POSIX-
| style file handling", "makes lots of DOS syscalls", or
| "targets AVR microcontrollers."
| Retric wrote:
| Most software doesn't live very long, and opportunity costs can
| be huge. For every Minecraft ported to every platform there are
| several Atari 2600 games that nobody cared about.
|
| Creating emulators today is vastly better use of resources than
| anyone writing ancient console games considering long term
| portability issues.
| cratermoon wrote:
| Time is a flat circle
| elcapitan wrote:
| Why bother with new technology?
| mikewarot wrote:
| I imagine programmers thinking something like
|
| "This code only has to run on the 1401, when we get a new system
| it won't be compatible, so it won't be around long anyway. Next
| time we'll write a better version incorporating our experience
| from this one, and taking advantage of the new hardware."
|
| Then IBM System 360 made things backward compatible, and the
| world broke. We saved tons of programmers time, and Y2K was a
| secondary effect of those savings.
| jes5199 wrote:
| when I work on old machines, I often get an overwhelming feeling
| that modern machines are _wasteful_. there was so much room to be
| clever and careful, but instead we just kept throwing more
| hardware at our problems
| bartread wrote:
| You of course know this already but it's not the machines that
| are wasteful, but rather the software we run on them and - by
| extension - the developers who create that software.
|
| UI latency is a never ending source of frustration to me, in
| large part, because it simply shouldn't exist with the
| computing power we have at our fingertips.
|
| On the other hand we have Microsoft Outlook and Microsoft Teams
| that are both absolute bastions of waste and instability. And
| not just in compute terms either, but in terms of my time - the
| finite number of breaths and heartbeats I have left - that is
| squandered in waiting around, restarting, rebooting my machine,
| because of these unstable, crashy behemoths.
| theandrewbailey wrote:
| _cough_ Electron _cough_
| low_tech_love wrote:
| As a retro enthusiast, I've been asked "why bother with old
| technology" a few times and, in my opinion, the best answer is
| simply "because I like it". There are probably some underlying
| objective reasons behind that which I'm not consciously aware of
| (like maybe studying old technology makes me a better tech person
| today, some kind of indirect pedagogical effect), but I can't
| really pinpoint that specifically, and it can be a bit tiresome
| sometimes. Next time I guess I'll link them to this article!
| chevill wrote:
| Got any recommendations for a good vintage computer to get
| started with that's more advanced than the C64? I took a course
| on C64 assembly and it was pretty good but I wanted to learn
| something a bit more complex but not as complex as a modern
| architecture.
| kordlessagain wrote:
| The Amiga had a 68000 chip in it and dedicated graphics and
| audio hardware which enabled it to be quite a bit faster than
| the C64.
| daggersandscars wrote:
| Any of the 68000-based machines may be worth a look. Atari
| ST, Amiga 500/1000, early Macs. There are also SBCs available
| that use the 68K.
|
| An early-ish 8086/8088 PC clone is a possibility, but the
| Atari/Amiga/Macs will have better graphics options and won't
| have segment/offset memory addressing.
| buescher wrote:
| A 680x0-based workstation could be really interesting for
| someone into that kind of thing, but an Amiga would
| probably be the most fun.
| rbanffy wrote:
| The advantage of Unix workstations is that they are still
| useful as X terminals.
|
| But then they aren't much simpler than our modern
| desktops running their own Unixes.
| buescher wrote:
| I'm thinking an eighties workstation like a Sun 3. If you
| can find one, an SGI Indigo or early NeXT cube. Much
| closer to an Amiga than to a modern system, but even more
| funky and exotic hardware.
|
| I wouldn't consider an X server running on one of those
| "still useful" but others might disagree.
| rbanffy wrote:
| I used an IBM PPC-based 43P as a work machine for some
| time. It can't run a modern browser, but back then using
| NetBeans running on my laptop was perfectly doable. Using
| Emacs and a terminal will work really well. Using one of
| these machines as a workstation is not much different
| from an older Raspberry Pi - you'll need to do the heavy
| lifting on the other side of the network anyway.
|
| The killer feature of this specific 43P was that it came
| with a gargantuan Intergraph CRT monitor.
| Hublium wrote:
| I feel like the Atari ST is the second easiest one to get
| into (after x86), because they share the floppy format with
| PC's.
| rbanffy wrote:
| Its hardware is also much simpler than the Amiga's.
| NegativeLatency wrote:
| I've been working on getting a Macintosh II to boot A/UX a
| sys v Unix. My eventual goal is to use it for doing the K and
| R C exercises, and just generally see what Unix was like.
| chevill wrote:
| That sounds like a really interesting project.
| NegativeLatency wrote:
| http://aux-penelope.com/
|
| There are some resources here if you're curious and want
| to see screenshots. (Not my site)
| Lio wrote:
| I'll add to the other suggestions with any of the Acorn Risc
| OS line[1].
|
| They're the original Arm based computers (not counting the
| development processor for the BBC Micro) and some of the
| earliest system on a chip computers.
|
| Might be fun if you fancy playing with Arm assembly language.
|
| https://en.wikipedia.org/wiki/RISC_OS
|
| https://en.wikipedia.org/wiki/Acorn_Archimedes#Later_A-
| serie...
|
| https://en.wikipedia.org/wiki/Risc_PC
|
| [1] I say Risc OS but they actually also supported a Unix
| like called Risc ix.
| dTal wrote:
| Not quite sure what you're after but you can get a Voyage 200
| graphing calculator for not much more than a RasPi now - it's
| got a Motorola 68000, a qwerty keyboard, a sunlight-readable
| screen, a serial jack, a useful OS with many games, a C IDE,
| a disassembler (both onboard!)... and it runs on 4 alkaline
| batteries.
| jerf wrote:
| One possible advantage is that it can be easier to learn the
| fundamentals when they aren't as obscured by as many later
| layers of smoothing over and/or complexity. For instance, it's
| very common for schools to teach assembler based on older tech,
| because it's simpler to deal with. Older tech will more
| directly expose you to the underlying issues with the
| foundations of the technology.
|
| For an example of something that smooths a lot of things over,
| using a nice, high-level USB library is abstracting away a huge
| amount of the issues involved with that sort of signaling. If
| you want to deeply understand how computers communicate with
| each other over wires, you're probably better off studying
| RS-232 first.
| jdsully wrote:
| When I was first learning how to program I felt this way.
| High level languages were unsettling in that I knew they were
| doing a ton of "stuff" but I didn't know what. Old 8-bit
| micros get you closer to understanding how computers work.
| WalterBright wrote:
| I tried to learn PDP-10 assembly language. I was just baffled
| by one concept after another (what's an accumulator? what's
| an addressing mode?).
|
| But then I did some programming for a 6800 with something
| like 40 simple instructions, and I "got it", and the -10
| became simple, too.
| jerf wrote:
| I've been doing web development since the late 1990s. I
| don't know every fiddly detail of every current web
| technology, but I can pretty much pick up any of them, read
| the docs for an hour, and have them going in just a bit
| more time, because I've got a solid foundation from working
| on things back when even XMLHTTPRequest was but a fever
| dream.
|
| I was recently speaking online to someone trying to get
| into it from a fresh start, and they lent me their
| perspective (kinda like a rubber duck debugging session),
| and I was a bit appalled at how hard it is to get into web
| development at this level now. I ended up recommending an
| approach in which one recapitulates the browser's
| development cycle if you want to really understand what's
| going on out there... it isn't the best choice technically
| in the short term because it's a long path to tread just to
| do "this one thing", but if you want to be similarly
| flexible and know how to work with the mess of technologies
| out there, for path-dependent and historically-contingent
| reasons (that is, opposed to any other good reasons), I
| think it may still be the best way to go.
|
| And to be honest, there's still a lot you can do with
| server-side generated HTML, the tags in modern HTML, and a
| bit of pure Javascript. There are good reasons to move
| beyond that; I don't mean that in a "back in my day" sort
| of way. But if you do start there, the rest of the stack
| makes a lot more sense than trying to start directly with
| React as your first intro to the web, as fine as React may
| be.
| mumblemumble wrote:
| I'm learning web dev right now, after not having really
| touched it since about the turn of the century.
|
| I bounced off of React & friends a few times before
| discovering the Lean Web movement. I'm genuinely happier
| for having found it. As a beginner, things like React and
| Elm feel opaque and obscenely complicated, all in order
| to solve problems that I don't actually have. Vanilla
| HTML+CSS+JS offers a much more pleasant learning curve,
| and has made it a fair bit easier to maintain momentum as
| I learn. From what I can tell, I'll probably also be able
| to take them really, really far before I need to adopt a
| front-end framework.
|
| I'm actually kind of wondering, now that I am more
| familiar with the history of the technology, if the
| continuing popularity of front-end frameworks is largely
| a hold-over from an earlier time when Web standards were
| weaker. Vanilla JavaScript and CSS have become a lot more
| capable over the past few years, but dropping back down
| to them may be technically or socially difficult. It's
| always easier to add more things to the pile than it is
| to take them away. Sunk costs and all that.
| rbanffy wrote:
| One fascinating feature of some old computers like the 8-bit
| Commodores and Ataris are the intelligent peripherals. The
| computer wouldn't need to wait for IO operations as long as the
| data would fit in the peripheral's buffers.
| michaelbrave wrote:
| I collect things like old Mp3 players because they are
| interesting examples of product design and UX design. But mostly
| it's because I just think they're neat.
| grouphugs wrote:
| being poor and unable to transition, and also you just might not
| want a cop in your home. fucking libera.chat troll admins called
| me anprim. fucking idiots
| cptnapalm wrote:
| You get to play with things you'd never have been able to dream
| of even touching or even seeing when they were in their heyday.
| martinmakesgame wrote:
| I realise everyone is probably already aware but Adrian's Digital
| Basement on youtube is a lot of fun to watch. I don't have access
| to the hardware or diagnostics that he has but I really
| appreciate remembering what things were like 30 years ago.
| Electronics is fun!
| haolez wrote:
| I like to imagine post-apocalyptic scenarios sometimes and
| mastering retro tech restoration would be a game changing skill
| :)
| abruzzi wrote:
| My use of old computing technology is really in support of old
| music synthesizer technology. For instance my Yamaha VL1, one of
| the first and greatest waveguide physical modeling synthesizers,
| does not allow full editing of the model parameters from the
| keyboard itself. Yamaha made a few editors for it that use MIDI
| SYSEX to edit the models. Unfortunatley those only run on MacOS
| System 7. So I have to keep an ancient mac for that.
|
| Many of my synths use 3.5" floppies. The ones that use FAT
| formatting can easily be used with a USB floppy on a modern
| computer, but the ones that have their own proprietary disk
| formats (most of them) require software with direct access to the
| floppy that can't be got through a USB connection. So, for those,
| I have an old Windows laptop with built-in floppy and software
| like Omniflop to manage those disks.
|
| Probably one of the greatest things to make old tech more
| manageable (for me) is the SCSI2SD project, which makes an SD
| card into a SCAI device. Since SCSI was hugely popular with
| classic samplers (synths that can record audio and use the
| recorded audio as the sound source in the synth sound) I have a
| half dozen SCSI2SD drives so I don't have to keep ancient
| parallel SCSI dive alive.
| eatonphil wrote:
| Older technology is extremely practical for teaching (yourself or
| others) because it's (mostly?) simpler than what exists today.
|
| For example writing an emulator for an older 8-bit CPU will be a
| simple problem overall to tackle than x86.
|
| That said, sometimes using modern technology is better for
| teaching since there are more tools and resources that exist
| today to help you learn today's technology than there are for
| older technology.
|
| So it depends. But it's definitely worth not completely ignoring
| old technology when learning a topic in case the older tech _is_
| easier to learn because it's simpler.
| gwbas1c wrote:
| Sometimes older technology is easier to develop for, mostly
| because there's more documentation, more stack overflow
| discussions, better understanding of quirks, ect.
| the_only_law wrote:
| I used to have an old 5150 (recently sold, as it's not my
| particular retro niche). The source code for the BIOS was
| listed in the manual for the machine. I was mildly and
| pleasantly surprised. I suppose a modern equivalent would be
| the firmware source code for your motherboard being
| downloadable from the vendor. I guess there's edk2, but I'd be
| content never to touch that again.
| jandrese wrote:
| A lot of this is complexity. The underlying systems are so
| complex that it is not really practical to try to explain
| them to the end user. But another part of this is political.
| Some parts are hidden on purpose to support features like DRM
| or to preserve a vendor's trade secrets.
| ClosedPistachio wrote:
| One thing I've never truly appreciated until I started reading
| the Dolphin Blog [0] is the many nuances physical hardware has,
| AND how software developers often leverage these nuances (which
| aren't typically reproduced, for example, with an emulator). With
| this perspective, I think we should memorialize old tech.
|
| [0] https://dolphin-emu.org/blog/
| adhoc32 wrote:
| Nostalgia.
___________________________________________________________________
(page generated 2021-06-16 23:02 UTC)