tag:blogger.com,1999:blog-7029605438334875741.post6500269468376078312..comments2024-01-24T22:19:44.224-08:00Comments on Eitan Adler's thoughts: Good Defaults for Technical DecisionsEitanhttp://www.blogger.com/profile/17949044170991613871noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-7029605438334875741.post-35668251158911865652024-01-23T16:18:25.257-08:002024-01-23T16:18:25.257-08:00I largely agree with your philosophies here, so it...I largely agree with your philosophies here, so it's only details that I'm interested in exploring.<br />"Warnings ought to error or not exist." I'm not aware of any standardized distinctions between error, warning and notification, etc but I think there is a role for a warning, which is when an exceptional, unexpected or questionable conditioned has occurred, but it doesn't stop the process from completing, yet it deserves attention. Like, a car warns you that your oil is low, but you can still drive to the mechanic. Low battery warning. Maybe a cache got deleted and so data had to be recalculated: warn the user that it will take longer than usual but it's not blocked. Obviously, by comparison, an error is when things cannot continue.<br />I treat all compiler warnings as errors, but that's personal preference. :)<br />I agree that noise is very unhelpful, and so all warnings and notifications must be chosen carefully.<br /><br />"Function and information hiding." I know this is a very common and important tenet, but I do wonder if it is misphrased and the real intention is to hide implementation? Since information is the currency of our industry, it's the thing of value, hiding it by default seems counterintuitive. The information that we don't value today might be extremely valuable tomorrow, or it's actually already valuable today, but to someone else. I guess in effect I think we should hide implementation, but information and functions (interfaces) should be as public as possible by default. So many times I've encountered an interface where the really useful thing that I need is hidden away privately, requiring rework to make it public. If we're not sure about the design of an interface, then it's fine to keep it private until we are. But I think keeping things private by default diminishes the value of what we create by limiting its accessibility.<br />Sometimes, the way to hide implementation is actually the specification/documentation, which can be a bit unsatisfying. For example you might document that a function returns a type that satisfies certain concepts (to use C++ parlance), but the exact type is unspecified and open to change. In practice the user can see exactly what type it is (the implementation), but the specification says you can't depend on it. (Much easier since C++11 introduced the auto variable type feature.)<br /><br />Otherwise, I completely agree with you! :)<br /><br />Here's a topic for you: when designing a solution to a problem, there is a tradeoff between specificity and generality. A specific solution helps people understand what the real, original problem was at the time, since that knowledge is often lost. A more general solution obscures what the original problem was, but of course has the benefit of solving a wider variety of problems. What is the good default?Jeremyhttps://www.blogger.com/profile/01910912497083882333noreply@blogger.com