systemd Breached One Million Lines Of Code In 2017

[starshipeleven]

What? I said from the very beginning "if both code bases are EQUAL then the smaller code base is better engineered".

I'm going to ignore your statement that they are "EQUAL" here because if they are truly equal then you can't have a smaller code base (because they are equal) to begin with.

I said that this example applies to a very tiny subset of the real life scenarios, so what's the point of using it at all?

Then "oiaohm" said "but assume they are not equal, assume one code base has lots of asserts and tests and the other code base lacks those tests" - well then the code bases are NOT equal, so the discussion is moot.

He talked about a realistic situation, where a code base is bigger overall because it has tests and auxiliary stuff.

Which is so much more common than just having two projects being "equal" but one has more project-related code than the other.

Either he or you does not understand what "equal functionality does mean"

Or your definition of "equal" and other adjectives is fuzzy and you didn't get the point across.

Really, see the first line of your post. If both code bases are "equal" then they are the same, there can't be a smaller code base and a bigger one.

[unixfan2001]

I just refactored an old Go codebase I had written a couple months ago (a small daemon that basically takes care of our nightly CI workflow),

The old version exposed one function as public that should've been private and while the interface was properly documented, the implementation wasn't.

Both versions are equal in functionality (the public/private mix-up not withstanding). The old release was exactly 80 lines of code. The new one is 92.

According to pavlerson the old version is way superior and I'm a shitty developer now (certainly worse than the one I was back in November of 2017).
Thanks for playing!


EDIT: Oh yea. The new version also auto-generates literate programming docs as part of its own CI process now. That's one more line in the CI and 700+ lines of auto-generated HTML. I know. I know. I'm literately worse than Hitler now.

[pavlerson]

I'm going to ignore your statement that they are "EQUAL" here because if they are truly equal then you can't have a smaller code base (because they are equal) to begin
with.

Are you trolling? I talked about two codbases having equal functionality. Not equal codebase. In general in engineering, math, comp sci, etc - if two constructs solves the same problem but one construct is bloated and large - then the larger one is inferior. There is no discussion about this, every engineer knows this. If you question this, you are not an engineer.

[unixfan2001]

Are you trolling? I talked about two codbases having equal functionality. Not equal codebase. In general in engineering, math, comp sci, etc - if two constructs solves the same problem but one construct is bloated and large - then the larger one is inferior. There is no discussion about this, every engineer knows this. If you question this, you are not an engineer.

Engineer here and I question this "knowledge".
There are more variables to it than just solving the same problem.

If that was the only goal, everyone would be writing software in BASIC.

[pavlerson]

Engineer here and I question this "knowledge".
There are more variables to it than just solving the same problem.

If that was the only goal, everyone would be writing software in BASIC.

It is well known that 1000 lines of code have roughly the same number of bugs, no matter which programming language nor the size of the project. Say that 1000 LoC has 3 bugs on average. If you have two code bases that have the same functionality (including tests, etc) and one code base have 10.000 LoC and the other has 1.000 LoC, then there will be far less bugs in the smaller code base. Also, the smaller code base have a smaller attack vector for hackers. If you dont understand this, you lack common programming knowledge so you are clearly not an engineer. A bloated construct is never as good as a small and lean construct - when both have identical functionality.

[oiaohm]

What? I said from the very beginning "if both code bases are EQUAL then the smaller code base is better engineered".

Then "oiaohm" said "but assume they are not equal, assume one code base has lots of asserts and tests and the other code base lacks those tests" - well then the code bases are NOT equal, so the discussion is moot. Either he or you does not understand what "equal functionality does mean"

I said run-time tests. Problem here Equal is very hard to work out by lines of code. Runtime tests include like Data validation. The two bits of code can perform exactly the same function but one be slightly bigger and slightly slower because it doing data validation. Developers who normal do Data validation have a habit of using stuff like asserts as well. Runtime tests are to validation at runtime that everything is working correctly. Another thing you find is programs failing to check that when they have asked for memory that memory was in fact allocated. These are runtime tests that quality quality will perform and will make quality code larger.

Then there is readability. You can reduce the lines of code by compacting the code formatting. So cleanly formatted code may be larger in lines.

Lines of code is a very bad measurement.

[starshipeleven]

I talked about two codbases having equal functionality. Not equal codebase. In general in engineering, math, comp sci, etc - if two constructs solves the same problem but one construct is bloated and large - then the larger one is inferior. There is no discussion about this, every engineer knows this. If you question this, you are not an engineer.

By "equal functionality" we need to include also debugging, error handling and contribution-friendlyness of the written code, as that is an important feature of any software project developed by more than one person.

If you include that too, you see that in 99% of the times the projects with less LOC will have drastically reduced functionality and will therefore fail to qualify for your comparison.