Should game devs have to support new hardware?

[roondar]

Originally Posted by Reynolds

You know what? In the heydays we felt ourselves so miserably because when on other platforms (e.g. pc and mac, not even on aming consoles) the resources were taken to get used for better and better audio and visuals, but we had stuff at the end of the mainstream era developed for basic models.

Did we? I didn't, I just had fun with my Amiga.

Secondly, Not coding a program to be system-friendly, is scandalous. (sorry, can't find a better word atm.) The WHDLoad package was created due to the painful need to bypass floppy loading and fix freezes because of ignoring to code something system-friendly, as -again- in the heydays a simple hdd install wasn't taken into consideration as generic, default option, like it was always on the pc.

Actually, on a 512KB A500 coding system friendly with HDD install basically meant 'no games'. On a 1MB A500 it essentially meant 'no action games'. By the A1200 it still mostly meant 'no good action games'.

HDD installs means losing around 230KB of RAM over a floppy trackloader boot. On a 512KB or 1MB system, that is an awful lot to give up. And that's just the RAM you lose, you also lose a significant portion of CPU time to the OS and much more if you also start using the OS to do in-game GFX.

Originally Posted by Reynolds

And that's because Backbone is nastily and shamelessly slaughters the resources in a stock machine with no additional benefit than building a game in IKEA-style. Try to imagine running a game like Shadow Of the Beast or Turrican made with Backbone...

No, Backbone is what always happens when you're happy to not program for the low end but instead go for expansions. You get software designed to make life of people easier at the cost of the extra resources. I see no real issues with it. Now, I wouldn't use it, but then I want my code to run on entry level machines.

Originally Posted by Reynolds

Most developers are far to squeeze all power out from the config... from any config...

This comment shows my problem with your point in a single sentence. It's really a quite ignorant thing to say.

[malko]

Originally Posted by E-Penguin

How do you square that with the "it's up to the developers" sentiment? Surely if they want to use a toolkit they may - or do we expect all developers to be amazing asm gurus?

Blitz basic, gfa basic, Amos, C, etc. And now "scorpion engine" that is pointing the top of his nose No need to be an ASM guru

[Bruce Abbott]

Originally Posted by Akira

Most accelerators were a terrible idea to begin with, stemming from a futile urge to "keep up" with technology that was clearly surpassing the Amiga come the 90s and the user base's fanatical loyalty that would not let go of the platform and do whatever if it was even to create a dim ray of hope of the Amiga remaining alive and "relevant".

What utter nonsense. Most Amiga users who bought accelerator cards got them to run software such as raytracers and compilers that were too slow on stock machines. One reason we know this is that (unlike PCs) FPUs were very popular on the Amiga, even being included on a lot of A1200 RAM boards.

I mean, I understand some professional applications benefited from them since the beginning of the platform's existence, but to *need* them for every day use or, even worse, for gaming, was absolutely stupid and to this day a fanatic push to take the Amiga where it, in my opinion, should NOT go.

So the A1200 should have had a 7MHz 68000 in it, not a 14MHz 020? Perhaps you are forgetting that a lot of Amiga owners used their machines for more than just playing platform games? By the same logic, nobody needs a hard drive or extra RAM either so needing them for every day use was absolutely stupid. I mean, you should run everything from floppy disk and certainly not have more than one program in memory at a time.

The reality is that a lot of games did work better with a hard drive, more RAM or even an accelerator card. In some cases they needed the extra speed because they were ported from the PC without being painstakingly optimized for the Amiga, but in other cases (eg. flight simulators) there was always a need for more speed than a 7MHz 68000 can deliver. Why should developers have been hamstrung by users refusing to purchase hardware powerful enough to run their games properly?

This has nothing to do with a "user base's fanatical loyalty that would not let go of the platform" but simply users wanting to get a better experience from their machines. Many Amiga users didn't even know what was happening on other platforms, but they would have wanted to keep up with the latest Amiga technology regardless.

The thing that makes other scene productions often more impressive, and also more attractive especially to new coders, is what mcgeezer said: the platform is fixed, and it gets milked. This is what you have and you have to make do with it. From a creative standpoint, it usually pushes people to think differently and come up with far more creative ideas to resolve problems with the limited capabilities of the platform.

There is a certain attractiveness in that, but the 'fixed' Amiga platform has been over 'milked' already, while more capable machines like the A1200 have been largely neglected. If you have a game idea that needs more RAM and a faster CPU to work properly, why limit yourself to a stock A500 (512k?) that will curtail your creativity?

Also, it simplifies things a lot to know that you don't have 1789312 target configurations to support when you deliver your product. A C64 game will basically run on any C64 that exists out there, the exceptions are few. Meanwhile the Amiga platform is so fragmented, that if needing to cater for all these myriad configs is a brick wall in people creating software, I would very much be glad if people stopped caring about these things.

That is simply not true. Properly written software should work on the vast majority of configurations without any great effort. Real developers have always known how to maintain compatibility because Commodore kept us informed. Most pitfalls can be avoided simply by reading the developer notes and not doing dumb stuff.

The problem with a lot of Amiga 'coders' is that instead of reading and understanding the official documentation they copy stuff from other coders who are just as ignorant. They can't be bothered dealing with the OS so they take over the machine and do everything themselves, and then they do have a problem with different hardware configurations - as well as pissing off users who have more capable machines. These days any Amiga owner can easily upgrade their machine at low cost, so it is not too onerous to expect a few Megs of FastRAM and a hard drive for those games that could use it (and games that don't should tolerate it).

