3 ms·

I have a pretty different experience here.. we have 30+ million lines of JS in production (2k+ devs and tens of thousands of files -- it isn't as scary as it so

I have a pretty different experience here.. we have 30+ million lines of JS in production (2k+ devs and tens of thousands of files -- it isn't as scary as it sounds). Prior to converting app development to JS in 2005, development was mostly done in C/C++ and the boost in productivity by writing things in JS has been clear as day. This isn't to say that it is easy to maintain; in our case, a core infrastructure team maintains the guts reasonably well (+dev/test tools) and it allows higher-level teams to build the product. 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. I suppose a distinction could be made between referring to a single large product/codebase versus a much larger amount of physical code but split between many teams/products. There are probably only a handful of apps that wind up being "large" (in the 10k+ LoC range).

mightybyte 13y ago
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.
camus2 13y ago
what are you doing in JS now that required C/C++ before ? that's the most interesting question. I dont think you needed C/C++ at first place.
- apaprocki 13y ago
  I agree, which is why the scripted approach works much better. Why were UI toolkits such as Gtk+/Qt written in C/C++? What kind of scripting language would have been suitable to use as a replacement at the time?
klodolph 13y ago
I think C and C++ are pretty terrible languages for most application developers, and they are also from an earlier generation of languages than JavaScript, so I don't see how we can ascribe the difference in productivity to dynamic versus static type systems. The most damning thing is perhaps that C and C++ require additional testing that JavaScript does not require, and that is testing for memory safety. In C++ you can kind of stay safe by using references but there is still a lot of risk and you always have to keep object lifetimes in mind. C and C++ are probably among the least productive languages in common use today for other reasons as well—such as for their header files.
- apaprocki 13y ago
  > I don't see how we can ascribe the difference in productivity to dynamic versus static type systems My personal opinion/observation/"gut feeling" is that dynamic typing has helped, but I haven't done any kind of concrete study to figure out its impact vs, say, removing the compile/link phase. I observe some of the code being written and definitely see programmers taking advantage of the dynamic nature of the language.

mightybyte 13y ago

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.

camus2 13y ago

what are you doing in JS now that required C/C++ before ? that's the most interesting question. I dont think you needed C/C++ at first place.

apaprocki 13y ago
I agree, which is why the scripted approach works much better. Why were UI toolkits such as Gtk+/Qt written in C/C++? What kind of scripting language would have been suitable to use as a replacement at the time?

klodolph 13y ago

I think C and C++ are pretty terrible languages for most application developers, and they are also from an earlier generation of languages than JavaScript, so I don't see how we can ascribe the difference in productivity to dynamic versus static type systems. The most damning thing is perhaps that C and C++ require additional testing that JavaScript does not require, and that is testing for memory safety. In C++ you can kind of stay safe by using references but there is still a lot of risk and you always have to keep object lifetimes in mind. C and C++ are probably among the least productive languages in common use today for other reasons as well—such as for their header files.

apaprocki 13y ago
> I don't see how we can ascribe the difference in productivity to dynamic versus static type systems My personal opinion/observation/"gut feeling" is that dynamic typing has helped, but I haven't done any kind of concrete study to figure out its impact vs, say, removing the compile/link phase. I observe some of the code being written and definitely see programmers taking advantage of the dynamic nature of the language.