5 ms·

No. It's not the Java language. It is the developers. They are the ones who have to have 35 levels of abstraction. Why? Because for some reason they think this

No. It's not the Java language. It is the developers. They are the ones who have to have 35 levels of abstraction. Why? Because for some reason they think this will make modifying the software they write easier. In reality, no, it doesn't because everyone gets frustrated wading through the abstractions. If I can hold ten items in my brain's working memory and all ten are taken up by keeping track of how many levels deep I'm in, then it is really hard to make any real changes to the code.

67726e 10y ago
It's not a language causing shitty abstractions, it's not a framework causing shitty abstractions. It's shitty developers. One can write a Java application and never touch XML, use AbstractFactoryWhateverTheFuck, and write sane, clean code. I've done so for years, worked on green and brown-field projects. I've also written, maintained, and modified monstrosities in Java... as well as C#, Javascript (front and back-end), PHP, Python, and plenty more. Java is not the Hot New Thing™ and never will be. It's also not always the answer, but for a run of the mill application running on a web-server you're going to have a hard time finding a better language and ecosystem that will keep on trucking and be reasonable to work with.
- willtim 10y ago
  The presence of many of these frameworks, spring, AOP etc, is proof that many people do not find Java reasonable to work with. If Java was sufficiently expressive, you would need only libraries.
  - 67726e 10y ago
    What, specifically, about having a framework means the language is not expressive enough?
    - willtim 10y ago
      Frameworks do not compose. Libraries do. If you need a framework, your language has failed.
      - 67726e 10y ago
        No one needs a framework, but if one makes things easier then what is the problem? What, in your mind, is a good language that needs no framework?
        willtim 10y ago
        Everything has a cost. As I said, frameworks do not compose and often fundamentally take away control. If you want to change the behaviour of your framework, you need to hope they have created the necessary callback interfaces.
    - zaptheimpaler 10y ago
      Not parent, but for example, this is how easy serialization is in Scala Play in the majority of cases: case class Person(name: String, age: Int, likes: List[CustomObject]) //simple data object implicit val personFormat: Format[Person] = format[Person] //this creates a "Format[Person]" with serialize/deserialize methods The code to generate a serializer/deserializer is completely independent from the definition of the data, no annotations or XML needed. It is also efficient in that it doesn't use reflection. This is only possible because of how expressive Scala is - macros and strong type system means a lot of powerful code introspection can be done at compile time. Because of implicits, most of the time I write that one line above, and an HTTP handler as a simple function from (Person => HttpResponse) and dont even think about the serialization/deserialization. And that one line is not an opaque abstraction, it is very customizable if you need it to be, and all via code not config. Using Jackson in Java can get much more complex because annotations and XML files creep across the whole code if you want compile time generation. I think this is directly because Java's inspect/generate code at compile-time is not as powerful as macros.
  - deleted 10y ago
    [deleted]
jt2190 10y ago
> If I can hold ten items in my brain's working memory and all ten are taken up by keeping track of how many levels deep I'm in... If you find yourself doing this, it is a clear indication that the software design is failing to abstract properly or at all. (I'd argue that the industry in general has a terrible ratio of "coders" to people who can design programs, thus you're much more likey to come across poor designs than good ones. Beware of this when judging programming languages.)
- qznc 10y ago
  > a clear indication that the software design is failing to abstract properly or at all I believe, it is an indication that people tried to fix all the leaks in the abstractions, which turns the abstraction into an ugly twin of the stuff it tried to simplify. ORMs are a good example. They start easy and simple, but lack various features of full SQL. If you start a new project, the ORM is fine. At some point, you are forced to use plain SQL, which clashes horribly with the ORM concepts. Thus the desire to extend the ORM. Over time more and more features are bolted on and the complexity grows.
  - Consultant32452 10y ago
    IMO that's still bad design on the end user of the ORM library. There's a time and place to use tools like Hibernate, but it became fashionable so it's used all over the place where it doesn't fit and has created huge messes. There's a really bad trend in the industry of choosing libraries or tools based on trying to improve your resume, rather than trying to find the best solution to a problem.
    - willtim 10y ago
      Absolutely, just look at all the Hadoop users who don't really have big data.
    - cryptonector 10y ago
      I've worked with a number of ORMs, mostly home-grown, admittedly. I've yet to see a good one. Often ORMs fail to implement JOINs efficiently. Every ORM fails to give you a powerful query language: if they had a powerful query language, someone would write an ORM for the ORM, because the reason ORMs exist is that "SQL is hard", as the doll says, and any powerful query language will get the same treatment. But SQL is not really hard, and not having SQL eventually means you pay a huge price. And then there's things like LDAP, which are absolutely awful. LDAP's object naming scheme has no canonical text representation. Let that sink in. And that's not even the main problem -- forcing your database to be hierarchical and a collection of objects, with no standard relation/pointer type, is. (Yes, Active Directory has an Object DN type, I'm aware.) Just say NO to ORMs.
