4 ms·

> IDEs generate 90% of my Java code; It's not generating code that is costly, but reading it. Understanding 100 lines of code is usually easier than understand

by hex13 9y ago

> IDEs generate 90% of my Java code; It's not generating code that is costly, but reading it. Understanding 100 lines of code is usually easier than understanding 1000 lines of code, understanding 1000 lines of code is usually easier than understanding 10000 lines of code etc. So generally it pays of to keep codebase small and simple.

gozur88 9y ago
>It's not generating code that is costly, but reading it. Understanding 100 lines of code is usually easier than understanding 1000 lines of code, understanding 1000 lines of code is usually easier than understanding 10000 lines of code etc. That's not at all true. The costly part is the complexity. You could spend half a day puzzling over ten lines of cleverly written Lisp and just breeze through 100 lines of Java that do the same thing.
- hex13 9y ago
  Yeah, this is also true. But "it depends" anyway. BTW author of article mentions also incidental complexity of Java classes. It's worth consider too and maybe it's more accurate picture of problems with Java (and many other languages, it's more like poor design and "cult of complexity" than technology problems). There are too many abstractions, classes, interfaces, inheritance, needless design patterns... it kills productivity and maintainability and ability to understand such codebases.
  - watwut 9y ago
    Only god and author knows what exactly was complex about those classes. I would guess that closure have good support for csv parsing, json integration, probably easier to read files? Or he used libraries in closure? Or maybe he used apache like every sane java project and something else was complicated? If 90% of that java code was generated, then what exactly were they doing? Also, there is such a thing as too much abstraction, but there is also such a thing as too little abstraction and refusal to use design pattern where it fits, because "it would be too complicated" alias someone was scared and lazy to learn. Neither is good. The projects I have seen that refused these "advanced" techniques all ended like hard to maintain and makes sense of mess of special exceptions to special situations - hard to reason about code. Design patterns are not hard and abstract thinking is as useful as good memory. Refusal to learn either is not mark of good developer.
    - stouset 9y ago
      If 90% of that code was generated, that's absolutely horrifying too. Code is read ten times more often than it's written. And you're forcing every poor fool who has to come in and maintain that code base to understand how five classes interoperate with and delegate responsibility to one-another and gloss over reams of unnecessary boilerplate (that under careful inspection might not actually be boilerplate, but have a subtle change).
      - watwut 9y ago
        I never generated 90% of my java code and I code in java for years. That is why I am asking - it is suspicious. Maybe, maybe if all you do is parse one complex xml from schema and decided to go jaxb way. Then again, such generated code tend to be tucked somewhere in the ../generated/ and then linked to class path - it is clearly separate from the rest and you dont review it. Basically, you read stuff it is generated from, and you dont read generated part unless you suspect bug in generator. The other occasionally generated stuff is syntactic sugar - hashCode, equals or delegate methods. That is quick to read once you get used to how it looks. More importantly, if that sort of thing is 90% of the code, then there is something wrong.
- stouset 9y ago
  You're comparing 10 lines of "clever" Lisp to 100 lines of (presumably boring) Java. In reality, it's more likely that those 100 lines of boring Java are easily written in 10 lines of just as boring Lisp, the only difference being the removal of 90 lines of boilerplate getters and setters, iteration logic, exception declarations, class definitions and instantiation, and so on. You can explain to someone (or learn on your own) "fancy" functional constructs like map, fold, and select in about ten minutes. And then they can be part of your vocabulary for an entire career. It is absolutely unfathomable to me that this is not a complete no-brainer. Imagine a novelist who replaced every instance of ten common English words with their literal dictionary definition every time they came up in a book. That's the level of incredulity I personally experience every time I see someone write the same implementation of `map` for the tenth time in a single source file.
  - gozur88 9y ago
    >In reality, it's more likely that those 100 lines of boring Java are easily written in 10 lines of just as boring Lisp, the only difference being the removal of 90 lines of boilerplate getters and setters, iteration logic, exception declarations, class definitions and instantiation, and so on. I hear this sort of thing from Lisp advocates all the time, but have never seen it in practice. Understandable Lisp isn't that compact.
    - lispm 9y ago
      The idea is that special constructs and a special machine in the problem domain will be used to write and execute dense code. This then tends to be VERY understandable in the domain, but brings the developer away from the low-level execution machine. Thus it is more understandable and less understandable, both at the same time, but on different levels. Much more understandable for the domain-level programmer. Much less understandable for the low-level execution-level programmer.
    - stouset 9y ago
      I'm guessing you easily have 100x or more experience with Java than you do Lisp. Do you suspect that this might have something to do with it? Lisp has a very different syntax from C-style languages, and this seems to trip people up much much more than the functional components of it. Not being familiar with the idioms of another language doesn't mean those idioms are hard. It just means you aren't familiar with them.

by hex13 9y ago

gozur88 9y ago

>It's not generating code that is costly, but reading it. Understanding 100 lines of code is usually easier than understanding 1000 lines of code, understanding 1000 lines of code is usually easier than understanding 10000 lines of code etc. That's not at all true. The costly part is the complexity. You could spend half a day puzzling over ten lines of cleverly written Lisp and just breeze through 100 lines of Java that do the same thing.

hex13 9y ago
Yeah, this is also true. But "it depends" anyway. BTW author of article mentions also incidental complexity of Java classes. It's worth consider too and maybe it's more accurate picture of problems with Java (and many other languages, it's more like poor design and "cult of complexity" than technology problems). There are too many abstractions, classes, interfaces, inheritance, needless design patterns... it kills productivity and maintainability and ability to understand such codebases.
- watwut 9y ago
  Only god and author knows what exactly was complex about those classes. I would guess that closure have good support for csv parsing, json integration, probably easier to read files? Or he used libraries in closure? Or maybe he used apache like every sane java project and something else was complicated? If 90% of that java code was generated, then what exactly were they doing? Also, there is such a thing as too much abstraction, but there is also such a thing as too little abstraction and refusal to use design pattern where it fits, because "it would be too complicated" alias someone was scared and lazy to learn. Neither is good. The projects I have seen that refused these "advanced" techniques all ended like hard to maintain and makes sense of mess of special exceptions to special situations - hard to reason about code. Design patterns are not hard and abstract thinking is as useful as good memory. Refusal to learn either is not mark of good developer.
  - stouset 9y ago
    If 90% of that code was generated, that's absolutely horrifying too. Code is read ten times more often than it's written. And you're forcing every poor fool who has to come in and maintain that code base to understand how five classes interoperate with and delegate responsibility to one-another and gloss over reams of unnecessary boilerplate (that under careful inspection might not actually be boilerplate, but have a subtle change).
    - watwut 9y ago
      I never generated 90% of my java code and I code in java for years. That is why I am asking - it is suspicious. Maybe, maybe if all you do is parse one complex xml from schema and decided to go jaxb way. Then again, such generated code tend to be tucked somewhere in the ../generated/ and then linked to class path - it is clearly separate from the rest and you dont review it. Basically, you read stuff it is generated from, and you dont read generated part unless you suspect bug in generator. The other occasionally generated stuff is syntactic sugar - hashCode, equals or delegate methods. That is quick to read once you get used to how it looks. More importantly, if that sort of thing is 90% of the code, then there is something wrong.
stouset 9y ago
You're comparing 10 lines of "clever" Lisp to 100 lines of (presumably boring) Java. In reality, it's more likely that those 100 lines of boring Java are easily written in 10 lines of just as boring Lisp, the only difference being the removal of 90 lines of boilerplate getters and setters, iteration logic, exception declarations, class definitions and instantiation, and so on. You can explain to someone (or learn on your own) "fancy" functional constructs like map, fold, and select in about ten minutes. And then they can be part of your vocabulary for an entire career. It is absolutely unfathomable to me that this is not a complete no-brainer. Imagine a novelist who replaced every instance of ten common English words with their literal dictionary definition every time they came up in a book. That's the level of incredulity I personally experience every time I see someone write the same implementation of `map` for the tenth time in a single source file.
- gozur88 9y ago
  >In reality, it's more likely that those 100 lines of boring Java are easily written in 10 lines of just as boring Lisp, the only difference being the removal of 90 lines of boilerplate getters and setters, iteration logic, exception declarations, class definitions and instantiation, and so on. I hear this sort of thing from Lisp advocates all the time, but have never seen it in practice. Understandable Lisp isn't that compact.
  - lispm 9y ago
    The idea is that special constructs and a special machine in the problem domain will be used to write and execute dense code. This then tends to be VERY understandable in the domain, but brings the developer away from the low-level execution machine. Thus it is more understandable and less understandable, both at the same time, but on different levels. Much more understandable for the domain-level programmer. Much less understandable for the low-level execution-level programmer.
  - stouset 9y ago
    I'm guessing you easily have 100x or more experience with Java than you do Lisp. Do you suspect that this might have something to do with it? Lisp has a very different syntax from C-style languages, and this seems to trip people up much much more than the functional components of it. Not being familiar with the idioms of another language doesn't mean those idioms are hard. It just means you aren't familiar with them.