4 ms·

> The entire codebase has been migrated from C to C++. In the process, we've removed thousands of lines of custom code and used standard C++ tools instead. The

> The entire codebase has been migrated from C to C++. In the process, we've removed thousands of lines of custom code and used standard C++ tools instead. The core's code has shrunk by 18%. The core codebase has been extensively refactored to be more testable and maintainable. I love negative-LOC commits! They warm my heart. As do the people who take the time to make them.

tincholio 4y ago
At my previous job, we re-did some Java stream processing stuff in Clojure. We added functionality, made it more stable and dropped 6K lines of code (out of 18K for that particular component) in the process. It felt like magic...
- capableweb 4y ago
  That's not a fair comparison, rewriting anything in any lisp will dramatically reduce the amount of cruft, both lines of code and complexity.
  - kaba0 4y ago
    Doubt. Plus, essential complexity is non-reducible.
    - capableweb 4y ago
      Essential complexity I agree, you cannot get rid of (hence the whole "essential" part). However, when you program, lots of non-essential complexity sneaks in. If you've only ever written code in one language, I bet you wouldn't even be able to notice what is essential vs non-essential.
  - argiopetech 4y ago
    It is still a LOC reduction produced via rewrite. I don't think we should hold it against them that they choose a great target language for the rewrite...
  - srcreigh 4y ago
    A lot of those dropped lines of code is gonna be lines which only contain }.
    - gottacodethem 4y ago
      replaced by lines of )))))
KronisLV 4y ago
> I love negative-LOC commits! They warm my heart. As do the people who take the time to make them. Agreed, but only if there's adequate test coverage and it's pretty clear how everything should work. Otherwise it's a very stressful experience, working with a seemingly brittle and puzzling codebase.
- marginalia_nu 4y ago
  Brittleness isn't really a property of having tests IMO, more about designing it to reduce unexpected dependencies and interaction-at-a-distance between components. (Part of it is also understanding how the system works. If you are new to a code base, virtually all dependencies are unexpected) Tests can help reveal when those types of dependencies break, but even so, I would argue that is brittle code held together with cling wrap. The fundamental problem is still there.
  - KronisLV 4y ago
    > Tests can help reveal when those types of dependencies break, but even so, I would argue that is brittle code held together with cling wrap. The fundamental problem is still there. Sure, however tests failing after refactoring or removing seemingly unused bits of code will be a great way to figure out when one's assumptions about how everything works are mistaken, or to discover bits of code that one wasn't even aware of. Along the lines of: "Oh hey, our tests caught that removing this seemingly unused dependency from pom.xml will break PDF export logic, because for some reason it loads classes dynamically and needs that package" or maybe "The tests revealed that our latest refactoring breaks JSON serialization of dates, because while we should be able to use these annotations for our Dtos properly, the underlying framework gets confused because of our serialization library." The worst cases are where you don't have the tests and things break in ways that might not be immediately obvious. Such codebases will make any attempts at refactoring unsafe and inherently stressful, that's what I meant with brittle - you'll never be able to change anything whilst having confidence that things won't break all over the place.
    - marginalia_nu 4y ago
1vuio0pswjnm7 4y ago
Program size has not shrunk though. 3.9M static binary for 2.84 9.0M static binary for 4.0.0
- mrtesthah 4y ago
  It's a universal binary.
  - ksec 4y ago
    Assuming they share Graphics assets on Mac, it is still larger though.
- 1vuio0pswjnm7 4y ago
  NB. I compiled these myself on Linux with musl and gcc.
- wpietri 4y ago
  My god, that's $0.00014 worth of disk space! Or $0.00063 on SSD! Do they think we're made of money?
- deleted 4y ago
  [deleted]
deleted 4y ago
[deleted]

tincholio 4y ago

At my previous job, we re-did some Java stream processing stuff in Clojure. We added functionality, made it more stable and dropped 6K lines of code (out of 18K for that particular component) in the process. It felt like magic...

capableweb 4y ago
That's not a fair comparison, rewriting anything in any lisp will dramatically reduce the amount of cruft, both lines of code and complexity.
- kaba0 4y ago
  Doubt. Plus, essential complexity is non-reducible.
  - capableweb 4y ago
    Essential complexity I agree, you cannot get rid of (hence the whole "essential" part). However, when you program, lots of non-essential complexity sneaks in. If you've only ever written code in one language, I bet you wouldn't even be able to notice what is essential vs non-essential.
- argiopetech 4y ago
  It is still a LOC reduction produced via rewrite. I don't think we should hold it against them that they choose a great target language for the rewrite...
- srcreigh 4y ago
  A lot of those dropped lines of code is gonna be lines which only contain }.
  - gottacodethem 4y ago
    replaced by lines of )))))

KronisLV 4y ago

> I love negative-LOC commits! They warm my heart. As do the people who take the time to make them. Agreed, but only if there's adequate test coverage and it's pretty clear how everything should work. Otherwise it's a very stressful experience, working with a seemingly brittle and puzzling codebase.

marginalia_nu 4y ago
Brittleness isn't really a property of having tests IMO, more about designing it to reduce unexpected dependencies and interaction-at-a-distance between components. (Part of it is also understanding how the system works. If you are new to a code base, virtually all dependencies are unexpected) Tests can help reveal when those types of dependencies break, but even so, I would argue that is brittle code held together with cling wrap. The fundamental problem is still there.
- KronisLV 4y ago
  > Tests can help reveal when those types of dependencies break, but even so, I would argue that is brittle code held together with cling wrap. The fundamental problem is still there. Sure, however tests failing after refactoring or removing seemingly unused bits of code will be a great way to figure out when one's assumptions about how everything works are mistaken, or to discover bits of code that one wasn't even aware of. Along the lines of: "Oh hey, our tests caught that removing this seemingly unused dependency from pom.xml will break PDF export logic, because for some reason it loads classes dynamically and needs that package" or maybe "The tests revealed that our latest refactoring breaks JSON serialization of dates, because while we should be able to use these annotations for our Dtos properly, the underlying framework gets confused because of our serialization library." The worst cases are where you don't have the tests and things break in ways that might not be immediately obvious. Such codebases will make any attempts at refactoring unsafe and inherently stressful, that's what I meant with brittle - you'll never be able to change anything whilst having confidence that things won't break all over the place.
  - marginalia_nu 4y ago

1vuio0pswjnm7 4y ago

Program size has not shrunk though. 3.9M static binary for 2.84 9.0M static binary for 4.0.0

mrtesthah 4y ago
It's a universal binary.
- ksec 4y ago
  Assuming they share Graphics assets on Mac, it is still larger though.
1vuio0pswjnm7 4y ago
NB. I compiled these myself on Linux with musl and gcc.
wpietri 4y ago
My god, that's $0.00014 worth of disk space! Or $0.00063 on SSD! Do they think we're made of money?
deleted 4y ago
[deleted]

deleted 4y ago

[deleted]