The code is the product, not the design. It is rather easy to think of code
as a design or blueprint for a compiler, but a compiler (or interpreter)
doesn't *build* a software product from a blueprint, it merely translates
it a software product (the source code) from a human readable/executable
representation into a machine readable/executable representation. Machine
code is still just code after all, there is nothing more *product* like about it
above and beyond the source code it was compiled from.
| [reply] |
The code is the product, not the design.
Give my Dad the source code to Word and he won't be happy. Give him a running program and he will be (at least, as happy as anybody can be with a copy of Word ;-) Source code is not a product. A running program is. I think this is the distinction that chromatic is trying to draw (hopefully not putting words into his mouth :-).
I think Jack Reeves was the first person make this analogy, and there's a nice article from the C++ Journal for those who are interested.
| [reply] |
| [reply] |
An unfinished product is still a product.
If I sell you a PC in parts, it's still a PC, you just have to assemble it.
If you're a statistician and I give you 10,000 peoples' poll results in separate files, you have the product, you just have to compile the statistics. Then the sociologist or politician or whoever interprets the statistics.
At all stages it's a product, but it's not finished until the end user can us ie.
A design is not an unfinished product. It's a plan for how to take raw materials and turn them into an unfinished product, with the idea that a finished product can then be made from those.
The design is sometimes not even concerned with turning the unfinished product into the finished product, as that's sometimes a well-defined production process.
I think the basic terms proposed are somewhat flawed. I believe very few people think of programming, bricklaying, carpentry or masonry as "crafts". People think of gluing flowers together or carving soap as crafts. I think people think of them more as "trades". Traditionally, you have the aristocracy/idle rich/statesmen, then the top working rich/merchants/company owners, then the professionals like physicians/teachers/attorneys/engineers, then the tradesmen like carpenters/masons/brewers/clockmakers/surveyors (and in modern times farmers), then the skilled laborers such as the apprentices to the above and the blacksmiths/weavers/tailors/bakers/butchers/soapmakers/herders, then the unskilled laborers who do brute force work.
There is a use of "craft" which fits, but I don't think that's the most popular connotation of that word. To think of programming from someone else's design as a trade and to think of designing software as architecture or engineering I think makes sense.
| [reply] |
Give my Dad the source code to Word and he won't be happy. Give him a
running program and he will be (at least, as happy as anybody can be with a
copy of Word ;-) Source code is not a product
That is an old, but fundamentally flawed argument. The fact that the source
might need to be compiled into a different language (machine language
instructions) to be used as intended doesn't mean the source isn't the
product. The source code for the Parrot virtual machine isn't a
specification of that virtual machine, it is an implementation of that
virtual machine. Knuth's TAOCP volume I *specifies* a MIX machine without
implementing one. It could be implemented in Perl, C, or even in hardware.
And if I write MIX machine code that implements SomeApp, that machine code
is my source code for SomeApp. The fact that the SomeApp's source code
happens to be directly executable on a physical MIX machine, but is
ultimately translated down to a completely different machine code when run
on my Perl or C based virtual MIX machines, doesn't make that source code a
final product in the first case, and just a specification or design
document in the second case.
| [reply] |
