4 ms·
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
by 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 agoThe 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 agoWhat, specifically, about having a framework means the language is not expressive enough?
- willtim 10y agoFrameworks do not compose. Libraries do. If you need a framework, your language has failed.
- 67726e 10y agoNo 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 agoEverything 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 agoNot 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]