6 ms·

I had first-hand experience with the way java developers avoid XML config. In my early days I wrote some javabean mapper framework but it wasn't liked by my pee

by fmjrey 19d ago

I had first-hand experience with the way java developers avoid XML config. In my early days I wrote some javabean mapper framework but it wasn't liked by my peers becaused it was driven by XML. Back then EJB, Struts, and many web/enterprise frameworks used XML for config, so it was a no brainer to continue the trend. However the DX of XML in Java wasn't that great I have to admit. This is what made Spring so successful with its annotation-driven approach to config: you can annotate directly in the code, no need to manually create or edit XML files. Clojure does not have this issue at all: XML easily translate into clojure data structures, and vice-versa, and from there you no longer feel any pain. I find it ironic that for a language in which data is code and code is data, you need to revert to java to integrate with annotations which is metadata added to code. I guess the fundamental question is: do we want clojure to develop a parallel story for enterprise development, or do we want to improve clojure for better integration with enterprise frameworks. Back to slipway: what do you think can be done on the clojure side to make the slipway integration story easier to reproduce for other enterprise frameworks? I doubt the JDK will change for us so best is for us to adapt as much as possible (despite such conclusion [0]). [0] https://blog.jakubholy.net/translating-enterprise-spring-app-to-clojure/#_conclusion https://blog.jakubholy.net/translating-enterprise-spring-app...

d_t_w 17d ago
> do we want clojure to develop a parallel story for enterprise development I don't think this is feasible, partly because these enterprise frameworks tend to be abstract systems, and I haven't seen any evidence in the Clojure world of anyone building anything similar to Quarkus for instance. It's too big a job, we have too few people doing this work in Clojure with the relevant experience to maintain something serious. Much of my thought is put into how do I achieve the standard necessary for my company, and that's where Slipway comes from. But I have to consider how I will also support enterprise grade SAML for instance, and how those lands are shifting, and a number of other similar needs. These are the things that are normally captured by the framework, and those JVM frameworks are moving in a non-Clojurish way. > what do you think can be done on the clojure side to make the slipway integration story easier to reproduce for other enterprise frameworks? Unfortunately I don't have an answer to this, and I'm not sure there is one. Slipway can work with Jetty because Jetty is POJO, and that is becoming more rare in this space. Which would put us back at your first question, 'do we want clojure to develop a parallel story for enterprise development'.

by fmjrey 19d ago

d_t_w 17d ago

> do we want clojure to develop a parallel story for enterprise development I don't think this is feasible, partly because these enterprise frameworks tend to be abstract systems, and I haven't seen any evidence in the Clojure world of anyone building anything similar to Quarkus for instance. It's too big a job, we have too few people doing this work in Clojure with the relevant experience to maintain something serious. Much of my thought is put into how do I achieve the standard necessary for my company, and that's where Slipway comes from. But I have to consider how I will also support enterprise grade SAML for instance, and how those lands are shifting, and a number of other similar needs. These are the things that are normally captured by the framework, and those JVM frameworks are moving in a non-Clojurish way. > what do you think can be done on the clojure side to make the slipway integration story easier to reproduce for other enterprise frameworks? Unfortunately I don't have an answer to this, and I'm not sure there is one. Slipway can work with Jetty because Jetty is POJO, and that is becoming more rare in this space. Which would put us back at your first question, 'do we want clojure to develop a parallel story for enterprise development'.