5 ms·

Well, given that I've seen 7-15 minute build times for 180,000 lines of code in a popular JVM language ... what I wouldn't give for Go-like build / test iterati

by BruceM 15y ago

Well, given that I've seen 7-15 minute build times for 180,000 lines of code in a popular JVM language ... what I wouldn't give for Go-like build / test iteration times in that language. I think there's some value in your list of things that you like about Go. It gives others an idea of what they might be missing out on. (And for me with my work on Open Dylan, it gives me a nice target to aim for.)

weavejester 15y ago
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.

by BruceM 15y ago

weavejester 15y ago

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.