wesselbindt

> they didn't have any separation between SREs/on-call engineers from the people who implement their services

I.e., treat DevOps as a way of working, rather than a role meaning something akin to "Ops person who knows terraform, or k8s, or Ansible etc".

We could invest in cheaper and faster coffin production. Or invest in trying to get mass graves to become culturally acceptable. Or we could try and actually do something about the conditions that create the hellscape to come, but with our current mode of production and incentives around industry, I don't see it happening.

What were you doing at 14?

My personal favorite is that he was part of authoring the RSS spec at age 14. But you're more than welcome to Google for other pieces of evidence yourself if you're genuinely interested and not just being argumentative.

Have you ever considered that it may be the other way around? That the horrors of living on the street (and "horrors" is an appropriate term here, you are fighting for survival every day; it is beyond the realm of comprehension of the housed) might be causing the mental illness and drug use, rather than the other way around?

If I want to get a homeless person off of drugs, it sure as crisps is not going to happen until they have a roof over their head. The core issue is the lack of affordable housing. That should be priority number 1.

> A monad is a monoid over a set of curried functions

I think this statement will have two kinds of readers. People who are not familiar with monads, for whom it'll fly right over their heads, and people who are familiar with monads, who will be annoyed at its inaccuracy.

I feel like this article misinterprets at least one of the points made by the articles it cites. There's a bit in here that roughly goes: "the filesystem api is geared towards Unix and doesn't work that well for windows, but that's ok, because it's designed for servers which run Unix". And that's perfectly valid, and I agree with this 100%, but it misses the broader point that's being made in the "I want to get off Mr golang's wild ride" post.

The problem that the wild ride post has is not that the filesystem api doesn't work for windows. It just uses it to illustrate a broader point: golang opts for silent failures (for example by just making up file permission bits for a file on windows), and just chugging along pretending everything is fine when it's not. This design choice goes well beyond the filesystem api.

Now, whether I think that's a fair criticism or not is beside the point. All I'm saying is that this post is not a valid response to the criticism illustrated by comparing Rust's filesystem api to that of Go.

> it's a big disruption and it's costly so it's not done lightly

Isn't this the very definition of not being agile?

> There is a lot of freedom

