Live data from Hacker News

Hang your code out to DRY

johan.hal.se

61–70 of 82 posts

Re: Hang your code out to DRY

#61

Earlier quoted context omitted.

I've pointed out in the past that if the characters you're deduplicating don't actually have the same meaning, you're just compressing your code; I've been trying to popularize labelling that kind of aggressive misapplication of DRY "Huffman coding".

On the other hand, if you keep repeating the same character sequence there is probably some structure on your code that you can also abstract away. You are not restricted to factoring business concepts.

There's clearly structure you can abstract away; doing so may be convenient, and that convenience may even make it a good idea. I contend, though, that if it does not represent a "piece of knowledge" that you're factoring out then you are dealing with concerns other than "DRY".

I do agree that a piece of knowledge may not be a business concept.

Re: Hang your code out to DRY

#62

Earlier quoted context omitted.

> I feel that this reflects the tech industry's obsession with hiring armies of relatively inexperienced developers, and then cycling through them, because we don't do what it takes to retain people. That is true (and it won't change, so we need to behave like it won't...), but that is not the only reason. An inheritance hierarchy in a large program that makes sense today might not make sense in a year or two. Refact…

I write Apple UIKit apps. I am looking forward to using SwiftUI, which is designed to afford use of Protocol-Oriented Programming, reactive/observer stuff, and a lot of lower-state stuff. I think it would have made the work I've been doing in the last few days, much easier. But if you use UIKit, then it's fairly important to use classic MVC (not MVVM), as that is what the SDK was specifically designed for. Trying to…

It’s possible (and IMO enjoyable) to write UIKit apps with ComposableArchitecture, a purely value-typed approach. I’ve also mostly used MVVM with UIKit since 2015, and found my apps to be stabler and easier to maintain than standard MVC apps.

In projects I lead I’ve been discouraging inheritance because I’ve found it highly detrimental to maintainability. “Base” classes invite bloat and overgeneralization, especially with inexperienced devs.

Re: Hang your code out to DRY

#63
post #62

Earlier quoted context omitted.

I write Apple UIKit apps. I am looking forward to using SwiftUI, which is designed to afford use of Protocol-Oriented Programming, reactive/observer stuff, and a lot of lower-state stuff. I think it would have made the work I've been doing in the last few days, much easier. But if you use UIKit, then it's fairly important to use classic MVC (not MVVM), as that is what the SDK was specifically designed for. Trying to…

It’s possible (and IMO enjoyable) to write UIKit apps with ComposableArchitecture, a purely value-typed approach. I’ve also mostly used MVVM with UIKit since 2015, and found my apps to be stabler and easier to maintain than standard MVC apps. In projects I lead I’ve been discouraging inheritance because I’ve found it highly detrimental to maintainability. “Base” classes invite bloat and overgeneralization, especially…

Isn't TCA a dependency framework?

I haven't found much joy in MVVM. I haven't found that it provides enough benefits to spend the time switching over.

I am looking forward to SwiftUI. I really hope that the documentation improves, though.

Re: Hang your code out to DRY

#64
post #62

Earlier quoted context omitted.

It’s possible (and IMO enjoyable) to write UIKit apps with ComposableArchitecture, a purely value-typed approach. I’ve also mostly used MVVM with UIKit since 2015, and found my apps to be stabler and easier to maintain than standard MVC apps. In projects I lead I’ve been discouraging inheritance because I’ve found it highly detrimental to maintainability. “Base” classes invite bloat and overgeneralization, especially…

Isn't TCA a dependency framework? I haven't found much joy in MVVM. I haven't found that it provides enough benefits to spend the time switching over. I am looking forward to SwiftUI. I really hope that the documentation improves, though.

TCA is a Redux/Elm-style data and state management lib that aspires to handle an app’s complete business logic, preventing devs from mixing the logic into the UI layer via SwiftUI’s @State and @StateObject. And contrary to Redux, it’s completely type safe and aware of deep component nesting (sub reducer states and actions are “pulled back” into their parent reducer pendants), so it allows truly composable components.

If you haven’t checked out PointFree’s content (authors of TCA among many other things), it’s one of the best resources on Swift and algorithms for sure.

Re: Hang your code out to DRY

#65

Earlier quoted context omitted.

To me, inheritance and polymorphism are two different things. Polymorphism is about different units implementing an interface or equivalent protocol and that rocks. Inheritance is, essentially, dumping a bunch of code into your new class, and most of the time just imposes constraints and breaks API boundaries for no good reason. After studying and doing OOP for about 5 years, I don't see the advantages of inheritance…

