kfitch42

I don't know much about Swedish, but I am learning Korean, and Google Translate is dangerous in a much more subtle way with Korean. In particular, in Korean you conjugate verbs (and often, choose different nouns) based on the relative age and social standing of the speaker and listener. In Korean specific translation tools (e.g. Naver) there is a toggle to select whether to use "honorifics" or not. But, Google tends to default to the form of speech (banmal) reserved for talking to young children or close friends. But, if I am using a translation tool, I probably don't know the person I am conversing with very well. As a result the translations tend to come off as very rude.

If I used Google Translate to talk to a shopkeeper, it would be roughly equivalent to saying "Hey, little buddy, how much for this?" as opposed to "Excuse me sir, what is the cost of this item?"

And this is all without considering all the weird mistranslations you can get because Korean is much more heavily context dependent than English. Korean speakers often leave out the subject or object if it can be understood from context (context that the translation tools are likely missing). So Google translate will insert pronouns (it, him, her...) to make the English flow better, but are not based on anything in the original Korean. So, if it guesses wrong, you could imagine the level of confusion that could ensue.

And then all the homonyms in Korean combined with the heavy context dependence makes for some weird translation. I once tried checking my Korean homework with Google translate, and before I knew it, I was drinking a car.

So the choices are "English" or "Platinum"? I guess English is a color scheme and/or material?

1) Software is eating the world, so a basic understanding of computers/programming/... is imperative to understanding the world they will inhabit. I think this is similar to the logic behind everyone taking English, history, etc. classes.

2) It promotes logical thinking and problem solving skills. This is much the same reasoning why everyone must take math/science classes. So, if we took some of the less "relatable" classes (e.g. geometry) in the mandated general curriculum, and replaced them with basic programming/data-science classes, that might be an improvement. Especially since it is probably easier to many students interested in creating a Minecraft mod that pulls in statistics related to the real world, than it is to get many students excited about acute vs obtuse angles.

P.S. I say this as someone who LOVED math classes in general and geometry specifically. I really did get excited about writing Q.E.D. at the end of a tough proof. But, I know I am seriously in the minority there.

Not only is this relevant to HPC environments, it also impacts the other end of the spectrum in the embedded space. When dealing with real-time requirements, you are much more concerned with the worst case performance as opposed to the average case or happy path performance.

This article makes it very clear that exceptions complicate analysis of performance. The non-local nature of exceptions mean I can't analyze performance in isolation. E.g. I can test that thread 1 always meets its deadlines (even with exceptions being thrown), then I can test that thread 2 always meets its deadlines.... but if thread 1 and thread 2 happen to throw exceptions at nearly the some time I might miss both deadlines. Who knows, maybe this means a thruster fires too long and that insertion burn fails ... and Mars has a new crater instead of a lander.

And, once you throw -fno-exceptions you are no longer using standard C++, which the standard library assumes. So, using anything that would throw exceptions on memory allocation failures is a no-go. You can work around this with extensive use of allocators (that reference enough static memory to avoid any possible out-of-memory situation)... but this is not looking like idiomatic C++ anymore, and most off-the-shelf libraries are unusable.

A completely local exceptions implementation (e.g. Herbceptions) would solve this.