<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Oct 31, 2025 at 8:10 AM Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com">archie.cobbs@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Oct 30, 2025 at 9:38 PM Rob Ross <<a href="mailto:rob.ross@gmail.com" target="_blank">rob.ross@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Contracts, `runtime` and `compile time`...</div></div></blockquote><div><br></div><div>All good thoughts.</div><div><ol><li>Strongly-typed languages like Java are favored for complex programming tasks because of the rich tools they provide to programmers allowing one to prove to oneself that the code's behavior will be correct. This is Java in a nutshell!</li><li>In general, such tools will operate at <i>both</i> compile/build time and runtime - and they should do so in a coherent way.</li></ol></div><div>The observation I'm trying to make in this thread is: Java gives its own tools the ability to operate seamlessly across both domains (compile-time and runtime) but it makes it difficult for the programmer to add their own tools that operate seamlessly across both domains.</div></div><div class="gmail_quote"><br></div><div class="gmail_quote"><div>-Archie</div><div><br></div></div></div></blockquote><div><br></div><div>I wasn't trying to suggest it was a either/or implementation. Just pointing out that *some* kinds of preconditions could be completely determined at compile time, and if so, there may not even be a need for any of those checks to be included in generated bytecode.  </div><div><br></div><div>Of course, most checks will require code to execute at runtime. And so the ability to ignore them (or some of them) at runtime would be an important feature in this system. Checks facilitate fast-fail program design, which makes code easier to debug. Checks also impose a runtime penalty that may not be warranted in mature, well-tested code. That's why I love asserts. They give me the best of both worlds. </div><div><br></div><div>During development, ideally you would program by contract with every function that takes parameters and returns data. This is the ultimate safety net. So a system that makes this easy to implement would be a huge productivity gain. And the ability to turn them off when they are not needed is a (potential) performance gain.  I see three use case categories regarding contract programming.</div><div><br></div><div>1. Internal, private, "black box" code</div><div>2. API code</div><div>3. Performant "expert" libraries </div><div><br></div><div>1. During development of your private implementation code, programming by contract has all the benefits discussed in this thread. But since you own this code, you are in the position to know when it is stable and mature and calls your internal methods with the correct arguments. You can leave the checks on during development and on your dev/test systems. But you have the option to improve performance in production by turning these checks off. </div><div>2. API code - since you can't control what foreign code is going to pass you, these checks will probably need to remain enabled even in production.</div><div>3. Expert libraries - think of a C graphics library where speed is critical. There is likely no error checking at all. You're on the "honor system" to pass correct data. However, you could still benefit from enabled checking in dev and test, still catching bugs quicker, and still optimized for speed in production.</div><div><br></div><div>That's why I love the asserts model. My mental picture of them is as a safety net at a construction site. You put up a net around areas where people might fall to prevent them from getting hurt. But when the building is completed, you remove the safety net. The beauty of software as a "virtual world" is that you can set up and tear down your virtual safety net with a simple compiler or jvm option flag. </div><div><br></div><div>- Rob</div></div></div>