leafboi

>"Comments should get more thoughtful and substantive, not less, as a topic gets more divisive." and "Eschew flamebait."

I mean, tbh, these are rather vague guidelines. You could say my comments are "thoughtful and substantive." I made an observation that the corruption in the article had many responsible parties and people from all walks of life participating in it, more than what would normally happen in the states. The fact that so many people participated does say something about the culture in general.

As for "eschew flamebait"... how much flame did this post cause? There's definitely a bit a flame, but I would say overall a flamewar didn't happen. So basically you're wrong. You use your "experience" to justify the warning but I would say your experience is wrong for this case... most of the sub threads aren't things that I would classify as flame.

I get where you come from though. It's hard to see from a distance whether a comment will cause a forrest fire.

Maybe put out the forest fire if you see one starting, but don't ban the use of matches all together.

>it seems Pulsar needs to be an order of magnitude more performant to capture developer mindshare.

Just to add to this, ease of use/setup is also a huge factor. There are technologies I can just spin up with zero knowledge and learn as I go. These are huge factors in adoption especially with Golang and nodejs.

This wasn't flame bait. It was just an observation. Please realize that it was other people who decided to flame. Just because someone decides to have a bad attitude doesn't make my post flame bait.

I made a general observation about corruption and culture, other people decided to respond to it in a bad way.

If this type of comment isn't allowed on HN it's a form of censorship. Basically I can't say anything negative about a culture or a country because it's classified as flame bait.

This is similar to the way the CCP practices censorship in China. People in my country basically can't say anything negative about it. Thank you for perpetuating that sentiment here on HN.

translation:

  If you can cheat, cheat. 

literal word for word translation:

  Can cheat. Do cheat.

In Chinese the word lie can be used in place of cheat and in this context it means something similar to cheating other people.

It's a society/cultural/behavioral thing.

In China they have a saying: 能骗就骗.

For sure, thanks for being more specific. I definitely noticed the overall attitude is generally different for Asians who are not of Chinese Nationality.

In my example above i specifically cited someone who makes guns or nuclear weapons.

Those people make bombs and guns knowing full well that these weapons will kill less people than cars even though the base intention of the weapon is to kill.

The kind of cultural attitude you describe reflects the supply and demand logistics of the economic conditions that were responsible for modern China as it is today.

Modern China was built off the backs of Cheap Manual laborers

What's nuts about this how tons of people from all levels of government/society participated in this conspiracy.

It says a lot about the general attitude of Chinese people.

