Yes it seems strange to me that a Java developer is willing to learn Spring, a massive ad-hoc framework which exists in part because of Java's weaknesses, rather than functional programming and Clojure (a lifelong skill that will benefit their Java programming).
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.
> 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.
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.
I've worked with plenty of devs in my time who don't really understand what they're doing and just copy and paste code from Stack Overflow until it seems to work. A lot of the enterprise takes the monkeys with typewriters approach to software development.
I think there are cultural reasons for that because enterprise treats devs like fungible cogs that you replace when they burn out. It tends to be highly dehumanizing environment where devs have no say, no autonomy, and no ownership. This naturally pushes out people who have options, and you end up with a pool of devs who just want any job that pays the bills.
>>I think there are cultural reasons for that because enterprise treats devs like fungible cogs that you replace when they burn out.
Its mostly approach to any work in general. If it were upto them, these are really the kind of the people who would dig earth with spoons and shovels, instead of heavy machinery.
The idea is simple, should you use Spring + Java, you are likely to need say 60+ people to run a product well. It could take 15 to make it work in Clojure. But having 60 people has its own advantages from their perspective. Say 10 people decide to leave, they can hire 10 replacements for the lowest prices from the market, train them on the application and get it going. Eventually the whole team could leave and get replaced this way, reducing the problem to a bit like the Ship of Theseus paradox. But it works for them.
If they use Clojure, they have to treat people well, pay them well to retain them. Because there teams tend to be small and a exodus puts everything at risk.
They have to use spoons and shovels, personnel trained to work on heavy machinery are expensive, training is expensive and replacing them is expensive.
I think it's interesting that people (willingly?) pigeonhole themselves to the extent that they're a "Java developer" or a ".NET Engineer" rather than more simply a "Software Engineer".
I'm a Software Engineer, and while I have my go-to tools, I'd like to think I make an informed choice to use what fits the task at hand .
An Engineer who's a comfortable polygot is perhaps also a better Engineer overall.
I'm willingly pigeonholing myself as a "software developer mostly working on the JVM" just to be honest about my (current) main strengths/experince.
Throwing me into a Go/Python/whatever project would first need some time for me to get up to speed with the language.
I think it's a vicious circle: management used year of experienc with <tool/language> as a hiring filter, so devs focus on building years of experience with in-demand tools/languages to maintain maximum career opportunity, and the laser-like focus developers exhibit reinforces the idea that devs can't be flexible on tools and languages, supporting the use of the classic hiring filter.
They both share the underlying JVM library ecosystem, and as Java increasingly applies functional programming to its mainstream frameworks, clojure is a good illustration of how a near-pure functional style can work within the JVM environment
