For all of the #fsharp bits I tweeted, this is the key takeaway. I can point a new developer on my team at this block of code and say "this is the protocol" and in a separate code file we have a concise FSM that processes all of these

Readably concise, immutable, and fully typed
Can't do that in C# without pressing F12 hundreds of times.
Not _quite_ fully typed - don't provide any hints on how the processor might respond. Not sure how I'd do that just yet.
Also, not sure it's necessary to do that here. A higher level type that expresses an input "ProductUpdateCommand" and an output "ProductResponse" is probably the right place to put that.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Aaron Stannard

Aaron Stannard Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @Aaronontheweb

12 Aug
Adding key / entityId interfaces to discriminated unions in F# for use with @AkkaDotNET routing constructs like Cluster.Sharding is such a succinct way to implement a protocol docs.microsoft.com/en-us/dotnet/f…
@AkkaDotNET I'm almost done with my first set of domain state machines with my F# prototype and it's just a breeze compared to the same one I implemented in C# - I'm | | close to recommending it to some customers who have greenfield projects
Benefits of this approach, once I forced myself to learn it over the course of 4-5 2hr Twitch stream sessions:

1. Not having to worry about mutability - cuts out 80% of boilerplate code alone
2. Can make it nearly impossible to express illegal states via the type system
Read 7 tweets
18 Jun
Playing with some ideas for this "ways in which software developers destroy value" blog post.

- Destroying optionality
- Frameworkism
- Domain omniscience
- Infrastructure coupling
Difficult idea to express because many of these weaknesses are strengths taken to an extreme.

i.e. Frameworkism, building frameworks for building apps rather than just building apps, occurs when DRY gets taken to an extreme and the developer misses the point.
In other cases though, it's failure on the part of the developer to anticipate future changes to the project when they're inexpensive to implement, i.e. building an event-sourcing abstraction when you don't have customer data to preserve, which becomes a giant project later
Read 6 tweets
18 Jun
Some developers objected to my insistence on using event sourcing by default, claiming that auditing features of modern databases are sufficient.

My mistake: the biggest benefit of event sourcing is not auditability, it's optionality.
If I have the history of state changes for my business entities preserved it creates options for the following:

1. Replaying old data with new code (simulation)
2. Creating novel features and experiences from old data (projections)
3. Reverting objects back to previous states
4. Introducing new ways of modifying business entities that can easily be reconciled along with prior ones

These are all extremely valuable and powerful future-facing tools that you will regret not having once you, inevitably, encounter a customer request that necessitates them
Read 6 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(