The US is fifth in the world in terms of incarceration rate (i.e., there are only 4 countries which imprison a larger portion of their population). The thirteenth amendment allows the US to enslave its imprisoned population (which they do, and it's a very lucrative business). The US also has a thing called the death penalty where they literally _kill_ the person convicted of a crime.

According to the world press freedom index, the US ranks 55th when it comes to freedom of the press.

I don't know if you know this, but the US has been holding immigrant kids in cages at the border. Started with Obama, increased under Trump, and then increased some more under Biden.

Guantanamo also still exists, but I suppose torturing civilians without formally charging them for a crime doesn't count against the freedom of US citizens.

By what metric does the US have a lot of freedom?

> Our universities are probably the best in the world

Good colleges aren't worth anything if only the owning class can afford to send their kids there. Going to college puts people into lifelong debt (in America, that is). Out of the top 10 universities in the world according to the QS world ranking, 4 are from the UK, 4 from the US, despite the UK having about a fifth of the population of the US.

> And having a strong economy is generally a good thing -- there are jobs, which matters.

There were jobs during slavery too (I mean the slavery from before 1865, not the 13th amendment slavery from today). Jobs are not an inherent good. About 40% of the homeless (in the US) have a job, but cannot afford housing.

Do you see a strong economy as a goal in itself? I see it as a proxy measure for the things that truly matter. Happiness, good health, good education, the freedom to lead your life the way you want. America fails miserably on all of those.

I truly cannot tell whether you're joking. If you're not, I'd love to pick your brain. I'm very interested in what standards you have and why you have them.

> It should be enough to make companies answerable to shareholders

It very obviously isn't. The prime incentive for shareholders is profit (which is only natural), and this is in many, many cases demonstrably misaligned with what's best for society. Cases in point: health insurance, the military industrial complex, fossil fuel based companies, education, landlords, big tech.

I don't understand, you're not allowed to change the types? Suppose you disallow any number other than 1, 2, and 3, and you model this with some enum with three members or something. Then you find out that actually a prospective client would love to also work with with the number 4, then you just add 4 to the enum in your next release, no?

But at what cost?

> why not test our use of the database

Primarily slowness and brittleness. Tests with side effects are much more likely to be flaky, and flaky tests are the worst. Especially if they're slow and hence hard to debug.

Of course, you do test your use of the database, but in a much smaller test suite. For the business logic tests you just spin up a copy of your app with fake adapters, and you're done. Quick, deterministic tests.

I don't have an answer to your question, but I can give a method that usually helps me think about these things.

I try to find theoretical situations that I find easier to think about, and hence easier to judge on a moral level. Usually I construct these situations by going to extremes with certain variables. What if your company had one employee? What if all of humanity was its workforce?

For example, let's say your employer just employs you, and your job is to press a button every month that kills a random person and generates 30k dollars. That's a situation where I personally find it very easy to make a moral judgement.

Then, in very small increments, try and change this theoretical situation to more closely resemble the real thing. Maybe there's some context missing, maybe one of the variables is too extreme. And with each increment, try to pass judgement.

For example, you can change the kill button so that maybe the button has some positive effect (maybe it kills someone, but also cures two terminal cancer patients). Or maybe you want to increase the number of employees and see how that makes you feel.

It's not a silver bullet, but there's a chance that pursuing this mode of thought ends up enabling you to confidently assess your personal situation in morality. It's also not necessarily easy. It can be difficult to find the right starting point (there's more than one!), or the right incremental change (there's more than one!). I hope it may be of help.

For an example of this way of thinking you could look up Peter Singer's argument for charity, or the pro stem cell research argument which asks you to choose between saving little girl or a box of embryos from a burning building (I forget the origin).

> We had developers duplicating entire models in separate databases and all number of dumbass shit.

That's DDD?

(2019)

I skimmed the article a bit, because it's structured in a strange way, and I couldn't quite find my footing. Then I came across the phrase

> it was everybody else that was wrong

in a section on composition vs inheritance. I know that it's a completely superficial thing to say, but I find it hard to take texts that sincerely use this phrase seriously.

From my end the decision to not use the Google product comes from two places. Firstly, any money I send to Google is probably a net negative for the human race as a whole (though the same could probably be said for Spotify). Secondly (and much more importantly for me personally), YouTube is quite addictive, and having premium would enable me. If someone offered me a music streaming subscription with a bit of free crack cocaine on the side, I would not take it over someone offering me just the subscription, regardless of the price (up to a point)

Repls are not unique to dynamically typed languages. Haskell has one.

I work in dynamically typed languages a lot, so I don't have many opportunities to feel the way you do. Could you give an example where moving from static to dynamic would reduce cognitive load?

For the opposite example, here's where my preference comes from: I'm editing a function. There's an argument called order, and most likely it's either an instance of some Order class, which has some attribute I need, or it's an integer representing the I'd of such an order, or it's null. I'm hoping to access that attribute, so I have to figure out the type of order.

In a dynamically typed language, I'll have to look at the caller of my function (goes on my mental stack), see where it gets it order from, potentially go to the caller of that function (goes on my mental stack), etc until I hopefully see where order is instantiated and figure out it's type, so I can take the call sites off of my mind, and just keep the type of order in my mental stack.

But actually, this is wrong, because my function is called by way more functions than the ones I examined. So really, all I know now is that _sometimes_ order is of type Order. To be sure, I have to go to _all_ callers of my function, and all their callers, etc. This grows exponentially.

But let's say I manage, and I find the type of order, and keep it in my mind. Then I need to repeat the same process for other arguments I want to use, which is now harder because I'm keeping the type of order on my mental stack. If I manage to succeed, I can go and edit the function, keeping the types of whatever variables I'm using in my head. I pray that I didn't miss a call site, and that the logic is not too complicated, because my mental stack is occupied with remembering types.

Here's how to do this in a statically typed language: read the type signature. Done.

There's a difference between inference and coercion, and no one here is arguing against inference, as far as I can tell.

> the compiler can tell you that there needs to be a semicolon right here

I can see that this is an annoyance, but does it really increase cognitive load? For me language design choices like allowing arbitrary arguments to functions (instead of having a written list of allowed arguments, I have to keep it in my head), or not having static types (instead of the compiler or my ide keeping track of types, I have to hold them in my head) are the main culprits for increasing cognitive load. Putting a semicolon where it belongs after the compiler telling me I have to is a fairly mindless exercise. The mental acrobatics I have to pull off to get anything done in dynamically typed languages is much more taxing to me.

Suppose I give you two functions f, and g. Can you run f(g()) without breaking things? The honest answer is you don't know until you read the functions, which is a slow and difficult thing to do.

Suppose I give you functions f and g of respective types int -> str and Nothing -> str. Can you compose them? No, and you see this immediately from the types. Types make reasoning about composability a lot easier.

Of course, it's not a panacea, and it's less helpful the more side effects a function has. Can we compose pure int->int functions? Of course! Can we compose two of them where the second expects some image to exist in some docker registry? You'll need to read the first to be able to tell.

Given the highly side effectful nature of pipelines, I'd think the applicability of types would be limited. But maybe that's just a lack of imagination on my part.

Certainly information like "this pipeline expects these variables" and "this pipeline sets these variables" are susceptible to a typed approach, and it would make things easier. By how much, I don't know.

When you quarantine third party code with an adapter (which you should probably be doing anyway), you can make your adapter well-typed. This is not hard to do, and it pays dividends.

Because of private ownership of capital in an inelastic market.

So you're in a pathological organization in the sense of the Westrum typology, and somehow proud of it.

No sorry, that causes me too much psychological harm, amounting to at least serious distress.

> psychological harm amounting to at least serious distress

Has shown itself to be vague enough to be a perfect stand in for "harmful" in everything the parent comment says.

The prosecution of Elling has the same vibe as that of Calley [1] after the vietnam war, and that of the small group of soldiers involved in the Mahmudiyah rape [2] during the second gulf war.

Viewed in isolation, the atrocities committed by these men deserve punishment. But in the bigger picture, the function these trials serve is for the institution in charge to be able to say "see? We do hold ourselves accountable" even though the vast majority of war crimes went uninvestigated and unpunished.

More heads, and more important heads, should roll. Not just that of one fall guy. Tens of thousands of deaths every year, and even more lives ruined. But we all know what side the US government is on, so I'm not holding my breath.

[1] https://en.m.wikipedia.org/wiki/William_Calley

[2] https://en.m.wikipedia.org/wiki/Mahmudiyah_rape_and_killings