Developing for the Amiga is different from other platforms like the C64 and ZX Spectrum. You have a very capable multitasking OS at your disposal, and quite likely a hard drive and extra memory or even a faster CPU. Don't avoid all that goodness just because you are too lazy to familiarize yourself with the platform you are coding for. Don't be like Microsoft, who ignored Commodore's guidelines and produced a BASIC interpreter that used the upper 8 bits of 32 bit addresses for other purposes! Don't assume that RAM will be in certain locations and ignore it if not. Use OS functions for stuff like loading files and allocating memory - it's not hard! If you must kill the OS and manipulate the hardware directly, make sure you fully understand how it works!

Another problem is that not one accelerator works like another, it's not like all you have to do is "support 680x0", it is well known that there are different (in)compatibilities among them. Personally, I have a 030 that really gives me a lot of headaches on my 1200.

Properly designed hardware should be transparent to normal code. I code on an A1200 with a 50MHz 030 and 32MB FastRAM. I test my code on a 1MB A500 with WB1.3, and a Vampired A600 with WB3.1. I run Enforcer continuously on the A1200 to pick up illegal memory accesses (usually caused by uninitialized pointers). It's surprising how much new stuff from Aminet etc. causes Enforcer hits. This isn't a result of '1789312 target configurations' but simply bad coding.

Not comparing to other platforms, look back at the Amiga demoscene in the past, at least, 5 years (probably more), where the focus seems to have re-centered in making OCS/ECS productions, and most times, these new productions for even older hardware, are far more impressive, interesting and innovative than anything that targets accelerated hardware that only very few own (looking at you 060 only, 3D flyby demo crew).

I agree. The problem with demos for high spec machines is they tend to concentrate on boring 3D effects just because they can. A good demo isn't about showing off the machine's capabilities, its about producing an artistic affect. But that doesn't mean a good demo can't be made that makes use of advanced hardware, nor does it mean that demos for lower spec machines shouldn't work on them.

Take that shit off the trapdoor and enjoy a good Amiga game in the 21st century.
You can always stick it back any time to play your favorite game, SysInfo

No, I will not take the accelerator card out of my A1200 just to play some crappy 'retro' game or demo! I also don't run games via WHDload. Either they run from floppy, install on the hard drive, or I don't play them (just like in the old days).

I need my accelerator card for stuff like programming (which I spend several hours a day doing), browsing the web, transferring files over the network, and playing games that need it. If it went faulty I would be very unhappy, so I won't risk damaging it by unplugging and reinserting it every time I want to play a game (besides which it's a right pain to do). I don't mind turning off CPU caches or FastRAM, but I shouldn't have to go to that effort for a modern program.

[Bruce Abbott]

Originally Posted by mcgeezer

Does anyone seriously do productivity (*) work on an Amiga these days? Surely not.


* Web Browsing, Word Processing, Accounting, Presentations, Email, Digital Imagine, Video Processing, Cloud Computing.

Edit... hang on...

I'm now starting to wonder what people do actually do with the extra speed in their Amiga systems.

