3 ms·

There are several things about this post that make me really question its validity. "The best feature of the script when it comes to higher-level product is th

There are several things about this post that make me really question its validity. "The best feature of the script when it comes to higher-level product is that large portions (if not the entire thing) can be scrapped and started anew in a different way without a significant loss of investment." Large portions can be scrapped and started anew without significant loss of investment?!? Is this code being auto-generated somehow? If it's legit actual lines being written by your developers, then that is the definition of a significant investment. And if you're redoing it, then that's by definition loss of the original investment. "There are probably only a handful of apps that wind up being 'large' (in the 10k+ LoC range)." What are you smoking? I've got more than 10k LoC in an app that has only been under development by < 2 developers for a few months. My company has another app built by one guy that's more than 30k LoC. And you say you have 30+ million LoC in production?!? If 10k is "large" for you, then you must have a shitload of apps out there. Also, there's a huge difference between maintaining 3000 apps with 10k LoC and maintaining even one app with >1m LoC.

frankc 13y ago
They have thousands of apps. Maybe 10s of thousands by now. It's been many years since I worked there. It's a pretty unique setup.
apaprocki 13y ago
Lots of time is spent understanding what the product needs to do and building a suitable solution to it that is intuitive for users. The resulting JS code does not always represent a large portion of the investment into delivering the end-to-end product. In my subjective experience, the JS is written more quickly, requiring overall time to get something working. An idea might change course in significant ways a few times in the span of time it would have taken to write it in C/C++ once. In our setup, apps leverage key lower level libraries that are maintained by a small team and represent a much smaller, more manageable native codebase. A very complex app can be written in 10k LoC. Yes, there are a lot of "apps". > Also, there's a huge difference between maintaining 3000 apps with 10k LoC and maintaining even one app with >1m LoC. I said exactly this at the end of my post, but I don't feel it is always black and white. I said "apps" in quotes above because many times they act more like modules than standalone apps. Many of them interact in non-trivial ways, making the comparison more muddled. It's definitely a lot of code either way and in our situation JS has definitely made evolving the product much easier from an end-user perspective. edit: ^once
- mightybyte 13y ago
  Wow, that's quite an unusual profile. Good for you guys that you've been able to decompose things into thousands of relatively self-contained apps. It's a really interesting situation. Part of me wants to say that this doesn't really qualify as a "large codebase" as referred to by the OP. I tend to think of "large" as hundreds of thousands of lines and up. But I certainly don't want to marginalize the experience of an organization maintaining 30 million lines of code in 10k chunks. Your experience definitely suggests there is great value in decomposing things into small self-contained pieces. But I would say that strong static type systems are better at helping you do that than weak dynamic type systems. It can certainly be done in dynamic languages, but it requires more discipline.

frankc 13y ago

They have thousands of apps. Maybe 10s of thousands by now. It's been many years since I worked there. It's a pretty unique setup.

apaprocki 13y ago

Lots of time is spent understanding what the product needs to do and building a suitable solution to it that is intuitive for users. The resulting JS code does not always represent a large portion of the investment into delivering the end-to-end product. In my subjective experience, the JS is written more quickly, requiring overall time to get something working. An idea might change course in significant ways a few times in the span of time it would have taken to write it in C/C++ once. In our setup, apps leverage key lower level libraries that are maintained by a small team and represent a much smaller, more manageable native codebase. A very complex app can be written in 10k LoC. Yes, there are a lot of "apps". > Also, there's a huge difference between maintaining 3000 apps with 10k LoC and maintaining even one app with >1m LoC. I said exactly this at the end of my post, but I don't feel it is always black and white. I said "apps" in quotes above because many times they act more like modules than standalone apps. Many of them interact in non-trivial ways, making the comparison more muddled. It's definitely a lot of code either way and in our situation JS has definitely made evolving the product much easier from an end-user perspective. edit: ^once

mightybyte 13y ago
Wow, that's quite an unusual profile. Good for you guys that you've been able to decompose things into thousands of relatively self-contained apps. It's a really interesting situation. Part of me wants to say that this doesn't really qualify as a "large codebase" as referred to by the OP. I tend to think of "large" as hundreds of thousands of lines and up. But I certainly don't want to marginalize the experience of an organization maintaining 30 million lines of code in 10k chunks. Your experience definitely suggests there is great value in decomposing things into small self-contained pieces. But I would say that strong static type systems are better at helping you do that than weak dynamic type systems. It can certainly be done in dynamic languages, but it requires more discipline.