Fork me on GitHub

I have a thousand important things I need to work on, so I decided it's the appropriate time to learn a new programming language. For those who have learned haskell after clojure (or just imagine you did), how did learning it benefit your clojure code?

Jimmy Miller19:02:23

For me it has been less about benefiting my clojure code directly and more about giving you a new way to think about problems. Monads/Functors/Applicative/Monoids/etc get a lot of hate. But making yourself see things in a new light can be really enlightening. There are all sorts of things that I used to see as disjoint, disconnected behaviors and now I can see the similarities between them. In short, just like lisp expands your mind as to what programming can be, so does haskell.


I have learned Haskell in 2018, but to be honest, I don't think it has influenced my Clojure code a lot. Maybe in one aspect: keep the types of your in and outputs simple. E.g. don't return "a single thing or a seq if you add this option, or a transducer if you use one less arity". Just write another function. Not a hard rule, but something I've come to like more.


I feel that it's not a bad heuristic to write another function any time you get stuck. And it's a very cheap decision that can be rolled back easily.


Does anyone here happen to have any long-term experience in using Hasura as a part of a larger application?


It seems like a nice tool to setup a simple MVP graphql + postgres demo applications with a few clicks, but the direct access to the DB seems like a poor integration point with regard to a larger app with potentially multiple databases..


I’ve seem multiple Hasura presentations, and share the concern. However it seems many times GraphQL is used with a simple crud design, and for that it seems great. They do have some security stuff, to limit what one can change. But tying you’re db to the api is not always a good idea. With multiple db’s you could also combine several GraphQL endpoints, with things like schema stitching or federation. But those kind of tools are almost exclusively in Node.


yeah, I'm dealing with a scenario where we will most likely have one or more proper application backends (with validation etc) with their own databases (and migrations) and I have a hard time figuring out how Hasura would fit in without creating additional problems. Apparently Hasura can merge several graphql APIs together ("remote schema") but this comes with its own limitations (no real-time subscriptions).


I've used both postgraphile and hasura. The former in production, the latter just "for fun". They are great tools for the right job. I prefer postgraphile generally because it offers a code-based workflow versus hasura's primarily UI driven process. Also leveraging postgresql's RLS with postgraphile works very well. We have a backend application in node that included postgraphile and was able to do some additional processing on the fly. In Hasura you need a microservice/external service architecture to handle that. With postgraphile you retain the feeling of owning your app because of all the extension points, I didn't get that with hasura. In either case though your graphql api is strictly tied to your database schema, and both encourage you to push logic into the DB. Which, well depends on your application and how strong your plpgsql chops are. I haven't used hasura's remote schemas nor their actions.

👍 3

I'm working with java classes from .http.* and as a clojure developer I see only 3 things: - interface: that the cool one, where i use reify - class // abstract class: I know that when reify throws, then I use proxy - final class: both throws and I get sad There is somewhere that I can learn more about the reasons for a java developer choose between these 3 approaches? For me it's pretty random. HttpClient is a protected abstract class HttpRequest is a public abstract class HttpResponse is a interface URI is a final class Why they are not all interfaces? Why URI is final ?


I think it boils down to the fact that Java is an old language featuring different generations of mechanisms and prevailing ideas (which continue mutating!) "Composition <interfaces> over inhertitance <abstract classes>" wasn't a prevailing idea in the 90s


> Why URI is final ? It's an explicit way to discourage customization outside their foreseen use cases. It's a similar reason to why someone would pick private - it delimits the API boundaries