4 ms·

Just personal opinions, I guess, I agree with most, but here are some I disagree with: - There is no pride in managing or understanding complexity Complexity

by GuB-42 2y ago

Just personal opinions, I guess, I agree with most, but here are some I disagree with: - There is no pride in managing or understanding complexity Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity. - Java is a great language because it's boring That is if you write Java the boring way. A lot of Java code (looking at you Spring) is everything but boring, and it is not fun either. - Most programming should be done long before a single line of code is written I went the opposite extreme. That is, if you are not writing code, you are not programming. If you are not writing code on your first day your are wasting time. It is a personal opinion, but the idea is that without doing something concrete, i.e. writing code, it is too easy to lose track of the reality, the reality being that in the end, you will have a program that runs on a machine. It doesn't mean you will have to keep that code. - Formal modeling and analysis is an essential skill set Maybe that explains our difference with regard to the last point. Given the opportunity, I prefer try stuff rather than formalize. It is not that formal modeling is useless, it is just less essential to me than experimentation. To quote Don Knuth out of context: "Beware of bugs in the above code; I have only proved it correct, not tried it." ;) - You literally cannot add too many comments to test code (I challenge anyone to try) time++; // increment time

snapcaster 2y ago
I agree with you, i'm much more on the "try stuff out" scale vs. formal methods. That being said, i've worked with people who are the other way and still very effective. I think this one is more of a trade-off or personality thing than something that's "true" or "false"
- AnimalMuppet 2y ago
  I agree with you that personality plays a role. But regardless of which way your personality pushes you: You can never think enough up front to know all you need to know, or even 95%. You're not omniscient enough, and you never will be. Big Design Up Front fails because of this - you have to be able to iterate. You also have to know what you're trying to build, and at least roughly how you're going to build it. If you don't, no amount of iteration and experimentation will enable you to converge on a solution. You need to experiment and iterate and explore within at least a sketch of a larger picture, not on a blank canvas.
  - snapcaster 2y ago
    True, the extreme version of any of these is usually wrong
do_not_redeem 2y ago
> time++; // increment time This isn't too many comments, it's a poor quality comment. Try: time++; // advance 1 simulated second
- bluGill 2y ago
  What is wrong with time++; That seem obvious enough to me without any comments.
  - smallerfish 2y ago
    Is it ms? seconds? days? weeks? months? How far up do I have to read to figure that out? When I'm looking at a test case is broken, I ideally want context IN the actual test that lets me understand what the test author was thinking when they wrote it. Why does this test exist as it does? Why are the expectations that are in place valid? Write the comments for you-in-2-years.
    - bluGill 2y ago
      Do you not know the conventions of your project? Doesn't your project have a convention that all time is in ms (second, weeks...)? If your project doesn't have that convention such that everyone knows than the code should be timeMs++; You may also have a time type and so you can use your IDE to examine the type.
      - rovolo 2y ago
        I agree that the time unit should be in the variable name. The code itself should do a good job of explaining "what" is happening, but you generally need comments to explain "why" this code exists. Why is the test advancing the time, and why are we advancing the time at this line of the test? networkTimeMs++; // Callback occurs after timeout timeSec++; // Advance time to check whether dependent properties update utcTime++; // Leap second, DON'T advance ntpTime
        2y ago
coldpie 2y ago
> - There is no pride in managing or understanding complexity > Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity. I interpreted that one as a suggestion to avoid welcoming needless complexity because of the false sense of pride it gives you to successfully manage that complexity. To give an example, I believe C++'s enduring popularity is mostly because of exactly this false sense of pride. You practically need a doctorate-level understanding of the language to use most of its features without stepping on the dozen landmines the language places in your way (I'm so smart because I: remembered to declare my destructors virtual and understand why; can interpret this 2MB of template errors in the compiler output; can """cleverly""" use operator overloads). It can feel nice to be a master of such a complex tool, but that's a false sense of pride. The complexity of your tooling is not the point; the end product is.
- GuB-42 2y ago
  C++ complexity exists for a reason. It does a lot of things and these things are useful, if not necessary for those who use it. I can't think of any language that can replace C++ completely. Plenty can replace C++ incompletely, but then you would need another language for the leftovers, that's displacing complexity. There are modern languages trying to eat C++ lunch, like Zig and Rust, but you don't get decades of backward compatibility, and they are not particularly simple either. Rust in particular is one of the most complex programming language in use today, it could definitely be simplified by removing the borrow checker and lifetime things and make "unsafe" implicit, leave memory safety to the programmer. But it makes no sense because Rust was designed for memory safety and performance, which is a complex problem, and therefore Rust is complex.
  - stickfigure 2y ago
    > C++ complexity exists for a reason. Yeah, because Bjarne was figuring it out as he went. Which is fair, he was treading new ground. But C++ would have turned out a lot better if he'd taken a lot more vacation time.
  - DeepSeaTortoise 2y ago
