borar
@borar.bsky.social
While I understand the good intentions behind such reocurring statements, I am less careful and "politically" balanced: #fsharp is absolutely inherently better. The "needs" are irrelevant, objective properties are what matters in engineering. Just like precise power tools vs manual mediaval tools.
April 2, 2025 at 1:31 PM
While I understand the good intentions behind such reocurring statements, I am less careful and "politically" balanced: #fsharp is absolutely inherently better. The "needs" are irrelevant, objective properties are what matters in engineering. Just like precise power tools vs manual mediaval tools.
Functional programming and its idioms are the most fitting and sensible interpretation/realization of #eventsourcing. Fold multiple composable values of types provided by the layered model, alongside the use-case specific version, apply model logic, store a new record. "Aggregates" are a mistake.
March 10, 2025 at 2:55 PM
Functional programming and its idioms are the most fitting and sensible interpretation/realization of #eventsourcing. Fold multiple composable values of types provided by the layered model, alongside the use-case specific version, apply model logic, store a new record. "Aggregates" are a mistake.
Reposted by borar
Why would people use other programming languages for frontend dev when #purescript is just right there?
#functionalprogramming
#functionalprogramming
March 9, 2025 at 5:48 PM
Why would people use other programming languages for frontend dev when #purescript is just right there?
#functionalprogramming
#functionalprogramming
I think I understood the popularity of "modern" as a term. It embodies the implicit and unconcious understanding that most of the (visible online) software industry is a web of ad-hoc, anti-fundamental knowledge, hype-driven, half-assed ideas which break easily. Then its on to the next "modern".
March 10, 2025 at 9:35 AM
I think I understood the popularity of "modern" as a term. It embodies the implicit and unconcious understanding that most of the (visible online) software industry is a web of ad-hoc, anti-fundamental knowledge, hype-driven, half-assed ideas which break easily. Then its on to the next "modern".
My 5c about this, as always somewhat heretical. "Bounded context" is vague and not really interesting/useful. Vertical slice architecture is not an architecture, but a principle *within* an architecture. In particular, in the Onion architecture (my default). #DDD 🔽
Fellow #DDD folks out there,
Can someone explain to me what is a _practical_ difference between a vertical slice and a bounded context?
Can someone explain to me what is a _practical_ difference between a vertical slice and a bounded context?
February 27, 2025 at 9:43 PM
My 5c about this, as always somewhat heretical. "Bounded context" is vague and not really interesting/useful. Vertical slice architecture is not an architecture, but a principle *within* an architecture. In particular, in the Onion architecture (my default). #DDD 🔽
Only if you are making a fat client and the back-end is merely a thin layer between it and the DB and other infra.
In functional teams, back-end implements for front-end.
In dysfunctional teams, front-end implements for back-end.
In dysfunctional teams, front-end implements for back-end.
February 21, 2025 at 1:51 PM
Only if you are making a fat client and the back-end is merely a thin layer between it and the DB and other infra.
Maybe thou pure just followeth m, returneth to sanity of
m.
m.
I don't know who needs to hear this, but:
MaybeT . pure . Just =<< m
… is the same thing as:
return =<< m
… which is the same thing as:
m
MaybeT . pure . Just =<< m
… is the same thing as:
return =<< m
… which is the same thing as:
m
February 20, 2025 at 11:19 PM
Maybe thou pure just followeth m, returneth to sanity of
m.
m.
Reposted by borar
Why Blog If Nobody Reads It?
“You write because you think, because you observe, because you need to put it somewhere.”
https://andysblog.uk/why-blog-if-nobody-reads-it/
“You write because you think, because you observe, because you need to put it somewhere.”
https://andysblog.uk/why-blog-if-nobody-reads-it/
February 10, 2025 at 6:54 AM
Why Blog If Nobody Reads It?
“You write because you think, because you observe, because you need to put it somewhere.”
https://andysblog.uk/why-blog-if-nobody-reads-it/
“You write because you think, because you observe, because you need to put it somewhere.”
https://andysblog.uk/why-blog-if-nobody-reads-it/
Planning to write a blog post "Using row types for handling events raised by Web Components". #purescript
January 30, 2025 at 11:52 PM
Planning to write a blog post "Using row types for handling events raised by Web Components". #purescript
I wrote about using GADTs in a design for #eventsourcing API in a #haskell back-end. Somewhat related to the recent post by @mattoflambda.bsky.social
systema10.org/posts/making...
systema10.org/posts/making...
Making my life easier with two GADTs
systema10.org
January 21, 2025 at 10:39 PM
I wrote about using GADTs in a design for #eventsourcing API in a #haskell back-end. Somewhat related to the recent post by @mattoflambda.bsky.social
systema10.org/posts/making...
systema10.org/posts/making...
Working on refining my #eventsourcing design/template for #haskell applications. Using GADTs we can turn on or off optimistic concurrency check using "global" journal versions. Depending on the on/off setting, the "concurrent change detected" outcome becomes impossible and need not be handled.
January 15, 2025 at 11:51 PM
Working on refining my #eventsourcing design/template for #haskell applications. Using GADTs we can turn on or off optimistic concurrency check using "global" journal versions. Depending on the on/off setting, the "concurrent change detected" outcome becomes impossible and need not be handled.
Streams per entity are fundamentally in conflict with the basic essence of #eventsourcing. The essence being that we can compute *anything* by folding all records.
Counter-example: find all customers in a system where each customer has a dedicated journal/stream by customer ID.
Counter-example: find all customers in a system where each customer has a dedicated journal/stream by customer ID.
January 10, 2025 at 4:06 PM
Streams per entity are fundamentally in conflict with the basic essence of #eventsourcing. The essence being that we can compute *anything* by folding all records.
Counter-example: find all customers in a system where each customer has a dedicated journal/stream by customer ID.
Counter-example: find all customers in a system where each customer has a dedicated journal/stream by customer ID.
I made a demo about working with different error types and the Result type in F#. #fsharp
gist.github.com/Savelenko/23...
gist.github.com/Savelenko/23...
F# Result error merging with IWSAMs
F# Result error merging with IWSAMs. GitHub Gist: instantly share code, notes, and snippets.
gist.github.com
January 10, 2025 at 9:12 AM
I made a demo about working with different error types and the Result type in F#. #fsharp
gist.github.com/Savelenko/23...
gist.github.com/Savelenko/23...
Is the cabal 'data-files' machinery useful for static files needed by a Haskell Web application, for example CSS, JS and similar? What are best practices for "packaging" together the latter and the build product of cabal? A build system on top of cabal? #haskell
January 1, 2025 at 7:24 PM
Is the cabal 'data-files' machinery useful for static files needed by a Haskell Web application, for example CSS, JS and similar? What are best practices for "packaging" together the latter and the build product of cabal? A build system on top of cabal? #haskell
Beyond basic programs, HM-like type systems can be quite mysterious and awesome. The definitions and types of the #purescript functions below look strange at the first sight. I wonder how IWSAMs will fare when ported to #fsharp.
December 28, 2024 at 5:20 PM
Beyond basic programs, HM-like type systems can be quite mysterious and awesome. The definitions and types of the #purescript functions below look strange at the first sight. I wonder how IWSAMs will fare when ported to #fsharp.
Reposted by borar
Just uploaded a new release of the `foldl` package. This release has a bunch of new instance and utilities added by one very helpful outside contributor (Topsii):
hackage.haskell.org/package/fold...
hackage.haskell.org/package/fold...
Changelog for foldl-1.4.18 | Hackage
hackage.haskell.org
December 20, 2024 at 5:16 AM
Just uploaded a new release of the `foldl` package. This release has a bunch of new instance and utilities added by one very helpful outside contributor (Topsii):
hackage.haskell.org/package/fold...
hackage.haskell.org/package/fold...
Reposted by borar
We are looking for Haskell developers for Scrive as well :) EU based dev - Remote.
careers.scrive.com/jobs/5365423...
careers.scrive.com/jobs/5365423...
Haskell Developer - Scrive
Join Scrive and be part of an international, fast-growing company headquartered in Stockholm, Sweden. Collaborate with smart, caring, and driven colleagues across Europe as we shape the Scrive stor...
careers.scrive.com
December 19, 2024 at 10:31 AM
We are looking for Haskell developers for Scrive as well :) EU based dev - Remote.
careers.scrive.com/jobs/5365423...
careers.scrive.com/jobs/5365423...
Some heated discussions below. I am working with something similar right now. In 2013 I made an in-house message broker at work with my own algorithm for historical + real time event stream generation. We are still using it now. 🔽
This weeks' Design Accelerator:
Why I Hate the Outbox Pattern
and Why You Should Hate It Too
Watch now: youtu.be/3nZLU3b47iU
Why I Hate the Outbox Pattern
and Why You Should Hate It Too
Watch now: youtu.be/3nZLU3b47iU
Design Accelerator: Why I Hate the Outbox Pattern
YouTube video by Vaughn Vernon
youtu.be
December 16, 2024 at 10:44 PM
Some heated discussions below. I am working with something similar right now. In 2013 I made an in-house message broker at work with my own algorithm for historical + real time event stream generation. We are still using it now. 🔽
I am planning to write about my ES approach (which is quite contrarian compared to common wisdom) on my blog systema10.org
#eventsourcing
#eventsourcing
systema10.org
December 14, 2024 at 10:24 PM
I am planning to write about my ES approach (which is quite contrarian compared to common wisdom) on my blog systema10.org
#eventsourcing
#eventsourcing
Another suspicious property of aggregates is that they (I think) collapse the application and model layers of the application. If an aggregate is essentially the scope/boundary of everything which is allowed to happen (consistently) within a use-case, then it means that the model layer 🔽
December 12, 2024 at 11:47 PM
Another suspicious property of aggregates is that they (I think) collapse the application and model layers of the application. If an aggregate is essentially the scope/boundary of everything which is allowed to happen (consistently) within a use-case, then it means that the model layer 🔽
I am following the Lit tutorial. It is striking how the combination of reactice properties, declarative event listeners and the properties object inside of the web component class are essentially like a Halogen component! #purescript
December 11, 2024 at 10:57 PM
I am following the Lit tutorial. It is striking how the combination of reactice properties, declarative event listeners and the properties object inside of the web component class are essentially like a Halogen component! #purescript
I studied Web components for the first time and succeeded in using Shoelace with PureScript Halogen. Somehow working with "raw" HTML seems too low-level now, a step forward. #purescript #shoelace
December 8, 2024 at 2:44 PM
I studied Web components for the first time and succeeded in using Shoelace with PureScript Halogen. Somehow working with "raw" HTML seems too low-level now, a step forward. #purescript #shoelace
My perspective, much more focused: at its core, #EventSourcing is a storage mechanism where the application persists records about observations or conclusions and computes various values by folding them from past records, interpreting the sequence of records in different ways.
At its core, I see #EventSourcing as a transformation of a command and past events to a list of new events.
The command is an intent to perform an action.
Events capture decisions made.
We can also get an error back if the command cannot be executed.
The command is an intent to perform an action.
Events capture decisions made.
We can also get an error back if the command cannot be executed.
November 29, 2024 at 10:53 PM
My perspective, much more focused: at its core, #EventSourcing is a storage mechanism where the application persists records about observations or conclusions and computes various values by folding them from past records, interpreting the sequence of records in different ways.