Announcement

Collapse
No announcement yet.

systemd Breached One Million Lines Of Code In 2017

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • starshipeleven
    replied
    Originally posted by pavlerson View Post
    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.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by pavlerson View Post
    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.

    Leave a comment:


  • pavlerson
    replied
    Originally posted by unixfan2001 View Post

    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.

    Leave a comment:


  • unixfan2001
    replied
    Originally posted by pavlerson View Post
    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.

    Leave a comment:


  • pavlerson
    replied
    Originally posted by starshipeleven View Post
    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.

    Leave a comment:


  • unixfan2001
    replied
    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.
    Last edited by unixfan2001; 04-06-2018, 04:51 AM.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by pavlerson View Post
    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.

    Leave a comment:


  • unixfan2001
    replied
    What does equal even mean? Like. Can one be written in Golang and the other in C++, as long as they exhibit the same feature set/expose the same interface?
    What about comments? While I agree that good code shouldn't necessarily need particularly wordy comments, some of us actually use comments (in combination with the underlying code) to generate API documentation, styleguides or literate documentation.

    Or what about the opposite direction? A program using things like var e; is most assuredly shorter than one defining properly named, block scoped variables. But is it better?
    Last edited by unixfan2001; 04-05-2018, 01:56 PM.

    Leave a comment:


  • pavlerson
    replied
    Originally posted by starshipeleven View Post
    In this specific case with specific assumptions you created yourself you are right, but what does this tell about real-life situations?
    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"

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by pavlerson View Post
    As I said, if both code bases are equal, but one code base use twice as many LoC to do the same thing as the other code base - then the first code base is bad. This includes asserts, error checking, etc. You make the assumption that one code base do more things; asserts, error checking, etc. That is not what I talk about. Both code bases are equivalent, ie. they catch the same errors, etc. They are equivalent in all aspects - but one is more wordy. In that case, the less verbose code has been written by the better developer.
    In this specific case with specific assumptions you created yourself you are right, but what does this tell about real-life situations?

    Leave a comment:

Working...
X