4 ms·

This is not the answer that HN wants to hear, but Spring has enormous market share and makes your resume more marketable for tens of thousands of jobs. Clojure

This is not the answer that HN wants to hear, but Spring has enormous market share and makes your resume more marketable for tens of thousands of jobs. Clojure, or any other niche language you might insert here, does not help with career building on that level. For every one shop that looks at darling niche stuff and thinks, "Ooh, that probably makes him or her a better programmer", there's ten shops who look at it and think, "They're probably going to be insufferable to work with, undermine the architects at every turn, and spend their whole time complaining about the tools we use". As an aside, if you see Spring as existing to correct issues with the underlying Java language, then I'm highly skeptical that you've ever had meaningful experience with either one. Spring is a portfolio of libraries, stretching across over a dozen business application development domains, with inversion of control as the only common thread. NO language has all that baked into its standard library, and you'd have to pull down a bajillion NPM packages (or whatever) to even come close to approximating it.

willtim 7y ago
> if you see Spring as existing to correct issues with the underlying Java language, then I'm highly skeptical that you've ever had meaningful experience with either one. Let's please avoid personal attacks if at all possible. Spring started out with the dependency injection framework and "aspect-oriented programming". It was marketed as an alternative to EJB. Web frameworks and other add-ons came later. If you don't see DI and AspectJ as working around Java's weaknesses, then I encourage you to try a more expressive language. In an expressive language (e.g. Clojure or Haskell), DI and AspectJ could be, for example, replaced by reifying a program as data and using modular interpreters. One interpreter using mock data, another talks to the database, uses transaction boundaries and logs. This sort of solution is unfortunately just not very practical in Java.
- Jach 7y ago
  DI is just another name for "passing values to functions". We did it in Java just fine before Spring became so popular and Spring doesn't add that much for this particular way of writing Java code. Of course Spring is nice as a whole, even if huge and much more than DI, but the benefits of using it just to specify lazy proxy singletons using annotations are overblown. Autowiring becomes seductive so you get situations when you still need to test and some devs now have a component class with 10 private autowired dependencies and ask questions on how to test it that lead to in order of awfulness using reflection in the test to bypass 'private' and assign dummy values to the dependencies, using Spring's JUnit test runner and mock beans, rewriting the class a bit to use constructor or setter-method autowires that you can set without bringing in all the spring machinery, or break up the test so it depends on less and individual parts may not even need to be Spring components at all. In another expressive language like Common Lisp, it has generic functions which 1) let you dispatch on more than just the class type of the first argument (implicitly in Java, explicitly 'self' in Python) which is a feature that by itself removes a lot of Java back-bending and 2) you can specify :before and :after and :around methods to provide the benefits of aspects with the built-in function compute-applicable-methods available to help see everything that might apply when invoking a method with specific arguments. There's also metaclasses which open other doors. There's just a whole lot of built-in expressiveness in the languages beyond the Java and JavaScript ecosystems.
solussd 7y ago
Software developers' skills are mostly fungible– supply meets demand. I've been happily employed (and regularly solicited) as a Clojure developer for over 8 years. There's no shortage of Clojure dev positions for developers that want to write Clojure.

willtim 7y ago

> if you see Spring as existing to correct issues with the underlying Java language, then I'm highly skeptical that you've ever had meaningful experience with either one. Let's please avoid personal attacks if at all possible. Spring started out with the dependency injection framework and "aspect-oriented programming". It was marketed as an alternative to EJB. Web frameworks and other add-ons came later. If you don't see DI and AspectJ as working around Java's weaknesses, then I encourage you to try a more expressive language. In an expressive language (e.g. Clojure or Haskell), DI and AspectJ could be, for example, replaced by reifying a program as data and using modular interpreters. One interpreter using mock data, another talks to the database, uses transaction boundaries and logs. This sort of solution is unfortunately just not very practical in Java.

Jach 7y ago
DI is just another name for "passing values to functions". We did it in Java just fine before Spring became so popular and Spring doesn't add that much for this particular way of writing Java code. Of course Spring is nice as a whole, even if huge and much more than DI, but the benefits of using it just to specify lazy proxy singletons using annotations are overblown. Autowiring becomes seductive so you get situations when you still need to test and some devs now have a component class with 10 private autowired dependencies and ask questions on how to test it that lead to in order of awfulness using reflection in the test to bypass 'private' and assign dummy values to the dependencies, using Spring's JUnit test runner and mock beans, rewriting the class a bit to use constructor or setter-method autowires that you can set without bringing in all the spring machinery, or break up the test so it depends on less and individual parts may not even need to be Spring components at all. In another expressive language like Common Lisp, it has generic functions which 1) let you dispatch on more than just the class type of the first argument (implicitly in Java, explicitly 'self' in Python) which is a feature that by itself removes a lot of Java back-bending and 2) you can specify :before and :after and :around methods to provide the benefits of aspects with the built-in function compute-applicable-methods available to help see everything that might apply when invoking a method with specific arguments. There's also metaclasses which open other doors. There's just a whole lot of built-in expressiveness in the languages beyond the Java and JavaScript ecosystems.

solussd 7y ago

Software developers' skills are mostly fungible– supply meets demand. I've been happily employed (and regularly solicited) as a Clojure developer for over 8 years. There's no shortage of Clojure dev positions for developers that want to write Clojure.