this is where design patterns come in handy even tho folks roll their eyes at it.

Design patterns are one of those things where you have to go through the full cycle to really use it effectively. It goes through the stages:

no patterns. -> Everything must follow the gang of four's patterns!!!! -> omg I can't read code anymore I'm just looking at factories. No more patterns!!! -> Patterns are useful as a response to very specific contexts.

I remember being religious about strategy patterns on an app I developed once where I kept the db layer separated from the code so that I could do data management as a strategy. Theoretically this would mean that if I ever switched DBs it would be effortless to create a new strategy and swap it out using a config. I could even do tests using in memory structures instead of DBs which made TDD ultra fast.

DB switchover never happened and the effort I put into maintaining the pattern was more than the effort it would have taken me to swap a db out later :,) .

	▲	tbossanova 9 hours ago \| parent [-]
		What about the productivity gains from in memory db for tests though? Hard to measure I guess

▲

cake-rusk 13 hours ago | parent | prev [-]

Design patterns exist to paper over language deficiencies. Use a language which is not deficient.

▲

WCSTombs 12 hours ago | parent | next [-]

There's some truth to this, since some design patterns can simply be implemented "for good" in a sufficiently powerful language, but I don't find it's true in general. Unfortunately, it has become something of a thought-terminating cliché. Some common design patterns are so flexible that if you really implemented them in full generality as, say, some library function, its interface would be so complex that it likely wouldn't be a net win.

	▲	cake-rusk 5 hours ago \| parent [-]
		> Some common design patterns are so flexible that if you really implemented them in full generality as, say, some library function, its interface would be so complex that it likely wouldn't be a net win Then I would say you have not arrived at the optimal solution. Keep looking.

▲

awesome_dude 11 hours ago | parent | prev | next [-]

Just my two cents - but a general purpose language is going to need to be coupled with design patterns in order to be useful for different tasks.

I'm using MVC design patterns for some codebases, I'm using DDD plus Event sourcing and Event Driven for others.

I suspect that you are thinking of a small subset of design patterns (eg. Gang of Four derived patterns like Visitor, Strategy, or Iterator )

	▲	cake-rusk 5 hours ago \| parent [-]
		> I'm using MVC design patterns for some codebases, I'm using DDD plus Event sourcing and Event Driven for others. All examples of OO nonsense. There is only one pattern you need (functions) (tongue-in-cheek): https://fsharpforfunandprofit.com/fppatterns/ Edit: Also consider using the ELM architecture instead of MVC: https://guide.elm-lang.org/architecture/

▲

antinomicus 13 hours ago | parent | prev [-]

Like what?

	▲	frogulis 7 hours ago \| parent \| next [-]
		First class functions and iterators are probably examples of what they mean, in terms of language features that obsolete (GoF) design patterns
	▲	cake-rusk 5 hours ago \| parent \| prev [-]
		Here you go: https://fsharpforfunandprofit.com/fppatterns/