Web browsing and word processing yes, as well as programming and working with images. I don't run a business now so I have no need for accounting any more, or presentations (actually never did that). Not sure what 'Digital Imagine' is, and I don't do video processing or 'cloud computing' on any platform. Currently I do email on a PC, but that may change if my PC dies again.

But mostly I use my Amigas for fun (which could be programming, browsing the web, listening to music or playing games - perhaps all at the same time!) and a faster system is more fun.

[mcgeezer]

Properly written software should work on the vast majority of configurations without any great effort. Real developers have always known how to maintain compatibility because Commodore kept us informed. Most pitfalls can be avoided simply by reading the developer notes and not doing dumb stuff.

Real developers as opposed to who? Game coders today? Game coders back in the day? You're advocating any new game developers should only use the OS along with the Commodore documentation to build games, there are some things that can't be done with the provided OS function and then you have the performance overhead on the OS. The dev's back in the day probably understood this too.

The problem with a lot of Amiga 'coders' is that instead of reading and understanding the official documentation they copy stuff from other coders who are just as ignorant. They can't be bothered dealing with the OS so they take over the machine and do everything themselves, and then they do have a problem with different hardware configurations - as well as pissing off users who have more capable machines.

When I was programming the Amiga in the early 90's I had to get my documentation from other games using my Action Replay cart and learn that way. I suspect many other real developers did the same and I would certainly not class them as ignorant, lazy or attempting to piss off users with more capable machines.

These days any Amiga owner can easily upgrade their machine at low cost, so it is not too onerous to expect a few Megs of FastRAM and a hard drive for those games that could use it (and games that don't should tolerate it).

Ram and hard drives is hardly ever the issue, I would say most coders on the Amiga know the difference between the different memory types and know how allocate those resources correctly.

Developing for the Amiga is different from other platforms like the C64 and ZX Spectrum. You have a very capable multitasking OS at your disposal, and quite likely a hard drive and extra memory or even a faster CPU.

So you're saying the Amiga is special case and if you're not up to the task you should bugger off and make games on another platform. This isn't going to attract new game developers to the Amiga and get any new games released to the quality of its good old days, but then I have a feeling that games isn't your bag.

Don't avoid all that goodness just because you are too lazy to familiarize yourself with the platform you are coding for. Don't be like Microsoft, who ignored Commodore's guidelines and produced a BASIC interpreter that used the upper 8 bits of 32 bit addresses for other purposes! Don't assume that RAM will be in certain locations and ignore it if not. Use OS functions for stuff like loading files and allocating memory - it's not hard!
If you must kill the OS and manipulate the hardware directly, make sure you fully understand how it works!

Nearly all the issues I had were timing related problems that take time and experience to understand and overcome, that sort of knowledge isn't a quick trip into some documentation and it's not developers being lazy either. Make it easier for new game developers to programmatically disable the accelerator because to be honest it is nothing but a pain in the arse. I wonder how many games would have been fixed if this was implemented as a standard from good old Commodore from back in the day.

Properly designed hardware should be transparent to normal code. I code on an A1200 with a 50MHz 030 and 32MB FastRAM. I test my code on a 1MB A500 with WB1.3, and a Vampired A600 with WB3.1. I run Enforcer continuously on the A1200 to pick up illegal memory accesses (usually caused by uninitialized pointers). It's surprising how much new stuff from Aminet etc. causes Enforcer hits. This isn't a result of '1789312 target configurations' but simply bad coding.

New game devs won't know about Enforcer early on, they just want to get their game running on their A500 and be proud of it as an accomplishment. From the off they won't know about things like the VBR, or that waiting for a particular scan line has it's perils in faster CPU's, these are just two examples. Properly designed hardware should be flexible enough for the programmer to disable it. KILLEHB anyone?

No, I will not take the accelerator card out of my A1200 just to play some crappy 'retro' game or demo! I also don't run games via WHDload. Either they run from floppy, install on the hard drive, or I don't play them (just like in the old days).

So game development or game playing isn't your bag by the sounds of it and your opinions are based on yourself, I call that an "I'm allright Jack attitude".

I need my accelerator card for stuff like programming (which I spend several hours a day doing), browsing the web, transferring files over the network, and playing games that need it. If it went faulty I would be very unhappy, so I won't risk damaging it by unplugging and reinserting it every time I want to play a game (besides which it's a right pain to do). I don't mind turning off CPU caches or FastRAM, but I shouldn't have to go to that effort for a modern program.

