Crashes DESTROYED by CODING and ALGORITHMS.
this post was submitted on 22 Jan 2025
416 points (99.1% liked)
memes
11090 readers
2414 users here now
Community rules
1. Be civil
No trolling, bigotry or other insulting / annoying behaviour
2. No politics
This is non-politics community. For political memes please go to [email protected]
3. No recent reposts
Check for reposts when posting a meme, you can only repost after 1 month
4. No bots
No bots without the express approval of the mods or the admins
5. No Spam/Ads
No advertisements or spam. This is an instance rule and the only way to live.
Sister communities
- [email protected] : Star Trek memes, chat and shitposts
- [email protected] : Lemmy Shitposts, anything and everything goes.
- [email protected] : Linux themed memes
- [email protected] : for those who love comic stories.
founded 2 years ago
MODERATORS
"big air" is hating these revolutions [spinning fan emoji]
yea, pretty much like that
These days they'd write "AI" and you'd be none the wiser, because even if it involves a machine learning model (which is definitely not a given either), they will still have used quite a lot of coding and algorithms to tie it all together.
I like to mentally substitute these terms with "magic". Because ultimately, it just means that they don't want to explain it to you, but they need to tell you something, so you don't ask about it.
This is actually how I would start out if I were developing this algorithm. I always start with the highest-level code first, then flesh out all the details in function definitions.
If {not_broken} then {fix_it_anyway};
For a sufficiently defined "goingToCrashIntoEachOther" and "don't", isn't that basically how it works?
Well, even at that level of abstraction, it's a bit weird, because goingToCrashIntoEachOther and dont() both need the information from where a collision is going to take place, so you'd expect something to be passed into dont().
Well, and it's easy to dismiss this stuff as implementation details, but that if-statement needs to run as part of a loop. This loop should probably be on a separate thread, so it doesn't get blocked by other stuff going on. Which means access to the motors needs to be behind some form of mutex, which it needs to be able to acquire fairly quickly. And then, yeah, those implementation details quickly add up to become the part that's actually complex.
It definitely should be, but at some point in time, very intelligent people though that this was a Good Thing:
bReadLine(bPort,&arru8NumberList)
Whoah, coding and algorithms???
I think you mean magic and miracles!
Magnets, how they work?
; }
plsAndThankYou