> After studying and doing OOP for about 5 years, I don't see the advantages of inheritance over composition. I mean, "prefer composition over inheritance" was in the GoF book which is from 1994, and is one of the core OOP books. If you've just been studying OOP for five years, it's likely that you weren't even BORN when this was already industry-level good practice.

Universities in my country are hopelessly stuck in the early 90s :)

Re: Hang your code out to DRY

#66
post #62

Earlier quoted context omitted.

It’s possible (and IMO enjoyable) to write UIKit apps with ComposableArchitecture, a purely value-typed approach. I’ve also mostly used MVVM with UIKit since 2015, and found my apps to be stabler and easier to maintain than standard MVC apps. In projects I lead I’ve been discouraging inheritance because I’ve found it highly detrimental to maintainability. “Base” classes invite bloat and overgeneralization, especially…

Isn't TCA a dependency framework? I haven't found much joy in MVVM. I haven't found that it provides enough benefits to spend the time switching over. I am looking forward to SwiftUI. I really hope that the documentation improves, though.

> Isn't TCA a dependency framework?

It is but it's quite straightforward to build your own simpler version using only Combine - that's what we're doing at the moment and it tends to work very well, interacting with Core Data has been kind of clunky though.

> I am looking forward to SwiftUI. I really hope that the documentation improves, though.

I've been on a project using it for the last 8 months both for macOS and iOS, I would honestly not rush into using it anytime soon. It's improved significantly since release, especially if you can target the newest iOS but requiring that is a hard-sell for most. On the Mac it's a different story and is much more neglected, macOS versions also tend to have far longer tails than iOS so it's a non-starter to try and sell a Monterey-only Mac app.

Edit: rereading my comment it sounds like I'm really down on SwiftUI - which I'm not, I think it's great when it works but there's a lot of rough edges at the moment and also quite a lot of hype.

Re: Hang your code out to DRY

#67
post #62

Earlier quoted context omitted.

It’s possible (and IMO enjoyable) to write UIKit apps with ComposableArchitecture, a purely value-typed approach. I’ve also mostly used MVVM with UIKit since 2015, and found my apps to be stabler and easier to maintain than standard MVC apps. In projects I lead I’ve been discouraging inheritance because I’ve found it highly detrimental to maintainability. “Base” classes invite bloat and overgeneralization, especially…

Isn't TCA a dependency framework? I haven't found much joy in MVVM. I haven't found that it provides enough benefits to spend the time switching over. I am looking forward to SwiftUI. I really hope that the documentation improves, though.

Thanks, both of you, for the explanations.

Re: Hang your code out to DRY

#68

I find it fascinating that people are so against inheritance/polymorphism, these days. That's one of the absolute best ways to DRY. factoring out common base classes is a classic OO exercise. It's possible to drastically reduce the size of a codebase, and the potential error exposure, by doing some simple extractions.

There's something to be said for preferring composition over inheritance, but in that case overly DRY code consists almost entirely of glue. As with almost anything it's a matter of choosing the right tool for the job. The only code style advices that I've found to hold nigh universally are the following: - The best code is no code - Don't end classes in 'er' or 'or' Coding paradigms are good when they let you do tho…

Simple fix, name it HelperClass instead?

Re: Hang your code out to DRY

#69

I find it fascinating that people are so against inheritance/polymorphism, these days. That's one of the absolute best ways to DRY. factoring out common base classes is a classic OO exercise. It's possible to drastically reduce the size of a codebase, and the potential error exposure, by doing some simple extractions.

There's something to be said for preferring composition over inheritance, but in that case overly DRY code consists almost entirely of glue. As with almost anything it's a matter of choosing the right tool for the job. The only code style advices that I've found to hold nigh universally are the following: - The best code is no code - Don't end classes in 'er' or 'or' Coding paradigms are good when they let you do tho…

Almost every one of my classes (in my UIKit app) is a ViewController. I don't really need to write anything more.

So they pretty much all are "er" classes. ¯\_(ツ)_/¯

Re: Hang your code out to DRY

#70
post #66

Earlier quoted context omitted.

Isn't TCA a dependency framework? I haven't found much joy in MVVM. I haven't found that it provides enough benefits to spend the time switching over. I am looking forward to SwiftUI. I really hope that the documentation improves, though.

> Isn't TCA a dependency framework? It is but it's quite straightforward to build your own simpler version using only Combine - that's what we're doing at the moment and it tends to work very well, interacting with Core Data has been kind of clunky though. > I am looking forward to SwiftUI. I really hope that the documentation improves, though. I've been on a project using it for the last 8 months both for macOS and…

If you are using TCA only for dependency management, I’d suggest to reconsider and put all business logic in it. In my experience, most serious efforts of wrangling SwiftUI into a complex app wind up with a solution that’s similar to TCA.
Post reply on HN