3 ms·

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

• cake-rusk 9mo ago
  Design patterns exist to paper over language deficiencies. Use a language which is not deficient.
  • antinomicus 9mo ago
    Like what?
    • frogulis 9mo ago
      First class functions and iterators are probably examples of what they mean, in terms of language features that obsolete (GoF) design patterns
    • cake-rusk 9mo ago
      Here you go: https://fsharpforfunandprofit.com/fppatterns/ https://fsharpforfunandprofit.com/fppatterns/
  • WCSTombs 9mo ago
    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 9mo ago
      > 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 9mo ago
    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 9mo ago
      > 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/ https://fsharpforfunandprofit.com/fppatterns/ Edit: Also consider using the ELM architecture instead of MVC: https://guide.elm-lang.org/architecture/ https://guide.elm-lang.org/architecture/
      • awesome_dude 9mo ago
        I typically reach for Go when I am building things, bubbletea, a TUI library uses the Elm architecture and enforces it on people using it. Did not like, Won't use again. MVC is well understood and works perfectly in my experience. edit: Even though you were tongue in cheek about F# - this stood out on the page > The functional programming community has design patterns and principles as well.
        • cake-rusk 9mo ago
          IMO the ELM architecture only works with pure functions. It doesn't work with languages which cannot provide this compile time guarantee. Also functional programming needs a different mindset / training. You won't benefit from it until you understand what it actually brings to the table (and what it leaves out).
          • awesome_dude 9mo ago
            I have to ask - I like some of the paradigms of Functional programming (IMO it makes concurrent programming a lot easier because state is never shared) Why hasn't it cut through, like OO did? and Beam has been around since the 90s, had a good marquee project (RabbitMQ) but still has low adoption
  • esafak 9mo ago
    https://www.cognitect.com/blog/2007/5/17/design-patterns-are-code-smells https://www.cognitect.com/blog/2007/5/17/design-patterns-are...
    • cake-rusk 9mo ago
      I agree. Doesn't contradict anything I said. So I will assume you posted the link in support of my argument :)
• nstart 9mo ago
  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 9mo ago
    What about the productivity gains from in memory db for tests though? Hard to measure I guess
    • guhidalg 9mo ago
      In my experience, there is no in-memory database replacement that correctly replicates the behavior of your database. You need to use a real database, or at least an emulator of one. For example, I have an app that uses Postgres as the database. I have a lot of functions, schemas, triggers, constraints in Postgres for modifying database state, because the database is 100x faster at this than my application will ever be. If I have an in-memory version of Postgres, it would need to replicate those Postgres features, and at that point I really should just be standing up a database and testing against it. I have worked with people claiming that unit tests need to hermetically run in-memory, because reasons. Ok, I don't disagree, but if my bug or feature requires testing that the database is modified correctly, I need to test against a real database! Your in-memory mock will not replicate the behavior of a database _ask me how I know_ ... These days, Docker makes this so easy that it's just lazy to not standup a database container and write tests againts it.
  • GreenWatermelon 9mo ago