It's always sad to see people in the tech industry who are opposed to learning things. Quite a lot of the anti-Java, anti-abstraction, anti-complexity crowd seem to actually just be people who are one step above a sysadmin in their mental model of programming, don't see how large-scale programming is different from imperative scripting, don't understand that complex problems sometimes require complex/systematic solutions, and resist leaving their comfort zone.
There are certainly valid arguments against everything I just said, but quite often they are not the true motivation.
>>Quite a lot of the anti-Java, anti-abstraction, anti-complexity crowd seem to actually just be people who are one step above a sysadmin in their mental model of programming, don't see how large-scale programming is different from imperative scripting, don't understand that complex problems sometimes require complex/systematic solutions, and resist leaving their comfort zone.
May be you are the one refusing to leave the comfort zone. Fairly large chunks of programming ecosystem has moved to Golang, Rust and even other JVM languages like Kotlin for a reason. Most Python programmers today are Java refugees too.
Its just that the overall culture of Java is loaded with programmers who like to use senseless abuse of design patterns as some 'smartness signalling' mechanism. Endless layers and indirections to achieve even simplest of the tasks.
Using something like Golang and Python feels instantly less stressful and liberating when you go from Java to these languages.
How can a programming language stressful or liberating at all? There is no real difference between imperative languages regarding what you can do, and minuscule one regarding how you can do them. I’ve seen hardly maintainable and understandable code in all mentioned programming languages, regardless of used framework.
I have come to form a strong opinion regarding software development people: In general we are more comfortable with operational complexity than conceptual complexity. (A somewhat wider sense of conceptual, to include architecture, structure, etc.)
Some of us, like me and possibly you, are more comfortable with conceptual complexity but abhor operational complexity. This [division] mirrors the society at large, imo, but was masked during the early days a couple+ of decades ago when software geeks were truly geeks. That subset of demographics never was upset by complexity per se, only un-necessary complexity was a cause for getting upset. The general demographics is bothered by complexity, period.
Companion theory partly based on this opinion is that as the community grew by orders of magnitude from say late '80s to '10, it began to more closely resemble the general population. So the degeneration of keep it simple, stupid (KISS) to mean keep it stupid and simple is an economic and social phenomena.
We are workers in a field with an arts and craft mentality on the production side and global industrial demand on the consumer side. The factory worker plugin iPhones together is not asked to think conceptually. The factory worker making software widgets in some IT department however has to come up with an ad-hoc 'assembly-line' with his or her teammates. Of course they are going to poo poo conceptual complexity. What does it bring to the table for them or the production line?
In contrast, learning (or copy/pasting) n chants for m different infra-beasts to get your widget online seems far more reasonable and far more bangs for mental bucks.
I don't want to start a flame war, but I don't think there are "pro-complexity" and "anti-complexity" sides in programming debates, but really different views on where that complexity should be placed. Is a complex language unnecessary and design patterns are enough, or are design patterns symptoms of a language that's not powerful enough? I hope nobody is adding complexity for its own sake, at least.
There are certainly valid arguments against everything I just said, but quite often they are not the true motivation.