January/February 2018 issue of acmqueue

The January/February issue of acmqueue is out now

The Bike Shed


  Download PDF version of this article PDF

ITEM not available


Originally published in Queue vol. 10, no. 5
see this item in the ACM Digital Library



Jez Humble - Continuous Delivery Sounds Great, but Will It Work Here?
It's not magic, it just requires continuous, daily improvement at all levels.

Nicole Forsgren, Mik Kersten - DevOps Metrics
Your biggest mistake might be collecting the wrong data.

Alvaro Videla - Metaphors We Compute By
Code is a story that explains how to solve a particular problem.

Ivar Jacobson, Ian Spence, Pan-Wei Ng - Is There a Single Method for the Internet of Things?
Essence can keep software development for the IoT from becoming unwieldy.


(newest first)

Jon W | Sun, 03 Dec 2017 21:45:28 UTC

"specify the exact layout of a protocol packet and the byte-endianess of its fields" <-- even at the time of writing, the Erlang binary term syntax allowed you to do just that, even including functional pattern matching for components. So perhaps the problem is that you're looking in the wrong place?

Fredrik Skeel Løkke | Sun, 27 May 2012 09:25:28 UTC

Code contracts are expressed in the language itself, they are code artifacts. They are asserted at runtime or in some cases, such as in the .net toolchain, it s possible to statically verify them. This indeed means that any contractual breaches will be caught at compile time. I wouldn't recommend this for most project since its time consuming. Instead I would rely on exhaustive testing to verify my contracts. Preferable via a tool such as pex that dynamically analyses my code, then generates tests for all paths while trying to break my contracts.

Range constraints does not equal dependent types ;)

Poul-Henning Kamp | Sat, 26 May 2012 16:39:16 UTC

I'm not sure I have ever fully understood the buzz behind "Contract Based Programming."

On one side, declaring a variable to be integer is a contract with the compiler about the use we plan to put that variable to vs. how the compiler will have to treat it. I'm fine with that, but don't see what the CBP metaphor brings to the table.

On the other side, writing a lengthy comments about what a function must, should, will & wont do, is at best, like real world contracts, a document you can use to appeal to some higher power that the other guy shafted you, and like real world contracts, you won't actually know what it means, until that higher power has interpreted it. Since nobody but humans can or will interpret these comments I don't see its relevance to programming as a man-machine activity, only to programming as a manage-many-programmers activity.

If we were able to express the contracts comprehensively inside the language, and the compiler would refuse to compile contractual breaches: ("You're attempting to call FroBozz() but you are not on the north side of the Great Flood Control Dam #5") then I would buy into the idea, and would call it a step towards intentional programming, and loose the "contract" metaphor :-)

It is my impression that we have neither attained the ability to express our intentions at that level, much less found out how to make compilers understand and validate them (See also: machine generated proofs)

Range constraints are not mine, I believe they originate in PASCAL or Ada and they have certainly been out of academia for many more years than I have been programming.

That other languages, like C, have not picked up that idea, precisely because it comes from the PASCAL/Ada end of the world, is testament to how far Computer Science is from actual Science.

Fredrik Skeel Løkke | Sat, 26 May 2012 09:25:14 UTC

Your assertions are reminiscent of contract based programming. Here assertions are used to specify the preconditions and postconditions of a function, the 'contract'. Contracts are seen as the specification and the function body as its implementation. I'm personally trying to promote this style in the projects I'm working on. Some of the benefits of contracts: Living documentation, no need for defensive programming, a systematic approach to error handling (only throw when you can't fullfill your contract) and last but not least, contracts as a design tool.

Your range constraints are expressible with dependent types. But they haven't made it out of academia yet..

Poul-Henning Kamp | Thu, 24 May 2012 23:39:42 UTC

First, let me say that you only see a very small part of the picture above, feel free to check the actual Varnish source code to learn more: (https://www.varnish-cache.org/trac/browser)

Second, if anybody tries to modify Varnish based on assumptions rather than doing their homework, they're probably in for a interesting ride. Varnish is written to be high-performance on modern hardware, and contains a lot of tricky stuff, including a compiler for a domain-specific language.

Thirdly, varnish assert function does precisely go out of its way to make sure usable debugging information is recorded so we can diagnose and reproduce, including dumping relevant state and data structures and a backtrace.

(Which brings me to another rant-topic: WTF does ISO-C not provide a portable way to get the best estimate of a backtrace the compiler can provide ?)

Brooks Moses | Thu, 24 May 2012 06:27:40 UTC

I strongly agree with most of this article, but I do disagree on one point: the assert() macro should never be used in a way that will cause the program to work incorrectly if compiled with -DNDEBUG, as Varnish reportedly does. The assert() macro has an established meaning that includes the idea that its argument has no side effects -- and other programmers who are working with your code will likely rely on this, in ways beyond simply compiling with NDEBUG defined. Misusing it this way is also simply a bad habit to get into because people do define NDEBUG in other codebases, and there this habit will bite you with bugs that only appear in the "release" build.

In cases where you do want to make an assertion about an expression with necessary side effects, the correct solution is to write your own error-handling code that is not affected by NDEBUG, so that your intention is correctly aligned with the language semantics.

Defining your own always-on assertion handler also has a secondary benefit: it encourages you to think for a moment about how the failure should be handled in the deployed code if it occurs. Perhaps the error will be lost if printed to stderr and should be logged instead or displayed in a dialog box; perhaps some sort of attempt to save the user's unsaved work should be made before aborting. If the assertion handler handles errors in a user-appropriate way, that's one less argument against leaving it turned on.

Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.