3 ms·

Yet, Java-codebases look the same now as they did then. The program structure is still "externalized" to a container because of a lack of abstractions. It's sti

by hurril 4y ago

Yet, Java-codebases look the same now as they did then. The program structure is still "externalized" to a container because of a lack of abstractions. It's still exactly the same.

kaba0 4y ago
I really don’t get what you mean. Java is not the most expressive language, but it is eons ahead of the expressivity of C or Go and yet I don’t believe it would be fair to claim that those languages also externalize their structure?
- hurril 4y ago
  What I mean is that a Java program is almost always sitting in a Spring container with most important stuff happening as "decorated magic"; this has been the case since even before 1.6. To say that it is somehow better now than it was, is therefore not worth much. Sure, I'm sure you guys'll put a map or a stream in there somewhere but it's ... still the same thing. There's no real evolution at all. The springification is what I mean by it being externalized and you generally don't see that in C, no. The pre-processor might be sort of the same thing but you generally don't bootstrap the entire thing using it.
  - kaba0 4y ago
    Well, Spring is mainly for backend systems that have a very specific functionality that is best handled by a generic solution. In my experience this is in line with how most other web frameworks operate. But this is absolutely domain-specific, Java the language is indifferent to exposing a library that will handle incoming request and dispatch them based on some library logic, or creating a “traditional” program for the litany of other domains where java is used st.
    - hurril 4y ago
      Spring isn't a web framework, it's gaffer tape for a language that just isn't good enough without it; that's why it's [spring] still around and its use is so prevalent. It's not at all mainly for very specific functionality in the sense that your post sort of implies [for web, and databasy things I presume]; in fact: it's just for wiring and for applying/ attaching things to "abstractions". As in: please decorate these sets of things with this behaviour. If you'd chosen languages that permit abstractions in a real and usable sense, then you would not need this. In fact: with _one_ exception, I've never had a container in any Haskell, Scala or F# project ever. Do you think we ever needed one? And this is my point: those other languages have seen _tons_ of development in the "abstraction arena" with (internal) DSL:s and super powerful frameworks for making powerful DSL:s. Java has had none of this because these concerns har all (poorly) handled at the container level. The tacked on "functional stuff" is for sure cool coming from a Java backround, but they're pretty much useless.
      - cityofdelusion 4y ago
        Spot-on analysis. I work on a team (that strongly prefers using Kotlin) in the CI-CD world. Despite web dev only being a minor part of our work, Spring just attaches itself to everything like a disease. I feel like it has gotten to the point where most Java developers that interview know Spring and not Java. Dependencies themselves also become attached to Spring (our example: bringing in Kafka -- super painful without Spring and hardly any examples or docs.) This "containerizing" is very unique to Java -- I've never seen anything like it in the other various languages I've used. I won't even mention the total disaster of JavaEE containers.
        hurril 4y ago
        Yes, it is terrible and it's the main reason I'll never be doing any Java, ever again. I did 10 years up until Java 6 (or so) and then jumped ship in favour of Scala (at that point.) Now, Scala for sure isn't perfect and Java isn't terrible, but mainstream Java really is. My point, though, is not to throw up all over Java but rather to quibble with the statement that Java has somehow evolved since then. It really hasn't!

by hurril 4y ago

Yet, Java-codebases look the same now as they did then. The program structure is still "externalized" to a container because of a lack of abstractions. It's still exactly the same.

kaba0 4y ago

I really don’t get what you mean. Java is not the most expressive language, but it is eons ahead of the expressivity of C or Go and yet I don’t believe it would be fair to claim that those languages also externalize their structure?

hurril 4y ago
What I mean is that a Java program is almost always sitting in a Spring container with most important stuff happening as "decorated magic"; this has been the case since even before 1.6. To say that it is somehow better now than it was, is therefore not worth much. Sure, I'm sure you guys'll put a map or a stream in there somewhere but it's ... still the same thing. There's no real evolution at all. The springification is what I mean by it being externalized and you generally don't see that in C, no. The pre-processor might be sort of the same thing but you generally don't bootstrap the entire thing using it.
- kaba0 4y ago
  Well, Spring is mainly for backend systems that have a very specific functionality that is best handled by a generic solution. In my experience this is in line with how most other web frameworks operate. But this is absolutely domain-specific, Java the language is indifferent to exposing a library that will handle incoming request and dispatch them based on some library logic, or creating a “traditional” program for the litany of other domains where java is used st.
  - hurril 4y ago
    Spring isn't a web framework, it's gaffer tape for a language that just isn't good enough without it; that's why it's [spring] still around and its use is so prevalent. It's not at all mainly for very specific functionality in the sense that your post sort of implies [for web, and databasy things I presume]; in fact: it's just for wiring and for applying/ attaching things to "abstractions". As in: please decorate these sets of things with this behaviour. If you'd chosen languages that permit abstractions in a real and usable sense, then you would not need this. In fact: with _one_ exception, I've never had a container in any Haskell, Scala or F# project ever. Do you think we ever needed one? And this is my point: those other languages have seen _tons_ of development in the "abstraction arena" with (internal) DSL:s and super powerful frameworks for making powerful DSL:s. Java has had none of this because these concerns har all (poorly) handled at the container level. The tacked on "functional stuff" is for sure cool coming from a Java backround, but they're pretty much useless.
    - cityofdelusion 4y ago
      Spot-on analysis. I work on a team (that strongly prefers using Kotlin) in the CI-CD world. Despite web dev only being a minor part of our work, Spring just attaches itself to everything like a disease. I feel like it has gotten to the point where most Java developers that interview know Spring and not Java. Dependencies themselves also become attached to Spring (our example: bringing in Kafka -- super painful without Spring and hardly any examples or docs.) This "containerizing" is very unique to Java -- I've never seen anything like it in the other various languages I've used. I won't even mention the total disaster of JavaEE containers.
      - hurril 4y ago
        Yes, it is terrible and it's the main reason I'll never be doing any Java, ever again. I did 10 years up until Java 6 (or so) and then jumped ship in favour of Scala (at that point.) Now, Scala for sure isn't perfect and Java isn't terrible, but mainstream Java really is. My point, though, is not to throw up all over Java but rather to quibble with the statement that Java has somehow evolved since then. It really hasn't!