nunuvit

It's a problem across all subjects.

Out of necessity, academia historically selected for students who could learn from being read to just once without much context, and there was little pressure to fundamentally change the education format. It's very easy to better serve most modern students by actually designing the program for those students for a change.

Debates over this get muddled by zero-sum concerns. E.g. catering to the average student hurts the top performers; putting applications first replaces rigorous education with training.

It's not blackmail in the first place. There were no secrets to reveal since everything was published online, and it's legal to sue and report a possible crime. Speculating about the consequences doesn't make it blackmail.

Science fiction is great like that, isn't it? The only limits are the author's imagination.

Thank you for the tutorial! I don't mean to be greedy, but would you mind sharing your top MS Word typography tip that you think people should know? Aside from this one.

In engineering practice, we often start using math without first consulting numerical analysts. It takes a long time to identify and fix the inevitable issues, which eventually becomes a lesson we have to teach students and practicing engineers because the field has accumulated so much historical baggage from doing it the wrong way.

As an example, early device models for circuit simulation were not designed to be numerically differentiable, leading to serious numerical artifacts and performance issues. Now we have courses dedicated to designing such models, and numerical analysis is used and emphasized throughout.

Is there anything today that you look at and think "yeah, they're gonna need to fix that at some point"?

I think the future of these languages is largely as a target for code generation and transformation. Their legacy tooling-unfriendly designs is what's slowing this transition.

> but the "ecosystem" just wasn't there

I don't think it ever will be, either. Ada's "ecosystem" is really the tooling. I've seen plenty of Ada, but there's always been zero (or very nearly zero) exchange of code into or out of the company. There's not much opportunity to grow a natural ecosystem like that. The tooling for C and C++ is catching up, facilitating model-based design code generation, which is the direction Ada's niche is heading. Ada didn't entrench itself as a target language early on, missing another chance to surge in popularity.

It's too late to edit my original comment. I was responding to the part about when you're breaking a lot of stuff all the time.

Checking limits is for preventing breaks. Visualizing heat is for troubleshooting when they happen anyway. You should do both.

I can't edit the comment now, but I worded it wrong. The quote only applies to exceeding maximum values. The visualization is much more useful if you've calculated worst-case. I use a thermal camera all the time.

It takes 5 minutes to show someone how to read maximum values off a datasheet, and it makes the visualization 100x more useful.

That's exactly what I'm saying.

I explained in my other comment how it's a great tool for other jobs, but the wrong tool for this job. You won't learn how not to break things by ignoring the proper tool.