4 ms·

The Java program may be more readable in small snippets but a large Java program is often completely incomprehensible because the overall structure doesn't map

The Java program may be more readable in small snippets but a large Java program is often completely incomprehensible because the overall structure doesn't map well to the problem being solved. A lisp program with comparable functionality can be much smaller and more comprehensible due to the ability to mould the language to the business problem.

pharmakom 5y ago
Yes!! Java programs often have so many classes, methods and interfaces that it’s hard to comprehend the overall flow of the application. Terse languages (lisps and MLs come to mind) can often solve the same problem in a single page.
- quantified 5y ago
  +1. “Let’s distribute all our algorithms in tiny chunks everywhere” seems to be the goal of some code bases. It’s unnecessary, you can control data and algorithm differently in most cases.
  - taeric 5y ago
    I cringe at how many code reviews are essentially, take this 40 line function that does things we don't need anywhere else, and split it into 5 other abstractions. I mean... the review isn't wrong. You can totally split the functionality in ways that are very logical. But... did it really make THIS program easier?
    - pjmlp 5y ago
      The dashboards used for QA code complexity metrics to assess project delivery now look nicer.
    - pkolaczk 5y ago
      It should make it definitely easier to read, if names of the extracted functions are good, signatures are simple and you can understand well what they do without looking at their implementations. The main point of abstraction is not reusability, but the ability to understand code without a need to read all of it. Therefore it doesn't really matter if these extracted pieces aren't used anywhere else. But after splitting, now someone has to read and understand only 5 lines instead of 40, which reduces the cognitive load.
      - taeric 5y ago
        I agree, to an extent. Just there is basically no world where splitting a forty line function into five files is less code. And sometimes, having less to hold in your head helps compartmentalize it. So you may make the specific function easier, at the expense of the entire project. :(
        pkolaczk 5y ago
        Of course it is not less code, but that additional code is mostly declarative documentation in the form of function signatures. You'd have to hold it in your head anyways to understand the original code, but now it is stated explicitly. The alternative to provide that information in a single big code blob would have to be code comments. And there are chances you wouldn't have to keep the function implementaions in your head, if they were extracted reasonably. Do you need to keep the details of how `sort` is implemented to be able to understand what it does?
- Jach 5y ago
  Even this isn't the problem; I generally prefer the style (in Java at least) of splitting things up into small pieces, pkolaczk below gives some more rationale. It's certainly easier to test, and is often easier to read. But yes, people can go way too far with it, leading to the infamous pejorative "ravioli code". And people can pervert it, e.g. in the name of expediency creating paranoia by wrecking previously simple and clear functions by editing in functionality that function shouldn't be handling and violating the principle of least surprise. Few things hurt as much as getting relaxed in a codebase, able to skim over most function calls that aren't relevant to the problem you're looking at, only to then be tricked by an innocuously named method along the code path doing what it shouldn't and wondering if you need to start inlining (mentally or otherwise) everything to avoid future trickery. Terseness that comes from powerful expressions (simple SQL queries can replace lots of code in any language) is great, though terseness just in the form of density shouldn't necessarily be a goal. At my last job the worst Java code was the most dense, with huge methods spanning hundreds of lines and sometimes up to 10 levels of indentation. Sure it's all there, but it's hard to understand everything it's doing (and more importantly why), impossible to cover with good tests, very difficult to refactor because of so many implicit dependencies you have to untangle first (and there are higher priority items), no justified pressure against "just adding one more conditional" to the middle of some big method to satisfy some new requirement from somewhere (so long as the tribal knowledge exists about where such code ought to be placed anyway, it'll take anyone new a long time to find out from scratch), and so much dense code in many core infrastructure areas was initially written by a superstar coder over a decade prior -- if he ever left the company, a lot of things would break with no one to fix them in a reasonable amount of time, he has so much institutional knowledge and no time or pressure to document it all if such a thing were even possible. Out of control ravioli code on the other hand was relatively easy to wrangle back under control -- my favorite was a huge logging framework written by a Principle level employee that actually wasn't used by anything, not even its supposed log() entry point, so it was just a big no-op, and could be deleted. The hardest parts of maintaining software aren't the difficulties in understanding a clever piece of code using advanced language features, but just the sheer complexity of computation being expressed. This is part of the essence that has even a few old time Lispers saying things like "language doesn't really matter" -- nevertheless, I think CL pressures reduce complexity and difficulty of understanding more so than Java, and still decades later has better tools to pierce the veil when understanding is difficult. (Monitoring tools, not as much, though well-understood code tends to not need as much monitoring.)
- kaba0 5y ago
  I used to believe it as well, but I think more often than not it is only a vertical terseness. If you count the number of words, it will be roughly in the same ballpark.
_0ffh 5y ago
An interesting study might be to first let people 1. code up solutions to a specific requirements list, then 2. randomly assign the participants within each language group to modify someone else's first-round solution to meet a second-round requirements list.

pharmakom 5y ago

Yes!! Java programs often have so many classes, methods and interfaces that it’s hard to comprehend the overall flow of the application. Terse languages (lisps and MLs come to mind) can often solve the same problem in a single page.

quantified 5y ago
+1. “Let’s distribute all our algorithms in tiny chunks everywhere” seems to be the goal of some code bases. It’s unnecessary, you can control data and algorithm differently in most cases.
- taeric 5y ago
  I cringe at how many code reviews are essentially, take this 40 line function that does things we don't need anywhere else, and split it into 5 other abstractions. I mean... the review isn't wrong. You can totally split the functionality in ways that are very logical. But... did it really make THIS program easier?
  - pjmlp 5y ago
    The dashboards used for QA code complexity metrics to assess project delivery now look nicer.
  - pkolaczk 5y ago
    It should make it definitely easier to read, if names of the extracted functions are good, signatures are simple and you can understand well what they do without looking at their implementations. The main point of abstraction is not reusability, but the ability to understand code without a need to read all of it. Therefore it doesn't really matter if these extracted pieces aren't used anywhere else. But after splitting, now someone has to read and understand only 5 lines instead of 40, which reduces the cognitive load.
    - taeric 5y ago
      I agree, to an extent. Just there is basically no world where splitting a forty line function into five files is less code. And sometimes, having less to hold in your head helps compartmentalize it. So you may make the specific function easier, at the expense of the entire project. :(
      - pkolaczk 5y ago
        Of course it is not less code, but that additional code is mostly declarative documentation in the form of function signatures. You'd have to hold it in your head anyways to understand the original code, but now it is stated explicitly. The alternative to provide that information in a single big code blob would have to be code comments. And there are chances you wouldn't have to keep the function implementaions in your head, if they were extracted reasonably. Do you need to keep the details of how `sort` is implemented to be able to understand what it does?
Jach 5y ago
Even this isn't the problem; I generally prefer the style (in Java at least) of splitting things up into small pieces, pkolaczk below gives some more rationale. It's certainly easier to test, and is often easier to read. But yes, people can go way too far with it, leading to the infamous pejorative "ravioli code". And people can pervert it, e.g. in the name of expediency creating paranoia by wrecking previously simple and clear functions by editing in functionality that function shouldn't be handling and violating the principle of least surprise. Few things hurt as much as getting relaxed in a codebase, able to skim over most function calls that aren't relevant to the problem you're looking at, only to then be tricked by an innocuously named method along the code path doing what it shouldn't and wondering if you need to start inlining (mentally or otherwise) everything to avoid future trickery. Terseness that comes from powerful expressions (simple SQL queries can replace lots of code in any language) is great, though terseness just in the form of density shouldn't necessarily be a goal. At my last job the worst Java code was the most dense, with huge methods spanning hundreds of lines and sometimes up to 10 levels of indentation. Sure it's all there, but it's hard to understand everything it's doing (and more importantly why), impossible to cover with good tests, very difficult to refactor because of so many implicit dependencies you have to untangle first (and there are higher priority items), no justified pressure against "just adding one more conditional" to the middle of some big method to satisfy some new requirement from somewhere (so long as the tribal knowledge exists about where such code ought to be placed anyway, it'll take anyone new a long time to find out from scratch), and so much dense code in many core infrastructure areas was initially written by a superstar coder over a decade prior -- if he ever left the company, a lot of things would break with no one to fix them in a reasonable amount of time, he has so much institutional knowledge and no time or pressure to document it all if such a thing were even possible. Out of control ravioli code on the other hand was relatively easy to wrangle back under control -- my favorite was a huge logging framework written by a Principle level employee that actually wasn't used by anything, not even its supposed log() entry point, so it was just a big no-op, and could be deleted. The hardest parts of maintaining software aren't the difficulties in understanding a clever piece of code using advanced language features, but just the sheer complexity of computation being expressed. This is part of the essence that has even a few old time Lispers saying things like "language doesn't really matter" -- nevertheless, I think CL pressures reduce complexity and difficulty of understanding more so than Java, and still decades later has better tools to pierce the veil when understanding is difficult. (Monitoring tools, not as much, though well-understood code tends to not need as much monitoring.)
kaba0 5y ago
I used to believe it as well, but I think more often than not it is only a vertical terseness. If you count the number of words, it will be roughly in the same ballpark.

_0ffh 5y ago

An interesting study might be to first let people 1. code up solutions to a specific requirements list, then 2. randomly assign the participants within each language group to modify someone else's first-round solution to meet a second-round requirements list.