4 ms·

You can have 1000 5-lines functions in all languages, not only java. Typescript FE projects can be as hard as java ones to read. It seems to me that there's a l

You can have 1000 5-lines functions in all languages, not only java. Typescript FE projects can be as hard as java ones to read. It seems to me that there's a lot of prejudice against java, maybe because it has been used by many low skilled devs developing poor quality codebases.

userbinator 4y ago
It seems to me that there's a lot of prejudice against java, maybe because it has been used by many low skilled devs developing poor quality codebases. I don't think that's the reason. The cultures of Java, C#, and now TS/JS definitely seem to worship abstraction far too much, and as a result you end up with what's classically known as "enterprise" code. I've seen the work of "low skilled devs" in other languages like PHP, VB, etc. and that leans far on the under-abstraction side; you're far more likely to find lots of copy-pasting and kiloline-long functions (if they even bother to write more than one), yet that code tends to be easier to work with in my experience because it's largely linear and not nested.
- albertopv 4y ago
  After some years I recently had to work on a very old PHP project with linear and untested code. Full of bugs, unmanaged corner cases, unnecessary code duplication, magic numbers...we didn't even try to understand the business logic or reverse it. I still think it's just low skilled devs vs professional ones. You can make similar mistakes with many, many languages, it seems to me that Java went out of fashion, considered old.
  - porker 4y ago
    As a counterpoint I'm working on an ex-PHP4 codebase, that's been "developed" (in the loosest possible meaning) by assorted people over 15 years. It's full of security vulnerabilities and the worst code I've seen in my career. I'm also working on a modern Symfony PHP codebase using popular 3rd party Symfony bundles. I've used Symfony for a decade but find the compiler passes and levels of abstractions (particularly when debugging 3rd party bundles) slow me down and make the code less understandable. Yesterday I spent half a day tracking down a bug which was the wrong setting in the config, but was obscured by too many layers of indirection. I'd take the terrible but understandable codebase any day as I know I can debug and improve it more easily.
    - albertopv 4y ago
      I upgraded a quite old java app from java 6 and spring 3 to java 8 and spring 4.30 in 4 hours without changing a single line of code. I guess we both may have good anecdotal examples :)
- kcartlidge 4y ago
  > The cultures of Java, C#, and now TS/JS definitely seem to worship abstraction far too much Unfortunately true. C# has been around long enough that some of the more 'mature' developers I've worked with still treat the book as gospel. Trying to find the actual code that does actual work can be tricky. That's started to change in recent years fortunately - especially with newer developers joining thanks to the increasing popularity of Core. As to the discussion: my basic rule of thumb is that single responsibility should be applied to every level of the stack, whether that be a single microservice, a single controller, a single function, or even a single property. Provided you follow that, many of the discussions vanish. For instance, how big should my functions be? Big enough to do one thing. Any bigger and they are too big. Any smaller and they are too small. Regardless of lines of code. So it narrows down to a simple decision - in the context of the code I'm writing, what is the one responsibility of this function? Following that practice it rarely ends up as a one-liner as it is hard (not impossible!) to encapsulate a complete piece of work in one line. It also rarely ends up more than a screenful as that usually means it's doing more than one thing. The important point is to switch the question away from "How big should it be?" and instead consider "What is the sole thing it is responsible for?" [1]. Then write code accordingly. After all, we know from the bad old days of being paid per line of code that 'lines of code' is a useless metric. --- [1] I'm aware that defining the responsibilities too tightly leads to fragmented code and a multitude of functions/abstractions. I'm also aware that defining them too loosely leads to huge functions and monolithic code flows. I'm not offering an answer, just saying we need to rephrase the question.

userbinator 4y ago

It seems to me that there's a lot of prejudice against java, maybe because it has been used by many low skilled devs developing poor quality codebases. I don't think that's the reason. The cultures of Java, C#, and now TS/JS definitely seem to worship abstraction far too much, and as a result you end up with what's classically known as "enterprise" code. I've seen the work of "low skilled devs" in other languages like PHP, VB, etc. and that leans far on the under-abstraction side; you're far more likely to find lots of copy-pasting and kiloline-long functions (if they even bother to write more than one), yet that code tends to be easier to work with in my experience because it's largely linear and not nested.

albertopv 4y ago
After some years I recently had to work on a very old PHP project with linear and untested code. Full of bugs, unmanaged corner cases, unnecessary code duplication, magic numbers...we didn't even try to understand the business logic or reverse it. I still think it's just low skilled devs vs professional ones. You can make similar mistakes with many, many languages, it seems to me that Java went out of fashion, considered old.
- porker 4y ago
  As a counterpoint I'm working on an ex-PHP4 codebase, that's been "developed" (in the loosest possible meaning) by assorted people over 15 years. It's full of security vulnerabilities and the worst code I've seen in my career. I'm also working on a modern Symfony PHP codebase using popular 3rd party Symfony bundles. I've used Symfony for a decade but find the compiler passes and levels of abstractions (particularly when debugging 3rd party bundles) slow me down and make the code less understandable. Yesterday I spent half a day tracking down a bug which was the wrong setting in the config, but was obscured by too many layers of indirection. I'd take the terrible but understandable codebase any day as I know I can debug and improve it more easily.
  - albertopv 4y ago
    I upgraded a quite old java app from java 6 and spring 3 to java 8 and spring 4.30 in 4 hours without changing a single line of code. I guess we both may have good anecdotal examples :)
kcartlidge 4y ago
> The cultures of Java, C#, and now TS/JS definitely seem to worship abstraction far too much Unfortunately true. C# has been around long enough that some of the more 'mature' developers I've worked with still treat the book as gospel. Trying to find the actual code that does actual work can be tricky. That's started to change in recent years fortunately - especially with newer developers joining thanks to the increasing popularity of Core. As to the discussion: my basic rule of thumb is that single responsibility should be applied to every level of the stack, whether that be a single microservice, a single controller, a single function, or even a single property. Provided you follow that, many of the discussions vanish. For instance, how big should my functions be? Big enough to do one thing. Any bigger and they are too big. Any smaller and they are too small. Regardless of lines of code. So it narrows down to a simple decision - in the context of the code I'm writing, what is the one responsibility of this function? Following that practice it rarely ends up as a one-liner as it is hard (not impossible!) to encapsulate a complete piece of work in one line. It also rarely ends up more than a screenful as that usually means it's doing more than one thing. The important point is to switch the question away from "How big should it be?" and instead consider "What is the sole thing it is responsible for?" [1]. Then write code accordingly. After all, we know from the bad old days of being paid per line of code that 'lines of code' is a useless metric. --- [1] I'm aware that defining the responsibilities too tightly leads to fragmented code and a multitude of functions/abstractions. I'm also aware that defining them too loosely leads to huge functions and monolithic code flows. I'm not offering an answer, just saying we need to rephrase the question.