4 ms·

> This is definitely more verbose and arguably uglier, but it hews closer to the object-oriented style because it’s visibly falling a method on an object. Of co

> This is definitely more verbose and arguably uglier, but it hews closer to the object-oriented style because it’s visibly falling a method on an object. Of course this is happening in C# as well, but it’s hidden by syntactic sugar. It's hard to appreciate how addictive the sugar is if you never had it. Frankly, language level auto properties -alone- would get rid of 25-33% of the pain I feel writing Java. Of course, there is always Scala on the JVM Side; which gives you all sorts of sugar, but in some ways -too much-.

jolux 6y ago
I think from an object-oriented design perspective that it's quite easy to overuse public field members and that a lot of getters and setters is generally a code smell. Nonetheless, properties are a very sharp tool and having them in the toolkit is wonderful. I've never used Scala but it seems to go much further in the syntactic sugar and semantic complexity direction, more akin to F# than C# (though with less elegant syntax, to my eye).
- pie_flavor 6y ago
  There have been many iterations of 'Java except it doesn't suck', but which all were extremely similar to Java - Xtend, Groovy, etc. So when Scala came onto the scene, even though it was a serious functional language and encouraged a very different style of programming than Java, it was seized on as a 'Java except it doesn't suck' language because it was much more different than previous ones and so felt more like a fresh start. The sentiment hasn't died yet, although Kotlin should at this point be treated as the official 'Java except it doesn't suck' language, since it's designed directly for it, is different enough, and has mainstream adoption.
qw 6y ago
Lombok fixes most of the getter/setter issues. It is also supported in IntelliJ
- pie_flavor 6y ago
  However bad the Java situation is, Lombok as a solution is worse. It uses unsupported and undocumented APIs of the compiler, it autogenerates code that is in some cases flat wrong (like the infamous enum @ToString), and it does this through a mechanism of the language specifically designed for pure metadata - code that compiles with annotations should not cease compiling without them. And, because of the way it does what it does, IDEs must have explicit Lombok support built into them. It is, effectively, a different language that's a superset of Java; at that point, you may as well actually use a superset of Java like Groovy, and then you don't have tools prone to breaking.
  - jolux 6y ago
    I’m not a huge fan of libraries that use attributes as a hook for code generation in C# either, though thankfully there’s less need for something like Lombok.

jolux 6y ago

I think from an object-oriented design perspective that it's quite easy to overuse public field members and that a lot of getters and setters is generally a code smell. Nonetheless, properties are a very sharp tool and having them in the toolkit is wonderful. I've never used Scala but it seems to go much further in the syntactic sugar and semantic complexity direction, more akin to F# than C# (though with less elegant syntax, to my eye).

pie_flavor 6y ago
There have been many iterations of 'Java except it doesn't suck', but which all were extremely similar to Java - Xtend, Groovy, etc. So when Scala came onto the scene, even though it was a serious functional language and encouraged a very different style of programming than Java, it was seized on as a 'Java except it doesn't suck' language because it was much more different than previous ones and so felt more like a fresh start. The sentiment hasn't died yet, although Kotlin should at this point be treated as the official 'Java except it doesn't suck' language, since it's designed directly for it, is different enough, and has mainstream adoption.

qw 6y ago

Lombok fixes most of the getter/setter issues. It is also supported in IntelliJ

pie_flavor 6y ago
However bad the Java situation is, Lombok as a solution is worse. It uses unsupported and undocumented APIs of the compiler, it autogenerates code that is in some cases flat wrong (like the infamous enum @ToString), and it does this through a mechanism of the language specifically designed for pure metadata - code that compiles with annotations should not cease compiling without them. And, because of the way it does what it does, IDEs must have explicit Lombok support built into them. It is, effectively, a different language that's a superset of Java; at that point, you may as well actually use a superset of Java like Groovy, and then you don't have tools prone to breaking.
- jolux 6y ago
  I’m not a huge fan of libraries that use attributes as a hook for code generation in C# either, though thankfully there’s less need for something like Lombok.