Takes me back 45+ years. Use XYZZY all the time in conversation and almost no one understands the reference but they use it too. Adventure!

Since forever? Or at least VS 6.0 anecdotally speaking. And with no end in sight. But so what? For the facilities it gives me which translates directly to speed of accomplishing things buying the bigger machine is well worth it compared to how much get paid. And this is my long term view after 30 or so years or using VS.

Have I (to your point) occassionally has a use for this?...Yes. Is this overkill?...Yes. This is what you get when you open source things and can't think of a compelling reason to say "no". That being said there ARE some useful things that have come from the open sourcing. BTW, Top Level command NOT being one of them! :-)

Impressive! I never went below the UART interrupt level. Your mention of 8MHz reminded me of one of the things I tell my once a week Data Structures class that I teach - namely, that when I first started working with microprocessors the clock rate was in KHz, not GHz as they now are.

Z80! Haven't heard that for almost 40 years, I used to write assembler for that, too. You know this really means we are all a bunch of old farts!

Wow, this really took me back 40+ years. While I never "raced the beam" I did plenty of other coding around interrupts (actual REAL interrupts, not the software abstracted ones of today) versus syncing up with the code.

years ago I started actively not remembering details but remembering where to FIND the detail.

Lazy and dumb are not mutually exclusive... ;) but given it is one of those unlikely to be a troll. You should see what I get in my Data Structures college course. I emphasize to them it is not their fault up to now because prior professors have not required even minimal standards, but it IS their fault from this moment forward because now I have explained to them how the real world will look at their efforts.

Besides my full time job as a developer I also teach Computer Science one night a week at a community college. My observation is that the focus for young developers/students is HOW to do things rather than WHY things need to be done. Having mentored many developers over the last 40+ years I always focus on the WHY, because once they understand the WHY the HOW not only becomes fairly obvious they find they often have multiple HOWs to choose from. This is not unique to Computer Science, my 3 daughters are all teachers, High School English, High School Biology, and Elementary school. There is hope, perhaps slight and teacher dependent. The Elementary school teacher pioneered Common Core math in her school district and discovered kids she had taught math to that way in 1st and 2nd grade had significantly better performance in 4th grade. Of course, not universally, but sufficient to clearly see a difference.

Probably not a reasonable answer because this is from back in the mainframe days but I seem to recall the Unisys A-Series operating System MCP (yes we laughed when Tron came out) was a million - ish lines of code. And not assembly code, written in NEWP, an Algol loke language.

Similar to the ID-10-T error.

While I completely agree with all of the POTENTIAL horror stories people have raised...points to the teacher for accepting the challenge and points to the student for stepping up to a challenge. This IS where knowledge comes from. BTW, 40+ years coding in the real world and mentoring many people. If you want to know true despair do what I do: teach a college course one night a week in C programming to a bunch of students who only saw the dollar signs of software development. Of the 59 remaining (out of initial class of 74) there are perhaps 5 - 8 that might have a future in software development.

Ah Python, the place where critical thinking goes to die... :-)

Exactly right, THEY need to understand they have a problem they need to fix before someone with the knowledge and skills (and mandate) can go fix it. Otherwise it is lose lose. You can't teach a pig to sing, first you'll be unsuccessful, second, it will just irritate the pig. :-)

As an atheist I agree with everything you said (except, obviously the Jesus part). I also agree with the first reply that said to just put the truth out there (after making sure it IS the truth) and whatever happens, happens. Truth IS important, for its own sake but also for setting the example that truth matters. No need to comment on the other person at all, as the other replier said, their reputation is their own.

I work out in the real world writing C#, JavaScript, TypeScript, and SQL everyday. I also teach one night a week at a community college, Data Structures in the Spring semester and a programming language (currently C) in the Fall semester. My observations is that Python is a scripting language and, like other scripting languages, useful for doing things a little more rapidly but inexactly. My observation of students who want to know why they can't use Python in the Data Structures class (college requires C++ for transfer reasons) is that the new crop of students really don't understand what or why they are doing things but are monkey-see, monkey-do programmers. Of course that doesn't apply to the 5 - 10 % of my students who really DO understand how a computer works. The net being, a lot of computer is "close enough is good enough" in our world of today. Obviously that doesn't apply to certain financial type transactions in banking, real estate, etc, but DOES apply to a lot of things that are just providing info.

There is a lot of angst and wisdom in all of the other replies. My take is that, like many things of late, developers do not use judgement and assume "if a little is good a lot is better" without doing the analysis of what is really needed. I was doing "Dependency Injection" (hate the term, it should actually be "Dependency Abstraction") before the term was ever coined simply because I needed a little bit of it to make certain things more general. As to why it seems simpler these days perhaps it is because the tooling (such as Unity, et al) have made it simpler to use and when you're less concerned about how the gas ignites to drive the piston it is easier to see the utility of the engine. But that simpler tooling comes at a price, namely we don't always know what is going on under the hood, which can be both a good thing and a bad thing depending on what we're doing and the issues being faced.

Yep, as he said you can set an option. Yep, it's a breaking (unbreaking by config) change. Their heart is certainly in the right place in trying to catch issues as you code. I can't think of a better way to go about it and they DID us notice a starting a couple of releases back that it was coming. I know that doesn't help your brief WTF shock. :-) As someone further on said, a reasonable idea and leads to less breakable code and the fix isn't tough in the singular instance, but it depends on how many instances you have how big of a task to make the changes. Good luck!

Being kind is fine, however the brutal truth should be delivered, albeit in a kind way.

While I agree with everyone's comments I would even go so far as to propose that (in the code you showed) that DoX detect its own error and return a meaningful result that cuold be acted on programmatically. And to protect against THAT going wrong there would be a try/catch at the outermost level.