4 ms·

After 15+ years of being an SRE in finance across firms ranging in size from 2 people to 350K people, I've come to the following conclusions: 1. There are no s

After 15+ years of being an SRE in finance across firms ranging in size from 2 people to 350K people, I've come to the following conclusions: 1. There are no solutions, only tradeoffs. Sure. You win in the OP example of easy to add things but you lose in the relational aspects. You could say the same thing in reverse, using a RDBMS make it much easier to do join based lookups but then it's harder to update 2. At the end of the day, it doesn't matter b/c some other layer will do what your base layer can't I've seen some really atrocious approaches to storing data in systems that were highly regarded by the end users. How did this happen? Someone went in and wrote an abstraction layer that combined everything needed into an easy to query/access interface. I've seen this happen so many times that whenever people start trying to future proof something I mention this point. You will get the design wrong and/or things will change. That means you either change the base layer or you modify/create an abstraction layer.

Waterluvian 4y ago
Re #1: I agree. But with a pedantic semantic distinction: There are a lot of objectively wrong ways to do something. But among all the right ways, there are trade offs.
- Xeoncross 4y ago
  You nailed it on the head (and people wonder why there are so many 'bad' laws passed).
- balfebs 4y ago
  When I was a Perl programmer, in our shop we amended the motto "There's more than one way to do it" to "There's more than one way to do it, but most of those ways are wrong." The Perl community themselves eventually extended the motto to "There's more than one way to do it, but sometimes consistency is not a bad thing either"
- 0xbadcafebee 4y ago
  But even if you do something objectively wrong, it can still work out anyway. Look at every Perl script written by non-programmers. Horrifying mess of bullshit, and you try to read the code and think this shouldn't even be parseable, but somehow the script works. There is no right or wrong, only working and not-working.
  - ALittleLight 4y ago
    If someone has written their own bubble sort to sort a list of numbers and you replace the custom bubble sort with a built-in sort - there really aren't tradeoffs to consider. Your method will be faster, easier to understand, more robust. Their method works, but is strictly inferior.
    - 0xbadcafebee 4y ago
      For the same result, within the same accepted parameters, the 'inferior' method is really identical, with no tradeoffs. By measuring the result rather than the design, you see the true value rather than the theoretical value. If you only need to move a 60lbs bag of sod across the yard, carrying it yourself, using a wheelbarrow, and using an F-150 Lightning all have exactly the same result and none is inferior. They can all be done in the same time by the same person with no real difference. It's only when the parameters change, like moving 400 bags of sod, that the first two require tradeoffs.
      - 1123581321 4y ago
        This is a thread about reddit and other scaled databases; it's given that the discussion is in 400+ sod bag territory...
      - Banana699 4y ago
        >For the same result You're assuming that the "result" data structure is only a single boolean, is_task_done. That's not how most things work, GP's bubble sort will pretty damn well show up in locked-up UIs and injured-dog-slow bottlenecks, that's as observable as the Sun at 9 AM. That would happen pretty fast too - don't delude yourself with "Move Fast And Fix Later" with quadratic algorithms - 1000 squared is a million, and at 10000 it is a hundred millions. >carrying it yourself, using a wheelbarrow, and using an F-150 Lightning all have exactly the same result and none is inferior Off course not, the method used would show up in your health and exertion data, your fuel costs, the amount of noise and heat you emit while doing the work, etc... Every single way of observing a boolean is_bag_moved result can also be used to observe a metric measuring those things, and thus determine the method you used. You're trying to defend an extremly strong claim : If algorithms A and B gives the same output in memory, NOTHING else matters. Here's an concrete example, consider the following sequence of algorithms: Algorithm 0 : Print("Hello") Algorithm 1 : do {Nothing} then Print("Hello") Algorithm 2 : 2.times do {Nothing} then Print("Hello") ... Algorithm N : N.times do {Nothing} then Print("Hello") This is an infinite sequence of algorithms that all have exactly the same behaviour in a time-space agnostic manner. Would you say every algorithm in this sequence solves the proplem of printing "Hello" exactly as well as every other algorithm ? If yes... interesting. If no, then your original claim is false as-is, it needs qualifying with what observable behaviour means, as this example shows, it's a difficult notion to exactly define, a naive definition of "Everything that can be observed in computer memory or on screen" would leave you open to ridicilous conclusions.

Waterluvian 4y ago

Re #1: I agree. But with a pedantic semantic distinction: There are a lot of objectively wrong ways to do something. But among all the right ways, there are trade offs.

Xeoncross 4y ago
You nailed it on the head (and people wonder why there are so many 'bad' laws passed).
balfebs 4y ago
When I was a Perl programmer, in our shop we amended the motto "There's more than one way to do it" to "There's more than one way to do it, but most of those ways are wrong." The Perl community themselves eventually extended the motto to "There's more than one way to do it, but sometimes consistency is not a bad thing either"
0xbadcafebee 4y ago
But even if you do something objectively wrong, it can still work out anyway. Look at every Perl script written by non-programmers. Horrifying mess of bullshit, and you try to read the code and think this shouldn't even be parseable, but somehow the script works. There is no right or wrong, only working and not-working.
- ALittleLight 4y ago
  If someone has written their own bubble sort to sort a list of numbers and you replace the custom bubble sort with a built-in sort - there really aren't tradeoffs to consider. Your method will be faster, easier to understand, more robust. Their method works, but is strictly inferior.
  - 0xbadcafebee 4y ago
    For the same result, within the same accepted parameters, the 'inferior' method is really identical, with no tradeoffs. By measuring the result rather than the design, you see the true value rather than the theoretical value. If you only need to move a 60lbs bag of sod across the yard, carrying it yourself, using a wheelbarrow, and using an F-150 Lightning all have exactly the same result and none is inferior. They can all be done in the same time by the same person with no real difference. It's only when the parameters change, like moving 400 bags of sod, that the first two require tradeoffs.
    - 1123581321 4y ago
      This is a thread about reddit and other scaled databases; it's given that the discussion is in 400+ sod bag territory...
    - Banana699 4y ago
      >For the same result You're assuming that the "result" data structure is only a single boolean, is_task_done. That's not how most things work, GP's bubble sort will pretty damn well show up in locked-up UIs and injured-dog-slow bottlenecks, that's as observable as the Sun at 9 AM. That would happen pretty fast too - don't delude yourself with "Move Fast And Fix Later" with quadratic algorithms - 1000 squared is a million, and at 10000 it is a hundred millions. >carrying it yourself, using a wheelbarrow, and using an F-150 Lightning all have exactly the same result and none is inferior Off course not, the method used would show up in your health and exertion data, your fuel costs, the amount of noise and heat you emit while doing the work, etc... Every single way of observing a boolean is_bag_moved result can also be used to observe a metric measuring those things, and thus determine the method you used. You're trying to defend an extremly strong claim : If algorithms A and B gives the same output in memory, NOTHING else matters. Here's an concrete example, consider the following sequence of algorithms: Algorithm 0 : Print("Hello") Algorithm 1 : do {Nothing} then Print("Hello") Algorithm 2 : 2.times do {Nothing} then Print("Hello") ... Algorithm N : N.times do {Nothing} then Print("Hello") This is an infinite sequence of algorithms that all have exactly the same behaviour in a time-space agnostic manner. Would you say every algorithm in this sequence solves the proplem of printing "Hello" exactly as well as every other algorithm ? If yes... interesting. If no, then your original claim is false as-is, it needs qualifying with what observable behaviour means, as this example shows, it's a difficult notion to exactly define, a naive definition of "Everything that can be observed in computer memory or on screen" would leave you open to ridicilous conclusions.