In a typical imperative application, business logic and side effects are inextricably linked. For example, when you write await db.checkInventory(…), the runtime immediately reaches out to the database. Our Effect System works differently. Instead of performing the action, our functions return a description of the action. When our code needs to check inventory, it doesn’t call the database; it returns a plain object instead, which will be executed later by an interpreter.
  • magic_lobster_party@fedia.io
    7·
    5 days ago

    This only checks that functions are called in the right order. Not that the functions are doing the right thing or if the functions are called with the correct arguments. Quite pointless testing IMO.

    For example, it won’t capture cases where cmdChargeCreditCard returns a payment ID that exists for cmdCompleteOrder to use.

    Set up an in-memory database, or test against a real database. You don’t test side effects by pretending that the side effects are correct.

    • Aijan@programming.devOP
      1·
      5 days ago

      You can still test the functions individually or run the entire flow against a test database, but without an effect system like this, it’s very hard to test business logic in isolation.

  • Arigion@feddit.org
    4·
    5 days ago

    However, I think it’s safe to say this architecture is effectively AI-native.

    Lol…at first I thought the article wasn’t satire until I found the AI part. Well done.

    Summary: Hey, let’s add another abstraction layer so we don’t need to mock these calls, but we don’t test what happends in that pesky database call, because we would need to mock that somehow. But now we need AI to handle the abstraction layer.

    I think I’ll use this article as a basis for discussion for job interviews.

    Thanks.

    • Aijan@programming.devOP
      1·
      5 days ago

      Integration tests against a real database can and should still be performed. The idea here is the ability to test business logic in isolation without using mocks. Effect systems also have other benefits. You basically get cross-cutting concerns like logging and profiling for free. Every single database call, API request, and file read in your entire application can be easily logged and profiled.

      • Arigion@feddit.org
        1·
        5 days ago

        I am not arguing against an effect system. They can help in certain circumstances. But none of the reasons in the article are one of them. Also the article is a bit lopsided because the real pain with these systems is error handling, resource handling like transactions or parallelism etc.

        What you write about the “other benefits” profiling and logging is also not the reason to introduce such a system.

        What does an api request has to do with business logic?

        It feels a bit as if you just discovered the idea of effect systems and are now trying to justify to use it no matter what. 😉

        • Aijan@programming.devOP
          1·
          5 days ago

          I think you might be focusing on the execution of the request rather than the orchestration. The decision of when and why to make an API request is absolutely business logic. In imperative code, that logic is hard-coded to the execution. By separating the intent from the execution, we can test that decision flow without spinning up the infrastructure.