Fine. There's no need to go on about crappy retro games or demos, or your reluctance to run WHD games because many Amigan's enjoy that sort of thing. You are probably in the minority for your use cases.

As it's obvious you're an experienced programmer you likely forgot what it was like when you were starting out programming an Amiga, the pitfalls you made, the frustrations you had...but then I may be wrong because you probably did everything Commodore allowed you to do and you followed all of the rules.

[Nobby_UK]

Originally Posted by phx

Otherwise, the developer has to say
"this product only works with that specific configuration".


Which I can understand and which is better than saying nothing, but it looks a bit lazy to me.

Lazy !

How many games have you done ?

[mcgeezer]

Originally Posted by Nobby_UK

Lazy !

How many games have you done ?

Celtic heart
Trap runner
Sqrxy 1 & 2

Those are the ones i know of.

All very good games.

[PixelsAtDawn]

I picked the stock option as I think that is the minimum, but I believe anything is fine as long as the dev is clear what they are targeting. There's games that target NG Amigas that I will likely never see as a Classic fan, and that's fine too. But no-one should be feeling an obligation to support a certain platform.

[tygre]

Hi all!

My apologies if this point has been already brought up in this very interesting thread

I understand Phx and others' point that developers should know what they do and, in theory, I agree of course!

But, practically, it seems to me that most developers, nowadays, are solo amateurs (in the noble sense of the term!), who code in their spare time and have little-to-no time to read all the documentation out there, find all the tricks (when they are documented...), and test on multiple platforms (if they have them).

I wonder if what we're missing, as a community, is a place that consolidates all the documentations, explains the pitfalls, surveys all the tricks, provides examples, supports developers, etc. for games as well as applications. A solid developers' Web site.

I mean, the EAB community offers a lot of support but the "barrier to entry" and "learning curve" are still quite high nonetheless. Hyperion's Wiki helps for applications, but mostly for OS4, I don't know how much it helps for games.

Cheers!

[malko]

Originally Posted by Nobby_UK

Lazy !
How many games have you done ?

Pssssst : https://www.lemonamiga.com/games/lis...20Owl%20Design
https://www.lemonamiga.com/games/lis...ist_title=sqrx
Not to mention: http://phoenix.owl.de/phxass_e.html
You may find others projects as well if you search a bit

[Tsak]

My 2 cents on McGeezer's question (what level of support/testing should game devs cover?).
A couple facts first (honestly, whatever anyone's opinion is, I don't think there's really any dispute with these).

a) Unlike other retro systems (f.e. most 8-bit micros, gaming consoles e.t.c.) the Amiga platform is highly fragmented and there are way too many different configurations, OS versions, Kickstarts, hardware add ons e.t.c. to take into account. It's a no brainer that as the list goes up, so does the testing and support required. Which takes time and resources (and a lot of learning and experimentation).

b) Good coding practices and deeper knowledge of the system can indeed ensure a better level of compatibility with most classic hardware still. How do we know this? There are arleady tons of games that display such properties and have absolutely no issues running on the vast majority of Amiga hardware, including vanilla classics, expanded machines e.t.c.
Having said that there are always going to be fringe cases, as exotic or custom configurations are not uncommon in Amiga land.

With the above in mind and to comprehensively answer the question at hand, one also needs to take into account a few other factors:

1) What is the level of experience of the dev? If you're a complete rookie and you're just started, try and support the bare minimum. Finishing a complete game already takes a lot of time and I wouldn't expect anyone to be able and figure out everything on his first go. From that point on it only makes sense to get better at this and reach a better level of support and understanding eventually. This is a gradual (and not an "all or nothing") approach so it really depends on the dev in question.

2) What level of support/testing is the dev himself willing to pour into his game? This is extremely personal and depends on why you are developing in the first place. If you want max appeal then -by all means- you need to support/test as much as your abilities allow. If you're in it just to have fun with coding/development, then simply focus on the coding/development parts that are fun for you. There are perfectionists that love to tinker with the slightest detail and defect and others that absolutely loath this process and are more interested in the trip and the broader experience while making a game (or just for educational purposes). Anything goes in this case.

