Tainnor

67 ms·

931.
by Tainnor 3y ago
We don't really know what the actual implementation looks like, so I find it hard to make a definite judgement. I think the refactoring introduced by the author probably wasn't good, because it looks like a very brittle abstractio
932.
by Tainnor 3y ago
That may work in some cases, definitely a no go in a workflow where deployment is fully automated via GitOps, i.e. every push to the default branch triggers a deployment to prod.
933.
by Tainnor 3y ago
> I was picturing a case where the CI was allowed privileged access to a resource to which developers were not allowed access at all. That's also possible. Imagine a pipeline which carries out a deployment in an environment where no
934.
by Tainnor 3y ago
> We all agree on what an Applicative is supposed to do. Maybe. But not on which parsing library to use (parsec? megaparsec? attoparsec? regex-applicative?), on whether to use Data.Text.Strict or Data.Text.Lazy, on how point-free the cod
935.
by Tainnor 3y ago
Without knowing too much about the context, it probably would have been possible to keep the structure where every shape is structurally independent from other shapes, but where calculations are abstracted away in pure functions that are ju
936.
by Tainnor 3y ago
The problem here is that changes are committed directly to the main branch without a review. There needs to be some sort of peer review (I don't care if via pairing or with a classic PR) for every code change exactly to prevent an esca
937.
by Tainnor 3y ago
If you implement one single function, then it's easy to refactor later on. If over 10 years, dozens of people add feature after feature without thinking carefully about the structure of the code, you get huge messes that are very hard
938.
by Tainnor 3y ago
Just to give some examples: - your code is using private dependencies, so you can't build the code without authentication - you have some integration tests that use test containers using private docker images, so you need to do a &quot
939.
by Tainnor 3y ago
Day 1 part 2 was harder than is common for the first day. I ended up using parser combinators (attoparsec for Haskell), which morally feels like the "right" way to do this (so you don't have to manually keep track of how much
940.
by Tainnor 3y ago
Almost every discussion about consciousness or human level intelligence eventually devolves into questioning whether everyone apart from you is just a robot
941.
by Tainnor 3y ago
It's mostly only Western European / American popular music that (for some reason thaf I don't quite understand) is obsessed with 4/4. In many other cultures (e.g. Eastern European folk music, but many others as well), ir
942.
by Tainnor 3y ago
Pierrot Lunaire is pre-dodecaphonic Schönberg, though. I actually find it quite charming, in a way.
943.
by Tainnor 3y ago
I think you have to be really, really charitable not to see the Second Incompleteness Theorem as a complete repudiation of the Hilbert Program - at least it destroys the possibility of proving ZFC consistent in PA - to the point that I thin
944.
by Tainnor 3y ago
Those kind of corporate environments would also never use a technology like MirageOS that very few people know how to use.
945.
by Tainnor 3y ago
Gödel's first incompleteness theorem just guarantees that for every system of axioms that is computable and "strong enough", an undecidable sentence exists. For systems we actually use, such as ZFC or PA, we know a number of
946.
by Tainnor 3y ago
First, I don't think that "capital efficiency" is something that we absolutely need to optimise for regardless of any other concerns, and even if I would concede that, there's an argument to be made that concentrating ca
947.
by Tainnor 3y ago
Do you have a specific reference by any chance?
948.
by Tainnor 3y ago
> It's extremely difficult if not impossible to completely corner some market Are we forgetting how Microsoft absolutely dominated the PC market in the 90s and early 2000s? How today, there's basically two mobile operating syst
949.
by Tainnor 3y ago
> there's more of everything and everything is cheaper And I don't believe that this is what we should optimise for. "More of everything, for cheaper" somehow doesn't seem to make people happier. I think that mo
950.
by Tainnor 3y ago
That doesn't contradict anything. Most people can't afford to start a new venture, so they have a 0% success rate.
951.
by Tainnor 3y ago
But I didn't intend 2000 to be an arbitrary cutoff. 1980 is important because it's right before Reagan- and Thatcher-style economics. And if you look at measures of wealth inequality (e.g. the share of wealth owned by billionaires
952.
by Tainnor 3y ago
I don't think you're seeing the whole picture if you think only about physical force. People who are well off have more opportunities to start other ventures that make them even more well-off, and if they're especially powerf
953.
by Tainnor 3y ago
Why are you only looking at income inequality, only in the United States and only in the last 20 years? Look at where that graph was in 1980, for example.
954.
by Tainnor 3y ago
You haven't responded to my main point: do you believe that a completely unregulated market doesn't lead to wealth accumulation in the hands of few people? It is of course true that some (bad) regulation, like protectionism of var
955.
by Tainnor 3y ago
In an unregulated market, capital very naturally tends to accumulate more capital - while, if you have nothing, it's very hard to build up capital in the first place. Which means that, if this continues indefinitely, more and more thin
956.
by Tainnor 3y ago
I do personally think it's preferable for components to have their dependencies injected in some way, and that it's better to have initialisation logic (especially related to heavy weight components) in one place. That doesn'
957.
by Tainnor 3y ago
That's the one I would prefer. If you're at all used to FP, this signals intent very clearly.
958.
by Tainnor 3y ago
1. Yes, I happen to think that the difference between this: fn f() { if foo && bar { if foo { } else { } } } and this: fn g() { if foo && bar { h() } } fn h() {
959.
by Tainnor 3y ago
Well, let's consider the three examples the author gives for "pushing ifs up": The first one isn't even a proper example because they write "push the if to the caller", but doesn't actually show the caller
960.
by Tainnor 3y ago
> Questions like [...] “what is the actual job this has to do” end up being the ones whose answers tend to have the most long-term value. How is that not "big picture", proper design and abstraction/encapsulation? You seem

More ›