3 ms·

> the productivity of dynamically typed languages is generally higher. This is the assumption, yes, and I am not sure that it's true at all; people simply beli

> the productivity of dynamically typed languages is generally higher. This is the assumption, yes, and I am not sure that it's true at all; people simply believe it to be true rather than actually check to see if their assumptions are correct. I believe this to be a very false assumption, in reality. The number of lines of JS that I see which do a particular thing is very high compared to other languages. This is not a JavaScript example, but it goes to my point that our assumptions are wrong: For example, can someone explain to me why a the Dropbox Desktop client 3 years ago was 4 million lines of Python?[0] If Python is such a high-level language, why are so many lines of code needed to do such a simple thing? [0]: https://dropbox.tech/application/our-journey-to-type-checking-4-million-lines-of-python https://dropbox.tech/application/our-journey-to-type-checkin...

pflanze 5y ago
The "4 million lines of Python" in that article is referring to the number of lines that are type checked (I don't see any mention of how much code remained unchecked, although the graphs might imply some 20%), but it also includes Dropbox' server side code base; the shown graphs imply that the server side is 4x larger than the client side. Assuming the above implications are true, the client side app would be 1 million lines of code. I guess someone with the client could go and measure? I don't mean to say that 1 M loc isn't still large, but you seem to be drawing conclusions from using numbers incorrectly.
- naikrovek 5y ago
  ok, over 1M lines of code... ...For the Dropbox client. line count from: (https://dropbox.tech/application/incrementally-migrating-over-one-million-lines-of-code-from-python-2-to-python-3 https://dropbox.tech/application/incrementally-migrating-ove...) how high-level are "high-level" languages? I would say that it would take far fewer lines of C or even Assembly to accomplish the same goals. 50k lines of C, probably. XTerm is ~70k lines of C, if I recall (I am certainly within 0.5 orders of magnitude), and it is extremely complex and does much more. if you want a more direct comparison, look at rsync or syncthing. I haven't looked at the size of those, ever, but I'd be willing to bet that both are FAR smaller than 1M lines of code. So, how it acceptable that a high-level language requires more lines of code than a "lower-level" language like C or Go? we're supposed to GAIN SOMETHING in the tradeoff by using high-level languages, and we're not. certainly not as much as we assume we are. we need to pay attention to these assumptions that we're making to ensure that they're true, periodically. we're not. it's just accepted as fact that "high-level" languages require fewer lines of code and less work to produce high-quality software, and I don't think we're seeing the benefits of the tradeoff anymore, if we ever really did, outside of tiny example programs.
  - pflanze 5y ago
    > and it is extremely complex and does much more Who's to say? The interesting bit in this discussion is why the code size is large, and looking in detail what the programs do would be a start. Of course, one could suppose that using a high-level language makes it easier to write code, hence, more code is going to be written. Or you or I could really conclude anything we want, if we're willing to pretend to know. It would be interesting to know, but that takes work to find out. And I'm a lazy bastard. PS. not to argue any more :), but I have checked the size of rsync 3.2.3 now, it's 51 Kloc of C code (including the 6300 loc of the included copy of zlib). You'd need to add a cryptographic library, a GUI library, and GUI code to make it a viable replacement for Dropbox, without comparing features. Git annex 8.20210223 is 70 Kloc of Haskell and 9100 loc of JavaScript, but it depends on Git to do its work, which (version 2.30.2) is 327 Kloc of C code and 225 Kloc of sh and Perl code. Thunar 4.16.8 is 73 Kloc of C code, sshfs is 4700 loc and fuse is 22 Kloc of C, openssh is 113 Kloc of C, so maybe you could build a Dropbox replacement in 212 Kloc of C without looking through the feature set. Maybe that's still 4-5 times smaller than the Dropbox client, but your number of 50 Kloc is again off by a factor of 4. :) (I guess one could say that the truth is "somewhere in the middle", looking at those number on a logarithmic scale...) I'm sure you could also come up with a much smaller implementation, just like you could write a music demo in 256 Bytes[1]. But why would you want to? [1] https://www.youtube.com/watch?v=sWblpsLZ-O8 https://www.youtube.com/watch?v=sWblpsLZ-O8
    - naikrovek 5y ago
      fine. so, 1 billion lines of code is acceptable for a file sync tool, then, so long as other pieces of software also have that many lines? is that what you're saying? how many is too many, then? 10 billion? 1 trillion? have you ever written software? 1 million lines of code for the Dropbox client is absolutely insane, and this is obvious to anyone who has written anything of substance. graphical libraries, security layers, it's all very simple to write stuff if you just take the time to do it. there is just nothing there worthy of 1 million lines of code, and the only way you would reach that line count is to liberally adopt hundreds or thousands of libraries so you can use a function or two from each of them (meaning: be a terrible developer who writes nothing, and only strings together the work of others)

pflanze 5y ago

The "4 million lines of Python" in that article is referring to the number of lines that are type checked (I don't see any mention of how much code remained unchecked, although the graphs might imply some 20%), but it also includes Dropbox' server side code base; the shown graphs imply that the server side is 4x larger than the client side. Assuming the above implications are true, the client side app would be 1 million lines of code. I guess someone with the client could go and measure? I don't mean to say that 1 M loc isn't still large, but you seem to be drawing conclusions from using numbers incorrectly.

naikrovek 5y ago
ok, over 1M lines of code... ...For the Dropbox client. line count from: (https://dropbox.tech/application/incrementally-migrating-over-one-million-lines-of-code-from-python-2-to-python-3 https://dropbox.tech/application/incrementally-migrating-ove...) how high-level are "high-level" languages? I would say that it would take far fewer lines of C or even Assembly to accomplish the same goals. 50k lines of C, probably. XTerm is ~70k lines of C, if I recall (I am certainly within 0.5 orders of magnitude), and it is extremely complex and does much more. if you want a more direct comparison, look at rsync or syncthing. I haven't looked at the size of those, ever, but I'd be willing to bet that both are FAR smaller than 1M lines of code. So, how it acceptable that a high-level language requires more lines of code than a "lower-level" language like C or Go? we're supposed to GAIN SOMETHING in the tradeoff by using high-level languages, and we're not. certainly not as much as we assume we are. we need to pay attention to these assumptions that we're making to ensure that they're true, periodically. we're not. it's just accepted as fact that "high-level" languages require fewer lines of code and less work to produce high-quality software, and I don't think we're seeing the benefits of the tradeoff anymore, if we ever really did, outside of tiny example programs.
- pflanze 5y ago
  > and it is extremely complex and does much more Who's to say? The interesting bit in this discussion is why the code size is large, and looking in detail what the programs do would be a start. Of course, one could suppose that using a high-level language makes it easier to write code, hence, more code is going to be written. Or you or I could really conclude anything we want, if we're willing to pretend to know. It would be interesting to know, but that takes work to find out. And I'm a lazy bastard. PS. not to argue any more :), but I have checked the size of rsync 3.2.3 now, it's 51 Kloc of C code (including the 6300 loc of the included copy of zlib). You'd need to add a cryptographic library, a GUI library, and GUI code to make it a viable replacement for Dropbox, without comparing features. Git annex 8.20210223 is 70 Kloc of Haskell and 9100 loc of JavaScript, but it depends on Git to do its work, which (version 2.30.2) is 327 Kloc of C code and 225 Kloc of sh and Perl code. Thunar 4.16.8 is 73 Kloc of C code, sshfs is 4700 loc and fuse is 22 Kloc of C, openssh is 113 Kloc of C, so maybe you could build a Dropbox replacement in 212 Kloc of C without looking through the feature set. Maybe that's still 4-5 times smaller than the Dropbox client, but your number of 50 Kloc is again off by a factor of 4. :) (I guess one could say that the truth is "somewhere in the middle", looking at those number on a logarithmic scale...) I'm sure you could also come up with a much smaller implementation, just like you could write a music demo in 256 Bytes[1]. But why would you want to? [1] https://www.youtube.com/watch?v=sWblpsLZ-O8 https://www.youtube.com/watch?v=sWblpsLZ-O8
  - naikrovek 5y ago
    fine. so, 1 billion lines of code is acceptable for a file sync tool, then, so long as other pieces of software also have that many lines? is that what you're saying? how many is too many, then? 10 billion? 1 trillion? have you ever written software? 1 million lines of code for the Dropbox client is absolutely insane, and this is obvious to anyone who has written anything of substance. graphical libraries, security layers, it's all very simple to write stuff if you just take the time to do it. there is just nothing there worthy of 1 million lines of code, and the only way you would reach that line count is to liberally adopt hundreds or thousands of libraries so you can use a function or two from each of them (meaning: be a terrible developer who writes nothing, and only strings together the work of others)