digler999 10y ago
> They are the ones who have to have 35 levels of abstraction. Have you seen FizzBuzz: Enterprise Edition ? https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- RUG3Y 10y ago
  haha thanks for sharing that, one of the most absurd things I've ever seen. Every once in a while I think about picking up Java or .NET and going for the enterprise-y jobs...no thanks.
- Dove 10y ago
  I'm going to be laughing about this for days.
  - digler999 10y ago
    its beautiful, not only is it absurd and hilarious, but it says so much. Not as a direct diss to java, but how badly a simple task can get over-designed to the point of being indecipherable. What would be great is if they added some kind of CRM or e-commerce to it, and donated the proceeds to charity. So like, could "Pay as a service" or sign up for "fizzBuzz as a service" and pay to run fizz buzz up to certain limits.
willtim 10y ago
I'm not sure you can really separate the two. Sun pushed out the language and also helped develop much of the culture (enterprise beans, the pet shop example). Languages shape peoples thinking.
scalesolved 10y ago
I disagree, it is some developers. Just as some developers can create a big ball of magic code dynamic code or as some developers can make insanely cryptic code in Scala/Haskell that looks like the user is typing in windings. Java 8 and the current ecosystem can be incredibly lean and devoid of high levels of abstraction. Like today how I took the lovely Sinatra inspired http://sparkjava.com/ http://sparkjava.com/ out for a spin. I think if Java can shed the memory of it's horrible past (and the enterprise space was truly bad) then it has a lot to offer developers these days.
dlwdlw 10y ago
I agree that there is a Java culture, but I also think that it developed into the way it is because it was so popular during a time when there werent very good engineering practices by non-technical people. The movement towards wanting managers with a technical background I think is fairly recent. The majority mass of java developers now probably "grew up" in the jaded horror story environments we seek to avoid. Also, i think new grads tend to only know how to make things dry via abstraction (not considering the trade offs) and b/c of javas popularity and oop as a buzzword, always did it via inheritance.

67726e 10y ago

It's not a language causing shitty abstractions, it's not a framework causing shitty abstractions. It's shitty developers. One can write a Java application and never touch XML, use AbstractFactoryWhateverTheFuck, and write sane, clean code. I've done so for years, worked on green and brown-field projects. I've also written, maintained, and modified monstrosities in Java... as well as C#, Javascript (front and back-end), PHP, Python, and plenty more. Java is not the Hot New Thing™ and never will be. It's also not always the answer, but for a run of the mill application running on a web-server you're going to have a hard time finding a better language and ecosystem that will keep on trucking and be reasonable to work with.

willtim 10y ago
The presence of many of these frameworks, spring, AOP etc, is proof that many people do not find Java reasonable to work with. If Java was sufficiently expressive, you would need only libraries.
- 67726e 10y ago
  What, specifically, about having a framework means the language is not expressive enough?
  - willtim 10y ago
    Frameworks do not compose. Libraries do. If you need a framework, your language has failed.
    - 67726e 10y ago
      No one needs a framework, but if one makes things easier then what is the problem? What, in your mind, is a good language that needs no framework?
      - willtim 10y ago
        Everything has a cost. As I said, frameworks do not compose and often fundamentally take away control. If you want to change the behaviour of your framework, you need to hope they have created the necessary callback interfaces.
  - zaptheimpaler 10y ago
    Not parent, but for example, this is how easy serialization is in Scala Play in the majority of cases: case class Person(name: String, age: Int, likes: List[CustomObject]) //simple data object implicit val personFormat: Format[Person] = format[Person] //this creates a "Format[Person]" with serialize/deserialize methods The code to generate a serializer/deserializer is completely independent from the definition of the data, no annotations or XML needed. It is also efficient in that it doesn't use reflection. This is only possible because of how expressive Scala is - macros and strong type system means a lot of powerful code introspection can be done at compile time. Because of implicits, most of the time I write that one line above, and an HTTP handler as a simple function from (Person => HttpResponse) and dont even think about the serialization/deserialization. And that one line is not an opaque abstraction, it is very customizable if you need it to be, and all via code not config. Using Jackson in Java can get much more complex because annotations and XML files creep across the whole code if you want compile time generation. I think this is directly because Java's inspect/generate code at compile-time is not as powerful as macros.
