// Once we have electric, we then establish the data change
// notification subscription, comparing the tablenames used by the
// query with the changed tablenames in the data change notification
// to determine whether to re-query or not.
//
// If we do need to re-query, then we use the saved function to reuse the query
So it re-runs queries on all updates in tables from the query.
Check data sheets for any 3d printing filament, Young’s modulus is the main characteristic in them and that's how you can reason about filament abilities.
Based on what I read it's very similar to Kafka Streams + batteries ([semi]automatic workload orchestration, reactive queries, higher-level/slicker/"smarter" API (?))
Could you please compare Rama with Kafka Streams, especially from the point of view, if I would try to reimplement Rama API on top of Kafka Streams? What fundamental difficulties I'd face?
How do you plan to make the CEF-based browser view accessible? Are you aware of the challenges of making CEF fully accessible with a screen reader when using off-screen rendering?
In truth, it's a balancing act. More than a few Haskell libraries are more tedious than Elm code (I've written upwards of 8,000 lines of production Elm but have been doing Haskell for much longer) because they're so intensely abstract.
Without typeclasses, that simply doesn't happen. I'd say 90% or more of Haskell typeclass usage is pointless, and maybe half of what remains is simple to replace with simpler polymorphism or no polymorphism.
is replaced, in Elm, by just having an explicit module reference, so Maybe.andThen instead of andThen. No joke, that replaces essentially all of it, except some stuff that's not used that often.
You're way more experienced than me in this, but it seems to me that anywhere you're going to be replacing polymorphism is going to result in more typing. If you know the module that you want, then it is trivial, but the point of type classes (IIUC) is to write generic functions that can act on a variety of types.
To replace the non-trivial cases is going to require pattern matching, it seems. If your types change, then you are going to have to update things in multiple places.
But, like you said, it's not the end of the world. In many cases the intent will probably be clearer. Still, I'd rather have type classes than not.
Typeclasses aren't bad, that's for sure. I kinda want something as flexible as typeclasses and derive generic but no where near that complex. A big part of me says I could do well with just promising some JavaScript really really meets a type signature. Ports are great for side effects but I there might be room for this for pure functions?
How do you decide what queries are relevant?