14 ms·

Why has this been upvoted? The author is a novice and provides no insight. This just reads like he finally got to the second page of your standard book on funct

Why has this been upvoted? The author is a novice and provides no insight. This just reads like he finally got to the second page of your standard book on functional programming and somehow came to believe that everyone else is still on page one. What village is this guy from?

djfm 10y ago
Probably because event-sourcing is beginning to trend. The article is not that interesting in itself, but the conclusion is a good starting point for a conversation that may be. > Systems are largely not functional. But they can be. So, how?
- yrashk 10y ago
  My research into this topic has led me to lazy event sourcing so far https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007e17#.v3yqh7ukh https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007... My current view is that by eliminating or reducing the need to serialize domain objects, we're creating a system which is easier to argue about and provides an easy way to adjust domain models as the understanding or circumstances evolve.
  - djfm 10y ago
    Yeah, now this is a nice continuation to the conversation :) I too have been mildly obsessed with the kind of thinking you're developing in your post - very nice article! I've been very attracted to event-sourcing since I realized that now that React and redux have mostly solved the UI problem what remains to be solved is the problem of how to store our beautiful event-driven data. EDIT: re-read your comment, felt the need to say that your "current view" is exactly mine too
    - yrashk 10y ago
      I am happy to continue this conversation off-HN, perhaps Gitter? http://gitter.im/eventsourcing/eventsourcing http://gitter.im/eventsourcing/eventsourcing
skrebbel 10y ago
> What village is this guy from? I know this thread is about functional programming and so condescension is the norm, but isn't it about time we change that part of our culture a bit? You offer significantly fewer insights than the OP. Zero arguments, just name calling. The author reads this thread and is a real person. Are you proud? I, for one, found the article an insightful articulation of things I kinda sorta already knew but hadn't acted on. Also our team is in the middle of building an Elixir backend with a classically designed mutable DB so the article helps me reflect. Maybe now is the better time to change this.
- jdeisenberg 10y ago
  Elixir has more to offer than just a functional approach; there is OTP, lightweight processes, etc. If these are things you need, Elixir might still be an excellent choice.
  - skrebbel 10y ago
    I meant that I'm now considering changing the thing the article is about: using immutable data in the database and considering any mutable parts of it a cache, in a sense. Basically he's describing CQRS but not using the term. Moving off of Elixir certainly isn't being considered :-) We chose it particularly for its concurrency and robustness features, which are important to us (we're a messaging component for marketplace/platform sites so deliverability and concurrency are very high on the list). We'd have picked Erlang if Elixir didn't exist.
    - yrashk 10y ago
      I am indeed describing CQRS, or at least the way I see it. The way I am doing is this by making my read side a combination of lightweight "code-only" domain models and heavy db-side indexing of events themselves (as opposed to domain model tables of some sort) You can read more about it at https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007e17 https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007... and https://blog.eventsourcing.com/why-use-eventsourcing-database-6b5e2ac61848#.6kbrzbtr9 https://blog.eventsourcing.com/why-use-eventsourcing-databas... If you have any thoughts or questions, feel free to reach out to me (my nickname is the same almost anywhere, twitter, gmail, etc.) or Eventsourcing gitter room http://gitter.im/eventsourcing/eventsourcing http://gitter.im/eventsourcing/eventsourcing and I'll be happy to talk about these things.

djfm 10y ago

Probably because event-sourcing is beginning to trend. The article is not that interesting in itself, but the conclusion is a good starting point for a conversation that may be. > Systems are largely not functional. But they can be. So, how?

yrashk 10y ago
My research into this topic has led me to lazy event sourcing so far https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007e17#.v3yqh7ukh https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007... My current view is that by eliminating or reducing the need to serialize domain objects, we're creating a system which is easier to argue about and provides an easy way to adjust domain models as the understanding or circumstances evolve.
- djfm 10y ago
  Yeah, now this is a nice continuation to the conversation :) I too have been mildly obsessed with the kind of thinking you're developing in your post - very nice article! I've been very attracted to event-sourcing since I realized that now that React and redux have mostly solved the UI problem what remains to be solved is the problem of how to store our beautiful event-driven data. EDIT: re-read your comment, felt the need to say that your "current view" is exactly mine too
  - yrashk 10y ago
    I am happy to continue this conversation off-HN, perhaps Gitter? http://gitter.im/eventsourcing/eventsourcing http://gitter.im/eventsourcing/eventsourcing

skrebbel 10y ago

> What village is this guy from? I know this thread is about functional programming and so condescension is the norm, but isn't it about time we change that part of our culture a bit? You offer significantly fewer insights than the OP. Zero arguments, just name calling. The author reads this thread and is a real person. Are you proud? I, for one, found the article an insightful articulation of things I kinda sorta already knew but hadn't acted on. Also our team is in the middle of building an Elixir backend with a classically designed mutable DB so the article helps me reflect. Maybe now is the better time to change this.

jdeisenberg 10y ago
Elixir has more to offer than just a functional approach; there is OTP, lightweight processes, etc. If these are things you need, Elixir might still be an excellent choice.
- skrebbel 10y ago
  I meant that I'm now considering changing the thing the article is about: using immutable data in the database and considering any mutable parts of it a cache, in a sense. Basically he's describing CQRS but not using the term. Moving off of Elixir certainly isn't being considered :-) We chose it particularly for its concurrency and robustness features, which are important to us (we're a messaging component for marketplace/platform sites so deliverability and concurrency are very high on the list). We'd have picked Erlang if Elixir didn't exist.
  - yrashk 10y ago
    I am indeed describing CQRS, or at least the way I see it. The way I am doing is this by making my read side a combination of lightweight "code-only" domain models and heavy db-side indexing of events themselves (as opposed to domain model tables of some sort) You can read more about it at https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007e17 https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007... and https://blog.eventsourcing.com/why-use-eventsourcing-database-6b5e2ac61848#.6kbrzbtr9 https://blog.eventsourcing.com/why-use-eventsourcing-databas... If you have any thoughts or questions, feel free to reach out to me (my nickname is the same almost anywhere, twitter, gmail, etc.) or Eventsourcing gitter room http://gitter.im/eventsourcing/eventsourcing http://gitter.im/eventsourcing/eventsourcing and I'll be happy to talk about these things.