3) The type of the game in question. Are we talking about free or commercial games? In the first case there is no clear answer and it depends solely on whatever the developer fancies (see above). However things are completely different in regards to commercial products. Here there's the obvious obligation of the dev, to ensure that everyone who has purchased his game has a good experience (at least on a technical level), meaning first and foremost the game should run as intended and it's as bug free as possible. You can -of course- still draw the line on what hardware you are willing to support, but you need to know and communicate that properly (so testing on most reasonable and common configs is necessary and inevitable).

4) Speaking of which, testing itself is not such a big deal, for starters we've got UAE and then there's a limitless supply of people with plenty real machines to test on (granted you lack them yourself) and the willingness to help. Plus there's also the community feedback (for non commercial and open developed games).

[grond]

Originally Posted by mcgeezer

You're advocating any new game developers should only use the OS along with the Commodore documentation to build games, there are some things that can't be done with the provided OS function and then you have the performance overhead on the OS. The dev's back in the day probably understood this too.

It's the second time you equal Commodore-compliant coding with OS-compliant coding. This is wrong. Commodore did only start recommending using the OS rather than directly accessing the hardware with KS 3.0 or even 3.1 when they started making sure that (almost) every hardware feature was accessible through a lean OS function such as lowlevel.library. They did this because they realised that they were going to have to leave the old chipset behind. Before that there was the Hardware Reference Manual which tells you what you may do and what you must not do to get the most out of the hardware (without strictly sticking to the OS).

As for the OS overhead: this is usually vastly overestimated. Yes, Shadow of the Beast would not have been possible through the OS but a lot of other (including more entertaining) games would have been possible. It is simply annoying if you can't play say Tetris on the Amiga while downloading something from aminet because the l33t c0d3r was worried about the ten clock cycles he would lose to the operating system. Even more so if you have many times more clock cycles available than the cheapest Amiga system. If anything killed the Amiga, it was the obsession for support of the low end models.

[roondar]

OS overhead on low end models (i.e. A500) is around 20-30% CPU and around 100-150KB RAM (much more if you have a HDD or more floppy drives). I measured this several times. It fluctuates and you do get some frames where it's a little less and some where it's a great deal more, but it's definitely not insignificant on the low end models.

Edit: I do want to add here that the above is neither a statement about the OS or it's quality, nor about whether or not you should code in a system friendly manner. It's just about making sure we have some of the facts about OS overhead in this discussions, rather than just subjective statements about overhead (which I have also made).

[dreadnought]

I must say, the bashing of old-time coders in this thread for being lazy, ignorant, or whatever, from the comfortable point of being ~30 years in the future is really quite something. It's as if they were all highly salaried senior programmers in some serious outfits, and not (very) young people in a still young industry, who often learnt as they went, had tight budgets and strict time constraints. Not to mention the bedroom coders and other amateurs who often achieved amazing results.

Unfortunately, apparently this is not good enough for the people from the future.

[mcgeezer]

Originally Posted by grond

It's the second time you equal Commodore-compliant coding with OS-compliant coding. This is wrong. Commodore did only start recommending using the OS rather than directly accessing the hardware with KS 3.0 or even 3.1 when they started making sure that (almost) every hardware feature was accessible through a lean OS function such as lowlevel.library. They did this because they realised that they were going to have to leave the old chipset behind. Before that there was the Hardware Reference Manual which tells you what you may do and what you must not do to get the most out of the hardware (without strictly sticking to the OS).

I'm talking about the OS routines that Commodore supply to access the hardware, I'm pretty sure you (and others) know what I meant - maybe I'll do it a third and fourth time though so you can keep telling me I'm wrong.

[roondar]

Originally Posted by dreadnought

I must say, the bashing of old-time coders in this thread for being lazy, ignorant, or whatever, from the comfortable point of being ~30 years in the future is really quite something. It's as if they were all highly salaried senior programmers in some serious outfits, and not (very) young people in a still young industry, who often learnt as they went, had tight budgets and strict time constraints. Not to mention the bedroom coders and other amateurs who often achieved amazing results.

Unfortunately, apparently this is not good enough for the people from the future.

The way I read this thread it seems to me to mostly be about new programs made by today's 'bedroom coders' in the Amiga scene. But actually, I do agree - old games/demos on pretty much all platforms had similar limitations and issues. No sense in complaining about it 30 years after the fact (and post A1200, most new releases did in fact work much better on many systems so people did learn even then).

[alpine9000]

