bccdee

15 ms·

211.
by bccdee 11mo ago
The article complained that a Rust program can crash when you call `unwrap`—in fact, the author says that's their strongest critique. Python crashes when you call `sys.exit`, so it's no better. Unfortunately I don't think the
212.
by bccdee 11mo ago
> telling a victim “but the memory was not corrupted in the crash” is a weak consolation. We actually had a recent Cloudflare outage caused by a crash on unwrap() function. It’s probably the strongest point of my whining: Rust is memory
213.
by bccdee 11mo ago
> I read portable as meaning the format’s semantics are consistent across platforms. By that definition, a format which is only implemented on one platform is 100% consistent. I agree Markdown is uniquely fragmented, but it's also u
214.
by bccdee 11mo ago
None of the author's other suggestions are portable either. So what if pandoc markdown is only understood by pandoc's tooling? DocBook is only understood by DocBook tooling. The difference is that pandoc markdown is already 95% si
215.
by bccdee 11mo ago
If I see a wall of text, I just read the first couple lines. It's usually not hard to tell whether it interests you or not.
216.
by bccdee 11mo ago
> This is not primary content In a forum, the discussion IS primary content. That's the problem: Reddit has shifted away from being a discussion forum toward an endless-scroll content feed. > Here we're all nobodies to every
217.
by bccdee 11mo ago
> So long as you're calling procedures that are determined by the "type" of the object, whether dynamic or statically dispatched, it's OOP. That's just polymorphism. Are Haskell typeclass manipulations OOP too? I
218.
by bccdee 11mo ago
It's rarely possible to future-proof a function by testing its entire range of possible inputs, so I'm not particularly concerned about trying to anticipate trivial cases that might become non-trivial in future—that just feels lik
219.
by bccdee 11mo ago
Money is important as a vector for power. It doesn't matter that much whether a person has a bunch of paintings in a Swiss vault when they're an institutional investor directing a substantial sector of the economy. And that indust
220.
by bccdee 11mo ago
I think making narrow use-case-specific test doubles is often better than a big shared one. You can even wrap the API with an interface that only exposes the methods you need.
221.
by bccdee 11mo ago
Yeah I think true mocks often lead to fragile, hard-to-read tests. A text which expects a bunch of specific interactions with a mock is white-box, whereas a test which tests the state of a fake after the operation is complete is mostly blac
222.
by bccdee 11mo ago
Not necessarily. If your error handling looks like this: value, err := externalLibraryFunctionFoo(a, b) if err != nil { return nil, fmt.Errorf("calling foo: %w", err) } then you probably don't need to test it.
223.
by bccdee 11mo ago
I think the important thing is that the code look pure from a testing perspective. Say you've got a function that accesses a key-value store. Ideally, you can factor out the i/o so that you do all your reads up front and all you
224.
by bccdee 11mo ago
Dependency injection frameworks can be a pain, but basic dependency injection (e.g. pass a DB handle to anything that needs the DB) is a must. What's the alternative? Having everyone independently create their own DB connections?
225.
by bccdee 11mo ago
Code is already banned by anti-circumvention laws.¹ I'm sure it wouldn't be that hard, legislatively, to have VPNs classified as a tool for circumventing "digital locks." [1]: https://en.wikipedia.org/wik
226.
by bccdee 11mo ago
It can be, if the composing object re-implements the constituent object's interface. This way, code reuse and polymorphism are orthogonal features, which I think is better. If you want both, you can do both, but inheritance pushes you
227.
by bccdee 11mo ago
> However blanket statements like "one should not use XYZ some abstract community thinks so" to me have near zero value. Come on, you don't believe this. How about a blanket statement like, "one should not use asbesto
228.
by bccdee 11mo ago
If the author of the article had done a bit of searching, they might know that Canadians (the primary predictable American ficasco spectators) phased out pennies years ago. We also "had no plan" for the remaining pennies, and we d
229.
by bccdee 11mo ago
> I feel like if we argued over a beer we’d probably end up agreeing on a lot of things. But let’s start by disagreeing. :-) Definitely! :D Re: SRP, my issue is that it's too subjective. Even for a very simple code snippet like `foo
230.
by bccdee 11mo ago
The fact that Java had to add a whole extra set of keywords to control this indicates that this is a site of complexity. Since it isn't needed for composition, it's a site of unnecessary complexity.
231.
by bccdee 11mo ago
That's not true. If Outer has a member Inner, Outer always has to invoke `my_inner.foo()` to use Inner::foo, and `foo()` always refers to Outer::foo (and some languages will force you to write `self.foo()`, which is even better). If Ou
232.
by bccdee 11mo ago
Java serialization is implemented with reflection, not inheritance. `extends Serializable` is just a marker which tells the serializer it's okay to serialize a class. Go serializes with reflection too, and there's no inheritance a
233.
by bccdee 11mo ago
> So much over very simple and primitive thing: John HAS a key vs dog IS an animal. Both are valid and proper. I don't think so. "Having" vs "being" are descended from an overly simulationist notion of program de
234.
by bccdee 11mo ago
True; I suppose I could concede the idea that inheritance has its place if we recognize that that place is quite small and out-of-the-way. My problem is that "everything has its place," without any qualifications, is effectively
235.
by bccdee 11mo ago
> And that is not remotely the case here. Isn't it? People have written extensively about why we should prefer composition to inheritance, and you haven't mounted any defence of inheritance beyond the thought-terminating cliché
236.
by bccdee 11mo ago
SOLID is a childish thing, imo. Very undergrad. "Single responsibility" isn't an especially useful yardstick. If you actually need to decompose a complex piece of logic into modules, the place to start is by identifying areas
237.
by bccdee 11mo ago
> There are many paradigms and each one has its place. That's a thought-terminating cliché. The argument against inheritance has been laid out pretty clearly. It's reasonable to rebut that argument. It's not reasonable to
238.
by bccdee 11mo ago
I dunno. It's easy to say, "there are trade-offs, it depends" any time two things are compared, and it's never entirely untrue. However, sometimes one option is just generally worse than the other. I'm not saying it
239.
by bccdee 11mo ago
> In swift I can have each object to conform to Hashable, Identifiable, Codabele, etc etc... and keep repeating the same stuff over and over, or just create a base DataObject, and have the specific data object inherit it and just . But t
240.
by bccdee 11mo ago
What I like about the modern¹ approach (interfaces + composition) is that it cleanly untangles polymorphism from behaviour-sharing. When you inherit from a parent class, you have to be careful to only override methods in ways that the paren

More ›