3 ms·

Out of interest, is there any technical reason you'd want a JVM application with 180,000 lines of code?

johncoltrane 15y ago
Not the parent. But the people who signed the checks probably didn't care about those details ("We want a solution to our problem and a reassuring longterm support contract.") and the people who banked the check probably just passed the baby to whoever ended up writing/managing these 180,000 LOC.
batista 15y ago
Is there any technical reason why you would NOT? The JVM is a proven and stable platform, with nice tooling and exceptional support. It's also polyglot. And 180,000 LOC is not that much --it depends on the requirements. Perhaps you are thinking "I can do all that in 1/10 the size in language X", but chances are you are wrong. It's not about doing the same thing in the turing-complete sense, it's about doing the same thing in the real world sense. You might achieve the same functionality with less code. But can you achieve the same interoperability with other systems the company uses with that other language? Could you utilize the 20-something already existing dev team of JVM coders? Could you have the same support from the vendor? The same toolkits? The same performance characteristics? Etc etc...
- weavejester 15y ago
  As a disclaimer, I wasn't intending to bait anyone. I'm genuinely interested if there are any reasons for writing a 100k+ LOC application, rather than dividing the functionality up between smaller applications and libraries. Operating systems like the Linux kernel are usually over 100k LOC, but Linus has made some compelling arguments about why you'd want a monolithic architecture in an operating system you want to be reasonably performant. But that argument doesn't appear to apply to server systems running under the JVM. Building an application out of small, interchangeable, independent components seems rather more sensible than one large monolithic architecture. My current hypothesis is that any server application over, say, 10K LOC is badly designed. I'm therefore quite interested in anyone who maintains or develops very large server systems, and if they could perhaps offer any reasoning why systems that large are the best solution. Admittedly this is a little off-topic, though :)
  - JoachimSchipper 15y ago
    Data point: nginx-1.0.14 has 124 574 lines in the src/ directory.
  - ExpiredLink 15y ago
    > I'm genuinely interested if there are any reasons for writing a 100k+ LOC application, rather than dividing the functionality up between smaller applications and libraries. IIRC, Google has such 'large' settings (for whatever reason). All companies I've seen use the latter approach.
  - skybrian 15y ago
    Well-designed large apps actually are divided up into smaller components - there'd be no way to maintain them otherwise. However, it doesn't help as much as you'd think. If it's a layered architecture, sometimes adding new feature means you have to modify code in every layer. And dividing code up into libraries doesn't help build times when you need to modify a base library that everything uses. If you have trouble imagining this, pretend that every dependency you use is actually part of your code base, and sometimes you have to modify them because they're not completely baked. If you have non-trivial functionality, you are certainly using way more than 100k LOC.
    - weavejester 15y ago
      I'm afraid I still can't imagine a large system that could not conceivably be divided into small, independent components. You mention dependencies that are "not completely baked", but isn't that just another way of saying "bad design"?
      - batista 15y ago
        I'm afraid I still can't imagine a large system that could not conceivably be divided into small, independent components. Well, examine some large systems then, and see whether you can fare better. Depends on what you describe as independent components. The 200LOC thing is probably also comprised of independent components. As in NGINX that somebody mentions elsewhere. That doesn't mean those independent components don't have to work together and a change in one doesn't affect the other. Consider a plugin host and a plugin. They are independent, alright, but the plugin takes advantage of certain things the host offers. If you change the host in those areas, you'll have to change the plugins too. Components only provide independency until the place where they meet each other, i.e. the "joins". (Even in a functional language, a pure function only provides independency until the point you call it --there you have to adhere to its interface).

Not the parent. But the people who signed the checks probably didn't care about those details ("We want a solution to our problem and a reassuring longterm support contract.") and the people who banked the check probably just passed the baby to whoever ended up writing/managing these 180,000 LOC.

batista 15y ago

Is there any technical reason why you would NOT? The JVM is a proven and stable platform, with nice tooling and exceptional support. It's also polyglot. And 180,000 LOC is not that much --it depends on the requirements. Perhaps you are thinking "I can do all that in 1/10 the size in language X", but chances are you are wrong. It's not about doing the same thing in the turing-complete sense, it's about doing the same thing in the real world sense. You might achieve the same functionality with less code. But can you achieve the same interoperability with other systems the company uses with that other language? Could you utilize the 20-something already existing dev team of JVM coders? Could you have the same support from the vendor? The same toolkits? The same performance characteristics? Etc etc...

weavejester 15y ago
As a disclaimer, I wasn't intending to bait anyone. I'm genuinely interested if there are any reasons for writing a 100k+ LOC application, rather than dividing the functionality up between smaller applications and libraries. Operating systems like the Linux kernel are usually over 100k LOC, but Linus has made some compelling arguments about why you'd want a monolithic architecture in an operating system you want to be reasonably performant. But that argument doesn't appear to apply to server systems running under the JVM. Building an application out of small, interchangeable, independent components seems rather more sensible than one large monolithic architecture. My current hypothesis is that any server application over, say, 10K LOC is badly designed. I'm therefore quite interested in anyone who maintains or develops very large server systems, and if they could perhaps offer any reasoning why systems that large are the best solution. Admittedly this is a little off-topic, though :)
- JoachimSchipper 15y ago
  Data point: nginx-1.0.14 has 124 574 lines in the src/ directory.
- ExpiredLink 15y ago
  > I'm genuinely interested if there are any reasons for writing a 100k+ LOC application, rather than dividing the functionality up between smaller applications and libraries. IIRC, Google has such 'large' settings (for whatever reason). All companies I've seen use the latter approach.
- skybrian 15y ago
  Well-designed large apps actually are divided up into smaller components - there'd be no way to maintain them otherwise. However, it doesn't help as much as you'd think. If it's a layered architecture, sometimes adding new feature means you have to modify code in every layer. And dividing code up into libraries doesn't help build times when you need to modify a base library that everything uses. If you have trouble imagining this, pretend that every dependency you use is actually part of your code base, and sometimes you have to modify them because they're not completely baked. If you have non-trivial functionality, you are certainly using way more than 100k LOC.
  - weavejester 15y ago
    I'm afraid I still can't imagine a large system that could not conceivably be divided into small, independent components. You mention dependencies that are "not completely baked", but isn't that just another way of saying "bad design"?
    - batista 15y ago
      I'm afraid I still can't imagine a large system that could not conceivably be divided into small, independent components. Well, examine some large systems then, and see whether you can fare better. Depends on what you describe as independent components. The 200LOC thing is probably also comprised of independent components. As in NGINX that somebody mentions elsewhere. That doesn't mean those independent components don't have to work together and a change in one doesn't affect the other. Consider a plugin host and a plugin. They are independent, alright, but the plugin takes advantage of certain things the host offers. If you change the host in those areas, you'll have to change the plugins too. Components only provide independency until the place where they meet each other, i.e. the "joins". (Even in a functional language, a pure function only provides independency until the point you call it --there you have to adhere to its interface).