in reply to Re: Re: Re: Programming Versus Engineering
in thread (OT) Programming as a craft

I think it is a serious mistake to equate code with design.

Why?

  • Comment on Re: Re: Re: Re: Programming Versus Engineering

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Programming Versus Engineering
by Anonymous Monk on Dec 16, 2003 at 20:08 UTC

    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.

      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.

        Thank you, that's indeed the distinction I'm trying to make. Good article.

        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.



        Christopher E. Stith
        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.