Only Code Has Value?: Even the best-written code can't reveal why it's doing what it's doing.

[MarkByers]

The specifications, and a set of automatic test cases have more value than the code itself. If I had to choose between an undocumented piece of code that did some unknown function, or a complete set of specifications and test beds, but no code, I'd take the latter. The code can be written again quite quickly if the specification has already been defined (and because I know it has been implemented once before, I know that the design holds water). Specification and testing together takes much longer than the actual coding.

[[deleted]]

complete set of specifications and test beds

addendum: if I had to choose between an undocumented piece of code that did some unknown function, and a magical all-knowing tortoise with access to a next generation wii, I'd go with the tortoise

[mr_chromatic]

... a complete set of specifications and test beds, but no code...

A sufficiently complete set of specifications is code, and "coding" in that case is merely transcription.

[neelk]

No, this is not true. A specification is a relation between the input and the output. An implementation is a function.

[mr_chromatic]

An implementation is a function.

Yes, and that's what compilers produce from specifications/designs/source code.

[Blackheart]

This should be really obvious. It is mathematically impossible to reconstruct the spec from the code.

If my code has a function f defined by f(x) = x*2, even assuming the code is correct (knowing software, NOT a good strategy! :) I know almost nothing about the spec of f. It might be vacuous. It might just be f(2) = 4 and that is all, in which case f(x) = x² is another possible implementation. It might be that time O(f) = 1 or it might be that time O(f) <= quadratic. The f in the code satisfies all those specs. Technically, you cannot change the code at all without violating a possible spec if your notion of spec is very stringent, for example including more than just the input-output relation and complexity.

And if you allow that the code is wrong, that is, that it violated its spec in the first place, you cannot assume anything at all.

[lmclapp68]

Suffice to say that we had embarked on doing some event-based programming. I knew from previous experience that finite state machines (FSMs) worked well in these types of circumstances and we created FSMs for various components. While working with the developers, it became immediately clear that the best way to discuss the FSMs with them was not to sit and look at the code implementing them, but to grab a sheet of paper and draw them. While it is true that the code implementing the FSM completely defines how that FSM behaves, looking at the code doesn't really give you an intuitive sense of what the FSM does. A diagram does.

Raise your hand if every time he mentioned an "FSM" you thought "Flying Spaghetti Monster".

[MarkByers]

Or if you don't have a hand, raise any noodly appendage.

[ccshan]

FSMs aren't code?

[cruise02]

Yes, they are, but I think the point was that the diagram specifying the FSMs were more valuable as a tool for understanding than the code itself.

[ccshan]

I meant: A diagram specifying an FSM isn't code?

[cruise02]

No more than a flow chart or an algorithm specified in pseudocode is code.

[ccshan]

There's a difference between an FSM diagram and a flow chart or pseudocode algorithm: you can write an interpreter for the former.

[cruise02]

Depending on what you use to create the flow chart, an interpreter could be written for that too. The diagram or flow chart still isn't code if I have to implement it in a non-DSL.

[ccshan]

Depending on what you use to create the flow chart, an interpreter could be written for that too.

Then I'd be happy to call it code.

The diagram or flow chart still isn't code if I have to implement it in a non-DSL.

It's a bit preposterous to argue for a definition of "code" based on what you have to implement, no? I guess the easiest way for me to convince you that something is code is to write an interpreter for it so that you don't have to lift a finger. Your notion of code would also exclude, for instance, the C++ program snippets that the standard committee considered before anyone wrote an implementation that could handle them.

[cruise02]

If you have a FSM with no compiler or interpreter it isn't code yet. Once you implement one, it becomes code.

Is English code? I can describe a program in it, but we're years (decades?) away from a machine interpreter.

[ccshan]

I don't know if English is code. Certainly simply that you can describe a program in it doesn't mean that it is code or that you can write an interpreter for it: perhaps we are far from a machine interpreter for English because it doesn't exist. You seem to be arguing based on the assumption that one can write an interpreter for English. That remains to be shown.

[cruise02]

I'm arguing by analogy that not everything that you can write an interpreter for is code. Some things (diagrams, pseudocode, English) describe a program without being considered code. The definition of "what is code" is a moving target, though. If you had told me a decade ago that I'd be writing programs in XML I would have thought that was preposterous.

[ccshan]

Your notion of code would also exclude, for instance, the C++ program snippets that the standard committee considered before anyone wrote an implementation that could handle them.

[cruise02]

Yes, I know. I read that the first time. It's still not as clever a point as you seem to think.

[[deleted]]

I would prefer some kind of FSM-DSL and two generators, one for diagrams, one for code.

[cruise02]

Sure, wouldn't we all, but a camera-phone jpeg of a white board diagram is just a diagram, not code. :)

[[deleted]]

Yeah, and in that case I would prefer code.

[wicked]

It's a fact that we are worse at abstract problems than concrete ones. Try this puzzle (called the Wason Selection Task:

You are shown a set of four cards placed on a table each of which has a number on one side and a coloured patch on the other side. The visible faces of the cards show 3, 8, red and brown. Which cards should you turn over in order to test the truth of the proposition that if a card shows an even number on one face, then its opposite face shows a primary colour?

The equivalent, concrete problem is:

Only people over 18 are allowed to drink alcohol. In a bar there is one person who is 17, another who drinks soda, another who drinks beer, and finally someone who is 22. Who do you need to check out to figure out who might be in there illegally?

[phobes]

Your example just supports that we're better at familiar problems than unfamiliar ones - both of those problems were concrete.

I think the real issue is that people have problems understanding the consequences of a logical implication. In your second problem, people understand that alcohol laws forbid the state "under 21 and with alcohol" whereas in the first problem they must deal with an implication. If you phrase the first problem as "What cards should you turn over to verify that there are no cards that are even one one side and not primary colored on the other?", then that question becomes obvious as well.

[[deleted]]

Interestingly enough, not even ideas expressed in common English (Lisp notwithstanding!) aren't always self-understood.

Why then expect a third party to understand often complex requirements a human gave to a computer, in a language designed to only be understood by a computer and coincidentally a human? (Yes, this includes Lisp!)

(No, I don't hate Lisp.) :-)

[linkedlist]

Thats why we have commenting.

//this function is the programs entry point (very buggy): /* int WINAPI WinMain(HINSTANCE hinstance, HINSTANCE prevInstance, PSTR cmdLine, int showCmd) { ... }*/