Hacker News Reader

Comment by QuadrupleA | Hacker News Reader

Might have once agreed in my young OOP days but after 20+ years of experience, totally disagree. Yagni. Don't add unnecessary code and abstractions. Minimize complexity wherever possible.

View on HN

Agreed. This mindset has turned parts of the rust ecosystem into a mess. It's frustrating coming across a generic function argument, for example. Like, what goes there? Instead of a primitive type, or a struct/enum with its own documentation in a provided link, you find a dead end.

Interfaces are nice when used appropriately, but the added complexity by default isn't worth it.

I think it’s pretty much necessary in Rust to allow things to interop with low overhead, which is an explicit goal of most Rust code. That said, this article is not talking about interfaces as in Rust traits or Go interfaces necessarily but more the general concept. You can see that more evidently by the way that they point out that they don’t necessarily mean to imply that people should be writing entire plugin systems. What’s going on with Rust traits is much, much more granular than what they seem to be discussing.

Having everything behind an interface is pretty much essential for strict TDD in pure Java 8 (I don't know if or how things have changed for later releases). Of course there are a plethora of mock frameworks that will hide the details, but I'm fairly certain under the hood it's dynamically creating an interface. My inclination is to prefer making that explicit rather than relying on magic.

What goes there? Anything that meets the specified requirements of that type

Definitely seen a lot of developers who, every time they want to go use a library- metrics, logging, http-clients, they go build their own TypeScript wrapper and interfaces. They think they're doing us all a huge favor by giving us something that might be portable, and which has an interface which is this way or that way easier or better. But it becomes a sticky not quite-sensible mess pretty quick, and ultimately, and no one can StackOverflow or nom search their way to success, since the internet has nothing to say about our homegrown overgrown wrapper + helpers.

I really want to find ways to better capture "we use X for logging along Y and Z plugins and U and V configurations". Making top down tools, that hide whats afoot, is just plain bad, but copy pasting the same solution dozens of times also doesnt fly.

Anyhow that all said, my problem here is more about encapsulation masking whats really happening, which I think is treacherous. I dont necessarily agree with the author; etcd for example I think has huge epic wins the author just doesnt get & that databases have simply never caught up on (common Http-centric interfaces, watch-api). But I did do many years of java and the Service Provider Interfaces (SPIs) everywhere were a cherishable & adorable source of great power & flexibility. That point is retained. I just think favoring sql is a terrible terrible example that ignores how excellent & typical http based interfaces are.

Sometimes it makes sense to write a wrapper. I've worked on a team where every few months we'd have some mandated framework change, or a microservice we depended on was being replaced by some new project. In that case it's easier to update an abstraction in some common library than ripping the code out from every place it's used in application code.

I love the rule of three. I know I've heard it on the Go Time podcast, but I'd heard it before then.

Copy your code once. If you find you've copied it again later, that's the right time to think about whether you'll continue to, and therefore whether it's worth making something reusable.

So yeah, wrappers are nice. But I'm also a really big fan of lazy wrappers. Wrap the thing barely enough to get the job done so you can upgrade in one place, but don't get fancy because you will probably hate yourself for it down the road.

I hate that rule. It makes almost entirely sure that you'll loose control for your duplicates. The way around is way easier

Welp definitely disagree -- pardon the assumption but when you say "young OOP days" I instantly think Java/C# and I think the baggage in those languages leaves a bad taste when it comes to abstractions that were supposed to stay light.

Of course it would have been impossible to jump to the future for you and use better languages, but modern languages with static type systems (Typescript, Rust, etc) reduce the difficulty of writing and maintaining interfaces so much that even if you never need it you benefit.

I also still think that the documentation benefit (seeing structure without implementation) is worth it.

> Minimize complexity wherever possible.

Fully agreed here, pretty much unassailable.

Just because a language makes it easy to create and maintain interfaces doesn't mean that interface was a good idea to begin with.

in case isn't clear to other, types and interfaces are effectively synonymous in Typescript. typescript doesn't really bring in that other cruft unless you want it

types are so synonymous that there is no reason to use interfaces in TypeScript.

There are several reasons to use interfaces in TypeScript:

- they perform better at build-time and in editor

- they have more relaxed rules for recursion

- they can help identify complex types and distinguish them from simpler ones

- they’re guaranteed to be usable to enforce class implementations, whereas only simple types can be used

- they’re much easier to read in type errors

> - they have more relaxed rules for recursion Do you have a source for this? I would like to read more.

I would be impressed to see readable, non-trivial TypeScript code that does not use Interface.

Unless you are referring to interface as a concept, and not the keyword in TS.

Can you use the “class MyClass implements MyType” keyword with types?? That might be the only reason if you can’t

You can certainly write java/c# without abusing interfaces. They're just available, not forced on you.

It can be worthwhile replacing a wide interface with a narrow one. If an external interface has 30 methods but you only use 3, declare an interface with those 3 methods. Go makes it easy.

This is the interface equivalent of removing unused function parameters. Most people would say you shouldn’t add extra, unused parameters to a function just in case you might need them someday. Why require methods that you don’t use?

Ouch! Good luck tho!

Reply on news.ycombinator.com