Originally Posted by roondar

OS overhead on low end models (i.e. A500) is around 20-30% CPU and around 100-150KB RAM (much more if you have a HDD or more floppy drives). I measured this several times. It fluctuates and you do get some frames where it's a little less and some where it's a great deal more, but it's definitely not insignificant on the low end models.

Edit: I do want to add here that the above is neither a statement about the OS or it's quality, nor about whether or not you should code in a system friendly manner. It's just about making sure we have some of the facts about OS overhead in this discussions, rather than just subjective statements about overhead (which I have also made).

For the game I am working on (Metro Siege) I have two versions.

1. A bootable floppy version which disables the OS.
2. A "system friendly" version which keeps the OS running.

When I say "system friendly", this means it allocates any hardware resources before "banging", and uses OS routines for all interrupt processing etc (no accessing the vector table). The game will happily co-exist with a network stack downloading files. Other than that, the code between the two versions is identical.

I have various tests I run to measure performance. I thought it would be interesting to run the "system friendly" version on an A500 with no fast ram with the OS running and compare it with the "OS off" version.

The simplest performance measurement is the number of "dropped" frames - that is, the number of times it took more than the expected number of vertical blank interrupts to render a frame.

The "OS off" version drops no frames during the test.

The "system friendly" version dropped 5% of frames. Note: many scenes in the test sequence are not "busy" so there is little chance of a frame being dropped in these cases. So during busy times in the game, the frames are being dropped much more than 5% of the time. It was quite noticeable slowdown.

So based on these results for me, it's seems that on an A500, the OS running in the background has a significant negative performance impact.

If we run the same test on a standard A1200 with no fast ram, we are back to no dropped frames.

[dreadnought]

Originally Posted by roondar

The way I read this thread it seems to me to mostly be about new programs made by today's 'bedroom coders' in the Amiga scene.

May be, but even so - I can't really fault a bedroom coder for not knowing about, or adhering to, all the standards. They are, by definition, unpaid amateurs who do things for fun. It's the same about supporting other configurations - perhaps for some having to deal with extra stuff (no matter how trivial it might seem to others) could be a tipping point where they shelve the project and we get zilch insetad of something.

It's perhaps a bit different with commercial products though.

[roondar]

Originally Posted by alpine9000

When I say "system friendly", this means it allocates any hardware resources before "banging", and uses OS routines for all interrupt processing etc (no accessing the vector table). The game will happily co-exist with a network stack downloading files. Other than that, the code between the two versions is identical.

I could really do with a proper how-to on OS friendly interrupts, I've read the RKM manual but somehow found it rather vague on how to actually do this properly. Would you happen to know of a full, working example somewhere I could check out?

The "system friendly" version dropped 5% of frames. Note: many scenes in the test sequence are not "busy" so there is little chance of a frame being dropped in these cases. So during busy times in the game, the frames are being dropped much more than 5% of the time. It was quite noticeable slowdown.

So based on these results for me, it's seems that on an A500, the OS running in the background has a significant negative performance impact.

If we run the same test on a standard A1200 with no fast ram, we are back to no dropped frames.

This is more or less what I expected to see, but nice to get a different viewpoint here where it's about actual real-life consequences rather than more abstract concepts such as CPU time per frame

Originally Posted by dreadnought

May be, but even so - I can't really fault a bedroom coder for not knowing about, or adhering to, all the standards. They are, by definition, unpaid amateurs who do things for fun. It's the same about supporting other configurations - perhaps for some having to deal with extra stuff (no matter how trivial it might seem to others) could be a tipping point where they shelve the project and we get zilch insetad of something.

It's perhaps a bit different with commercial products though.

Yes, I agree with this. But I also think that we as community could be doing a better job of making it easier for newcomers. Both in the sense of making sure the information is out there in an easy and understandable form (the old manuals can be quite daunting and don't usually contain full-form examples, but rather snippets here and there) and in accepting that it's harder to get right than the people with more experience might remember it being (meaning I'd prefer vastly prefer an atmosphere of constructive criticism and encouragement over "your game sucks!").

[grond]

Originally Posted by dreadnought

I must say, the bashing of old-time coders in this thread for being lazy, ignorant, or whatever, from the comfortable point of being ~30 years in the future is really quite something.

We are discussing whether present day coders should repeat mistakes that were already mistakes 30 years ago.