2026-07-29 00:10:26 veltas, Exactly, your normal program logic can deal with the normal, and exceptions handle the exceptional. 2026-07-29 01:44:29 Shark8: even if it was managerial interference, it still resulted in the rocket failing in a way that was particular to Ada and wouldn't have happened with any other language I know of except for Python 2026-07-29 01:45:13 (the uncaught exception in question was from an arithmetic overflow) 2026-07-29 01:48:04 xentrac, The overflow was physically impossible, proven that way, and modeled in the code for the Ariane 4. The managers pushed code-reuse of the 4. 2026-07-29 02:13:12 Yes. And under other circumstances having your inertial navigation system produce wrong answers could be fatal. But as it turned out that wasn't the case this time. 2026-07-29 02:24:15 In this case, though, it was two decisions in the design of Ada that proved fatal: the decision to make arithmetic overflow throw an exception, and the decision to terminate the program in the case of an uncaught exception 2026-07-29 03:18:01 xentrac, IIRC, It didn't terminate the program though; it correctly initiated self-destruct. The irony is that the code was only needed for those first few moments of launch. -- But one thing that isn't mentioned much, is after the error was fixed Arianne became a very reliable system. 2026-07-29 03:18:22 (Sorry about the tardy reply; I was out for a bit.) 2026-07-29 03:30:21 It wasn't needed at all on the Ariane 5, I believe, so initiating self-destruct was incorrect. Or, rather, vectoring the rocket's thrust far to one side was incorrect, and self-destruct was a correct response to that 2026-07-29 03:31:19 I have three relevant bookmarks in http://canonical.org/~kragen/human-folly/tag/ariane5.html for those who are interested 2026-07-29 08:24:28 The cause was definitely as Shark8 said not proving the new revision of the design with old code 2026-07-29 08:25:06 Yet also one can comment on how the language affected the way it dealt with this exceptional situation 2026-07-29 08:25:40 I think throwing an exception is fine, the issue is making sure you are catching and dealing with all exceptions correctly, and enforcing that 2026-07-29 08:27:10 And a catch-all self-destruct was not the right handler for that arithmetic exception, but what should the code even have done in that situation where arithmetic was overflowing? It was doomed from the second they tried to use old code with new hardware without reproving it 2026-07-29 08:28:37 I guess a better exception handler for arithmetic overflow might have been to try and just return thrusters to zero degrees, if that was possible, but you're already losing control of the rocket at that point 2026-07-29 08:29:46 It's not unlike running firmware for an old GPU on a newer GPU and wondering why it doesn't work, and then blaming the language the old firmware was written in 2026-07-29 08:30:15 No idea if it applies to this case specifically, but I'd suspect that too much faith in the "safety and correctness" of the language might've made the developers (whether managers or coders, or both) pay less attention to the code itself. 2026-07-29 08:30:36 Probably the managers but maybe the coders too 2026-07-29 08:30:48 And we're watching people re-learn this with Rust right now 2026-07-29 08:31:36 But unfortunately correctness, stability, security, can't be solved entirely by a language. There is no free lunch 2026-07-29 08:34:43 But if I had to write something safety-critical I'd probably use SPARK, I just wouldn't expect it to do my job for me 2026-07-29 08:35:57 Like I've said before, unless Rust (or Rust programmers - not sure who's to blame for it) learn to properly employ dynamic linking capabilities of Unix-like (and not-so-Unix-like) systems, Rust is a no-go for me personally, hence I only pay attention to the cases something I use gets a Rust-rewrite - so that I can start looking for alternatives. 2026-07-29 08:35:57 Well, except, perhaps, for embedded software - there's hardly much reason to use shared objects on 8-bit AVR, or even 32-bit ARM Cortex-M3, so I guess I can consider using Rust there, if possible. 2026-07-29 08:36:31 Well the only serious safety code I've written was flight certifiable code and that was all written in assembly and C (because it was boot firmware) 2026-07-29 08:38:08 And if it was indeed safe it was because we followed a process, and reviewed it all, simulated it, tested it, etc. We did follow some safety standards for C, and also used static analysis, but relying on that was insufficient for certification 2026-07-29 08:38:47 And you can follow that process and still mess up, e.g. Boeing 2026-07-29 08:39:55 Although I would say they didn't follow it in good faith, and again managers were to blame 2026-07-29 08:42:03 Static analysis is fairly limited, AFAICT. Unit tests is something I have experience with, but I wonder if there're other techniques that an amateur programmer like me can apply? Is there perchance some guide on how to use, say, fuzzing? 2026-07-29 08:44:53 Proprietary static analysis is pretty strong, we didn't use an open source thing 2026-07-29 08:45:44 Fuzzing is the sort of thing you invent independently if you go for full line coverage but try to keep your tests black-box 2026-07-29 08:46:11 I'm not sure what a guide would have other than tips on how to produce fuzzing for different kinds of situations, that might not apply to your code anyway 2026-07-29 08:47:31 Static analysis, stuff like valgrind, and ubsan, are probably sufficient for most C code 2026-07-29 08:48:16 Alongside good code, testing, etc 2026-07-29 08:52:50 Unit testing needs integration testing too, and functional testing 2026-07-29 09:03:38 In my mental model, the program at large is one unit that comprises several subunits, which can have subunits in turn. Ideally, all of these units are to be tested. Is there something else I'm ought to cover? 2026-07-29 09:14:08 Unit testing refers to only testing what you call the subunits 2026-07-29 09:14:32 Integration testing is when you test how different subunits work together 2026-07-29 09:14:48 And functional testing would be testing the whole 'unit' as you'd call it 2026-07-29 09:16:00 So your terminology is a bit different to the norm, 'unit' tends to mean just one module or file in the context of testing 2026-07-29 09:35:35 I have to admit I'm both seeing and not-seeing much difference. On the one hand, the closer to the top, the more the code tends to deal with things you cannot quite control. Such as when writing a network client, testing it as a whole would involve connecting to a server - which, often enough, is /not/ feasible to make a part of your test suite. 2026-07-29 09:35:35 On the other, I have libfoo.c and libbar.c as 'units,' but why can't I consider main.c yet another unit - even if it relies on libfoo, libbar, and libc? Or, IOW, I might not test integration explicitly, but I still test the higher-level code that relies on lower-level units proper, which, if properly done, I expect to uncover integration issues as well. 2026-07-29 10:28:00 You can call it a unit, it just won't make sense in context of normal testing termonology 2026-07-29 10:28:30 Integration testing is probably not necessary for most C code as long as you do the high-level testing 2026-07-29 10:28:51 But one advantage of integration testing is it helps diagnose where the issue is, in integration between two or more units 2026-07-29 10:29:16 The last place you want an automated test fail is in a functional test, having previously passed unit tests 2026-07-29 10:38:07 Looks like Ariane 5 exception was raised by pre-flight code that was still running after take-off 2026-07-29 10:38:25 So if that code had been handled properly it probably would have worked fine 2026-07-29 10:39:48 And they did actually analyse which operations could throw exceptions, and handled them for most vars, but didn't handle it for the var in question and never explained why 2026-07-29 10:40:39 This is the big problem with a process like this, you can have all these reviews and analysis but you can't make engineers *think*, they have to do that themselves 2026-07-29 10:57:34 iv4nshm4k0v: Rust is indeed getting used on Cortex-M3 2026-07-29 10:58:43 iv4nshm4k0v: static analysis can be arbitrarily rigorous. Hypothesis and other "property-based testing" or "generative testing" libraries kind of straddle the boundary between unit tests, formal methods, and fuzzing 2026-07-29 11:00:00 Hypothesis tutorials may be of interest 2026-07-29 11:00:58 veltas: I think they did (as Shark8 said) do some range analysis to prove that the variable in question could never overflow with Ariane 4's flight parameters, so they could avoid the runtime overhead of handling the exception in that case 2026-07-29 11:09:29 And the teams all decided they didn't need to do this for Ariane 5 .... for some reason 2026-07-29 11:09:47 What's interesting in the report is how little justification they had for all the related decisions and lack of handling 2026-07-29 11:31:06 the marvelous, secure, and safe Ada didn't prevent Ariane 5 from blowing up 2026-07-29 16:29:33 X-Scale, Yes, yes, but tell me if you were writing software for simulating Ford Model-T and -A, and you had the speed as a value that could be 0..100 (well over its top speed), and then someone tried to add modern race-cars to the simulation, is the simulation a piece of junk because it crashes when speeds exceed 100? Or is violating the specifications and/or justified-assumptions of the software you're working with outside the scope 2026-07-29 16:29:33 of the language? 2026-07-29 16:38:30 02hi, how common is metaprogramming in forth projects and code that isn't like a compiler etc 2026-07-29 17:00:32 pyzozord: Somewhat common 2026-07-29 17:00:43 What sort of metaprogramming are you thinking of 2026-07-29 17:07:41 02i'm not that familiar with forth but EXECUTE DOES etc 2026-07-29 17:12:31 EXECUTE is not metaprogramming, it's merely indirection. IMMEDIATE is metaprogramming. 2026-07-29 17:18:02 02i guess i mean everything that can't be directly transpiled to a static language like c without including a runtime forth interpreter 2026-07-29 18:08:47 pyzozord: depends on the application. For me, I don't intentionally rely on things that would actually need the runtime interpreter, but sometimes it's really convenient to be able to leverage it to extend things. 2026-07-29 18:10:53 02hmm yeah it's hard to tell 2026-07-29 18:11:23 02i have an impression that those features are much more common in forth than other languages but it's based on mostly just ai responses so i don't really know 2026-07-29 18:24:39 in one of my applications, there's 31 namespaces (of 162, including additions to my standard ones) that contain words that directly use the runtime interpreter & compiler. The definitions comprise 111 uses out of 2575 definitions. 2026-07-29 18:25:34 So roughly 4.5% of the words in this application would need the underlying interpreter/compiler 2026-07-29 18:41:36 02hmm yeah that's quite a lot 2026-07-29 18:41:55 02especially if this is representative of an average application 2026-07-29 18:43:52 I don't know if I'd consider my programs as average for Forth 2026-07-29 18:53:22 at the least, my systems are non standard, which probably affects the programs written in them 2026-07-29 18:55:36 if we consider IMMEDIATE to be metaprogramming, that'd be something I don't use often. E.g., in my konilo forth, I have three immediate words: [ ] ; 2026-07-29 18:57:05 I do a lot more involving templated creation of words/data structures, and runtime lookups of information. 2026-07-29 20:31:25 02yeah that's also tricky with forth 2026-07-29 20:31:33 02forth programmers are like cats 2026-07-29 20:31:39 02each one doing their own thing 2026-07-29 20:31:48 02so its hard to tell whats common 2026-07-29 20:50:11 I'd say most Forth programmers are using a relatively standard dialect, actually 2026-07-29 20:50:44 When you said metaprogramming I did think of thinks like IMMEDIATE , but wasn't sure if you meant e.g. DOES> 2026-07-29 20:51:01 I've used both a fair amount, but it just depends on the kind of application 2026-07-29 20:51:28 And I would guess in practice neither of those is used frequently, but they do get used. Lots of simple programs don't really call for either 2026-07-29 20:51:40 But when they do call for them they're there, and it's useful to have that power