There was a great story back in 2019 where an American security researcher bought the vanity licence plate "NULL" in California, presumably hoping that it would make his car invisible to the DMV so he could speed and park indiscriminately without consequence. Instead he got hit with $12,000 of fines from other people whose licence plates were not recorded at the time of the offence so were stored as NULL instead.
@@dannydandaniel8040 it was in many online news outlets. The guy told his story at a hacker conference in 2019 but his troubles had been going on for 3 years. Now I've read into it a bit more, apparently the main reason he got it was to try have matching family plates of NULL and VOID.
I'm surprised those tags weren't reserved in the entry system, just like plates with three digits or less are reserved for gov't vehicles, etc. And ditto with tags that could be blatantly offensive and tend to be blocked from use.
Remember Reagan's "Star Wars" (aka "Strategic Defense Initiative") proposal? Just write a program that ensures that all nuclear missiles will be intercepted in a timely fashion -- easy peasy! And then we will be able to nuke Russia with impunity!
In 1983 the Soviets had an estimated 2,490 ICBM launchers and five times as many warheads, not *4*. The claim that they only had four working missiles is from 1961. It also wasn't Petrov's decision to launch anything, he was only the officer of the day at at a western command centre (Serpukhov-15) for the Oko early warning system. He would have to give confirmation to the reports being produced by the instruments, and that is what he refused to do after corroborating the information with other sources. His superior, General-Colonel Votintsev, later arrived and backed up his decision that it was a false alarm when reporting to the head of the Air Defence Forces and the Ministry of Defence. Many cool heads prevailed in preventing catastrophe, not just Petrov's. They had their own internal computer network that was only a few years younger than ARPANET, built on pirated copies of IBM designs like the S/360 and 370, which is all the more impressive since theirs were built out of just "rocks and elastic bands". It might deeply disturb you to learn they also had a home computer market in the 80s. Very silly way to end an otherwise interesting and entertaining lecture.
Yep, and Pentiums were not first to include coprocessor, 486DXes had 487 integrated. Pentiums were superscalar/could do 2 instructions in parallel as opposed to 486.
@@firstname4337 check the number of small&middle range rockets dismantled as result of Perestroika(tm) under supervision of the US - and review you thoughts about scale of a (possible) nuclear apocalypse. IMHO it is a way to serious to keep joking about it.
Lucky you -- I've been in it for nearly 30 years, and I'm 4m30s in and seriously considering stopping because it's too painfully familiar/familiarly painful. 🤣
Back in 1985 our computer centre invested £1m in a new mainframe, however, they didn't invest £40k in a new roof which leaked. The new mainframe had to be removed and dried out!
Consistently one of the most entertaining and quietly funny speakers on programming I've come across. I've fallen asleep at many conferences (in an unrelated field), but would love to see a talk by Mark one day as I would be confident of not only staying awake, but enjoying a little chuckle every now and then.
It was a huge mistake for Microsoft to choose ' ' as the line ending sequence. They could have just stuck with ' ' that Unix used, and saved so much grief for text file compatibility. (And Apple chose ' ' for whatever silly reason.)
They gotta be different! Personally, I think M$ has the most technically correct format. If you look at where all text comes from - the typewriter - CR and LF are two, different, distinct functions. In _most_ cases, you want to perform both functions, but not 100% of the time!
@@jfbeam There were some old terminal that had the same distinction (not just the teletype), but for file format, using two characters for next line is simply stupid.
There are 2 main reasons I might use recursion: - In a language with immutability loops get pretty nasty, and immutability is pretty nice. - When you have good algebraic data types, structural recursion is really nice.
You need recursion if you merge multiple subsolutions. He means trivial recursion and forgets to mention it + yeah, he forgets that some languages don't have loops. Or you can drive your loop with an explicit stack, but why, when there is already one?? What is really cheap is how in the end he says tail call elimination is a goto. Like loops did not have a jump in them. Feels like trying desperately for a punchline.
Also graph traversal. People hate recursion because it's overused in leetcode interview questions, and because some people use it as a status symbol of being a 'Real Programmer' and force it everywhere. But it does have its uses. I think the reason it's considered hard is that there's no control flow structure for it. Consider that For-loops are so simple and yet we still made a control structure for it - I think recursion/dynamic programming could benefit from that.
Those languages normally do some recursion elimination (like tail recursion elimination) to spare you from the disadvantages of recursion, e. g. hitting stack limits or performance issues (caused by the increased stack usage)
The "Dog 38" problem is easily "solved" (well, kicked down the road) as long as the Kennel Club isn't so stuffy as to demand monotonically increasing numbers and accept a sparse numbering scheme (although, show dog folks often seem quite stuffy). There are 1308 roman numerals in the range [1..3999] that can be represented in six or less ASCII characters (things get weird at 4000 and above and would probably create _other_ problems). In fact, if one just skips #38, numbers up to and including 77 can be used. So, for the "short term", just put a post-it note on everyone's keyboard at the Kennel Club that says "Woof Woof, DON'T USE 38, Woof Woof" should work fine. Eventually the post-it notes will have to be expanded to add other forbidden numbers, but they probably will need replacing by then anyway (and banning just 60 numbers yields over 250 usable ones - I think I can fit the 60 banned numbers on a large post-it note). There, fixed that -- send my my consulting check (I'll make sure to cash it before "Fido 78" arrives for registration!)
They can just use a standard ascii numeral string and change nothing, eg "38" it's not like the machine is doing numeric operations on the roman numerals.(still limited to 999,999 so step up to hex FFF FFF for 16.8M)
That part about recursion seems either a gag for a cheap laugh, a lapse in communication, or intentional misrepresentation. It's combining Computer Science with Software Engineering in a way to completely miss the point. If you want to bash on recursion for being "just a goto", you'll need to do that for the loops as well. And all other control flow structures like ifs and switch cases. And calls are also just gotos with some added fluff you could do manually. But realistically, you don't say that ifs are bad because they are just gotos. Ifs are great because they are gotos that can't do whatever -- they are more restrictive. Same goes for loops and recursion. Loops and recursion both have their uses, but as Mark said, recursion gets praise in computer science, and it has a reason - some complex things are easier to represent with recursion. And that part about stack: Computer science, at the level I understand that term has no stack. It has no memory. It's math. Once the computer science problem has been solved using recursion, the developer is free to transform it into loops (CS has proven that this can always be done) or gotos or whatever needed by the the Software Engineering side of the problem solving. And no, Computer Science recursion will also never run forever. By definition a recursive function has a base case, which means it's over, and all other cases tend toward the base case.
Another (likely) causal factor of the Y2K bug was a general belief that software written well before the year 2000 wouldn't still be used by then. I remember writing software back in the 1980's that had code to handle dates past the year 2000, and being chided by a co-worker, who told me "nobody's going to still be running that program in the year 2000". I.e. he thought I should only use 2 digits for the year.
I remember getting a phone call from a company.. who was running some software 25 years after I wrote it. I had trouble even remembering the application.
Same here. I was writing commercial software in the mid '80s and they teased me for worrying about the century in dates. The very same people, I'd found, wouldn't even worry about leap years, so I just went along with my way of managing dates. The software I wrote wasn't sold anymore after I left in 1988, but its core was still used well after the year 2000 - basically, they had modified the UI part and left the operational part alone. One guy from that company started working at my new place a few years later and told me they had started to worry about the bug in 1999 and everybody was panicking until they simply tried to put a few future dates in and saw that it all worked.
The BIG problem with the Y2K bug was the number of archive files that had to be reformatted so that, if one of them had to be read by a corrected program for some reason, it could be processed correctly. One company wrote financial software so that the Y2K bug would be avoided: a loan company that was building an online database and online access/updating system in the early 1970s, which anticipated writing long term loans that would not be paid off until the 21st century. They used a 16-bit unsigned integer (which requires a few extra instructions in S/360 Assembler, since a 2-byte binary field is normally 15-bit signed in 2s-complement format) to represent days since a start-of-epoch date (which I have forgotten), and they converted from and to 8-digit yyyy/mm/dd for input-output. This also served well in computing APR, since the dates could just be subtracted.
As an aside, I find it interesting that for disasters like rockets exploding, they actually figured out what went wrong. That seems like something that could take a heroic effort.
@@1996Pinocchio-- There are copies of the flight code and they have telemetry from the flight vehicle. These days, a lot of that telemetry consists of information about the state of the guidance and control systems.
I remember reading about one incident (probably very early) in the Soviet space program that accidentally proved the round Earth (again). For one early launch, they initialized the gyroscope in the inertial guidance to point straight up as the reference direction during the first part of the countdown, then when an error was detected, they put the countdown on hold. It took a few hours to fix the problem, and they resumed the countdown WITHOUT reinitializing the gyroscope, since the rocket hadn’t moved, right? WRONG! The rocket had moved with the Earth’s rotation, or about 45 degrees in 3 hours! The guidance system detected this as a deviation from the course and triggered self-destruct. Since then, EVERY rocket scientist has written into the checklist for launch that, if a launch hold lasts more than a specified time, the gyro must be reinitialized before resuming.
@@allanrichardson1468 Ah, but that was not a bug, that was a test of the guidance system's automated self destruct subroutine! Or, at least, that's what the official report up the food chain would have said, I'm sure. I've heard a couple of translations of Soviet official documents trying to normalize things they couldn't properly explain. The best I've come across is one on some hikers who died while out on a hike (known as the Dyatlov Pass incident). The coroner was unable to determine the cause of death and thus reported something along the lines of that they had "encountered a force which they were unable to overcome." Which, yes, the avalanche that almost certainly did it can indeed be described that way. (There's been a number of more ...creative... interpretations of the events over the years, many of which could make a decent short story.)
I had to build a driver for a 'chain printer'. A chain printer has this long chain with a bunch of glyphs on them and it spins along this inked pad and these hammers slam down on the glyph when the glyph flies by the spot it needs to be placed. Awesome! High speed printing that can spit out characters as fast as the glyph can go by and the paper can go down. The problem? We had chains that were *exploding* out of the printers. Why? Turns out that people wanted 'demo' pages which would have all these glyphs on the page so they could show off how fast they could print a full page. Some bright person figured out that they could line up the glyphs in the order they were on the chain and so *all* the hammers would come down at once right as the chain came along and came into alignment. The fix was to limit the number of glyphs that could be hit at once. The noise was amazing.
We had two of those in the bank I worked for end of the eighties. Really amazing speed! The printer were in some noise-cancelling "boxes" so the noise was ok - as long as the lid was closed.
My worst mistake involved a loop without an exit back in the 90s. Unfortunately, that loop wrote a file to a drive. So I filled up an entire HDD in a split second...
I was working at Oak Ridge National Laboratory (ORNL) when it was run by Lockheed Martin Energy Systems, as were the other two plants at Oak Ridge TN, i.e., the Y-12 nuclear weapons plant and the K-25 gaseous diffusion plant. I was assigned to a team consisting of representatives from all three plants that was developing a Software Development Methodology to be used at all three plants. We were receiving comments from the Lockheed software group in Denver that was working on the MARS Climate Orbiter. They were regaling us with how good and error-free their code development was because they performed line by line code review and criticizing our work because we hadn't called for such review. After the orbiter crashed we never had another comment from the Denver group!
PIC 9(6) in COBOL does not mean 6 bits. It means a 6 decimal digit numeric field or variable. It can’t have decimal points or minus signs. These are specified separately.
Not from the COBOL era but I have quite recently learned COBOL for fun and interest and can confirm this. Variables are declared with something called picture clause (like it is a visualisation or picture of the variable in memory) and the number in paranthesis is the number of digits. In any case less digits specified = less memory allocated. Do this with dates and voilla, the Y2k bug is born!
PIC 9(6) ----- 123456 okay for math PIC 9(4)V99 ----- 1234.56 but internally 123456 -- period assumed. works as 1234.56 for math PIC S9(6) --- allows negative numbers. okay for math.
The most difficult bug I ever found was on an LSI-11 Unix System VII using the Portable C Compiler. I tried everything and my code just would not work. Finally, I told the compiler to excrete the assembly code version of my program. Then I finally found the bug! The compiler was allocating 9 registers for a processor which only had 8 registers. I could then rewrite my program so that the compiler would only allocate 8 registers.
You might expect that compiler errors are not that common nowadays, but a 6 line function had an optimisation issue and was returning 65534 instead of 0. I caught it in the TLS tests of the device.
@@metala I do expect compiler errors to be common. State-of-the-art in parsing stopped in 1972 because most coders were not able to comprehend the new advances. When I worked at Texas Idiots (TI), they had decided the corporate language would be Pascal and had their people create Texas Instruments Pascal (TIP). I tested it and it called the wrong subroutines. I found a copy of Pascal 8000, bought it with my own money from The Atomic Energy Commission of Australia, and ported it to the TI mainframe cluster. Ten years after TI fired all of us, Pascal 8000 was being used by all engineers.
When talking about dates and Cobol, it's worth mentioning that that was in the 1950s and 60s, So it was quite natural to use just the digits for a date. After all, the previous century change was prior to WWI and the next one would be after you retired.
@@I_Don_t_want_a_handle I was filling out a new and recent government form, and it used two digits for the year ... after all, three digits are so 78 years in the future
Some issues with COBOL definitions here: PIC 9(6) is shorthand for PIC 999999 - i.e. 6 numeric digits. Nothing to do with 6 bits. Not used for "hyphen, comma and dot" either - that formatting would only be applied when moving to a print field.
I noticed that. PIC 9(6) is six BYTES, not six BITS. When you start getting into COMP and COMP-3 and all the various other definition types, you can save memory. But in anything that was textual like inputting from a punched card or transaction system, it was going to be a six-byte date. I started programming in 1987 and worked in COBOL for 17 years before swapping to QA full-time so I got to do a lot of Y2K remediation. At the time the bank I was contracted to was actually sending physical tapes of source code to India and back, every week, in order to do the remediation. 1999 hit different, yo.
I noticed that too, I only did a little Cobol at Uni. Other misleading statements early on put me off, Linux for example moved to 64bit __time64_t and developed compatibility library that fixed 32bit userspace. Support for 32bit is being dropped altogether by tool chains, but disk formats that have been changing gradually.
@@largemocha On all the systems I worked on, that would be USAGE COMP-3. So if you had, say, PIC S9(6) COMP-3 and (let's say on an IBM) it contained 091622, it would be stored in four bytes as 00 91 62 2C, with the "C" in the last four bits being the sign. ("C" for positive, "D" for negative, if I remember right.) If it was a 9(6) I think IBMs still reserved that right four bits for a sign, I can't remember 100% sure, they may not have.
@@Moose6340 I haven't looked at COBOL code since the early 90's. Even then, I hardly touched it, so I'm almost certainly forgetting some bits. Point being that there is a lot of misunderstanding about COBOL and "young folks" are inclined to mock it, when it was actually really advanced at the time it was launched. I wonder how many "modern" languages will have its longevity.
I had a highly egotistical boss who was NEVER wrong. And I watched as he reduced 2 programmers to quivering tears. The issue - the companies flagship program calculations was off by 1c. No explanation could be found. No code differences, nor data. Yet unbox a program and run it and you get 2.98, however unbox another in the same shelf and you get 2.99. I actually tracked it down to the fact that one development computer uses V1.1 of a popular compiler, and the other used V1.2!!! And there was a difference in the floating pount rounding routine between the two versions. Boss then screamed at the programmers for not realising these differences, abd I got myself fired for screaming at the Boss that " He was a F@cking cheapscake for never keeping the compilers up to date"
Floating point for money is bad - or more general: floating point is bad if you need a predefined precision. I'm always surprised and shocked how many developers don't know this.
You complain about Cobol, but it works VERY well for currency calculations. Does not use floating point, older compilers don't even support it. Multiplying 123.45 by 2 actually multiplies 12345 by 2, than puts decimal back in where it belongs.
Worst boss I had - old bureaucrat back at university - yelled at me because when I added a CSRF token to a web form, I made it pick the variable name randomly from a list of names, so it would be called "joe" or "mike", and his argument actually was "what if people look at the source code and think we're not serious?"...
In the early 1970s when mainframes started issuing electricity bills, some customers were furious when demands arrived to pay -£0.00 or else be prosecuted. It was a software glitch where £0.00 could have either a positive or a negative sign, and if negative then supposedly the customer had not cleared their bill... 😊
I had a similar issue decades long past when NCSU took over the phone services for all the dorms. I had a bill of $0.00 that they insisted I pay; threatening to turn off my phone, forward to collections, notify ACS to withhold my diploma, etc. I should've framed that check when I got it back from the bank. (banks used to send you all your processed checks.) The lady at the counter didn't even blink - who knows how many thousands of those bullshit bills they sent out.
One pretty major mistake I found when investigating someone else's code was a for-loop (C/C++) that was, IIRC, some kind of memory copying loop. The termination clause for that loop was that the loop variable became negative. Too bad the loop variable had been declared as an UNSIGNED integer...
The Mars Climate Orbiter had a mismatch between units but it was NOT distance in inches vs centimeters, it was impulse measured in pound seconds vs newton seconds
21:30 *AKTUWALLY,* the 486 was the first Intel CPU with a built-in FPU. A version with the FPU *disabled* was indeed available, but the 80487 "add-on FPU" was literally a full-blown 486 in an incompatible package that would only fit into certain motherboards that came with an 80486SX soldered down to them; when plugged in, the 80487 would simply lock the 486SX out by shorting out an enable signal, and take over the data bus forthwith. The Pentium was the first *superscalar* CPU from Intel, meaning that it could handle more than one instruction per cycle, and it did have a *higher performance* FPU than the 486 did.
The thing about the FDIV bug... Intel _knew_ it was broken before it ever went into production, but it would've taken time to correct, so they went ahead with it _after concluding no one would ever notice._ Boy were they ever wrong. (As I recall, it was discovered within days in scientific calculations. I've run into qualification errors like this with compiler errors!)
@@jeremypnet yep, would make sense if failed be rebadged as SX just like today the industry still dose these things just like Clive Sinclair ZX Spectrum using memory we’re the upper half wasn’t used because it was defective so got them cheap
@@sundhaug92 Makes sense. When dies are produced you always have a certain percentage of faulty ones. So you produce 486DX. If all is ok you sell them as DX, if something is wrong in the FPU part you sell them as SX, if something is wrong in the CPU part you sell them as FPU and only if both parts are messed up you have to throw it away. As the percentage of errors doesn't match with market demands you also take fully working DX and disable one part and sell it as SX or 487. (That's at least what I remember as explanation)
Early in my career I was asked to implement a kernel watchdog timer as a workaround for another kernel module that would hang the system. Because I disagreed with the concept of such a hackish workaround, I labelled the feature the Basic Automatic Rebooting Facility (figure out the acronym yourself). I was planning on renaming the module before it shipped, but as luck would happen the root cause of the bug was found so my feature was not needed. Then by mistake my code made it into a production build and shipped anyhow (in incomplete form, so it caused regular reboots to happen). So customer support was having to tell clients to list kernel modules and look for one called BARF. Not quite as bad as a name with f*ck in it but did teach me the lesson of being careful with names.
While working on an instructor station for a full flight simulator, I discovered, while working on lates, that one of the other teams had failed to correct a bug with one of the simulated malfunctions, again! So I modified one of the many buttons on one of the many pages of simulated faults so that when pressed it displayed a box containing the message "This fucking fault still doesn't work". The next day, there was an unscheduled visit by the customer (JAL) who were given a demo of the work in progress on their latest £10m simulator, and which fault do you think the guy doing the demo selected to show them?
About the tail call thing: By that metric loops are also just gotos. However, it should be noted that recursion is definitely more goto-alike, though not in the way it was explained here - you can jump to OTHER functions with that optimisation; at least in most compiled languages [provided there's no destructors running *after* the call or anything of the sort; and that the optimiser recognises it, LLVM & GCC based ones definitely do], dunno if that applies to .NET as well. That said, it's much safer than just a single goto and much easier to reason about, *as long as* you have functions that are small enough. Because then, using tail calls, it's essentially saying "I can reduce the problem I'm trying to solve into *this* simpler problem"; which is quite nice not only for proving things mathematically but also for reasoning about it; especially where the equivalent loop has to deal with mutable state & such where the tail call version might not, because you don't have many small state transitions every time you change something in any variable, but one *BIG* state transition once you hit the tail call, instead, that lets you reason about the state as a whole much more easily in my experience. It's the same thing that can be generally said about side effects, just in a slightly different context, imho.
loops are just well defined goto's which stop you doing all the fun stuff with gotos. I had some fun trying to adjust some old MASM (on dos) to read from a different phone switch serial output than the one it had been designed for. Some of those "functions" had multiple entry points a couple of which inside the main loop and multiple exit points one of which was inside the loop, but got used after the main loop had ended BY JUMPING BACK INTO THE LOOP. Very little documentation, which said what it should do. Hours of fun....
@@MrMeltdown tail recursive gotos are also more restricted through their argument list - which means that it's not really comparable to jumping into the middle of a function, since the "equivalent" tail recursive stuff would still enumerate all the "state" you're dealing with (especially because tail recursive functions should ideally be side effect free, too!), making it equivalent to reasoning about tail recursive functions in general.
The code gets a definitive memory location on load. Unless you're running some kind of hybrid self-modifying code stored in the heap you can't really remove the code from memory until the executable gets unloaded. For this reason it doesn't really matter if you run any destructors; the code remains. The only thing that you need to keep in mind is that the code might expect some other memory to be viable.
@@Kenjuudo I honestly don't know what exactly you're trying to say - but based on what I think you're trying to assert, which is that destructors don't stand in the way of TCO, I have to say that they definitely *do* stop TCO unless the language is garbage collected (in which case the garbage collector takes care of it either way) or the compiler is allowed to call destructors early - which in for example Rust or C++ is iirc not the case, since destructors are used *for their side effects sometimes*! And there would be reordering needed, since the destructor can only run after the function call (`return f();` is equivalent to `x = f(); return x;` in most languages - so the destructors running before `f` would be different behaviour) if the current function gets control flow back, which makes TCO impossible.
In 2007, Los Angeles Unified School District went to ERP software. The payroll was a disaster. Thousands of teachers were overpaid, underpaid, or didn't receive a check. When something went wrong, the teachers had to go in person to an HR office, which were open during regular school hours. That meant the teacher had to arrange for substitutes while they dealt with HR. The problem went on for months.
Or the teacher could bring the whole class along to observe the interaction with HR as a life lesson. If enough teachers did that, the problem would have been fixed much faster!
The Mars Climate Orbiter case wasn't as simple or "stupid" as you make it out to be. It wasn't that Lockheed-Martin stubbornly clung to Imperial units. They knew better. By the time of the Mars Climate Orbiter project, they along with most other aerospace firms had long been using the metric standard. The problem was that their code incorporated some older code modules from much earlier space missions, back from the days before metric had become the norm. As you surely know, it's usually better to re-use proven code than to write complex functions from scratch each time and hope you get all of it right again. Lockheed-Martin was well aware that the old code used formulas based on Imperial units, and painstakingly updated them all to metric calculations. Unfortunately they simply missed one. Having to update the units in the old code was a known risk, of course, but so was trying to write entirely new code to handle complex real-time navigational controllers. As for Americans being "stupid" for using Imperial units, that's not so simple either. It's not like chose to adopt the Imperial system of units when offered a choice between the Imperial system and the metric system with no prior history. The problem is that America (like much of the world) had long used Imperial units, *and* by the time the metric system came along America had a vast amount of technology, tools, and machinery already committed to specifications in Imperial units. Even the international aerospace industries around the world were locked into Imperial units for a long time after their respective countries "went metric" due to the inertia of (at the time) America's outsized contributions to the aerospace industry. It takes a long time to phase out the old and come up to speed on the new.
Great rebuttle, and I too cringed when he called Americans "stupid". But he's British, so it's kinda ok - but don't wear it out. But we can sometimes be imbecilic, e.g., Trump. But it was kind of a dumb mistake, but given miles of code, almost unavoidable. Bugs bite, and when they bite, it's usually at the most inopportune time.
American's could of had the metric system back in 1793 if it wasn't for pirates stealing the measurements from the boat carrying it. They've also had plenty of time after that to change however the main issue is people in power not wanting to spend the money to save lots more money.
@@lordtraust That sounds like a lot of nonsense. I am sure they had more than one ship. Even England was on the Imperial System then, after all it is the "Imperial" system. Rather than corporate greed, "people in power", or any other conspiracy type deal, it was most likely cultural inertia, then and now which resist the change, which you gotta admit, involves a great deal of adjustment and change, even though we have technically been on the "metric" system for decades. Much, if not most of my tools are standard, though changing fast, and we still measure in ounces, cups and tablespoons.
I'm constantly seeing people on the Internet claiming that Y2K was a big hoax. In 1999 I spent weeks fixing 1970s code that had the year in *two* formats. One was two character bytes and the other was a byte that was supposed to work past 2000 but instead crashed everything whenever it went over ninety nine mainly because no code expected that to ever happen. The weirdest thing was that we told our clients that our software would crash on January 1st and they needed the latest versions of everything yet a few refused to update anything. They seemed certain that we were lying about it as if it had been some kind of trick to sell them something.
Making the unix timestamp unsigned 32 bit, actually shifted it to the year 2106... so developers can be like "I'll be retired by then.. so: not my problem anymore".
The problem with the Y2K fixes is that many of the companies did not truly FIX the problem by having 4-digit years, they just put patches in place that said that if a 2-digit year was below some value, then it was in the 1900s, otherwise it was in the 2000s... The problem is that this window of times varied by the program... Even worse is that on Windoze, the 3rd party DLLs might use different sliding windows... We went from having a known problem date to having an unknown number of future problem dates... I wrote some code in 'C' back in the late 1990s that is still being using by the company today without any changes... There were certain portions that had 'time_t' variables, so they are going to be 32-bit integers for the time and will have the 2038 problem... I knew about it and documented the code to reflect it, but there was no way that I thought that the code would still be running in 40 years... It's still running after around 25 years, so "never say never"... There's a CHANCE that I might still be alive in 2038 to see how it turns out, but statistically, it's unlikely... I'm an old fart -- when I first started programming, we were using FORTRAN and punch cards...
Hey, I'm no programmer. But one of the most powerful tools in aerodynamics is Dr. Richard Epplers FORTRAN code for inverse-airfoil design. It is ridiculously useful, but also extremely unintuitive. And NOBODY has ever made a better program to design airfoils from thin air. Love it. Still not hard to get it to work on Windows 10.
The Ariane 5 explanation is wrong. Trying to convert the 64 bit fp value to a 16 bit integer caused a hardware exception. The nozzle deflection was caused by the on board computer interpreting the resulting diagnostic bit pattern as flight data.
Algol W was devised by Niklaus Wirth (hence the "W"), not by Tony Hoare. I was studying computer science, and in particular, the Algol language family, under the tutelage of Professor-Dr. Peter R King, at that time.
I'm only 5mins in here, I have a feeling I will have more comments.... I also shipped an "Undo New File Usage Change Kernel" (yup, that is what I called it), it was basically a boot option to revert some files on a windows installation in the other partition to a previously known good state. My UNFUCK lived in a rescue partition (the Advanced Rescue System Environment) alongside an option to access the Command Line Interface Terminal (basically a DOS prompt). The joke was obvious, but it never played out quite as well as that one time I was walking through the call centre and heard a support guy say to a customer "Okay, it looks like we can rescue your system, we just need to go into ARSE and stimulate the CLIT."
Error! The 80486DX did have a floating-point unit (FPU) built in. It was the 80486SX, introduced after the 80486DX, that had a disabled (defective) FPU, and a 80487SX FPU co-processor was then offered for extra money. Apparently, the early batches of 80486DX's had enough chips with defective FPU that this made economic sense.
I can remember working on the SITA global network who backed up their leased lines with a piece of equipment manufactured by a German company Controlware. I once received an error message saying "the system is fucked". The error messages often used words like "buggered" and "screwed"!
17:45 OMG, I know this kind of madness. In the end you get PPT Slides which document detailed contents of a Patch, line by line. And someone else has to write it down and test it again... instead of just receiving a Pull Request.
The 486DX had an FPU. It was the cheaper 486SX that didn't have a usable one. (It was on the die, just disabled.) It was only the SX that required the 487 coprocessor if you wanted efficient floating point computations. Which makes the Pentium bug a little more puzzling, because Intel did know how to do this right.
The document.all stuff is deliberate because there's code out there checking for document.all to detect IE which rightfully assumes IE will be IE(and by that I mean outdated, buggy, and barely pay lip service to any nice features). IE7 changed the behaviour of testing it's type specifically to stop people detecting IE in that way because, even though it was still a 5 years behind browser, it was no longer a 10 years behind the standards browser and they stupidly thought it was the right move to pretend compatibility.
Hmmm.... I do not think that the Ariane failure is correctly explained. As I remember it was even more insane: there was an inertial reference system that was useful only before lift-off and just continued to run after lift-off without any purpose. It was re-used from Ariane IV but not useful in actual inertial calculations for Ariane V after lift-off. They just used it for the start preparation phase. I think they kept it running after lift-off because it was originally designed to do so for Ariane IV and they wanted to mitigate risks by not shut it off or changing the code. Then the floating point error occurred because Ariane V had higher acceleration than Ariane IV and caused an exception. Which caused the perfectly running primary physical inertial system to shut-off. Then the redundancy system took over, ran into the same error and also shut off. This caused the rocket to lose trajectory and self-destruction system activated. I studied aeronautical engineering at that time and was keen about to know what happened.
Very nice talk and examples. About 'arrogance' at the end , I would like to know if anyone here shares this view of mine: "If you think you can write 5 lines of code without bug : you are definitely arrogant". Usually test code should be as long as code.
20:30 That reminds me of my first professional experience... fresh out of school, hired by a big company who do so love their processes. I had (temporarily) been put to work on a POTENTIAL security upgrade to a legacy embedded system... mainly, it was updating OpenSSL to support TLS1.2, but there were also some X.509 shenanigans. Since I wasn't doing anything else, I started working on it. Took me about two weeks, including learning how the damn thing worked, and testing. By the whole thing was DONE and WORKING, my bosses were STILL having meeting to assess the risks and the costs associated with developing the feature... Ultimately and a few months later, they went to the client and told them it'd cost them about 100k to develop the feature... Client said "no because it's too expensive". Project, upgrade and all of my work got canned. And of course, my own pay wouldn't have even made a *dent* in that 100k bill in the first place... it was all useless overhead. Wonder how much those meeting costs?...
I believe the key lesson in this video is that there must, with any non-trivial system, ALWAYS be a human in ultimate control with the power to say "Hold on...... , We must do this instead". And it MUST be a very skilled, wise & experienced person. Unfortunately, such people are expensive and beancounters can't understand that in the long run this is likely to be the cheaper option.
Recursion is good as a way to reason about program flow, although if it *looks* like something that could be converted to iteration, it *should* be IMO; also, ordinary loops are implemented using the goto-like instructions (a.k.a. jumps), the same way tail-call elimination for recursion is. The true reason that []==![] is true in JS is, in essence, that the abstract equality comparison tries to convert operands of different types to numeric values (after a special case in which null and the undefined value are abstractly equal to themselves and each other and no other values, except that the DOM, because of an old IE compatibility hack, also makes document.all abstractly equal to them): First, to evaluate ![], the empty array, which is an object, is coerced to boolean, which is true because the empty array is not one of the seven values that evaluate to false in a boolean context (false, null, undefined, '', NaN, 0, and -0), and then the logical not converts true to false; next, the ToPrimitive operation converts the empty array to 0 and also converts false to 0, and those two values are equal, so [] and false are abstractly equal. More generally, it was a huge mistake that JS operations result in unexpected type-coercions rather than errors; the language didn't even have exceptions until ES3; other smaller issues like the bug in the original typeof operator that made it output 'object' instead of 'null' for null could not be fixed, for the reason you stated.
SAFE: There is a daily status meeting, there is a three week time increment called a "sprint" but planning is done in "program increments" (name varies over time) of ten weeks which is the real planning horizon. And on top of this there is a project with a fixed end date and fixed content that runs for years...
And when the project invariably gets delayed, there will be over time (for everyone, regardless if they work on that project or not) and another daily status meeting. Now, I actually do not mind the last nope, because they reinvented the "pulse room", where every team in the project and any stake holders (chicken I believe is the correct technical term) can check the status without bothering the teams.
recursion is a very elegant way of processing certain data structures and no your loop explanation doest have the same effect as the recursive code. Its different, and dont blame your tools if you code a bug into it. Which is just as likely in a loop as it is using recursion.
On Oct 5, 1960, BMEWS (Ballistic Missile Early Warning System) (big honkin' radar) in Thule, Greenland "detected" a massive launch that turned out to be the rising Moon.
In some languages, like Prolog you can only do recursion, and you get used to it, and it becomes no big deal for most. However I have met a student who said she just could not wrap her head around it. She committed suicide shortly after, I don't know if there was a cause and effect phenomenon.
Many of these errors were due to NOT (edited) properly defining the problem, developing, and reviewing the specifications before handing them off to programmers. I've bailed out a half-dozen programming projects in every case; the programmers didn't understand what needed to be done. Often no one involved was any better informed, and I had to figure out the solution. Most weren't too difficult, but one took the better part of three years and a Ph.D. level knowledge of hydrology. At least I didn't have to pay tuition, take tests, take any elective courses, pay any fees, or write a thesis. I only set in on courses I needed. There is far too little planning and design before the first line of code is written or the first piece of hardware is purchased or designed. Too often, the folks in marketing drive these decisions with little or no input from hardware and software engineers. Building things that work on time and within budget is really important. The way most outfits do it guarantees that never happens. Weekly code reviews help as well.
I agree that most efficient line of code is one you don't need to write at all (and least buggy and least need to test and so on). And that is why pre-planning things is so important. I've seen projects go ass-backwards starting from entirely wrong end of things even after being told it isn't going to work. Well, some time and resources later things improved, but still some warnings were being ignored ("this is going to become a problem later" and nothing happens to it). And yes, you are right about marketing: some people work on commission and then other people who need to implement what they've sold and need to handle the fallout. Often times software people are asked to join in discussing when deadline is already nearly there and it can't be pushed around any longer so there's not much resources and not much money to implement what they've sold. And fixed-cost contracts are the worst since everything is shaved down to a bare minimum and all the rest is extra work on a different contract and having to fix issues made by people before on different contracts are just going to balloon the costs again.
Did you mean "Many of these errors were due to NOT properly defining the problem, developing, and reviewing the specifications before handing them off to programmers. "? We would a proper specification be a problem.
@@IlkkaPrusi We write way too much code for most projects. code libraries, style, and weekly code reviews need to be done. Weekly meeting to go over problems work.
" _There is far too little planning and design before the first line of code is written_ " -- Or, similarly, sometimes the upfront design work is done with little or no thought given to concrete implementation details (e.g. "how can we change our pre-existing db schema to support this new feature?" or "which pieces of db data do we need to have available to use as input, and are they even present in the db at all?"), and then the resulting bad design document becomes *set in stone* before the programmers have read it.
Can relate to the first story. Back in the days when software was still shipped on floppy disk in a letter, some boss though it would save us work if customers had access to the (dangerous!) patch/fix software. In fact, it was so dangerous that it was password protected so you couldn't use it accidentally, or without prior lecturing by someone who knew the password. Since it was internal use only, and only for very tech-savvy persons, the password was strongly protected against accidental leakage. It was a word, or rather a phrase, which no one would write on a whiteboard, or use in communication with a customer or superior. So one day I got a call from the front desk. A customer had a question about the patch/fix software. I was, like, wtf, the customer is not even supposed to know of this software, let alone get his hands on it! And, besides, it's password protected, so they won't be able to use it anyway. The secretary told me that the password had been included in the envelope, which I clearly didn't believe. She showed me the letter. Right in the middle of the letter, in *large* friendly letters, was the, uh, decidedly unfriendly password. Apparently, the boss had demanded the password from someone, who had written it down on a slip of paper (because you don't say such a thing to your boss) and the boss had given the password the the typist. That was in Germany, and the German typist apparently lacked enough knowledge about the English language to figure out what the combination of letters meant. So I had to call the customer, who asked what the password was. "Yes, we've received a letter....but instead of the password, was just an expletive...". I was able to convince the customer that the phrase (which was similar to "help yourself", but with an "f"-word instead of an "h"-word) was indeed the super-secure password and that they should not, under no circumstances, use that software, and "And as I know that you won't listen, make a backup of your data first! Otherwise, you might experience a situation which is...sort of similar to what the password means". Situation was contained, I wasn't fired and the boss got a bit smarter. Okay. I lied about the boss getting smarter. We just got secretive about our internal tools.
1:15 "Before I start, CW: there is going to be swearing. I am going to say f**k, quite a lot, just in the next segment. But it is relevant to the plot and...so that is justified." This sounds like a scriptwriter pitching #DoomPatrol screenplay to management of @dcentertainment
What I remember from the Knight Capital case: The software processed messages. In the new version of the software they used an already existing attribute, which wasn't used in years (who wants to change a structure, when you have unused things to abuse...) - and they had a flag to control the behaviour (like "ignore_attribut_x"). So they deployed the software and set the flag to activate the usage of the message attribute. As Mark said, the deployment was fine on seven servers but not on the eighth. So the eighth was starting to run the old behaviour. They realized something was wrong, but they didn't realize the true nature of the problem, so they just wanted to undo the deployment, but didn't have a proper rollback implemented. So, as mentioned by Mark, they copied the old version to the other seven servers, but forgot about the flag, so all eight servers ran the unwanted, old code...
@@brdrnda3805 Yes, 40 years of programming has left me no understanding of it at all. I also never heard of any of these stories. So It's a good thing you're here to fill in the major gaps. genZ freak
@@brdrnda3805 Yes i was talking about that story also. You see genZ buffoon, it's also fine to call them stories. I understand you're some kind of nitpick over everything genZ freak. Clearly you're so fail in life this is all you can do to make yourself feel worth anything. Let me talk to you like a child so you too can grasp a consept. When you hear a story even if it's about a fact, it is fine to refer to that as a story you heard.. Take it slow read it a few times. You can do this little man!
You can write a sort routine without recursion, but for many algorithms you'll need to implement your own stack which will no doubt be slower than the system stack.
I like this guy's humour, but he got some stuff a bit wrong, so here, for posterity: Heartbleed wasn't a bedroom coder's unseen mistake, and it wasn't OpenSSL developers' mistake. It was introduced by a Debian maintainer to Debian's build of OpenSSL, because they wanted Valgrind (a tool for checking memory safety) to shut up about a particular line of code. They removed that line, and OpenSSL appeared to still work, so they shipped it, but it turns out it was working with orders of magnitude lower entropy in its encryption key generation mechanism (= orders of magnitude more hackable), and it took 2 years to discover. And the xkcd comic wasn't about OpenSSL, it was about libcurl :)
The 486 (the DX version) had a floating point unit integrated. There was another version (486SX) without the FP unit, for those who did not nead the FP boost. The last processor commenly sold alongside a dedicated floating point coprocessor was the 386.
@@Ice_Karma I believe the 487SX was actually a 486DX with the main processor part disabled, sold at a lower price. Anyway, I never knew anyone getting it, everyone I knew that needed the FP capability would get the DX right away.
@@haakoflo Nope, the 487SX was a full 486DX. The 486SX could actually be removed entirely after the installation of the 487SX, although this was uncommon because the 486SX was not usually mounted in a ZIF socket.
I always considered a "bug" to be more like a typo - an actual error made by the programmer. Failure to correctly anticipate and code for a specific situation or circumstance isn't a software bug, but you can call it a design flaw. Y2K was a bad design flaw. Programmers are not responsible for the vast majority of these mistakes - it's usually the BA's fault ;-)
Bugs can appear at any stage in a project. The more time between introduction and eradication, the harder they are to fix. Y2K was a methodology bug perpetuated into the designs of many software projects. It was created by software engineers to cope with inadequate hardware, then pushed onto following generations of students that then put it into the specifications of their software projects. It took the looming crisis to get it fixed. A programmer is woken up after being cryogenically preserved. Upon awakening he asks if there is a cure for his cancer. No was the response. We have succeeded in preventing cancer, but it is the year 9999 and we understand you are a COBOL programmer.
I had a bug once that was so useful that it became a feature. This was on an old PDP-11 and later VAX-11 program that used VT-100 terminals to enter data in a formatted screen. You could use arrow keys to move back and forth between entry fields on the screen. For some reason I have completely forgotten by now, there was a character you could press that would take it automatically to the next screen. I didn't design it that way at all and was swore that the program couldn't do that when a user asked about it because it wasn't mentioned in the documentation. It turned out that he didn't want me to fix the bug -- he wanted me to document it so that they could officially use it.
Most added code to assume - for appointments or any date assumed to be in future - that a year less than 80 was after 1999. Birthdays and other dates in past needed the 8 digit year, sorry.
@@russellstyles5381 On the VAX, Digital Equipment Corporation, DEC, counted in the number of 100 nanosecond intervals since 17--Nov-1958 and stored it in 63 bits.
Matt Parker (the guy behind stand up maths) wrote an entire book called Humble Pi about similar things like the dog38 issue, a comedy of maths and computer number errors and cock ups and it's fantastic!
In which he debunks that tired old story about the mars climate orbiter. It wasnt because we used inches. By then NASA used metric through and through and demanded all length and weight measurements from contractors did the same. It was from pound-feet not being converted into Newton-meters. Those who continue to assert 'hur dur inches' are only displaying their ignorance.
FWIW the original 486 DID have a floating point unit built in, which led to another fabulous floating point bug. Due to market demand for a cut down version Intel came up with the 486SX which either didn't have a FPU or had a nonfunctional one. The "487" was basically a complete 486 with a slight pin-out change so fitting it would disable the existing CPU. Unfortunately... By this time software had been released making the assumption that a 486 would always have a FPU, so when it was run on a 486sx all floating point operations returned zero.
I remember that old chestnut, and being an ex-486SX2-50Mhz owner I remember all too fondly being critically appraised for always preferring addition and subtraction in BCD rather than actual floating point.
@@jonbondMPG Its good to read that someone else at least gets the point of BCD. Since just about every library has int to string and string to int functions built in BCD seems to have been largely forgotten, even in embedded.
@@peterhelpme It was funny how the later model 486 could outperform the first generation Pentium. If I remember correctly the 486 had gone to 3.3V but the P. was still 5V CMOS and was quite a good fan heater.
@@oliverbroad4433 oh yes those first 60MHz Pentiums were brutal. I remember a co-worker having paid '$$$' for a laptop that burned you lap and killed its batter in under an hour of use.
Sorry mate, but it was the 486 that has the math co-processor included. They also had a version called 486SX that didn't include it (actually disabled), which required you to buy the 487SX
Core memory has three wires through each core, not two. You need three to do the addressing. But, yes, they were usually assembled by women who could do this skilled work fast.
From what I remember that third line is 'SENSE' it tells you (by a pulse coming from the core) if the polarization reversed, i.e. you had a 1 in the bit before clearing it through a destructive read, (IBM Early Computers 1986 Bash, Pugh). But yes agreed to wind those under microscope very daunting work. I was told by an old IBM field technician the 'gals' worked in 20 min sprints then had a coffee and cigarette to recover their wits before resuming the work.
You would be shocked how much of Healthcare runs on Javascript as a backend. Most integration engines use an ECMA script library backend for their programming language.
Definition: BRATWARE - Software created by kids who, unlike me, didn't have to worry about their coding errors starting World War III. In 1964, a civilian software engineer installed an octal patch to the SPACETRACK system running on a Philco 2000. Everything was in assembly language in those days and recompiling took inordinate amounts of time so octal patches were used to make quick fixes. SPACETRACK was running at NORAD HQ in Colorado Springs Colorado. The patch accidentally set off the "bomb alarms" at SAC HQ in Omaha Nebraska and caused SAC to scramble, i.e., all the bombers launched. It was a year before I got there as a new second lieutenant software engineer but the incident was still being talked about. It was said that a 3-star general from SAC visited NORAD HQ and was yelling "You mean to tell me a civilian scrambled SAC! I don't even have authority to scramble SAC!" Software used to be MUCH more exciting! Philco 2000: 256K of 48-bit words where software to track 1500 satellites was shoe-horned in exclusively using assembly language... It was fun! But we became VERY CAREFUL software engineers!
Well, I know nothing about a COBOL, but I've spent half-a-year or something rewriting PL code to consume 4-digit years instead of 2-digit ones. But this is not the point. The point is this speech is redefinition of a genre of stand-up comedy camouflaged as something scientific(-like)
There is also the Therac-25, although the bad software of that machine was allowed to act very poorly due to the absence of hardware interlocks. On previous machines, the faults were hidden by the presence of interlocks, that didn't allow any deadly condition to occur (say, the lack of a target to convert electrons to X-rays, when in high energy electron beam mode).
One of the restrictions of the talk was the bugs weren't supposed to directly harm anyone, because it's not funny when cancer patients are getting burnt to death by their radiation treatments
I'd call that more of a management error than a programming mistake. They should not have hired a hobby programmer to write control software for a machine which (literally) shoots death rays at persons.
Good stuff John @markrendle for bringing out the fun in programming. It's serious and I wish I could be just as half as good you are. All said, that inspires and encourages many in the wider community to consider and take up programming. Having done it in the past, I wish to retake the journey even as a hobby going forward, hoping my current age (40's) won't be an inhibiting factor. Kudos to @NDC Conferences for making such good things happen.
Mark presents it as fun, but believe, if you have to work with this kind of cr*p for years, you really, REALLY start to hate it. If you really care about code quality, doing enterprise code is a nightmare.
Who patched time_t with an extra bit? I only know Linux, which is not Unix, but only Unix-like, and that uses 64 bit (signed, I believe). You can compile 32bit programs using that 64bit time_t (similar for off_t), but it requires an extra compile flag for backwards compatibility reasons. For 64bit programs it's of course always 64bit.
Can’t change to unsigned because it’s the return value from some time conversion functions which return -1 as an error indication. And even better the conversion functions would accept negative values and produce correct dates before Jan 1, 1970. Until someone with no understanding of history “fixed” glibc so it wouldn’t accept negative values.
Turns out a certain version of the archive format cpio, which is used by rpm, uses 33 bits for some odd reason (11 octal digits). But 1) this is not Linux (the way this talk talks about things I assume Linux as just the kernel), 2) not every Linux distribution, only those that use rpm/cpio, are affected, and 3) it can be easily patched. Just use a new rpm version in a new version of Redhat/Fedora (maybe using a better, newer archive format). Can't install rpms of a newer release on an older release anyway.
As a 500k/year customer I'd be chuckling and buying you a beer WRT y2k, one of the less reported things that happened was most of the world's security systems not working on 9/9/99 In Feb 1998 (IIRC), a minor epochoalypse happened - people discovered that many systems were storing utime as a signed 32bit integer instead of unsigned and NTP implementations around the world broke (particularly in routers)
@@Pence128 No, you're wrong. I've seen quite a few annoying cases where modern gccs elide a test (remove the if) because according to the standard, it can't happen (compiler can assume that undefined behavior can't happen, and remove code because of that ). None of these were for DSPs btw.
About Y2K, in addition to all the costs he mentioned of having 4 digit years you would also have the extra time spent typing "19" over and over and not always perfectly. 2 digit years avoided that at the cost of making life miserable for those born before 1900 (there were still plenty of those in the 1950s and even 1970s).
Extra time typing was not the problem. But using the year field while batch processing indicating a deleted data set by putting in '99' so that any next sorting process will put the data to the end of file where you can simply truncate the file ... It was an extra deletion bit saved and some extra lines of code reading the deletion bit.
@@jeremypnet by "default" do you mean fill in the top 2 digits when only 2 are typed in? That was done in many applications and had its own set of problems. In Excel, for example, there was a rolling limit such that "57" might become "1957" while "29" might be "2029". In another context "29" might be "1929" instead. The rules could be quite complex and still cause a few errors.
Stories like this video turn me off to programming. Not only do languages change, people come up with new tools they want you to use all the time, and then stuff like this, where a huge problem was caused because someone wanted to save a little paper and time. Then there are the stories about all of the inefficiency and back biting in companies. It makes the job sound awful.
The problem was the storage. It really was expensive per byte, and therefore, computers didn't have very many available. The biggest problem was ivy covered professors*. In 1984 I was taking a COBOL programming course, and the professor told us to use 2 digits for the rear since it was a long time till the end of the century and we would never have to worry about it. I pointed out that was only 16 years away and I was still planning on writing software well after that. I will admit to planning on not having any money in any bank on January 1, 2000. I changed my mind when I saw how far we had gotten at fixing the problem. * From one of the songs of Tom Lehrer
Actually it's not. Only those where the compiler can optimise them away are "a lie". Funny enough, "for" and "while" loops are a lie. They are all implemented with (conditional) jumps (gotos), whereas recursion (as mentioned, if not optimised away) are done with jsrs (jump to subroutine). So you can have recursion in assembler / machine code, but you don't have the structured loops.
Loops also use "goto" at assembly level, though. Recursion is really useful for working on recursive data types, like lists, especially multi-level ones, file systems and many more.
I'm convinced that the aversion to goto's is insane. Like, what do they think break, continue, and pass are under the hood? Conditional jumps. It's all conditional jumps.
@@Blaisem there are over 100,000 instances of goto in the Linux kernel. Who knows how many in Windows NT and MacOS. Sometimes you just need to use an unconditional jump
@@robinpage2730 In the kernel yes I agree. Sorry, I thought we were talking about high-level control flows and how some languages still use goto on a high-level. I wasn't that far into the video yet.
@@robinpage2730 There are many, MANY developers that don't know jack shit about what's going on under the hood. To make _everybody_'s lives easier just make a rule to avoid goto. However, you can do whatever you want if you're the only one who's going to look at your code. Ever.
There was a great story back in 2019 where an American security researcher bought the vanity licence plate "NULL" in California, presumably hoping that it would make his car invisible to the DMV so he could speed and park indiscriminately without consequence. Instead he got hit with $12,000 of fines from other people whose licence plates were not recorded at the time of the offence so were stored as NULL instead.
😂 is this a true story?
@@dannydandaniel8040 it was in many online news outlets. The guy told his story at a hacker conference in 2019 but his troubles had been going on for 3 years. Now I've read into it a bit more, apparently the main reason he got it was to try have matching family plates of NULL and VOID.
so his plan worked. no judge would hold up any automatic citation if such an error could be proven.
@@timm1328 If you call it a success when he has to spend time disputing several tickets a week. Perhaps even in court.
I'm surprised those tags weren't reserved in the entry system, just like plates with three digits or less are reserved for gov't vehicles, etc. And ditto with tags that could be blatantly offensive and tend to be blocked from use.
These are the sort of things I think of every time I see another question or news article about driverless vehicles.
Remember Reagan's "Star Wars" (aka "Strategic Defense Initiative") proposal? Just write a program that ensures that all nuclear missiles will be intercepted in a timely fashion -- easy peasy! And then we will be able to nuke Russia with impunity!
In 1983 the Soviets had an estimated 2,490 ICBM launchers and five times as many warheads, not *4*. The claim that they only had four working missiles is from 1961. It also wasn't Petrov's decision to launch anything, he was only the officer of the day at at a western command centre (Serpukhov-15) for the Oko early warning system. He would have to give confirmation to the reports being produced by the instruments, and that is what he refused to do after corroborating the information with other sources. His superior, General-Colonel Votintsev, later arrived and backed up his decision that it was a false alarm when reporting to the head of the Air Defence Forces and the Ministry of Defence. Many cool heads prevailed in preventing catastrophe, not just Petrov's.
They had their own internal computer network that was only a few years younger than ARPANET, built on pirated copies of IBM designs like the S/360 and 370, which is all the more impressive since theirs were built out of just "rocks and elastic bands". It might deeply disturb you to learn they also had a home computer market in the 80s. Very silly way to end an otherwise interesting and entertaining lecture.
Yeah, such "mistakes" make one to think whether the whole talk is a rubbish or not...
Yep, and Pentiums were not first to include coprocessor, 486DXes had 487 integrated. Pentiums were superscalar/could do 2 instructions in parallel as opposed to 486.
There's a few bugs in his speech but that just makes it even more fun.
you are incorrect
the soviets didn't have anywhere near that number -- they exaggerated their numbers to "scare" off a US first strike
@@firstname4337 check the number of small&middle range rockets dismantled as result of Perestroika(tm) under supervision of the US - and review you thoughts about scale of a (possible) nuclear apocalypse. IMHO it is a way to serious to keep joking about it.
I haven't been in the computer programming world for 40+ years, yet found this compelling and all but impossible to turn off. Best to this guy!
Lucky you -- I've been in it for nearly 30 years, and I'm 4m30s in and seriously considering stopping because it's too painfully familiar/familiarly painful. 🤣
What a wonderful talk! I wasn't expecting to watch more than a few minutes but I had to stay for the whole thing.
Back in 1985 our computer centre invested £1m in a new mainframe, however, they didn't invest £40k in a new roof which leaked. The new mainframe had to be removed and dried out!
Consistently one of the most entertaining and quietly funny speakers on programming I've come across. I've fallen asleep at many conferences (in an unrelated field), but would love to see a talk by Mark one day as I would be confident of not only staying awake, but enjoying a little chuckle every now and then.
Thank you!
It was a huge mistake for Microsoft to choose '
' as the line ending sequence. They could have just stuck with '
' that Unix used, and saved so much grief for text file compatibility. (And Apple chose '
' for whatever silly reason.)
Yes, line endings. And character encodings.
They gotta be different! Personally, I think M$ has the most technically correct format. If you look at where all text comes from - the typewriter - CR and LF are two, different, distinct functions. In _most_ cases, you want to perform both functions, but not 100% of the time!
@@jfbeam There were some old terminal that had the same distinction (not just the teletype), but for file format, using two characters for next line is simply stupid.
@@jfbeam True, but then for those rare cases you could write your application to interpret them differently.
There are 2 main reasons I might use recursion:
- In a language with immutability loops get pretty nasty, and immutability is pretty nice.
- When you have good algebraic data types, structural recursion is really nice.
Tree Traversal using recursion is like 2nd nature. I actually have to THINK about it using loops!
You need recursion if you merge multiple subsolutions. He means trivial recursion and forgets to mention it + yeah, he forgets that some languages don't have loops. Or you can drive your loop with an explicit stack, but why, when there is already one?? What is really cheap is how in the end he says tail call elimination is a goto. Like loops did not have a jump in them. Feels like trying desperately for a punchline.
Also graph traversal.
People hate recursion because it's overused in leetcode interview questions, and because some people use it as a status symbol of being a 'Real Programmer' and force it everywhere.
But it does have its uses. I think the reason it's considered hard is that there's no control flow structure for it. Consider that For-loops are so simple and yet we still made a control structure for it - I think recursion/dynamic programming could benefit from that.
@@vladimirljubopytnov5193 yeah, the guy made quite a few errors in his first examples.
As if the world didn't have enough disinformation already.
Those languages normally do some recursion elimination (like tail recursion elimination) to spare you from the disadvantages of recursion, e. g. hitting stack limits or performance issues (caused by the increased stack usage)
The "Dog 38" problem is easily "solved" (well, kicked down the road) as long as the Kennel Club isn't so stuffy as to demand monotonically increasing numbers and accept a sparse numbering scheme (although, show dog folks often seem quite stuffy).
There are 1308 roman numerals in the range [1..3999] that can be represented in six or less ASCII characters (things get weird at 4000 and above and would probably create _other_ problems). In fact, if one just skips #38, numbers up to and including 77 can be used.
So, for the "short term", just put a post-it note on everyone's keyboard at the Kennel Club that says "Woof Woof, DON'T USE 38, Woof Woof" should work fine. Eventually the post-it notes will have to be expanded to add other forbidden numbers, but they probably will need replacing by then anyway (and banning just 60 numbers yields over 250 usable ones - I think I can fit the 60 banned numbers on a large post-it note).
There, fixed that -- send my my consulting check (I'll make sure to cash it before "Fido 78" arrives for registration!)
Also happy to see the Matt Parker reference there. He does really good stuff.
Very easy .. you just record the records as numeric. If you want a fancy Roman numeral then add that to the print script.
@@comatose3788That's the obvious and boring solution though.. (which was mentioned in the talk) live a little!
I pity their doggos.
They can just use a standard ascii numeral string and change nothing, eg "38" it's not like the machine is doing numeric operations on the roman numerals.(still limited to 999,999 so step up to hex FFF FFF for 16.8M)
Fun talk. Is it ironic or expected that the talk itself has bugs? :)
There are faulty humans involved in all of it, so I’d assess that as a featured bug!
That part about recursion seems either a gag for a cheap laugh, a lapse in communication, or intentional misrepresentation. It's combining Computer Science with Software Engineering in a way to completely miss the point. If you want to bash on recursion for being "just a goto", you'll need to do that for the loops as well. And all other control flow structures like ifs and switch cases. And calls are also just gotos with some added fluff you could do manually. But realistically, you don't say that ifs are bad because they are just gotos. Ifs are great because they are gotos that can't do whatever -- they are more restrictive. Same goes for loops and recursion. Loops and recursion both have their uses, but as Mark said, recursion gets praise in computer science, and it has a reason - some complex things are easier to represent with recursion. And that part about stack: Computer science, at the level I understand that term has no stack. It has no memory. It's math. Once the computer science problem has been solved using recursion, the developer is free to transform it into loops (CS has proven that this can always be done) or gotos or whatever needed by the the Software Engineering side of the problem solving. And no, Computer Science recursion will also never run forever. By definition a recursive function has a base case, which means it's over, and all other cases tend toward the base case.
Another (likely) causal factor of the Y2K bug was a general belief that software written well before the year 2000 wouldn't still be used by then. I remember writing software back in the 1980's that had code to handle dates past the year 2000, and being chided by a co-worker, who told me "nobody's going to still be running that program in the year 2000". I.e. he thought I should only use 2 digits for the year.
I remember getting a phone call from a company.. who was running some software 25 years after I wrote it. I had trouble even remembering the application.
#metoo
Same here. I was writing commercial software in the mid '80s and they teased me for worrying about the century in dates. The very same people, I'd found, wouldn't even worry about leap years, so I just went along with my way of managing dates.
The software I wrote wasn't sold anymore after I left in 1988, but its core was still used well after the year 2000 - basically, they had modified the UI part and left the operational part alone. One guy from that company started working at my new place a few years later and told me they had started to worry about the bug in 1999 and everybody was panicking until they simply tried to put a few future dates in and saw that it all worked.
clearly those people have not dealt with beancounter management very much.
The BIG problem with the Y2K bug was the number of archive files that had to be reformatted so that, if one of them had to be read by a corrected program for some reason, it could be processed correctly.
One company wrote financial software so that the Y2K bug would be avoided: a loan company that was building an online database and online access/updating system in the early 1970s, which anticipated writing long term loans that would not be paid off until the 21st century. They used a 16-bit unsigned integer (which requires a few extra instructions in S/360 Assembler, since a 2-byte binary field is normally 15-bit signed in 2s-complement format) to represent days since a start-of-epoch date (which I have forgotten), and they converted from and to 8-digit yyyy/mm/dd for input-output. This also served well in computing APR, since the dates could just be subtracted.
As an aside, I find it interesting that for disasters like rockets exploding, they actually figured out what went wrong. That seems like something that could take a heroic effort.
Exactly what I thought. How do you figure out such a minor bug after the whole thing already exploded?
@@1996Pinocchio-- There are copies of the flight code and they have telemetry from the flight vehicle. These days, a lot of that telemetry consists of information about the state of the guidance and control systems.
I remember reading about one incident (probably very early) in the Soviet space program that accidentally proved the round Earth (again). For one early launch, they initialized the gyroscope in the inertial guidance to point straight up as the reference direction during the first part of the countdown, then when an error was detected, they put the countdown on hold. It took a few hours to fix the problem, and they resumed the countdown WITHOUT reinitializing the gyroscope, since the rocket hadn’t moved, right? WRONG! The rocket had moved with the Earth’s rotation, or about 45 degrees in 3 hours! The guidance system detected this as a deviation from the course and triggered self-destruct.
Since then, EVERY rocket scientist has written into the checklist for launch that, if a launch hold lasts more than a specified time, the gyro must be reinitialized before resuming.
@@allanrichardson1468 Ah, but that was not a bug, that was a test of the guidance system's automated self destruct subroutine!
Or, at least, that's what the official report up the food chain would have said, I'm sure. I've heard a couple of translations of Soviet official documents trying to normalize things they couldn't properly explain. The best I've come across is one on some hikers who died while out on a hike (known as the Dyatlov Pass incident). The coroner was unable to determine the cause of death and thus reported something along the lines of that they had "encountered a force which they were unable to overcome." Which, yes, the avalanche that almost certainly did it can indeed be described that way. (There's been a number of more ...creative... interpretations of the events over the years, many of which could make a decent short story.)
I had to build a driver for a 'chain printer'. A chain printer has this long chain with a bunch of glyphs on them and it spins along this inked pad and these hammers slam down on the glyph when the glyph flies by the spot it needs to be placed. Awesome! High speed printing that can spit out characters as fast as the glyph can go by and the paper can go down.
The problem? We had chains that were *exploding* out of the printers. Why? Turns out that people wanted 'demo' pages which would have all these glyphs on the page so they could show off how fast they could print a full page. Some bright person figured out that they could line up the glyphs in the order they were on the chain and so *all* the hammers would come down at once right as the chain came along and came into alignment.
The fix was to limit the number of glyphs that could be hit at once.
The noise was amazing.
We had two of those in the bank I worked for end of the eighties. Really amazing speed! The printer were in some noise-cancelling "boxes" so the noise was ok - as long as the lid was closed.
My worst mistake involved a loop without an exit back in the 90s. Unfortunately, that loop wrote a file to a drive. So I filled up an entire HDD in a split second...
I was working at Oak Ridge National Laboratory (ORNL) when it was run by Lockheed Martin Energy Systems, as were the other two plants at Oak Ridge TN, i.e., the Y-12 nuclear weapons plant and the K-25 gaseous diffusion plant. I was assigned to a team consisting of representatives from all three plants that was developing a Software Development Methodology to be used at all three plants. We were receiving comments from the Lockheed software group in Denver that was working on the MARS Climate Orbiter. They were regaling us with how good and error-free their code development was because they performed line by line code review and criticizing our work because we hadn't called for such review. After the orbiter crashed we never had another comment from the Denver group!
PIC 9(6) in COBOL does not mean 6 bits. It means a 6 decimal digit numeric field or variable. It can’t have decimal points or minus signs. These are specified separately.
I really hate it to agree to someone on a COBOL topic...
It's an easy way to confirm yourself, that you are really OLD.
:-D
@@suchaluch5615 I'm new to all this but at my job we use Cobol and I have to learn it. It's not going away.
Not from the COBOL era but I have quite recently learned COBOL for fun and interest and can confirm this. Variables are declared with something called picture clause (like it is a visualisation or picture of the variable in memory) and the number in paranthesis is the number of digits. In any case less digits specified = less memory allocated. Do this with dates and voilla, the Y2k bug is born!
Thanks for the correction, I'm doing the talk again today so I'll fix that.
PIC 9(6) ----- 123456 okay for math
PIC 9(4)V99 ----- 1234.56 but internally 123456 -- period assumed. works as 1234.56 for math
PIC S9(6) --- allows negative numbers. okay for math.
The most difficult bug I ever found was on an LSI-11 Unix System VII using the Portable C Compiler. I tried everything and my code just would not work. Finally, I told the compiler to excrete the assembly code version of my program. Then I finally found the bug! The compiler was allocating 9 registers for a processor which only had 8 registers. I could then rewrite my program so that the compiler would only allocate 8 registers.
You might expect that compiler errors are not that common nowadays, but a 6 line function had an optimisation issue and was returning 65534 instead of 0. I caught it in the TLS tests of the device.
@@metala I do expect compiler errors to be common. State-of-the-art in parsing stopped in 1972 because most coders were not able to comprehend the new advances.
When I worked at Texas Idiots (TI), they had decided the corporate language would be Pascal and had their people create Texas Instruments Pascal (TIP). I tested it and it called the wrong subroutines. I found a copy of Pascal 8000, bought it with my own money from The Atomic Energy Commission of Australia, and ported it to the TI mainframe cluster. Ten years after TI fired all of us, Pascal 8000 was being used by all engineers.
@@robertpearson8546
was it better than Pascal 7999?
When talking about dates and Cobol, it's worth mentioning that that was in the 1950s and 60s, So it was quite natural to use just the digits for a date. After all, the previous century change was prior to WWI and the next one would be after you retired.
When I asked what would happen when we got to 2000 I was told not to bother as there would be new software by then ...
@@I_Don_t_want_a_handle I was filling out a new and recent government form, and it used two digits for the year ... after all, three digits are so 78 years in the future
Some issues with COBOL definitions here: PIC 9(6) is shorthand for PIC 999999 - i.e. 6 numeric digits. Nothing to do with 6 bits. Not used for "hyphen, comma and dot" either - that formatting would only be applied when moving to a print field.
I noticed that. PIC 9(6) is six BYTES, not six BITS. When you start getting into COMP and COMP-3 and all the various other definition types, you can save memory. But in anything that was textual like inputting from a punched card or transaction system, it was going to be a six-byte date. I started programming in 1987 and worked in COBOL for 17 years before swapping to QA full-time so I got to do a lot of Y2K remediation. At the time the bank I was contracted to was actually sending physical tapes of source code to India and back, every week, in order to do the remediation. 1999 hit different, yo.
@@Moose6340 The COBOL systems I worked on used "packed decimal", which uses only 4 bits per digit. So a PIC 9(6) would take up 24 bits, or 3 bytes.
I noticed that too, I only did a little Cobol at Uni. Other misleading statements early on put me off, Linux for example moved to 64bit __time64_t and developed compatibility library that fixed 32bit userspace. Support for 32bit is being dropped altogether by tool chains, but disk formats that have been changing gradually.
@@largemocha On all the systems I worked on, that would be USAGE COMP-3. So if you had, say, PIC S9(6) COMP-3 and (let's say on an IBM) it contained 091622, it would be stored in four bytes as 00 91 62 2C, with the "C" in the last four bits being the sign. ("C" for positive, "D" for negative, if I remember right.) If it was a 9(6) I think IBMs still reserved that right four bits for a sign, I can't remember 100% sure, they may not have.
@@Moose6340 I haven't looked at COBOL code since the early 90's. Even then, I hardly touched it, so I'm almost certainly forgetting some bits. Point being that there is a lot of misunderstanding about COBOL and "young folks" are inclined to mock it, when it was actually really advanced at the time it was launched. I wonder how many "modern" languages will have its longevity.
I had a highly egotistical boss who was NEVER wrong. And I watched as he reduced 2 programmers to quivering tears.
The issue - the companies flagship program calculations was off by 1c.
No explanation could be found. No code differences, nor data.
Yet unbox a program and run it and you get 2.98, however unbox another in the same shelf and you get 2.99.
I actually tracked it down to the fact that one development computer uses V1.1 of a popular compiler, and the other used V1.2!!! And there was a difference in the floating pount rounding routine between the two versions.
Boss then screamed at the programmers for not realising these differences, abd I got myself fired for screaming at the Boss that " He was a F@cking cheapscake for never keeping the compilers up to date"
Actually, never do currency calculations using floating point as this always happens. ;-/ I learned that the hard way. ;-/
Floating point for money is bad - or more general: floating point is bad if you need a predefined precision. I'm always surprised and shocked how many developers don't know this.
You complain about Cobol, but it works VERY well for currency calculations. Does not use floating point, older compilers don't even support it.
Multiplying 123.45 by 2 actually multiplies 12345 by 2, than puts decimal back in where it belongs.
Worst boss I had - old bureaucrat back at university - yelled at me because when I added a CSRF token to a web form, I made it pick the variable name randomly from a list of names, so it would be called "joe" or "mike", and his argument actually was "what if people look at the source code and think we're not serious?"...
@@brdrnda3805 I'm still reeling over mySQL doing things like "converting" 0.17 to 0.17000000000000002 or 0.1699999999999999 or whatnot.
In the early 1970s when mainframes started issuing electricity bills, some customers were furious when demands arrived to pay -£0.00 or else be prosecuted. It was a software glitch where £0.00 could have either a positive or a negative sign, and if negative then supposedly the customer had not cleared their bill... 😊
I had a similar issue decades long past when NCSU took over the phone services for all the dorms. I had a bill of $0.00 that they insisted I pay; threatening to turn off my phone, forward to collections, notify ACS to withhold my diploma, etc. I should've framed that check when I got it back from the bank. (banks used to send you all your processed checks.) The lady at the counter didn't even blink - who knows how many thousands of those bullshit bills they sent out.
Negative zero is not a glitch, but billing people for it sure is.
It's more of a stand up comedy show than a conference talk, I loved it😂😂😂
One pretty major mistake I found when investigating someone else's code was a for-loop (C/C++) that was, IIRC, some kind of memory copying loop. The termination clause for that loop was that the loop variable became negative. Too bad the loop variable had been declared as an UNSIGNED integer...
That's the sort of thing compilers catch. But, then the programmer ignores - or _turn off_ - all the warnings. (I've seen that too many time.)
The Mars Climate Orbiter had a mismatch between units but it was NOT distance in inches vs centimeters, it was impulse measured in pound seconds vs newton seconds
Fair to get it mixed up: There were several cubesat-projects mixing up inches and centimeters on their solar array sizes, at the time...
21:30 *AKTUWALLY,* the 486 was the first Intel CPU with a built-in FPU. A version with the FPU *disabled* was indeed available, but the 80487 "add-on FPU" was literally a full-blown 486 in an incompatible package that would only fit into certain motherboards that came with an 80486SX soldered down to them; when plugged in, the 80487 would simply lock the 486SX out by shorting out an enable signal, and take over the data bus forthwith.
The Pentium was the first *superscalar* CPU from Intel, meaning that it could handle more than one instruction per cycle, and it did have a *higher performance* FPU than the 486 did.
The effects of the Y2K bug were first seen in 1965 on 35 year mortgages
The thing about the FDIV bug... Intel _knew_ it was broken before it ever went into production, but it would've taken time to correct, so they went ahead with it _after concluding no one would ever notice._ Boy were they ever wrong. (As I recall, it was discovered within days in scientific calculations. I've run into qualification errors like this with compiler errors!)
Actually, the 486DX had an integrated FPU, you only needed a 487 if you had the SX
It’s rumoured the 486SX had an FPU in it but it was disabled.
@@jeremypnet IIRC the early versions of the SX had one physically disabled. One fun bit of the 487 is that it actually disabled the main CPU.
@@jeremypnet yep, would make sense if failed be rebadged as SX just like today the industry still dose these things just like Clive Sinclair ZX Spectrum using memory we’re the upper half wasn’t used because it was defective so got them cheap
@@sundhaug92 Makes sense. When dies are produced you always have a certain percentage of faulty ones. So you produce 486DX. If all is ok you sell them as DX, if something is wrong in the FPU part you sell them as SX, if something is wrong in the CPU part you sell them as FPU and only if both parts are messed up you have to throw it away. As the percentage of errors doesn't match with market demands you also take fully working DX and disable one part and sell it as SX or 487.
(That's at least what I remember as explanation)
Early in my career I was asked to implement a kernel watchdog timer as a workaround for another kernel module that would hang the system. Because I disagreed with the concept of such a hackish workaround, I labelled the feature the Basic Automatic Rebooting Facility (figure out the acronym yourself). I was planning on renaming the module before it shipped, but as luck would happen the root cause of the bug was found so my feature was not needed. Then by mistake my code made it into a production build and shipped anyhow (in incomplete form, so it caused regular reboots to happen). So customer support was having to tell clients to list kernel modules and look for one called BARF. Not quite as bad as a name with f*ck in it but did teach me the lesson of being careful with names.
While working on an instructor station for a full flight simulator, I discovered, while working on lates, that one of the other teams had failed to correct a bug with one of the simulated malfunctions, again! So I modified one of the many buttons on one of the many pages of simulated faults so that when pressed it displayed a box containing the message "This fucking fault still doesn't work".
The next day, there was an unscheduled visit by the customer (JAL) who were given a demo of the work in progress on their latest £10m simulator, and which fault do you think the guy doing the demo selected to show them?
About the tail call thing:
By that metric loops are also just gotos.
However, it should be noted that recursion is definitely more goto-alike, though not in the way it was explained here - you can jump to OTHER functions with that optimisation; at least in most compiled languages [provided there's no destructors running *after* the call or anything of the sort; and that the optimiser recognises it, LLVM & GCC based ones definitely do], dunno if that applies to .NET as well. That said, it's much safer than just a single goto and much easier to reason about, *as long as* you have functions that are small enough.
Because then, using tail calls, it's essentially saying "I can reduce the problem I'm trying to solve into *this* simpler problem"; which is quite nice not only for proving things mathematically but also for reasoning about it; especially where the equivalent loop has to deal with mutable state & such where the tail call version might not, because you don't have many small state transitions every time you change something in any variable, but one *BIG* state transition once you hit the tail call, instead, that lets you reason about the state as a whole much more easily in my experience. It's the same thing that can be generally said about side effects, just in a slightly different context, imho.
loops are just well defined goto's which stop you doing all the fun stuff with gotos.
I had some fun trying to adjust some old MASM (on dos) to read from a different phone switch serial output than the one it had been designed for. Some of those "functions" had multiple entry points a couple of which inside the main loop and multiple exit points one of which was inside the loop, but got used after the main loop had ended BY JUMPING BACK INTO THE LOOP. Very little documentation, which said what it should do. Hours of fun....
@@MrMeltdown tail recursive gotos are also more restricted through their argument list - which means that it's not really comparable to jumping into the middle of a function, since the "equivalent" tail recursive stuff would still enumerate all the "state" you're dealing with (especially because tail recursive functions should ideally be side effect free, too!), making it equivalent to reasoning about tail recursive functions in general.
Quite agree, someone needs to run unfer.exe on his talk as he was innacurate from PIC 9(6) to __time64_t, so I looked for corrections in comments
The code gets a definitive memory location on load. Unless you're running some kind of hybrid self-modifying code stored in the heap you can't really remove the code from memory until the executable gets unloaded. For this reason it doesn't really matter if you run any destructors; the code remains. The only thing that you need to keep in mind is that the code might expect some other memory to be viable.
@@Kenjuudo I honestly don't know what exactly you're trying to say - but based on what I think you're trying to assert, which is that destructors don't stand in the way of TCO, I have to say that they definitely *do* stop TCO unless the language is garbage collected (in which case the garbage collector takes care of it either way) or the compiler is allowed to call destructors early - which in for example Rust or C++ is iirc not the case, since destructors are used *for their side effects sometimes*! And there would be reordering needed, since the destructor can only run after the function call (`return f();` is equivalent to `x = f(); return x;` in most languages - so the destructors running before `f` would be different behaviour) if the current function gets control flow back, which makes TCO impossible.
I have seen that “10 IBM consultants in a room” thing far too many times 😩
In 2007, Los Angeles Unified School District went to ERP software. The payroll was a disaster. Thousands of teachers were overpaid, underpaid, or didn't receive a check. When something went wrong, the teachers had to go in person to an HR office, which were open during regular school hours. That meant the teacher had to arrange for substitutes while they dealt with HR. The problem went on for months.
Or the teacher could bring the whole class along to observe the interaction with HR as a life lesson. If enough teachers did that, the problem would have been fixed much faster!
@@allanrichardson1468 Students learning important things for life in school ? .. we can't have that.
The Mars Climate Orbiter case wasn't as simple or "stupid" as you make it out to be.
It wasn't that Lockheed-Martin stubbornly clung to Imperial units. They knew better. By the time of the Mars Climate Orbiter project, they along with most other aerospace firms had long been using the metric standard. The problem was that their code incorporated some older code modules from much earlier space missions, back from the days before metric had become the norm. As you surely know, it's usually better to re-use proven code than to write complex functions from scratch each time and hope you get all of it right again. Lockheed-Martin was well aware that the old code used formulas based on Imperial units, and painstakingly updated them all to metric calculations. Unfortunately they simply missed one.
Having to update the units in the old code was a known risk, of course, but so was trying to write entirely new code to handle complex real-time navigational controllers.
As for Americans being "stupid" for using Imperial units, that's not so simple either. It's not like chose to adopt the Imperial system of units when offered a choice between the Imperial system and the metric system with no prior history. The problem is that America (like much of the world) had long used Imperial units, *and* by the time the metric system came along America had a vast amount of technology, tools, and machinery already committed to specifications in Imperial units. Even the international aerospace industries around the world were locked into Imperial units for a long time after their respective countries "went metric" due to the inertia of (at the time) America's outsized contributions to the aerospace industry. It takes a long time to phase out the old and come up to speed on the new.
Great rebuttle, and I too cringed when he called Americans "stupid". But he's British, so it's kinda ok - but don't wear it out. But we can sometimes be imbecilic, e.g., Trump. But it was kind of a dumb mistake, but given miles of code, almost unavoidable. Bugs bite, and when they bite, it's usually at the most inopportune time.
As an American, I agree that we're stupid
American's could of had the metric system back in 1793 if it wasn't for pirates stealing the measurements from the boat carrying it. They've also had plenty of time after that to change however the main issue is people in power not wanting to spend the money to save lots more money.
@@lordtraust That sounds like a lot of nonsense. I am sure they had more than one ship. Even England was on the Imperial System then, after all it is the "Imperial" system. Rather than corporate greed, "people in power", or any other conspiracy type deal, it was most likely cultural inertia, then and now which resist the change, which you gotta admit, involves a great deal of adjustment and change, even though we have technically been on the "metric" system for decades. Much, if not most of my tools are standard, though changing fast, and we still measure in ounces, cups and tablespoons.
@@natemills9030 I agree we refused British rule and look where that's gotten us. 😆
I'm constantly seeing people on the Internet claiming that Y2K was a big hoax. In 1999 I spent weeks fixing 1970s code that had the year in *two* formats. One was two character bytes and the other was a byte that was supposed to work past 2000 but instead crashed everything whenever it went over ninety nine mainly because no code expected that to ever happen.
The weirdest thing was that we told our clients that our software would crash on January 1st and they needed the latest versions of everything yet a few refused to update anything. They seemed certain that we were lying about it as if it had been some kind of trick to sell them something.
Making the unix timestamp unsigned 32 bit, actually shifted it to the year 2106... so developers can be like "I'll be retired by then.. so: not my problem anymore".
The problem with the Y2K fixes is that many of the companies did not truly FIX the problem by having 4-digit years, they just put patches in place that said that if a 2-digit year was below some value, then it was in the 1900s, otherwise it was in the 2000s... The problem is that this window of times varied by the program... Even worse is that on Windoze, the 3rd party DLLs might use different sliding windows... We went from having a known problem date to having an unknown number of future problem dates...
I wrote some code in 'C' back in the late 1990s that is still being using by the company today without any changes... There were certain portions that had 'time_t' variables, so they are going to be 32-bit integers for the time and will have the 2038 problem... I knew about it and documented the code to reflect it, but there was no way that I thought that the code would still be running in 40 years... It's still running after around 25 years, so "never say never"... There's a CHANCE that I might still be alive in 2038 to see how it turns out, but statistically, it's unlikely... I'm an old fart -- when I first started programming, we were using FORTRAN and punch cards...
Hey, I'm no programmer. But one of the most powerful tools in aerodynamics is Dr. Richard Epplers FORTRAN code for inverse-airfoil design. It is ridiculously useful, but also extremely unintuitive. And NOBODY has ever made a better program to design airfoils from thin air. Love it. Still not hard to get it to work on Windows 10.
Microsoft Excel counts 1 as January 1, 1900 @ 12AM.
1.25 is 6AM, 1.5 is 12PM, 1.75 is 6PM, and so-on.
It still doesn't support any dates before 1900.
Excel's first date is 0 Jan, 1900. Makes sense. VBA handles dates prior to 1900,, but Excel will refuse to display them.
The Ariane 5 explanation is wrong. Trying to convert the 64 bit fp value to a 16 bit integer caused a hardware exception. The nozzle deflection was caused by the on board computer interpreting the resulting diagnostic bit pattern as flight data.
Algol W was devised by Niklaus Wirth (hence the "W"), not by Tony Hoare. I was studying computer science, and in particular, the Algol language family, under the tutelage of Professor-Dr. Peter R King, at that time.
I'm only 5mins in here, I have a feeling I will have more comments.... I also shipped an "Undo New File Usage Change Kernel" (yup, that is what I called it), it was basically a boot option to revert some files on a windows installation in the other partition to a previously known good state. My UNFUCK lived in a rescue partition (the Advanced Rescue System Environment) alongside an option to access the Command Line Interface Terminal (basically a DOS prompt).
The joke was obvious, but it never played out quite as well as that one time I was walking through the call centre and heard a support guy say to a customer "Okay, it looks like we can rescue your system, we just need to go into ARSE and stimulate the CLIT."
Error! The 80486DX did have a floating-point unit (FPU) built in. It was the 80486SX, introduced after the 80486DX, that had a disabled (defective) FPU, and a 80487SX FPU co-processor was then offered for extra money. Apparently, the early batches of 80486DX's had enough chips with defective FPU that this made economic sense.
I can remember working on the SITA global network who backed up their leased lines with a piece of equipment manufactured by a German company Controlware. I once received an error message saying "the system is fucked". The error messages often used words like "buggered" and "screwed"!
I used to use neologisms as verbs for unlikely failures.
Access system ghoeped.
Index flonked.
Cache screebled.
17:45 OMG, I know this kind of madness. In the end you get PPT Slides which document detailed contents of a Patch, line by line. And someone else has to write it down and test it again... instead of just receiving a Pull Request.
The 486DX had an FPU. It was the cheaper 486SX that didn't have a usable one. (It was on the die, just disabled.) It was only the SX that required the 487 coprocessor if you wanted efficient floating point computations. Which makes the Pentium bug a little more puzzling, because Intel did know how to do this right.
The story at the time was that the SX chips were DX ones whose FPU had failed QA. Sounds plausible.
Programming mistakes which cost you millions are always fun to listen to :)
Great speaker!
no, coding mistakes that cost *someone else* millions of dollars are fun to listen to
The document.all stuff is deliberate because there's code out there checking for document.all to detect IE which rightfully assumes IE will be IE(and by that I mean outdated, buggy, and barely pay lip service to any nice features).
IE7 changed the behaviour of testing it's type specifically to stop people detecting IE in that way because, even though it was still a 5 years behind browser, it was no longer a 10 years behind the standards browser and they stupidly thought it was the right move to pretend compatibility.
This talk was very well presented, I was hooked throughout the whole hour!
Hmmm.... I do not think that the Ariane failure is correctly explained. As I remember it was even more insane: there was an inertial reference system that was useful only before lift-off and just continued to run after lift-off without any purpose. It was re-used from Ariane IV but not useful in actual inertial calculations for Ariane V after lift-off. They just used it for the start preparation phase.
I think they kept it running after lift-off because it was originally designed to do so for Ariane IV and they wanted to mitigate risks by not shut it off or changing the code. Then the floating point error occurred because Ariane V had higher acceleration than Ariane IV and caused an exception.
Which caused the perfectly running primary physical inertial system to shut-off. Then the redundancy system took over, ran into the same error and also shut off. This caused the rocket to lose trajectory and self-destruction system activated. I studied aeronautical engineering at that time and was keen about to know what happened.
"comfortably spit a rat" - I have only ever heard Ford Prefect and myself use this phrase 😄👍
The man is class
The reason for the name 'Pentium' was they added 100 to 486 and got 585.5
Very nice talk and examples. About 'arrogance' at the end , I would like to know if anyone here shares this view of mine: "If you think you can write 5 lines of code without bug : you are definitely arrogant". Usually test code should be as long as code.
Love the graph at 16:12 - note how Leadership has absolutely no connection to the actual software development!
20:30 That reminds me of my first professional experience... fresh out of school, hired by a big company who do so love their processes.
I had (temporarily) been put to work on a POTENTIAL security upgrade to a legacy embedded system... mainly, it was updating OpenSSL to support TLS1.2, but there were also some X.509 shenanigans.
Since I wasn't doing anything else, I started working on it. Took me about two weeks, including learning how the damn thing worked, and testing.
By the whole thing was DONE and WORKING, my bosses were STILL having meeting to assess the risks and the costs associated with developing the feature...
Ultimately and a few months later, they went to the client and told them it'd cost them about 100k to develop the feature...
Client said "no because it's too expensive". Project, upgrade and all of my work got canned.
And of course, my own pay wouldn't have even made a *dent* in that 100k bill in the first place... it was all useless overhead. Wonder how much those meeting costs?...
I believe the key lesson in this video is that there must, with any non-trivial system, ALWAYS be a human in ultimate control with the power to say "Hold on...... , We must do this instead". And it MUST be a very skilled, wise & experienced person.
Unfortunately, such people are expensive and beancounters can't understand that in the long run this is likely to be the cheaper option.
Recursion is good as a way to reason about program flow, although if it *looks* like something that could be converted to iteration, it *should* be IMO; also, ordinary loops are implemented using the goto-like instructions (a.k.a. jumps), the same way tail-call elimination for recursion is.
The true reason that []==![] is true in JS is, in essence, that the abstract equality comparison tries to convert operands of different types to numeric values (after a special case in which null and the undefined value are abstractly equal to themselves and each other and no other values, except that the DOM, because of an old IE compatibility hack, also makes document.all abstractly equal to them): First, to evaluate ![], the empty array, which is an object, is coerced to boolean, which is true because the empty array is not one of the seven values that evaluate to false in a boolean context (false, null, undefined, '', NaN, 0, and -0), and then the logical not converts true to false; next, the ToPrimitive operation converts the empty array to 0 and also converts false to 0, and those two values are equal, so [] and false are abstractly equal.
More generally, it was a huge mistake that JS operations result in unexpected type-coercions rather than errors; the language didn't even have exceptions until ES3; other smaller issues like the bug in the original typeof operator that made it output 'object' instead of 'null' for null could not be fixed, for the reason you stated.
SAFE:
There is a daily status meeting, there is a three week time increment called a "sprint" but planning is done in "program increments" (name varies over time) of ten weeks which is the real planning horizon.
And on top of this there is a project with a fixed end date and fixed content that runs for years...
And when the project invariably gets delayed, there will be over time (for everyone, regardless if they work on that project or not) and another daily status meeting.
Now, I actually do not mind the last nope, because they reinvented the "pulse room", where every team in the project and any stake holders (chicken I believe is the correct technical term) can check the status without bothering the teams.
recursion is a very elegant way of processing certain data structures and no your loop explanation doest have the same effect as the recursive code. Its different, and dont blame your tools if you code a bug into it. Which is just as likely in a loop as it is using recursion.
On Oct 5, 1960, BMEWS (Ballistic Missile Early Warning System) (big honkin' radar) in Thule, Greenland "detected" a massive launch that turned out to be the rising Moon.
Well, I almost never use recursion because it ends up not being the best way to do it, but I just like recursion. It's a really cool idea.
In some languages, like Prolog you can only do recursion, and you get used to it, and it becomes no big deal for most. However I have met a student who said she just could not wrap her head around it. She committed suicide shortly after, I don't know if there was a cause and effect phenomenon.
@@feraudyh wow really? I can understand why someone will kill themselves over code, coz it's frustrating at lots of times...
Many of these errors were due to NOT (edited)
properly defining the problem, developing, and reviewing the specifications before handing them off to programmers. I've bailed out a half-dozen programming projects in every case; the programmers didn't understand what needed to be done. Often no one involved was any better informed, and I had to figure out the solution. Most weren't too difficult, but one took the better part of three years and a Ph.D. level knowledge of hydrology. At least I didn't have to pay tuition, take tests, take any elective courses, pay any fees, or write a thesis. I only set in on courses I needed.
There is far too little planning and design before the first line of code is written or the first piece of hardware is purchased or designed. Too often, the folks in marketing drive these decisions with little or no input from hardware and software engineers. Building things that work on time and within budget is really important. The way most outfits do it guarantees that never happens. Weekly code reviews help as well.
I agree that most efficient line of code is one you don't need to write at all (and least buggy and least need to test and so on). And that is why pre-planning things is so important.
I've seen projects go ass-backwards starting from entirely wrong end of things even after being told it isn't going to work. Well, some time and resources later things improved, but still some warnings were being ignored ("this is going to become a problem later" and nothing happens to it).
And yes, you are right about marketing: some people work on commission and then other people who need to implement what they've sold and need to handle the fallout. Often times software people are asked to join in discussing when deadline is already nearly there and it can't be pushed around any longer so there's not much resources and not much money to implement what they've sold. And fixed-cost contracts are the worst since everything is shaved down to a bare minimum and all the rest is extra work on a different contract and having to fix issues made by people before on different contracts are just going to balloon the costs again.
Did you mean "Many of these errors were due to NOT properly defining the problem, developing, and reviewing the specifications before handing them off to programmers. "? We would a proper specification be a problem.
@@brdrnda3805 Yes! Thanks
@@IlkkaPrusi We write way too much code for most projects. code libraries, style, and weekly code reviews need to be done. Weekly meeting to go over problems work.
" _There is far too little planning and design before the first line of code is written_ " -- Or, similarly, sometimes the upfront design work is done with little or no thought given to concrete implementation details (e.g. "how can we change our pre-existing db schema to support this new feature?" or "which pieces of db data do we need to have available to use as input, and are they even present in the db at all?"), and then the resulting bad design document becomes *set in stone* before the programmers have read it.
Can relate to the first story. Back in the days when software was still shipped on floppy disk in a letter, some boss though it would save us work if customers had access to the (dangerous!) patch/fix software. In fact, it was so dangerous that it was password protected so you couldn't use it accidentally, or without prior lecturing by someone who knew the password.
Since it was internal use only, and only for very tech-savvy persons, the password was strongly protected against accidental leakage. It was a word, or rather a phrase, which no one would write on a whiteboard, or use in communication with a customer or superior.
So one day I got a call from the front desk. A customer had a question about the patch/fix software. I was, like, wtf, the customer is not even supposed to know of this software, let alone get his hands on it! And, besides, it's password protected, so they won't be able to use it anyway. The secretary told me that the password had been included in the envelope, which I clearly didn't believe. She showed me the letter. Right in the middle of the letter, in *large* friendly letters, was the, uh, decidedly unfriendly password. Apparently, the boss had demanded the password from someone, who had written it down on a slip of paper (because you don't say such a thing to your boss) and the boss had given the password the the typist. That was in Germany, and the German typist apparently lacked enough knowledge about the English language to figure out what the combination of letters meant.
So I had to call the customer, who asked what the password was. "Yes, we've received a letter....but instead of the password, was just an expletive...".
I was able to convince the customer that the phrase (which was similar to "help yourself", but with an "f"-word instead of an "h"-word) was indeed the super-secure password and that they should not, under no circumstances, use that software, and "And as I know that you won't listen, make a backup of your data first! Otherwise, you might experience a situation which is...sort of similar to what the password means".
Situation was contained, I wasn't fired and the boss got a bit smarter.
Okay.
I lied about the boss getting smarter. We just got secretive about our internal tools.
That's a nice idea. Still has loopholes as you found.
I would say that not considering horizontal loads was an engineering error rather than a programming error.
I've laughed out loudly more often than on most comedy stand up specials. True gold, I salute you sir.
1:15 "Before I start, CW: there is going to be swearing. I am going to say f**k, quite a lot, just in the next segment. But it is relevant to the plot and...so that is justified."
This sounds like a scriptwriter pitching #DoomPatrol screenplay to management of @dcentertainment
Did he _really_ say that recursion is no better for safety because of how safe the machine code looks? Because that's not how compilation works.
What I remember from the Knight Capital case: The software processed messages. In the new version of the software they used an already existing attribute, which wasn't used in years (who wants to change a structure, when you have unused things to abuse...) - and they had a flag to control the behaviour (like "ignore_attribut_x"). So they deployed the software and set the flag to activate the usage of the message attribute. As Mark said, the deployment was fine on seven servers but not on the eighth. So the eighth was starting to run the old behaviour. They realized something was wrong, but they didn't realize the true nature of the problem, so they just wanted to undo the deployment, but didn't have a proper rollback implemented. So, as mentioned by Mark, they copied the old version to the other seven servers, but forgot about the flag, so all eight servers ran the unwanted, old code...
Seems like you're just pointing out what we already seen. It's a good thing we have you around to point out the ovious.
@@comatose3788 No, I provided more details. But I already noticed from your other posts that you have problems in understanding things.
@@brdrnda3805 Yes, 40 years of programming has left me no understanding of it at all. I also never heard of any of these stories. So It's a good thing you're here to fill in the major gaps. genZ freak
@@comatose3788 What do you mean by "these stories"? The Knight Capital case?
@@brdrnda3805 Yes i was talking about that story also. You see genZ buffoon, it's also fine to call them stories. I understand you're some kind of nitpick over everything genZ freak. Clearly you're so fail in life this is all you can do to make yourself feel worth anything. Let me talk to you like a child so you too can grasp a consept. When you hear a story even if it's about a fact, it is fine to refer to that as a story you heard.. Take it slow read it a few times. You can do this little man!
You can write a sort routine without recursion, but for many algorithms you'll need to implement your own stack which will no doubt be slower than the system stack.
I love that after watching this talk the next recomended video is another talk titled "Failure is always an option"
I like this guy's humour, but he got some stuff a bit wrong, so here, for posterity:
Heartbleed wasn't a bedroom coder's unseen mistake, and it wasn't OpenSSL developers' mistake. It was introduced by a Debian maintainer to Debian's build of OpenSSL, because they wanted Valgrind (a tool for checking memory safety) to shut up about a particular line of code. They removed that line, and OpenSSL appeared to still work, so they shipped it, but it turns out it was working with orders of magnitude lower entropy in its encryption key generation mechanism (= orders of magnitude more hackable), and it took 2 years to discover.
And the xkcd comic wasn't about OpenSSL, it was about libcurl :)
The 486 (the DX version) had a floating point unit integrated. There was another version (486SX) without the FP unit, for those who did not nead the FP boost. The last processor commenly sold alongside a dedicated floating point coprocessor was the 386.
There was also the "487SX", a 486DX in a funny package that would bypass the 486SX.
My first PC, bless. (DX, obviously! :)).
@@Ice_Karma I believe the 487SX was actually a 486DX with the main processor part disabled, sold at a lower price.
Anyway, I never knew anyone getting it, everyone I knew that needed the FP capability would get the DX right away.
@@haakoflo Nope, the 487SX was a full 486DX. The 486SX could actually be removed entirely after the installation of the 487SX, although this was uncommon because the 486SX was not usually mounted in a ZIF socket.
I always considered a "bug" to be more like a typo - an actual error made by the programmer. Failure to correctly anticipate and code for a specific situation or circumstance isn't a software bug, but you can call it a design flaw. Y2K was a bad design flaw. Programmers are not responsible for the vast majority of these mistakes - it's usually the BA's fault ;-)
Bugs can appear at any stage in a project. The more time between introduction and eradication, the harder they are to fix. Y2K was a methodology bug perpetuated into the designs of many software projects. It was created by software engineers to cope with inadequate hardware, then pushed onto following generations of students that then put it into the specifications of their software projects. It took the looming crisis to get it fixed.
A programmer is woken up after being cryogenically preserved. Upon awakening he asks if there is a cure for his cancer. No was the response. We have succeeded in preventing cancer, but it is the year 9999 and we understand you are a COBOL programmer.
A bug is a moth in a relay.. Shout-out to the late Grace Murray Hopper.
I had a bug once that was so useful that it became a feature.
This was on an old PDP-11 and later VAX-11 program that used VT-100 terminals to enter data in a formatted screen. You could use arrow keys to move back and forth between entry fields on the screen.
For some reason I have completely forgotten by now, there was a character you could press that would take it automatically to the next screen. I didn't design it that way at all and was swore that the program couldn't do that when a user asked about it because it wasn't mentioned in the documentation. It turned out that he didn't want me to fix the bug -- he wanted me to document it so that they could officially use it.
Most added code to assume - for appointments or any date assumed to be in future - that a year less than 80 was after 1999.
Birthdays and other dates in past needed the 8 digit year, sorry.
@@russellstyles5381 On the VAX, Digital Equipment Corporation, DEC, counted in the number of 100 nanosecond intervals since 17--Nov-1958 and stored it in 63 bits.
Your nervous breakdown changed my life forever. I ended up going to the US in 96 and I haven't got back to Hastings yet.
7:56 let's not kid ourselves, they still call it "core dump" because it sounds way cooler than "memory dump".
Seriously, on the first one: letting that go to the customer was definitely a QA and support failure.
The recursion bit just screams "I don't like recursion, so here is a cherry-picked example of when recursion is stupid!!!"
The XKCD 2347 he talks about in 49:30 is actually about curl.
Matt Parker (the guy behind stand up maths) wrote an entire book called Humble Pi about similar things like the dog38 issue, a comedy of maths and computer number errors and cock ups and it's fantastic!
In which he debunks that tired old story about the mars climate orbiter. It wasnt because we used inches. By then NASA used metric through and through and demanded all length and weight measurements from contractors did the same. It was from pound-feet not being converted into Newton-meters. Those who continue to assert 'hur dur inches' are only displaying their ignorance.
@@zombieregimeit's basically the same thing
@@coffeedude ITS 3 RODS TO THE HOGS HEAD AND THATS THE WAY WE LIKE IT!!!
FWIW the original 486 DID have a floating point unit built in, which led to another fabulous floating point bug.
Due to market demand for a cut down version Intel came up with the 486SX which either didn't have a FPU or had a nonfunctional one. The "487" was basically a complete 486 with a slight pin-out change so fitting it would disable the existing CPU.
Unfortunately...
By this time software had been released making the assumption that a 486 would always have a FPU, so when it was run on a 486sx all floating point operations returned zero.
I remember that old chestnut, and being an ex-486SX2-50Mhz owner I remember all too fondly being critically appraised for always preferring addition and subtraction in BCD rather than actual floating point.
@@jonbondMPG Its good to read that someone else at least gets the point of BCD. Since just about every library has int to string and string to int functions built in BCD seems to have been largely forgotten, even in embedded.
I remember the lightning fast AMD 486 DX 4/100 back in 90-something. I thought, with MS-DOS running, how much faster do I need my computer to be?
@@peterhelpme It was funny how the later model 486 could outperform the first generation Pentium. If I remember correctly the 486 had gone to 3.3V but the P. was still 5V CMOS and was quite a good fan heater.
@@oliverbroad4433 oh yes those first 60MHz Pentiums were brutal. I remember a co-worker having paid '$$$' for a laptop that burned you lap and killed its batter in under an hour of use.
Loved this talk. My only query would be how to traverse graph nodes without recursion. 🤔
Sorry mate, but it was the 486 that has the math co-processor included. They also had a version called 486SX that didn't include it (actually disabled), which required you to buy the 487SX
Regarding the recursion and goto. All loops are goto(jump) after compilation.
Core memory has three wires through each core, not two. You need three to do the addressing. But, yes, they were usually assembled by women who could do this skilled work fast.
From what I remember that third line is 'SENSE' it tells you (by a pulse coming from the core) if the polarization reversed, i.e. you had a 1 in the bit before clearing it through a destructive read, (IBM Early Computers 1986 Bash, Pugh). But yes agreed to wind those under microscope very daunting work. I was told by an old IBM field technician the 'gals' worked in 20 min sprints then had a coffee and cigarette to recover their wits before resuming the work.
You would be shocked how much of Healthcare runs on Javascript as a backend. Most integration engines use an ECMA script library backend for their programming language.
Definition: BRATWARE - Software created by kids who, unlike me, didn't have to worry about their coding errors starting World War III. In 1964, a civilian software engineer installed an octal patch to the SPACETRACK system running on a Philco 2000. Everything was in assembly language in those days and recompiling took inordinate amounts of time so octal patches were used to make quick fixes. SPACETRACK was running at NORAD HQ in Colorado Springs Colorado. The patch accidentally set off the "bomb alarms" at SAC HQ in Omaha Nebraska and caused SAC to scramble, i.e., all the bombers launched. It was a year before I got there as a new second lieutenant software engineer but the incident was still being talked about. It was said that a 3-star general from SAC visited NORAD HQ and was yelling "You mean to tell me a civilian scrambled SAC! I don't even have authority to scramble SAC!" Software used to be MUCH more exciting! Philco 2000: 256K of 48-bit words where software to track 1500 satellites was shoe-horned in exclusively using assembly language... It was fun! But we became VERY CAREFUL software engineers!
So much in this talk was just so wrong I gave up. Facts, people... they kinda matter.
Well, I know nothing about a COBOL, but I've spent half-a-year or something rewriting PL code to consume 4-digit years instead of 2-digit ones. But this is not the point. The point is this speech is redefinition of a genre of stand-up comedy camouflaged as something scientific(-like)
seems like it hit you right in the balls!
There is also the Therac-25, although the bad software of that machine was allowed to act very poorly due to the absence of hardware interlocks. On previous machines, the faults were hidden by the presence of interlocks, that didn't allow any deadly condition to occur (say, the lack of a target to convert electrons to X-rays, when in high energy electron beam mode).
One of the restrictions of the talk was the bugs weren't supposed to directly harm anyone, because it's not funny when cancer patients are getting burnt to death by their radiation treatments
I'd call that more of a management error than a programming mistake. They should not have hired a hobby programmer to write control software for a machine which (literally) shoots death rays at persons.
It fried my wife’s intestines. It took 40 years but this software error eventually killed her.
"Hartford Center" is actually the Hartford Civic Center, in Hartford, CT (USA)
Love this presentation. 🤗🤭As an old programmer, this is gold.
Good stuff John @markrendle for bringing out the fun in programming. It's serious and I wish I could be just as half as good you are. All said, that inspires and encourages many in the wider community to consider and take up programming. Having done it in the past, I wish to retake the journey even as a hobby going forward, hoping my current age (40's) won't be an inhibiting factor.
Kudos to @NDC Conferences for making such good things happen.
Mark presents it as fun, but believe, if you have to work with this kind of cr*p for years, you really, REALLY start to hate it. If you really care about code quality, doing enterprise code is a nightmare.
Who patched time_t with an extra bit? I only know Linux, which is not Unix, but only Unix-like, and that uses 64 bit (signed, I believe). You can compile 32bit programs using that 64bit time_t (similar for off_t), but it requires an extra compile flag for backwards compatibility reasons. For 64bit programs it's of course always 64bit.
I also couldn't find anything about that. Most of the fixes have just changed time_t to 64-bit. Making it 33-bit sounds truly strange.
@@EebstertheGreat I can believe that someone might have changed from 32 bit signed to unsigned, thus winning one extra bit for the same code model.
@@oliverbroad4433 Good point, that does make more sense. Though it couldn't assign times to anything before 1970.
Can’t change to unsigned because it’s the return value from some time conversion functions which return -1 as an error indication. And even better the conversion functions would accept negative values and produce correct dates before Jan 1, 1970. Until someone with no understanding of history “fixed” glibc so it wouldn’t accept negative values.
Turns out a certain version of the archive format cpio, which is used by rpm, uses 33 bits for some odd reason (11 octal digits). But 1) this is not Linux (the way this talk talks about things I assume Linux as just the kernel), 2) not every Linux distribution, only those that use rpm/cpio, are affected, and 3) it can be easily patched. Just use a new rpm version in a new version of Redhat/Fedora (maybe using a better, newer archive format). Can't install rpms of a newer release on an older release anyway.
The Deloitte one looks like a Major Metro's Subway Map
As a 500k/year customer I'd be chuckling and buying you a beer
WRT y2k, one of the less reported things that happened was most of the world's security systems not working on 9/9/99
In Feb 1998 (IIRC), a minor epochoalypse happened - people discovered that many systems were storing utime as a signed 32bit integer instead of unsigned and NTP implementations around the world broke (particularly in routers)
Signed Integer overflow in C is *undefined behavior*. I would honestly expect Mark Rendle to know this.
Technically. In practice unless you're on a DSP with saturating arithmetic every implementation wraps around to INT_MIN.
@@Pence128 No, you're wrong.
I've seen quite a few annoying cases where modern gccs elide a test (remove the if) because according to the standard, it can't happen (compiler can assume that undefined behavior can't happen, and remove code because of that ). None of these were for DSPs btw.
@@vladpetric7493 Huh. TIL.
It's been 25 years since I wrote any C code.
Informative, entertaining and I didn't have to get up from my chair.
About Y2K, in addition to all the costs he mentioned of having 4 digit years you would also have the extra time spent typing "19" over and over and not always perfectly. 2 digit years avoided that at the cost of making life miserable for those born before 1900 (there were still plenty of those in the 1950s and even 1970s).
Extra time typing was not the problem. But using the year field while batch processing indicating a deleted data set by putting in '99' so that any next sorting process will put the data to the end of file where you can simply truncate the file ... It was an extra deletion bit saved and some extra lines of code reading the deletion bit.
Are you seriously suggesting it was beyond the ability of programmers to default the century part of a four digit year to 19?
@@jeremypnet by "default" do you mean fill in the top 2 digits when only 2 are typed in? That was done in many applications and had its own set of problems. In Excel, for example, there was a rolling limit such that "57" might become "1957" while "29" might be "2029". In another context "29" might be "1929" instead. The rules could be quite complex and still cause a few errors.
Stories like this video turn me off to programming. Not only do languages change, people come up with new tools they want you to use all the time, and then stuff like this, where a huge problem was caused because someone wanted to save a little paper and time. Then there are the stories about all of the inefficiency and back biting in companies. It makes the job sound awful.
The problem was the storage. It really was expensive per byte, and therefore, computers didn't have very many available.
The biggest problem was ivy covered professors*. In 1984 I was taking a COBOL programming course, and the professor told us to use 2 digits for the rear since it was a long time till the end of the century and we would never have to worry about it. I pointed out that was only 16 years away and I was still planning on writing software well after that. I will admit to planning on not having any money in any bank on January 1, 2000. I changed my mind when I saw how far we had gotten at fixing the problem.
* From one of the songs of Tom Lehrer
Finally, someone who realizes that recursion is a lie! Thank you!
Actually it's not. Only those where the compiler can optimise them away are "a lie". Funny enough, "for" and "while" loops are a lie. They are all implemented with (conditional) jumps (gotos), whereas recursion (as mentioned, if not optimised away) are done with jsrs (jump to subroutine). So you can have recursion in assembler / machine code, but you don't have the structured loops.
Loops also use "goto" at assembly level, though.
Recursion is really useful for working on recursive data types, like lists, especially multi-level ones, file systems and many more.
I'm convinced that the aversion to goto's is insane. Like, what do they think break, continue, and pass are under the hood? Conditional jumps. It's all conditional jumps.
@@robinpage2730 All of those and recursion don't have arbitrary destinations for the goto. That's why they're okay and goto isn't.
@@Blaisem there are over 100,000 instances of goto in the Linux kernel. Who knows how many in Windows NT and MacOS. Sometimes you just need to use an unconditional jump
@@robinpage2730 In the kernel yes I agree. Sorry, I thought we were talking about high-level control flows and how some languages still use goto on a high-level. I wasn't that far into the video yet.
@@robinpage2730 There are many, MANY developers that don't know jack shit about what's going on under the hood. To make _everybody_'s lives easier just make a rule to avoid goto. However, you can do whatever you want if you're the only one who's going to look at your code. Ever.
Wouldn't an implementation that uses loops actually also look similar as the goto version? It's all just jumps at the assembly level after all...