Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

SupSuper: Apr 8, 2009; At the Heart of the city is an Alien horror, so vile and so powerful that not even death can claim it.

Spatial posted:

I work in embedded land, there is no wheel

The wheel is square.

# ? May 19, 2017 20:20

Adbot: ADBOT LOVES YOU

# ? May 28, 2024 14:37

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

SupSuper posted:

The wheel is square.

And the seat costs $2500.

# ? May 19, 2017 21:10

Joda: Apr 24, 2010; When I'm off, I just like to really let go and have fun, y'know?; Fun Shoe

Nude posted:

This is awesome, I did a quick build using one of their examples last night and couldn't believe how fast I could get something going. Wanted to get back into C++ so this is a nice way of doing so.

Seconding this. I pretty much have a fully fledged debug system and console (with command handler) in less than 300 lines of code written myself. I wouldn't recommend it for end-user facing GUI systems, but it's great and fast for debug systems and tools development.

# ? May 21, 2017 00:13

Pollyanna: Mar 5, 2005; Milk's on them.

Toady posted:

On a related note, UltraHLE was a massive surprise when it came out as the N64 was still commercially viable, but when you find out how it worked, it's glaringly obvious. In contrast to Nintendo's previous consoles, N64 games were written in C, so the UltraHLE developers wrote their own implementation of Nintendo's toolkit.

What were pre-N64 games written in? Straight-up assembly?

# ? May 21, 2017 01:16

Bongo Bill: Jan 17, 2012

Pollyanna posted:

What were pre-N64 games written in? Straight-up assembly?

Mostly, yes.

# ? May 21, 2017 01:27

fishmech: Jul 16, 2006; by VideoGames; Salad Prong

Pollyanna posted:

What were pre-N64 games written in? Straight-up assembly?

There were plenty of pre-N64 console games written in C or other high level languages, not much before the SNES/Genesis generation, and not many during that generation either. You saw very little high level language written games on the NES or Sega Master System for instance, as you really needed to rely on assembly due to general lack of compilers. And high level language development for pre-NES titles was generally right out.

Remember, the PlayStation 1 was out almost a whole 2 years ahead of the N64 and so was the Sega Saturn, and both of them had plenty of high-level programmed games before the N64 released.

Edit: For example, on the SNES most Electronic Arts titles were done in C for the main game logic. This was because they happened to have developed good compilers for the 65C816 CPU used on the Apple IIGS, and the SNES' 5A22 CPU is very closely based on that, the porting of the compiler ended up workable enough to use. But there were still plenty of EA titles on there with all-assembler, and many other development companies did not build or purchase workable compiler tools.

And over on the Sega Genesis, there was a sound driver system created for Sega of America by Technopop called "GEMS", which was used in many American-developed titles. The development kit for it was released a while ago and Sega Retro hosts it http://segaretro.org/images/6/6b/GEMS.zip

The driver itself is in Motorola 68k and Zilog Z80 assembly to be run on the Genesis' main CPU and sound CPU respectively, but it comes with sample C programs to be compiled and run on your Genesis developer equipment, and various files to make it easy to incorporate it in majority-C based games for the Genesis.

fishmech fucked around with this message at 01:51 on May 21, 2017

# ? May 21, 2017 01:30

JawnV6: Jul 4, 2004; So hot ...

Pollyanna posted:

What were pre-N64 games written in? Straight-up assembly?

If you'd prefer a view from the trenches this would be a good start.

# ? May 22, 2017 22:16

Pollyanna: Mar 5, 2005; Milk's on them.

JawnV6 posted:

If you'd prefer a view from the trenches this would be a good start.

Fascinating. I feel like I'm missing an entire treasure trove of stuff by staying away from assembly. It boggles my mind that this stuff was at all possible on that level. Maybe I should take some time and dive into assembly-level programming...there's a lot of questions I want to get answers to.

# ? May 23, 2017 00:37

B-Nasty: May 25, 2005

Pollyanna posted:

Fascinating. I feel like I'm missing an entire treasure trove of stuff by staying away from assembly. It boggles my mind that this stuff was at all possible on that level. Maybe I should take some time and dive into assembly-level programming...there's a lot of questions I want to get answers to.

