From rob.ross at gmail.com Sat Nov 1 02:43:08 2025 From: rob.ross at gmail.com (Rob Ross) Date: Fri, 31 Oct 2025 19:43:08 -0700 Subject: Ad hoc type restriction In-Reply-To: References: <651bcb1a-3dba-48c8-b615-740034760d88@oracle.com> <36edf5e8-791e-4d31-8e7d-05cea3eabd22@oracle.com> <_hpWIJCY4KKm-omhziKAtP-HzavBj0EWmR2PVZa236HpRJNKeovu8Ni1PtaVMTVk1-Tawmxtiz7gGQx_b70MmIXJ0KCEBRMwtdWnxx8Y6g8=@proton.me> Message-ID: On Fri, Oct 31, 2025 at 8:10?AM Archie Cobbs wrote: > On Thu, Oct 30, 2025 at 9:38?PM Rob Ross wrote: > >> Contracts, `runtime` and `compile time`... >> > > All good thoughts. > > 1. 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! > 2. In general, such tools will operate at *both* compile/build time > and runtime - and they should do so in a coherent way. > > 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. > > -Archie > > 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. 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. 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. 1. Internal, private, "black box" code 2. API code 3. Performant "expert" libraries 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. 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. 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. 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. - Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: