3 ms·

> But back to the topic, while there is a (fortunately getting less and less relevant) branch of Java which is very into needless abstractions, the language is

> But back to the topic, while there is a (fortunately getting less and less relevant) branch of Java which is very into needless abstractions, the language is a very small and easy to pickup one, allowing very readable and concise programs. How often do you actually just use the core language without one of the frameworks, though? I guess it largely depends on what you do. For example, if you use Java for web app development, one of the more popular frameworks out there is Spring or maybe Spring Boot, which will force you to deal with a large amount of abstractions. So while the languages themselves might not be that dissimilar, the ecosystems and frameworks/libraries around them, which actually shape how you'll use them most of the time (depending on the context), will most certainly lead to the differences being more pronounced.

kaba0 4y ago
In practice, Spring will not be much more than putting some annotation here and there (which is strangely enough what others like about Python’s Flask for example), it is very much not the XML-hell from decades ago - even Java EE is much better nowadays.
- KronisLV 4y ago
  > In practice, Spring will not be much more than putting some annotation here and there... As someone who's worked with quite a few (monolithic) enterprise projects, I couldn't disagree more! The regular Spring framework can turn out to be a total mess of various intertwined .xml configuration files, based on whatever the project needs - access control mechanisms or integrations with external providers (say, LDAP or Kerberos), perhaps various filters for processing web requests (transformations, logging, additional flow controls), things to make any number of integrated libraries work correctly (JSR310 integration with Jackson, for example), all of which gets even worse if you need to get server side rendering in any of the older technologies working correctly, like JSF and PrimeFaces. You can get a variety of things done with Spring, true, but in practice it's going to be brittle and needlessly verbose. The Spring Boot framework is a marked improvement, however you will still need a whole bunch of configuration in your .properties file(s), or maybe your YAML configuration if someone has opted to use that format. Of course, you shouldn't forget that you still need to figure out how to ensure that the profiles are loaded correctly and that you somehow haven't screwed up the settings in each file. But with Spring Boot, all of the sudden you need to also figure out which configuration related annotations you need and which ones could cause problems - how to better figure out passing DB connections to myBatis or Hibernate or whatever and also ensure that the session parameters are set as needed (say, default locale, so you don't get issues with Oracle). Spring Boot simply takes a lot of the XML hell and turns it into a Java hell - better, because you're working with a proper programming language, but still not quite there yet, because a lot of the problems will only manifest at runtime (ever needed @Lazy with @Autowired?), which isn't fun when your app with thousands of source files takes minutes to start up so you can check everything out. Personally, I blame reflection and dynamic behavior for a lot of these problems, which is far harder to reason about than your IDE telling you that what you're attempting to write is weird and won't work before you launch everything. Of course, my dislike of Spring is shaped by the utter messes of projects that I've had to work with, which is largely the inevitable outcome for any monolithic codebase that has to be kept around and is important to a business for close to a decade but also with limited resources (say, unlike the Linux kernel). That's also why previously I mentioned the "Green Vs. Brown Programming Languages" article - you tend to dislike some stacks once you've seen what long term projects in them end up looking like. So, if you can, it's probably best to stick to smaller projects and microservices so these pain points don't become readily apparent and then most frameworks would be passable - be it Spring, Spring Boot or most others. Though I sometimes wonder whether people who wrote COBOL and FORTRAN also found starting out and having smaller projects to be enjoyable. Somehow we talk about languages and frameworks, but not how much of a difference there can be between a new project and an older one - some sort of a maintainability degradation coefficient that would express how maintainability changes over time.
  - kaba0 4y ago
    I am by no means in disagreement with you, sure, spring (and javaee) monorepos can grow to barely maintainable complexities, but with the amount of features you listed I have to wonder, would it look any better in another stack? That huge complexity has to live somewhere, and I don’t know of any silver bullet platform managing to remain easy to maintain down that far the “add this feature as well” line. I would even go as far and claim that the reason Java has this reputation of huge complexity in every monorepo is partly the effect of survivorship bias. Some other stack may have crumbled long before growing to such a monstrosity. Nonetheless, I would also like to have more of compile-time DI, records, etc, but we shouldn’t just reinvent everything in a heartbeat.

kaba0 4y ago

In practice, Spring will not be much more than putting some annotation here and there (which is strangely enough what others like about Python’s Flask for example), it is very much not the XML-hell from decades ago - even Java EE is much better nowadays.

KronisLV 4y ago
> In practice, Spring will not be much more than putting some annotation here and there... As someone who's worked with quite a few (monolithic) enterprise projects, I couldn't disagree more! The regular Spring framework can turn out to be a total mess of various intertwined .xml configuration files, based on whatever the project needs - access control mechanisms or integrations with external providers (say, LDAP or Kerberos), perhaps various filters for processing web requests (transformations, logging, additional flow controls), things to make any number of integrated libraries work correctly (JSR310 integration with Jackson, for example), all of which gets even worse if you need to get server side rendering in any of the older technologies working correctly, like JSF and PrimeFaces. You can get a variety of things done with Spring, true, but in practice it's going to be brittle and needlessly verbose. The Spring Boot framework is a marked improvement, however you will still need a whole bunch of configuration in your .properties file(s), or maybe your YAML configuration if someone has opted to use that format. Of course, you shouldn't forget that you still need to figure out how to ensure that the profiles are loaded correctly and that you somehow haven't screwed up the settings in each file. But with Spring Boot, all of the sudden you need to also figure out which configuration related annotations you need and which ones could cause problems - how to better figure out passing DB connections to myBatis or Hibernate or whatever and also ensure that the session parameters are set as needed (say, default locale, so you don't get issues with Oracle). Spring Boot simply takes a lot of the XML hell and turns it into a Java hell - better, because you're working with a proper programming language, but still not quite there yet, because a lot of the problems will only manifest at runtime (ever needed @Lazy with @Autowired?), which isn't fun when your app with thousands of source files takes minutes to start up so you can check everything out. Personally, I blame reflection and dynamic behavior for a lot of these problems, which is far harder to reason about than your IDE telling you that what you're attempting to write is weird and won't work before you launch everything. Of course, my dislike of Spring is shaped by the utter messes of projects that I've had to work with, which is largely the inevitable outcome for any monolithic codebase that has to be kept around and is important to a business for close to a decade but also with limited resources (say, unlike the Linux kernel). That's also why previously I mentioned the "Green Vs. Brown Programming Languages" article - you tend to dislike some stacks once you've seen what long term projects in them end up looking like. So, if you can, it's probably best to stick to smaller projects and microservices so these pain points don't become readily apparent and then most frameworks would be passable - be it Spring, Spring Boot or most others. Though I sometimes wonder whether people who wrote COBOL and FORTRAN also found starting out and having smaller projects to be enjoyable. Somehow we talk about languages and frameworks, but not how much of a difference there can be between a new project and an older one - some sort of a maintainability degradation coefficient that would express how maintainability changes over time.
- kaba0 4y ago
  I am by no means in disagreement with you, sure, spring (and javaee) monorepos can grow to barely maintainable complexities, but with the amount of features you listed I have to wonder, would it look any better in another stack? That huge complexity has to live somewhere, and I don’t know of any silver bullet platform managing to remain easy to maintain down that far the “add this feature as well” line. I would even go as far and claim that the reason Java has this reputation of huge complexity in every monorepo is partly the effect of survivorship bias. Some other stack may have crumbled long before growing to such a monstrosity. Nonetheless, I would also like to have more of compile-time DI, records, etc, but we shouldn’t just reinvent everything in a heartbeat.