I would recommend doing one of the things that article recommends: write an emulator. I got about 75% through a Gameboy emulator (not the graphics side), and it taught me a ton about assembly programming. A simple CPU like the Z80 (Gameboy's CPU is slightly modified), is easy enough to reason about all the opcodes and registers, and it isn't a huge project.

There are a bunch of tricks and cool stuff that was done in asm, but for the most part, you just keep layering on complexity bit by bit.

# ? May 23, 2017 00:55

EssOEss: Oct 23, 2006; 128-bit approved

Making Crash Bandicoot is also a fascinating read, about how they squeezed some amazing performance out of mediocre hardware by going way down into low level coding, beyond anything the competition could do. The fact that only a couple of programmers coded the whole thing is mindblowing to me - you have to know about so many different and difficult topics at the same time, and deliver results in just days!

# ? May 23, 2017 07:36

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

Hah, the same people were also behind my top choice for such tales: the first Jak and Daxter game.

It seems like internally-developed lisps were a common aspect of their game development process.

# ? May 23, 2017 08:27

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

Doc Hawkins posted:

internally-developed lisps

This seems appropriate for a bizarro Coding Horror thread. It's amazing they managed to actually write games that way *and ship them*.

# ? May 23, 2017 09:28

RandomBlue: Dec 30, 2012; hay guys!; Biscuit Hider

Pollyanna posted:

What were pre-N64 games written in? Straight-up assembly?

Remember, pre-N64 days were SNES and Sega Genesis days, that's only two generations after the Atari 2600 IIRC.

# ? May 24, 2017 05:20

baka kaba: Jul 19, 2003; PLEASE ASK ME, THE SELF-PROFESSED NO #1 PAUL CATTERMOLE FAN IN THE SOMETHING AWFUL S-CLUB 7 MEGATHREAD, TO NAME A SINGLE SONG BY HIS EXCELLENT NU-METAL SIDE PROJECT, SKUA, AND IF I CAN'T PLEASE TELL ME TO
EAT SHIT

Bullfrog had a 'let's learn assembler' tutorial in an Amiga magazine around that time
http://www.angelfire.com/planet/redbladenz/bullfrog/bullfrog.html

There was an Atari ST one too - I'm not sure if Peter Molyneux graced everyone with his coding wisdom though

# ? May 24, 2017 06:03

Zemyla: Aug 6, 2008; I'll take her off your hands. Pleasure doing business with you!

EssOEss posted:

Making Crash Bandicoot is also a fascinating read, about how they squeezed some amazing performance out of mediocre hardware by going way down into low level coding, beyond anything the competition could do. The fact that only a couple of programmers coded the whole thing is mindblowing to me - you have to know about so many different and difficult topics at the same time, and deliver results in just days!

I think the most hilarious part is that everyone was assuming Naughty Dog got secret libraries from Sony because their stuff looked so good, when the actual truth was that they got so good by avoiding Sony's libraries for everything they possibly could.

# ? May 24, 2017 20:58

Pixelboy: Sep 13, 2005; Now, I know what you're thinking...

Zemyla posted:

I think the most hilarious part is that everyone was assuming Naughty Dog got secret libraries from Sony because their stuff looked so good, when the actual truth was that they got so good by avoiding Sony's libraries for everything they possibly could.

Eh, it was very common. Didn't really think it was a mystery....

We all bypassed sceLibs and went straight to the metal on the PS1 (hell, even the PS2...)

# ? May 24, 2017 21:48

toiletbrush: May 17, 2010

baka kaba posted:

Bullfrog had a 'let's learn assembler' tutorial in an Amiga magazine around that time
http://www.angelfire.com/planet/redbladenz/bullfrog/bullfrog.html

There was an Atari ST one too - I'm not sure if Peter Molyneux graced everyone with his coding wisdom though

I remember following along with those for a little while, but about halfway through I got AMOS for my 12th birthday and went with that because it was so easy to write games and whatnot compared to assembler. I wonder what sort of dev I'd be now if I'd have stuck with it.

# ? May 25, 2017 11:02

Mr Shiny Pants: Nov 12, 2012

toiletbrush posted:

I remember following along with those for a little while, but about halfway through I got AMOS for my 12th birthday and went with that because it was so easy to write games and whatnot compared to assembler. I wonder what sort of dev I'd be now if I'd have stuck with it.

AMOS, wow I still have those. Yep, AMOS the creator, compiler and 3D.

Never figured them out though.....

# ? May 25, 2017 11:13

hyphz: Aug 5, 2003; Number 1 Nerd Tear Farmer 2022.

Keep it up, champ.

Also you're a skeleton warrior now. Kree.; Unlockable Ben

Mr Shiny Pants posted:

AMOS, wow I still have those. Yep, AMOS the creator, compiler and 3D.

Never figured them out though.....

I loved AMOS. But I know better now.

# ? May 25, 2017 21:36

Mr Shiny Pants: Nov 12, 2012

hyphz posted:

I loved AMOS. But I know better now.

I was a bit too young then I guess and the games for the Amiga were too much of a distraction to figure it out.

# ? May 25, 2017 23:20

Absurd Alhazred: Mar 27, 2010; by Athanatos

https://twitter.com/bengoldacre/status/867697599427510272

There must be a coding horror behind this.

Absurd Alhazred fucked around with this message at 19:17 on May 27, 2017

# ? May 27, 2017 19:12

Jaded Burnout: Jul 10, 2004

Sort of

# ? May 27, 2017 19:27

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Absurd Alhazred posted:

There must be a coding horror behind this.

Welcome to EMR. Even the good systems are awful.

# ? May 27, 2017 19:28

kitten emergency: Jan 13, 2008; get meow this wack-ass crystal prison

Arachnamus posted:

Sort of

'user configurable' is the gateway to most horrors

# ? May 27, 2017 19:28

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

uncurable mlady posted:

'user configurable' is the gateway to most horrors

Maybe, but the poor organization here is probably still the fault of the user.

Before reading that tweet, I would have blasted the GUI code because there was no possible excuse not to split that stuff into two or three menus. (Laziness isn't always a virtue!)

But I can well imagine something that required the menu be user-configurable.

# ? May 27, 2017 19:31

Beamed: Nov 26, 2010; Then you have a responsibility that no man has ever faced. You have your fear which could become reality, and you have Godzilla, which is reality.

NihilCredo posted:

Maybe, but the poor organization here is probably still the fault of the user.

Before reading that tweet, I would have blasted the GUI code because there was no possible excuse not to split that stuff into two or three menus. (Laziness isn't always a virtue!)

But I can well imagine something that required the menu be user-configurable.

For most of the medical industry, things like that have to be as user-configurable as possible, as any single line of code change could require literal tens of thousands of dollars of documentation.

# ? May 27, 2017 20:04

lifg: Dec 4, 2000; <this tag left blank>; Muldoon

Speaking of coding horrors in the medical industry, anyone who hasn't yet read about the Therac-25 should do so.

https://en.m.wikipedia.org/wiki/Therac-25

# ? May 27, 2017 20:13

Ghost of Reagan Past: Oct 7, 2003; rock and roll fun

Absurd Alhazred posted:

https://twitter.com/bengoldacre/status/867697599427510272

There must be a coding horror behind this.

Not specific to that, but boy would you like to see some medical coding horror that isn't Therac-25?

Give this a read

# ? May 28, 2017 17:25

Pollyanna: Mar 5, 2005; Milk's on them.

Ghost of Reagan Past posted:

Not specific to that, but boy would you like to see some medical coding horror that isn't Therac-25?

Give this a read

That was loving horrifying.

# ? May 28, 2017 17:49

Spatial: Nov 15, 2007

A friend of mine worked as a medical device tester and the stories he tells would sure make you worry.

My favourite tale so far was the medical pump which would switch into reverse mode when you put a strong enough RF source next to its USB port. This would definitely kill you. They had removed some of the shielding to place the USB port in an aesthetically pleasing spot. :v:

# ? May 28, 2017 18:05

Spatial: Nov 15, 2007

Regular silly old horror time:

Deep within the asynchronous IO manager:

code:

Lock acquireDataLock( mutex );
putData( extremelyLongDiskOperation() );

Holding a mutex for two entire seconds isn't very asynchronous. This is the same ASIO waits on to queue tasks!

code:

Data data = extremelyLongDiskOperation();
Lock acquireDataLock( mutex );
putData( std::move(data) );

Ah, that's better. :buddy:

Spatial fucked around with this message at 18:13 on May 28, 2017

# ? May 28, 2017 18:11

Absurd Alhazred: Mar 27, 2010; by Athanatos

Spatial posted:

Regular silly old horror time:

Deep within the asynchronous IO manager:
code:
Lock acquireDataLock( mutex );
putData( extremelyLongDiskOperation() );
Holding a mutex for two entire seconds isn't very asynchronous. This is the same ASIO waits on to queue tasks!
code:
Data data = extremelyLongDiskOperation();
Lock acquireDataLock( mutex );
putData( std::move(data) );
Ah, that's better.

# ? May 28, 2017 18:13

kitten emergency: Jan 13, 2008; get meow this wack-ass crystal prison

Ghost of Reagan Past posted:

Not specific to that, but boy would you like to see some medical coding horror that isn't Therac-25?

Give this a read

That's a fascinating piece. I think the points about "stop the line" and alerting are probably both incredibly useful takeaways for people in software especially. I can say with a lot of certianity that most of the really dumb mistakes I've seen where I work are due to some combination of people ignoring signals due to either there being too many of them, or because they're maybe a junior person who doesn't want to bother a senior dev.

# ? May 28, 2017 18:14

Nippashish: Nov 2, 2005; Let me see you dance!

Ghost of Reagan Past posted:

Not specific to that, but boy would you like to see some medical coding horror that isn't Therac-25?

Give this a read

I'm sure there's some interesting psychology to be done on why medical systems generate so many alerts even when alert overload is known to be a thing.

# ? May 28, 2017 18:45

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Nippashish posted:

I'm sure there's some interesting psychology to be done on why medical systems generate so many alerts even when alert overload is known to be a thing.

In isolation (when designing a single component), it makes sense to be over-cautious: nobody gets sued for alerting when things don't happen, but they do get sued for not alerting when something does happen. It's when you add all these isolated decisions together that you get the unworkable mess.

# ? May 28, 2017 18:56

Spatial: Nov 15, 2007

SupSuper posted:

The wheel is square.

How about some square SRAM? A little while ago, our qual team found a timing issue with our current MCU design. The hardware designers' suggested solution: halve the speed of SRAM instead of fixing it so we can meet the release deadline.

Unlike the processors you are all familiar with, this is an embedded microcontroller with no cache. All memory accesses just become twice as slow. It's straight up performance death and would add deeply shameful stuff to the datasheet. Flash being faster to access than SRAM, effective power consumption 50% above what we promised due to the increased duty cycle, comically poo poo MIPS for the process and MCU class. gently caress.

In summary, their solution is to kill the product so we can release the corpse on time. This is supposed to be our next generation kickass product and it's the first one where I've been able to influence decisions from the beginning of the project so I'll be seriously pissed if this ends up happening.

# ? May 28, 2017 19:03

Space Kablooey: May 6, 2009

Ghost of Reagan Past posted:

Not specific to that, but boy would you like to see some medical coding horror that isn't Therac-25?

Give this a read

Man, this so well-written.

# ? May 28, 2017 20:13

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

HardDiskD posted:

Man, this so well-written.

Unlike your post!

Just playin'. I also thought it was well written, but oddly I also thought it was twice as long as it needed to be.

# ? May 28, 2017 21:29

Nippashish: Nov 2, 2005; Let me see you dance!

I would have enjoyed reading a post-mortem report instead of a human focused narrative, personally.

# ? May 28, 2017 21:32

Adbot: ADBOT LOVES YOU

# ? May 28, 2024 14:37

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Nippashish posted:

I would have enjoyed reading a post-mortem report instead of a human focused narrative, personally.

Exactly my thought.

# ? May 28, 2017 21:33

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »