In my experience, complex tools encourage fluffy programming. You mention a generic container; if I were using C, I just wouldn't use a generic container; instead, I'd specify a few container types that handle what needs handled. If there seem to be too many types, then I immediately start thinking that I'm going down a bad architecture path, using too many, or too mixed, abstraction layers, or that I haven't broken down the problem correctly or fully.
The constraints of the tool are inherited in the program; if the constraints encourage better design, then the program will have a better design. You benefit from the language providing a path of least resistance that forces intentionality. That intentionality makes the code easier to reason about, and less likely to contain bugs.
You do pay for this by writing more boilerplate, and by occasionally having to do some dirty things with void pointers; but these will be the exception to the rule, and you'll focus on them more since they are so odd.
Sometimes, but I would argue that C is too simplistic and is missing various common-sense tools. It's definitely improving, but with things like namespaces there's pretty much no risk of "too complex" stuff.
Also, I wouldn't be saying this if people didn't constantly try to recreate C++-isms in C. Which sometimes you need to do. So, then you have this strange amalgamation that kind of works but is super error prone and manual.
I also don't necessarily agree that C's constraints encourage better design. The design pushes far too much to runtime, which is poor design from a reasoning point of view. It's very difficult to reason about code when even simple data models require too much indirection. Also, the severely gimped type system means that you can do things you shouldn't be able to do. You can't properly encode type constraints into your types, so you then have to do more validation at runtime. This is also slightly improving, starting with _Bool years ago.
C++ definitely is a very flawed language with so, so many holes in its design. But the systems it has in place allows the programmer to more focus on the logic and design of their programs, and less on just trying to represent what they want to represent. And templates, as annoying as the errors are, prevent A LOT of runtime errors. Remember, every time you see a template that translates into pointers and runtime checks in C.
I used it quite a bit early on during military operations. The ability to see the timing component was key; not only would you plot the purchase locations, but you could play the timeframe of records, work out the timing so you knew the order in which they visited the locations, where they must have stopped for gas along the route. In a classic workflow, you'd then investigate the gas stations, attach them to the event with confidence intervals, pull CCTV footage, see if you can get a payment receipt, and enter all of that data back into palantir. A few days of doing this, and you can build up all a map of every aspect of the drug run; the who what when where and why. It's a fantastic organization system.
I appreciate the technical achievements here. However, I wonder how long before it’s standard practice to track all peoples movement, not just those suspected of a crime. I know of at least one YouTube channel that is always recording all traffic camera streams in Washington so there must be some State entities doing the same. Back in 2020 there was a twitch channel that would play a 9x9 grid of all the livestream footage from the George Floyd protests. I’m sure an archive of that exists somewhere on a LE server.
In the world of content moderation, we refer to this as constructive friction. if you make it too easy to do a thing, the quality of that thing goes down. Difficulty forces people to actually think about what they are writing, whether it is germaine and accurate. So generative AI, as you point out, removes all the friction, and you end up with bland soup.
Curious, could you not calibrate using a force sensor, then include the output as a learning parameter. This seams a naive approach, which likely means it has been tried early on with other low hanging fruit, but I'm curious what the analysis of that approach is. Is there a fundamental reason this wouldn't work?
The reason we don't want to do this is that it is difficult to cover all possible characteristics. Say we do single point contact localization, and 3-axis forces prediction. What happens when we have multi-point contact? The calibration has only been used to calibrate/align in a lower dimensional space. This is primarily why not needing calibration and baking this into the hardware is a lot more appealing. The user/designer no longer needs to think about the task and the dimensions of alignment required for that task.
Those three and REAMDE (which I'm currently rereading) are just fantastic. Snow Crash was very stylized; too much for some tastes, not enough for others.
IMO, Stephenson's books are too long for the stories they tell, especially the final 25-33% - those can be a real slog. I gave up on Seveneves at about 90% or the book, reading it was no longer fun. I read a handful of his prior work to completion when I was a book completionist, so I can't tell of it says anything about the nature of the novels, or my own perseverance.
I imagine the flight planning software they use was affected (so their ability to coordinate with other airport's ATC), but not their radio systems or aircraft radar (nearly all radar systems I've worked with are run on Linux, and are hardened to the Nth degree). Been out of the game for 12 years though, so things have likely changed.
I've run into #3 quite often in embedded Linux projects, especially when dealing with the Jetson ecosystem where upgrading to a modern Python is a nightmare due to all the specialized hardware. Glad to see I'm not the only one who runs into this.
As someone who spent a decade doing precision metrology with optical devices... there isn't a way to correctly measure that part with the precision they indicate in the measured values.
If you're in optical measurement and it should be around 200nm (rayleigh criterion, wavelength dependent), am I missing something? Obviously, that's just angular resolution, not measurement precision, so I'm guessing I'm missing some detail.
If I recall the precision is limited to by the wavelength of the light being used. If they are using X-Rays in the 0.01 nm to 10 nm range wouldn't that give them more precision then optical light in the 380 nm to 700 nm range?
I don't see it that way. Most of my travel (and what I assume is true for the majority) is that they are traveling to a location because of an event, be it work or personal. If I am delayed a day, then there is no longer any reason to travel, because I've missed the meeting or event. Every time this has occurred it is quite problematic.
Conversely, with a hotel, if they overbooked and I cannot stay there, there are usually quite a few locations nearby where I can get a room for a night. I've had this happen a few times and it's never been more than a minor inconvenience.
The constraints of the tool are inherited in the program; if the constraints encourage better design, then the program will have a better design. You benefit from the language providing a path of least resistance that forces intentionality. That intentionality makes the code easier to reason about, and less likely to contain bugs.
You do pay for this by writing more boilerplate, and by occasionally having to do some dirty things with void pointers; but these will be the exception to the rule, and you'll focus on them more since they are so odd.
reply