(I'm chinese, btw)

Makes sense. Even if the creator of the car never had the intention of making cars so that police men can use the cars to oppress people; the creators of those cars become liable as soon as they have knowledge of what those cars are used for.

Thus as a car creator you must take some level of responsibility for any atrocity your car is associated with.

For example did you know 1.36 million car related fatalities happen per year every year? If you make cars you are participating in the violent mass slaughter of people on a scale that dwarfs the genocide committed during the holocaust. In the US alone car manufacturers are responsible for creating cars that kill 100 people per day.

Does creating a tool that you know with absolute certainty will "accidentally" kill millions of people make it an "accident?" Are you guilty for murder when you create something that you know with absolute certainty that it will kill people?

To make the moral contradiction even more confusing let's examine people who make weapons.

As a maker of nuclear weapons you know that there will be exactly zero deaths in the next year due to nuclear explosions. Thus you've killed less people than the car maker and you're fully aware that your weapon is basically going to kill nobody. You want to pick a career that will absolutely kill zero people? Make nuclear weapons.

Even a ladder maker is aware sometimes people die when they fall off ladders but I can guarantee you that nobody died in a nuclear explosion last year.

Even if you make hand guns for the police, those guns will kill less black people than the amount of cars that killed black people. So car makers have killed more Black people than police men and gun manufacturers. Does that make them more racist? No.

You may be thinking that the above logic is absurd and your mind must be racing furiously to come up with counter-logic to make sense of all the garbage I said above. I'm telling you right now that it's a pointless endeavor to make sense of it all. It's pointless to talk about it and it's pointless to think about it. Morality was never suppose to make any sense.

Your morality is an inborn emotional module in your brain that is designed to help you survive and navigate a prehistorical setting where you lived as cavemen in a tribe. It's designed only for survival it was not designed for logical internal and external consistency. Think about it. Does Natural selection and evolution evolve these moral instincts in your head to help you create world peace or to help you survive so you can reproduce? Whether or not your morals had internal and external logical consistency never really was a factor for helping you survive thus your brain evolved moral instincts that can be highly contradictory when examined closely.

It's not suppose to be consistent and it's not suppose to make any sense.

Once you realize this, then you'll know all this stuff is really kind of pointless.

Don't think about it too deeply, is my advice... just deal with the surface issue: racism... there is no need to attack the manufacturer who makes police badges... because in the end even the surface issue of racism is sort of a superficial exaggeration from a cosmological perspective.

Even when you just consider the fact that the USA is already one of the least racist countries in the entire world it's sort of inconsequential. Have any of you been to other countries? The racism is on another scale in most other places.

You're talking about things like dependency injection. I'm not a huge fan of testing but "testable code" when written in a certain way (without dependency injection) actually has many external benefits that don't have to do with testing per se.

Really the way you need to structure your program is to divide functions in your code between things that can be unit tested and can't (IO calls).

This can easily be done without dependency injection which is likely what you're complaining about.

For example Don't do this:

    #unit testable with mock (Bad!)
    function add_one(key: str, database: Database):
         return database.get(key) + 1

Or.. even worse:

    #Unit testable with mock (Bad!)
    class Adder
       Adder(database) -> None {
          this.database = database
       }

       add_one(key: str) -> int {
          return this.database.get(key) + 1
       }

Do this instead:

      #IO function, Not unit testable
      def get_database_value(key, database) -> None:
          return database.get(key)

      #Unit testable without mock! Good!
      def add_one(value: int) -> int:
          return value + 1

      #IO function, not unit testable. 
      def composition(key: str) -> int:
          return add_one(get_database_value("name"))

>100% test coverage is likely impossible, but if we do find errors, we can learn from them and try to prevent them happening in the future by adding them to the tests.

You do know there's a way to verify a function to a degree of 100% without writing a single test?

You do also realize that for even a trivial function f(x) = x + 2, the only way to achieve 100% coverage is to write:

    assert f(0) == 2
    assert f(1) == 3
    assert f(2) == 4
    assert f(3) == 5
    ....
    assert f(N) == N + 2 where N = infinite. 

There are infinite possible inputs and infinite possible outputs so to get 100% coverage you need to write infinite tests. Because your "tests" can never even approach this number most of your "coverage" really amounts to a number close to 0%.

The question is, why does testing seem to kinda sort of work even when our test coverage covers only an amount roughly equal to 0% of all inputs to the program?

It's an interesting question with an interesting answer. Suffice to say "test coverage" is a garbage statistic.

One way to look at testing is that you're taking a statistical sample of a population. You take a small sample and do a statistical measurement on that population and if all tests pass for a sample you assume that the correlations implies that the entire population of inputs will pass all tests.

So in a sense testing is just science. We try to establish correlations among a given observational data set and we assume that this is true the entire population of data including ones that aren't seen.

Except the above isn't actually true either...

The reason is most test writers don't randomly sample test input data. Their methodology is very divergent from the way a statistics expert gathers data. Test writers don't write functions that randomly pick a set of data to test... instead they're highly biased in the tests that they write... for example a typical test set can look like this:

   F(x) = 320302/x
   assert F(2) == 160151
   assert F(0) == error

As you can see the above two tests are highly biased with the second test picked in order to deliberately cause an error. Imagine if the test data was randomly picked? It would be highly that the random picker would draw zero as an input test case indicating that statistical sampling may not be the best way to test data....

So if our tests cases are biased then why do tests kind of sort of work? Or do they not actually work? How is the programmer picking a test and how does that influence the overall correctness of their program? Perhaps it's not the test itself or the amount of tests that the programmer is writing but it's more about how the tests influence the way the programmer thinks about the function...?

I would say the last micro service I wrote, (in python) was virtually 100% bug free ever since it went into prod. I also didn't write a single unit test for it. I did do some manual testing on the system but the application itself does not have a suite of unit tests to protect it and it has since had 0 bugs ever since it was placed into prod.

I would still say a testing suite is still good for new programmers diving into an unfamiliar system attempting to change things haphazardly, but in terms of correctness I question this strict almost religious adherence to unit testing.

Food for a thought.

It's largely because they're dealing with an area with no theoretical tools. Any time you hit an area that are full of people "Designing" solutions/abstractions rather then "Calculating" an optimal solution/abstraction you know you've hit an area where there's very little theoretical knowledge and most people are just sort of wandering chaotically in circles trying to find an "optimal" solution/abstraction without even a formal definition of what "optimal" is.... I mean what is the exact definition of the "perfect abstraction"? What is bad about duplication what is a bad over abstraction and what is this "cheaper" cost that the title is talking about? It's all a bunch of words with fuzzy meanings injected with peoples biased opinions.

That being said theories on abstractions do exist. If you learn it you'll be at the top of your game; but it's really really hard to master. If you do master it, you'll be part of a select group of unrecognized elites in a world of programmers that largely turn to "design" while eschewing theory.

Here are two resources to get you started:

The Algebra of Programming: https://themattchan.com/docs/algprog.pdf

Program Design by Calculation: http://www4.di.uminho.pt/~jno/ps/pdbc.pdf

You will note that both of these resources talk about functional programming at its core which should indicate to you that the path to the most optimal abstraction lies with the functional style.