ukj

55 ms·

481.
by ukj 7y ago
In my reality I am the "sysadmin". I am also the "developer". I am the guy who wrote tests (unit and integration). I also configured the CI/CD pipeline. I am also the guy who puts metrics in place to monitor the hea
482.
by ukj 7y ago
Strawman. You are conflating denotational semantics [1] with operational semantics [2]. In the free world, a pilot is free to recognize that the 'already-defined autopilot' is doing something stupid/dangerous (despite all the
483.
by ukj 7y ago
> Seems like something a language ought to forbid, anyway > What about the rest of my comment? The expression problem? Navigating around the expression problem is precisely what I am demonstrating. A language ought not [1] decide for
484.
by ukj 7y ago
>Still don't understand your non-contradiction example. >Haskell can say everything Ruby can Go ahead and say P ∧ ¬P ⇔ True in Haskell. Here is me saying it in Ruby: https://repl.it/repls/AccurateJauntyDimens
485.
by ukj 7y ago
Getters/setters may be seen as anti-patterns in the functional paradigm. They are seen as pattern in the imperative paradigm. Of course I am making trade-offs, but so are you. It's just another word for making choices. What I mean
486.
by ukj 7y ago
TDD has its uses. BDD has its uses. Code first - test later has its uses. YOLO has its uses. Not a fan of silver bullets.
487.
by ukj 7y ago
I mean adding setters/getters to existing data types. It's solved in any language in which mutable data structures don't require a Rube Goldberg machine like lenses. e.g languages which optimise for expressiveness over purism
488.
by ukj 7y ago
Adding a new setter method to a data object buried in 10 layers of abstraction. In Ruby it's changing the attr_accessor line. In Haskell objects are immutable, so you need lenses.
489.
by ukj 7y ago
Is that 1% not true or 99% not true? Amortizing the up-front cost of design, into a continuous cost of refactoring every time the requirements change doesn’t make the original claim false. You are still paying the price of rigidity.
490.
by ukj 7y ago
Do you understand the difference between extensibility and refactoring? For the purposes of flexibility extensibility is more desirable than refactorability (to me and my problem space anyway). >because we are talking about your comment
491.
by ukj 7y ago
Perhaps you didn't understand my point. Being 'good at refactoring' is only a desirable feature if you are spending a lot of your time refactoring code. Why are you spending so much of your time refactoring code? Because your
492.
by ukj 7y ago
In the DevOps world, the person who understands the code is the person who got paged for it being broken.
493.
by ukj 7y ago
'Great refactoring experience' relative to what? An imperative language? Yeah right! I don't have to refactor extensible code.
494.
by ukj 7y ago
Haskell Monads! #Sarcasm
495.
by ukj 7y ago
>Architecture is extremely sensitive to the initial choices due to isolation of side effects. This is fundamentally why it's useless in practice. It requires you to anticipate/predict everything ahead of implementation. It requ
496.
by ukj 7y ago
And what happens if your time-estimates are wrong; or unbounded? You have two tasks (one Urgent, one Important) and 10 days at your disposal. If each task takes at least 4 days, which one do you do first? > But the point is that when add
497.
by ukj 7y ago
>They have different priorities IN DIFFERENT CONTEXTS. That's precisely your error in reasoning! You are violating the ceteris paribus principle by inventing multiple contexts. We don't exist in multiple contexts. We exist in a
498.
by ukj 7y ago
In what universe do you live in that you operate under different time contexts/constraints to the rest of us? The very fact that you are forced to make a choice between Urgent and Important indicates that you ARE time-constrained withi
499.
by ukj 7y ago
Your argument is A != B. My argument is that your argument is not useful when having to choose between A and B. If A != B is true, then go ahead and evaluate A > B.
500.
by ukj 7y ago
>The point was that importance is not the same thing as urgency, which the parent comment didn't seem to understand. There is nothing to understand about that point. It's a linguistic distinction which makes no practical differ
501.
by ukj 7y ago
This is a perfect example of faking it! The very thing this thread is about. Instead of figuring out how to make the hard choice between Urgent<->Important in the first place, you've drawn a distinction which lets you kick the ca
502.
by ukj 7y ago
Perhaps, but you can't determine whether a system is over or under-engineered a priori. Certainly not when you are racing a clock. These kind of assertions are always after the fact. And in hind-sight I think we could've done a ta
503.
by ukj 7y ago
>Nobody reading this thread is doing that, and the few that are know who they are. That's the false dichotomy which earned me my stripes. I used to think I am the former guy, then I realised I am the latter guy. The only thing that
504.
by ukj 7y ago
Short-term thinking is a form of technical debt. How important of a problem are you really solving if the solution is not meant to "stick around"? https://en.wikipedia.org/wiki/Time_preference
505.
by ukj 7y ago
Nothing ever is a problem 'in and of it self'. This kind of vacuous 'thinking' is not what I am talking about. Holistically, if your system is meant to endure the test of time (think Google-scale), more technical debt is
506.
by ukj 7y ago
That depends on whether you see technical debt accrual as a 'meta problem'. The faster you iterate without thinking long-term - the faster it accrues. 20/20 hindsight and all that.
507.
by ukj 7y ago
I may have been faking it and making it till I caught on. I was faced with a trade-off I don’t know how to make. Do I prioritize urgent work or important work when not doing either has tragic consequences along similar timelines? Oh! We inv
508.
by ukj 7y ago
Relevant reading: 1. https://medium.com/incerto/the-most-intolerant-wins-the-dict... 2. https://en.wikipedia.org/wiki/Paradox_of_tolerance Logical conclusion: To be intolerant of intolerance is a
509.
by ukj 7y ago
The theory is ROC curves [1]. The practice requires that you play devil's advocate with yourself - figuring out ways to disconfirm your own beliefs. I usually start with the question: 'What data would convince me that I am wrong?&
510.
by ukj 7y ago
It seems the damage is done and cannot be reversed. About the only lesson you can learn from this is that if you really cherish Freedom of Speech, then you actually require Fuck-you money to practice that right effectively.

More ›