- deleted 10y ago
  [deleted]

jt2190 10y ago

> If I can hold ten items in my brain's working memory and all ten are taken up by keeping track of how many levels deep I'm in... If you find yourself doing this, it is a clear indication that the software design is failing to abstract properly or at all. (I'd argue that the industry in general has a terrible ratio of "coders" to people who can design programs, thus you're much more likey to come across poor designs than good ones. Beware of this when judging programming languages.)

qznc 10y ago
> a clear indication that the software design is failing to abstract properly or at all I believe, it is an indication that people tried to fix all the leaks in the abstractions, which turns the abstraction into an ugly twin of the stuff it tried to simplify. ORMs are a good example. They start easy and simple, but lack various features of full SQL. If you start a new project, the ORM is fine. At some point, you are forced to use plain SQL, which clashes horribly with the ORM concepts. Thus the desire to extend the ORM. Over time more and more features are bolted on and the complexity grows.
- Consultant32452 10y ago
  IMO that's still bad design on the end user of the ORM library. There's a time and place to use tools like Hibernate, but it became fashionable so it's used all over the place where it doesn't fit and has created huge messes. There's a really bad trend in the industry of choosing libraries or tools based on trying to improve your resume, rather than trying to find the best solution to a problem.
  - willtim 10y ago
    Absolutely, just look at all the Hadoop users who don't really have big data.
  - cryptonector 10y ago
    I've worked with a number of ORMs, mostly home-grown, admittedly. I've yet to see a good one. Often ORMs fail to implement JOINs efficiently. Every ORM fails to give you a powerful query language: if they had a powerful query language, someone would write an ORM for the ORM, because the reason ORMs exist is that "SQL is hard", as the doll says, and any powerful query language will get the same treatment. But SQL is not really hard, and not having SQL eventually means you pay a huge price. And then there's things like LDAP, which are absolutely awful. LDAP's object naming scheme has no canonical text representation. Let that sink in. And that's not even the main problem -- forcing your database to be hierarchical and a collection of objects, with no standard relation/pointer type, is. (Yes, Active Directory has an Object DN type, I'm aware.) Just say NO to ORMs.

digler999 10y ago

> They are the ones who have to have 35 levels of abstraction. Have you seen FizzBuzz: Enterprise Edition ? https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

RUG3Y 10y ago
haha thanks for sharing that, one of the most absurd things I've ever seen. Every once in a while I think about picking up Java or .NET and going for the enterprise-y jobs...no thanks.
Dove 10y ago
I'm going to be laughing about this for days.
- digler999 10y ago
  its beautiful, not only is it absurd and hilarious, but it says so much. Not as a direct diss to java, but how badly a simple task can get over-designed to the point of being indecipherable. What would be great is if they added some kind of CRM or e-commerce to it, and donated the proceeds to charity. So like, could "Pay as a service" or sign up for "fizzBuzz as a service" and pay to run fizz buzz up to certain limits.

willtim 10y ago

I'm not sure you can really separate the two. Sun pushed out the language and also helped develop much of the culture (enterprise beans, the pet shop example). Languages shape peoples thinking.

scalesolved 10y ago

I disagree, it is some developers. Just as some developers can create a big ball of magic code dynamic code or as some developers can make insanely cryptic code in Scala/Haskell that looks like the user is typing in windings. Java 8 and the current ecosystem can be incredibly lean and devoid of high levels of abstraction. Like today how I took the lovely Sinatra inspired http://sparkjava.com/ http://sparkjava.com/ out for a spin. I think if Java can shed the memory of it's horrible past (and the enterprise space was truly bad) then it has a lot to offer developers these days.

dlwdlw 10y ago

I agree that there is a Java culture, but I also think that it developed into the way it is because it was so popular during a time when there werent very good engineering practices by non-technical people. The movement towards wanting managers with a technical background I think is fairly recent. The majority mass of java developers now probably "grew up" in the jaded horror story environments we seek to avoid. Also, i think new grads tend to only know how to make things dry via abstraction (not considering the trade offs) and b/c of javas popularity and oop as a buzzword, always did it via inheritance.