mbonnet 2y ago
I think the "most programming" thing has to be determined according to project type. You should have your architecture and data relationships all figured out long before coding when it comes to safety-critical systems.
gtirloni 2y ago
> Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity. My thoughts, exactly. And considering that so much unnecessary complexity keeps being added to software (through poor understanding of requirements, technical debt, etc), it's an extremely valuable skill.

by GuB-42 2y ago

snapcaster 2y ago

I agree with you, i'm much more on the "try stuff out" scale vs. formal methods. That being said, i've worked with people who are the other way and still very effective. I think this one is more of a trade-off or personality thing than something that's "true" or "false"

AnimalMuppet 2y ago
I agree with you that personality plays a role. But regardless of which way your personality pushes you: You can never think enough up front to know all you need to know, or even 95%. You're not omniscient enough, and you never will be. Big Design Up Front fails because of this - you have to be able to iterate. You also have to know what you're trying to build, and at least roughly how you're going to build it. If you don't, no amount of iteration and experimentation will enable you to converge on a solution. You need to experiment and iterate and explore within at least a sketch of a larger picture, not on a blank canvas.
- snapcaster 2y ago
  True, the extreme version of any of these is usually wrong

do_not_redeem 2y ago

> time++; // increment time This isn't too many comments, it's a poor quality comment. Try: time++; // advance 1 simulated second

bluGill 2y ago
What is wrong with time++; That seem obvious enough to me without any comments.
- smallerfish 2y ago
  Is it ms? seconds? days? weeks? months? How far up do I have to read to figure that out? When I'm looking at a test case is broken, I ideally want context IN the actual test that lets me understand what the test author was thinking when they wrote it. Why does this test exist as it does? Why are the expectations that are in place valid? Write the comments for you-in-2-years.
  - bluGill 2y ago
    Do you not know the conventions of your project? Doesn't your project have a convention that all time is in ms (second, weeks...)? If your project doesn't have that convention such that everyone knows than the code should be timeMs++; You may also have a time type and so you can use your IDE to examine the type.
    - rovolo 2y ago
      I agree that the time unit should be in the variable name. The code itself should do a good job of explaining "what" is happening, but you generally need comments to explain "why" this code exists. Why is the test advancing the time, and why are we advancing the time at this line of the test? networkTimeMs++; // Callback occurs after timeout timeSec++; // Advance time to check whether dependent properties update utcTime++; // Leap second, DON'T advance ntpTime
      - 2y ago

coldpie 2y ago

> - There is no pride in managing or understanding complexity > Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity. I interpreted that one as a suggestion to avoid welcoming needless complexity because of the false sense of pride it gives you to successfully manage that complexity. To give an example, I believe C++'s enduring popularity is mostly because of exactly this false sense of pride. You practically need a doctorate-level understanding of the language to use most of its features without stepping on the dozen landmines the language places in your way (I'm so smart because I: remembered to declare my destructors virtual and understand why; can interpret this 2MB of template errors in the compiler output; can """cleverly""" use operator overloads). It can feel nice to be a master of such a complex tool, but that's a false sense of pride. The complexity of your tooling is not the point; the end product is.

GuB-42 2y ago
C++ complexity exists for a reason. It does a lot of things and these things are useful, if not necessary for those who use it. I can't think of any language that can replace C++ completely. Plenty can replace C++ incompletely, but then you would need another language for the leftovers, that's displacing complexity. There are modern languages trying to eat C++ lunch, like Zig and Rust, but you don't get decades of backward compatibility, and they are not particularly simple either. Rust in particular is one of the most complex programming language in use today, it could definitely be simplified by removing the borrow checker and lifetime things and make "unsafe" implicit, leave memory safety to the programmer. But it makes no sense because Rust was designed for memory safety and performance, which is a complex problem, and therefore Rust is complex.
- stickfigure 2y ago
  > C++ complexity exists for a reason. Yeah, because Bjarne was figuring it out as he went. Which is fair, he was treading new ground. But C++ would have turned out a lot better if he'd taken a lot more vacation time.
- DeepSeaTortoise 2y ago

mbonnet 2y ago

I think the "most programming" thing has to be determined according to project type. You should have your architecture and data relationships all figured out long before coding when it comes to safety-critical systems.

gtirloni 2y ago

> Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity. My thoughts, exactly. And considering that so much unnecessary complexity keeps being added to software (through poor understanding of requirements, technical debt, etc), it's an extremely valuable skill.