Random thought of the day
-
@MrL said in Random thought of the day:
@topspin said in Random thought of the day:
betaverse.
I keep seeing this stupid name and thinking to myself "a whole new internet for cucks? That's a bit much".
Well, since "metaverse" is a stupid facebook buzzword that doesn't exist and I hate how they (and corresponding press) keep talking about building it as if it had any kind of meaning, I'll stick to @Applied-Mediocrity's mockery term. Anyone who uses the term "metaverse" otherwise without disclaimers needs to be slapped in the face.
-
-
"A whole new internet for cucks" is a pretty accurate description of Facebook.
-
@topspin well, in the book it was taken from it does have a meaning. Just as “the Matrix” was given a description in Neuromancer 15 years before the film of the same name came out.
Snow Crash is alright as a book, and its author has come out and said that whatever Facebook is doing is nothing to do with him, they just “took inspiration” from his book…
-
@Gąska said in Random thought of the day:
I'm a 90s kid, so everything before 1991 is equally old to me.
Sir, either you leave immediately on your own, or I'm calling the security service to escort you out.
-
@Zerosquare said in Random thought of the day:
I'm calling the security service
Don't look at me; I'm very insecure.
-
@HardwareGeek said in Random thought of the day:
@Zerosquare said in Random thought of the day:
I'm calling the security service
Don't look at me; I'm very insecure.
Don't worry, the security service works by nagging younguns.
-
The naive representation of ownership (ie composition) is backwards in SQL compared to most programming languages.
Most languages: A contains a group of B
class A { List<B> Foo; ... }
SQL: Many rows of the table for B have the same value in a field that is a foreign key to the id of the table for A. Pseudo-SQL because to actually write the right things here...
CREATE TABLE a (id INT AUTOINCREMENT, ...); CREATE TABLE b (id INT AUTOINCREMENT, a_id INT NOT NULL, ..., FOREIGN KEY fk_a_id_b REFERENCES a(id));
One seems to say "A has a bunch of Bs in it"; the other says "If I have a B, I can find the A that owns it." I hope no one would ever write SQL where table
a
has a bunch of ids in a single "list-type column" (if such a thing exists) for rows in tableb
.I think I understand why this is (set-based logic vs object-based logic), but it's an oddity I just recognized.
-
@Benjamin-Hall "abstract entity relationships are inherently tied to physical structure of data" is just one of many reasons why OOP sucks.
-
@Gąska said in Random thought of the day:
@Benjamin-Hall "abstract entity relationships are inherently tied to physical structure of data" is just one of many reasons why OOP sucks.
But SQL (the one that sticks out to me as "unintuitive") isn't the OOP one, and it's not tied to any of the physical concerns (where SQL tables very much are). The OOP version makes total sense from a naive impression.
Unless I'm totally misunderstanding things.
-
@Benjamin-Hall said in Random thought of the day:
@Gąska said in Random thought of the day:
@Benjamin-Hall "abstract entity relationships are inherently tied to physical structure of data" is just one of many reasons why OOP sucks.
But SQL (the one that sticks out to me as "unintuitive") isn't the OOP one
Exactly. It's the other one that sucks.
and it's not tied to any of the physical concerns
In theory. Because in practice, it's impossible to decouple data representation from logical hierarchy in OOP. That's the whole point of OOP, to tightly couple data and semantics and to encapsulate it from the outside world.
The OOP version makes total sense from a naive impression.
Emphasis on "naive".
(It's half-, don't take it too seriously.)
-
-
@Gąska said in Random thought of the day:
In theory. Because in practice, it's impossible to decouple data representation from logical hierarchy in OOP. That's the whole point of OOP, to tightly couple data and semantics and to encapsulate it from the outside world.
And often "array of structs" representations have performance problems over "struct of arrays". Converting one to the other isn't easy once you're deep in the OOP.
-
@topspin for certain values of "often".
-
@Gąska said in Random thought of the day:
@topspin for certain values of "often".
Whenever performance matters enough to care?
-
@topspin and even then only if you iterate over all B's in the system more often than you iterate over B's of a certain A.
Coincidentally, this is true 100% of the time in basically every video game ever.
-
@topspin said in Random thought of the day:
And often "array of structs" representations have performance problems over "struct of arrays". Converting one to the other isn't easy once you're deep in the OOP.
Only if you insist on having the object be the storage. It very much doesn't have to be. It could simply hold indices into the arrays, and from the perspective of the world outside the object/class it would look extremely similar. Yes, it won't work if you're used to doing direct field access from outside; don't do that, there are alternatives.
This all sounds almost exactly like the row-oriented vs column-oriented storage debate that's been going on in database circles for quite a while. I don''t know that they've come to a solution either (beyond perhaps “try both and see what's best in your application”).
-
@dkf said in Random thought of the day:
“
try both and see what's best in your applicationuse both in the same application and end up with an unmaintainable mess”ed that for you.
-
@Benjamin-Hall said in Random thought of the day:
I hope no one would ever write SQL where table
a
has a bunch of ids in a single "list-type column" (if such a thing exists) for rows in tableb
.I'm working on erasing this exact fucking thing from this app, actually.
-
@Tsaukpaetra said in Random thought of the day:
@Benjamin-Hall said in Random thought of the day:
I hope no one would ever write SQL where table
a
has a bunch of ids in a single "list-type column" (if such a thing exists) for rows in tableb
.I'm working on erasing this exact fucking thing from this app, actually.
Why am I not surprised? Have I become that jaded?
-
@Benjamin-Hall said in Random thought of the day:
Why am I not surprised? Have I become that jaded?
It means you have finally reached IT
enlightenmentdisillusionment.Congratulations, @Benjamin-Hall. Your training is over, you're one of us now.
-
Millennials can't stand to listen to any music more than a couple of years old. Even stuff they liked a couple of years ago.
Meanwhile, I grew up in the sixties listening to not only stuff that was out at the time but all the music my parents and grandparents liked from ten to maybe thirty years before. I didn't like all of it, but I listened, and some of it I did kind of like. And in the intervening years I found out about music that was even older and got into a lot of it.
I've got a bookmark in my browser to the Cylinder Preservation Project and a TuneIn favorite to the 1920s Radio Network, because there's music on both of those that I really like.
Spotify and Pandora can't even keep up with me.
-
@Benjamin-Hall said in Random thought of the day:
I hope no one would ever write SQL where table a has a bunch of ids in a single "list-type column" (if such a thing exists) for rows in table b.
Brillant developers have been doing that all the time for at least 30 years.
Usually in a comma separated text field or similar, but these days they often hide it in a JSON column.
-
@nerd4sale said in Random thought of the day:
@Benjamin-Hall said in Random thought of the day:
I hope no one would ever write SQL where table a has a bunch of ids in a single "list-type column" (if such a thing exists) for rows in table b.
Brillant developers have been doing that all the time for at least 30 years.
Usually in a comma separated text field or similar, but these days they often hide it in a JSON column.Mine is a csv separated column that references a TEXT column holding a json object where the top object property names are the UUIDs from the first!
-
@Tsaukpaetra said in Random thought of the day:
Mine is a csv separated column that references a TEXT column holding a json object where the top object property names are the UUIDs from the first!
-
@da-Doctah said in Random thought of the day:
I grew up in the sixties listening to not only stuff that was out at the time but all the music my parents and grandparents liked from ten to maybe thirty years before. I didn't like all of it, but I listened, and some of it I did kind of like.
I grew up in the sixties listening to pretty much only what my parents and grandparents listened to, because at the time I didn't much like the popular music of the time. I've since learned to like it, but not when it was new. (I just barely remember watching the Beatles on the Ed Sullivan show. I'm not sure how old I was, but I couldn't have been more than 6, because we moved from that house when I was 6. My parents didn't like it, so I didn't either.)
And in the intervening years I found out about music that was even older and got into a lot of it.
I've mostly gotten into music that was newer, because there isn't a lot of extant music older than what I listened to growing up.
I've got a bookmark in my browser to the Cylinder Preservation Project and a TuneIn favorite to the 1920s Radio Network, because there's music on both of those that I really like.
Cool!
-
@da-Doctah said in Random thought of the day:
Millennials can't stand to listen to any music more than a couple of years old. Even stuff they liked a couple of years ago.
- You realize most millenials are over 30 now?
- If anything, millenials despise the music of the last couple of years. And this was as true in 2005 as it is now. Music 10-20 years ago was always better than now, regardless of what year it is. We've had an entire global subculture dedicated to hating recent music FFS!
-
@Gąska said in Random thought of the day:
Music 100-200 years ago was always better than now, regardless of what year it is.
FTFM
-
@HardwareGeek You're older than I thought
-
@HardwareGeek said in Random thought of the day:
@Gąska said in Random thought of the day:
Music 100-200 years ago was always better than now, regardless of what year it is.
FTFM
If it wasn't clear, that post was mocking the people who think that way.
-
@da-Doctah said in Random thought of the day:
Millennials can't stand to listen to any music more than a couple of years old. Even stuff they liked a couple of years ago.
Millennial here, fan of some 60s, lots of 70s through mid-90s and very little thereafter.
-
@Gąska said in Random thought of the day:
If it wasn't clear, that post was mocking the people who think that way.
Doesn't mean it's not true
-
@HardwareGeek said in Random thought of the day:
@Gąska said in Random thought of the day:
Music 100-200 years ago was always better than now, regardless of what year it is.
FTFM
The more you study music history, the better you feel about the tendency of shitty music to be eventually forgotten.
-
@dkf are you suggesting that one day in the distant future, no-one will know what a rickroll is?
-
@Arantor They're never gonna give that up.
-
@dkf and you didn't let me down with that reaction.
-
-
@Arantor That's what happens when people have known each other for so long.
-
-
@Gąska And so do I.
-
My new rebuttal to everyone who claims imperial units are more "natural" than metric:
If God didn't want us to use the metric system, why would He make Earth's circumference exactly 40,000km?
-
@Gąska said in Random thought of the day:
My new rebuttal to everyone who claims imperial units are more "natural" than metric:
If God didn't want us to use the metric system, why would He make Earth's circumference exactly 40,000km?
He also made the diameter of the sun in miles just ten times the number of seconds in a day. Tell me that's not proof that the imperial system makes more sense.
-
@Gąska said in Random thought of the day:
If God didn't want us to use the metric system, why would He make Earth's circumference exactly 40,000km?
Not God, Delambre and Méchain.
-
@dkf I'm pretty sure that's the joke.
-
Does porting an app from 16-bit to 64-bit more the performance than shim?
-
@Tsaukpaetra said in Random thought of the day:
Does porting an app from 16-bit to 64-bit more the performance than shim?
You should more the verbs.
-
@Zecc said in Random thought of the day:
@Tsaukpaetra said in Random thought of the day:
Does porting an app from 16-bit to 64-bit more the performance than shim?
You should more the verbs.
Was used on all the extra bits.
-
@HardwareGeek said in Random thought of the day:
@Zerosquare said in Random thought of the day:
@Gąska said in Random thought of the day:
why do we even bother with passwords then? Why not just make the email/SMS code the only required info?
On some sites I rarely use, I don't even bother storing (or remembering) the password ; I just use the "I forgot my password" feature to get a new one every time, because . I suspect I'm not the only one...
There's one site I use regularly that I do that. Not because I don't have the password stored in KeePass; I do. But the site will never accept it to log in (it accepts it just fine to set it; at least there's no user-visible error that some special character is not allowed, or whatever), even though I'm pasting it from KeePass, and it's the same password I've been pasting into the "new password" field for months.
This is almost always because they silently truncate the password when you set it but not when you try to login. You need to figure out what the secret actual password length is.
-
@Benjamin-Hall said in Random thought of the day:
@Gąska said in Random thought of the day:
@Benjamin-Hall "abstract entity relationships are inherently tied to physical structure of data" is just one of many reasons why OOP sucks.
But SQL (the one that sticks out to me as "unintuitive") isn't the OOP one, and it's not tied to any of the physical concerns (where SQL tables very much are). The OOP version makes total sense from a naive impression.
Unless I'm totally misunderstanding things.
A more "accurate" representation of the relationship might be to use a join table with foreign keys to each table (which you really do need for a many-to-many relationship) but it's usually more efficient to put just a foreign key from the many-table to the one-table for a many-to-one relationship.
It's an implementation detail, but I agree with @Gąska that it's OOP where it seems weirder, since SQL always allows you to follow the relationship from either side.
-
@boomzilla said in Random thought of the day:
it's usually more efficient to put just a foreign key from the many-table to the one-table for a many-to-one relationship
Only if you don't want the individual relation arc to have its own properties (labels, etc.) Once those things sprout, you've got another table of entities…