Why use SQL for authentication and authorization? I understand that the point of SQL is so that the query optimizer can create an efficient execution plan, but there is no need for that when it comes to configuring auth, right?
I think at my day job it's used so that a bunch of things can connect to the production database to siphon off data for BI/do ancillary tasks (owned by other teams) without messing anything up, while the main business application that actually writes to the database has the ability to do pretty much everything.
GP is correct. Ivanov or Ivanova would generally be surnames, whereas Ivanov or Ivanov[n]a would be patronyms. In Russian culture, they generally don't use matronyms. And yes, it is indeed common in Russia to refer to individuals whom you are not close with using their surname, similar to Japanese culture.
In high school, we referred to our teachers by honorific and surname, and we were also addressed by surname, even by our peers.
When I rewatched the Harry Potter film series this year, I began paying attention to how Harry was addressed. Draco Malfoy called him "Potter". So did many teachers: "Mr Potter". He who must not be named called him "Harry" and many epithets like "the boy who lived". Hagrid and Professor Dumbledore, at least in private, called him "Harry" all the time.
This is especially interesting, because "Potter" is a homophone with the Latin Pater, meaning "Father".
Only ever heard of matronym use as a joke or very archaic.
Referring with surname only is a hierarchy assertion thing, and somewhat rude - boss would talk down to subordinate like that, or teacher to student.
When talking "up" or "sideways", or "down" but without a desire to assert superiority a name+patronymic is usually used, which reflects a respectful distance while not slipping into rudeness or overt familiarity. Sadly, it is mostly disappearing and giving way to Western "name-only".
And then, to emphasize familiarity, some groups adopt way of referring to each other by patronymic only :)
The relative difference is so absurdly small to be irrelevant at any realisable input size. At least that's my read; e.g. even at n=10^80 (~number atoms in universe), the relative difference is ~0. That's still probably underselling how similar this is to n log n.
this is how all the proofs today are looking, they seems so minimal even when compared to minor improvements in these fields from that last 10 years im wondering why even publish these and not just make research notes public
Arrays are hash tables. You can implement a very simple hash table from a tutorial, but can you implement a sophisticated one? What about a concurrent hash table?
Yeah, I'm pretty sure we made hash tables in the first C class I took in college in my second semester freshman year. If you can make a linked list, and then make an array of them, and a function to map keys to array indexes, you have a hash table. Whether it's actually performant is entirely a separate question, but a naive hash table is still a hash table.
Hash tables are awesome. They are both an incredibly simple data structure and a seriously deep rabbit hole. Most of the complexity comes from collision resolution [1], and how you handle resolution largely determines what kind of hash table you have. There are at least dozens of collision resolution approaches. The simplest, and probably the one you implemented in your undergrad C class was open addressing. That’s also what I implemented as an undergrad. But there are many more approaches, some quite a bit more complicated, and many of them let you continue to shave off asymptotic costs when you run collision resolution, or they improve locality for typical lookups, allowing better cache utilization, etc. Hash tables are super fun to play with, and for full effect, you really do need to implement them in something like C.
I only skimmed the linked article, but I do wonder whether the author ever realized that they needed to think about scope rules. I searched for the word “scope” but never found it. Closures seriously complicate language design and things get painful and counterintuitive unless you use lexical scope (or… you know… you like pain).
Yeah, I learned about a bunch of the other algorithms later (forgetting the names, but stuff like "move to the next slot rather than putting collisions into buckets" and "hash a second time if you hit a collision"; I'm sure I'm forgetting some of the nuances).
> Closures seriously complicate language design and things get painful and counterintuitive unless you use lexical scope (or… you know… you like pain)
Well if you like both lexical scope and pain, there's always lisp!
You might end up founding one of the first e-commerce sites, sell it for a handsome payday, and then create the first startup accelerator and make insane amounts of money while transforming the industry.
Maybe in JavaScript... but there is a topic called datastructures, where arrays are arrays, and hashtables are hastables. If people say this without a flip of an eye I'm not surprised why people write stuff like
> I thought that hash tables were something that were basically impossible to make in C
reply