Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Programming is more like:

by Arunbear (Prior)
on Sep 05, 2008 at 10:53 UTC ( #709237=poll: print w/replies, xml ) Need Help??

Vote on this poll

[bar] 127/25%
Carpentry / Masonry
[bar] 68/14%
[bar] 14/3%
[bar] 70/14%
Painting / Drawing
[bar] 42/8%
[bar] 54/11%
Knitting / Weaving / Sewing
[bar] 39/8%
Rocket science
[bar] 16/3%
Brain surgery
[bar] 23/5%
[bar] 47/9%
500 total votes
Replies are listed 'Best First'.
Re: Programming is more like:
by BrowserUk (Patriarch) on Sep 05, 2008 at 11:50 UTC

    I vote for carpentry. Because,

    • You have to work within the constraints of the materials.

      The carpenter has to assess and work with the variations of the grain, strength, and imperfections of the wood.

      And he has to chose the tools and techniques he uses for any particular job to suit the requirements of the job. Mortice and tenon joints and glue may be perfect for building a cabinet, but would take far too long when erecting shuttering for a concrete pour, where nails are more cost effective.

      The programmer has to work with and around data that may be incomplete, badly formatted, or just damned inconvenient.

      Likewise, he has to choose his language and tools carefully, and work with the strengths and around the weaknesses and imperfections of them.

    • It takes skills knowledge and experience to make the raw materials approximate the design.

      No matter how well designed and drawn the plans for a workpiece are done, translating the raw materials into the product is far more than just 'cut here', 'drill there', 'screw that'. How you cut, drill and screw means that two equally skilled practitioners of the art, or even the same guy on different days, can produce good and bad examples of the same thing.

      The same analogy holds for programmers. How you choose to perform each step is nearly as influencial to the outcome as performing all the steps and doing them in the right order.

    • Carpenters, like programmers, are not machines.

      Where a sheet metal press, or autolathe or grinder can be set up to turn out consistantly identical parts, each workpiece or program is created anew.

      Even the best carpenter can have off-days. Cut in the wrong place or too deep; pick the wrong piece of stock; or misread the measurements.

    • Mass production methods can go some way to speeding up production and alleviate variance, but the final product is never quite as satisfactory.

      Using engineered woods (plywood, MDF, veneers etc.), and automated machinery can allow for the production of cheaper products.

      But just as a set of mass produced kitchen cabinets will never quite fit any given kitchen as well as the bespoke output of master carpenter. So the results of a 4GL; the mix'n'match of generic libraries; or the filling-in-the-blanks of a framework; program will never be as fit for purpose as one written by a skilled programmer to satisfy a targetted specification.

    Basically, just as with carpentry, there is just as much art and craft in software development as there is engineering. Perhaps more so. That will have to change unfortunately.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Perhaps your analogy could be extended to languages too.

      Perl being a well seasoned piece of Oak while others are just MDF or Chipboard not built to last and crumble at the slightest stress.

      That will have to change unfortunately.

      Why? - threefold: why does it have to, why should it, and how could it? Carpentry is as long as things are made of plain wood. Yes, tools improve, power tools get invented - but the craft remains the same.

        Why? - threefold: why does it have to, why should it, and how could it?

        Simple. Economics.

        There are still Master Furniture makers like Joseph Hemingway around, and most of us would love to be surrounded by the type of furniture he produces, but few people can afford to be so.

        Software production costs way too much. The development costs are alleviated somewhat by the cheapness of mass distribution, but still it will have to get cheaper.

        For the how, you need to look at better tools. In particular, a set of standards covering the interfaces for reusable, interchangable components (libraries) so that we programmers can bolt together more parts of our programs from them, more quickly and with less interfacing glue.

        And there will have to be less languages. When I was growing up there were a dozen or more mass production car manufacturers in the UK, a dozen or so in France more in Germany. Now there are less than a dozen across Europe. And many of those are brand names owned by the same parent conglomorates. (Nissan == Renault; Volvo/Jaguar == Ford; Seat/Bentley/Bugatti == VW-Audi; Gone are Austin; Morris; Humber; Hillman; Roots; Vanden Plas; DAF; and many more.)

        Consolidation is inevitable. As is automation. People have been trying to automate program generation since programming began. There was one pretty serious attempt made way back in the early '80s called The Last One. (Meaning the last program that would ever have to be written by hand.)

        We know that it got no where, but it won't stop people trying. And eventually succeeding. There is nothing more suited to applying the power of computers to than the creation of programs. We programmers are applying the power of computers to ever more complex fields of endevour every day, but still insist on hand crafting our own endevours using a disconnected, non-interoperable set of tools that go back decades. That's the equivalent of corporate accountants and commodity traders still doing double entry book keeping using quills and ledgers.

        C & Fortran compilers can already generate better optimised assembly code in the general case than an experienced assembler programmer can achieve. The Haskell compiler can basically take a mathematical description of an algorithm and turn it into extremely fast and robust code.

        But most of use are still coding in a general purpose editor, then submitting our code to the compiler/interpreter for syntax checking. Then stuffing that into a text-driven source control database. And recompiling/interpreting the source code from text representation every time.

        Sure, there are IDEs that will syntax check (some) languages as we type--but they are still widely eshewed. And we have object libraries, but they are in a different format and once created basically become static entities. Some compilers support pre-compiled headers and incremental compilation, but their databases are in proprietary formats and can't interoperate with each other, or other tools.

        All of that has to change. And it will. Programmers have to start applying their art to their own works and tools. It's inevitable.

        For more reading of (my writings) on this subject see also: Re: How do you view programming and Re+: (OT) Programming as a craft (loong post. Even by my standards!). There is more kicking around this place, but that is probably more than anyone will read.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        Personally I see it as more like a puzzle. You start by finding that easy, well-loved corner bit, and then you have to mix and match more and more of the puzzle until you have the perfect result. If one little fragment is missing, it is not perfect and may be misprocessed by others:).

        The other option is seeing it as being like algebra. I once had an algebra teacher who kept telling me, nope, you can not start to solve the problem by finding the solution, you need to simply do the very first step, and then the next... Programming is exactly like this as you need to have each little element working perfectly before anything further will do so. In algebra, one incorrect calculation and the whole thing falls apart. In programming it is just the same.


      These all sound like reasons why it's like engineering, which was my vote. Engineers have to work within the constraints of the materials available, they have use the available skills and knowledge, they are not machines, and mass production helps but isn't a cure-all.

      And there's most definitely craftmanship in engineering.

      Alex / talexb / Toronto

      "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

        Not really. Or at least not in most engineering fields.

        1. Engineers have to work within the constraints of the materials available,

          These days, in many fields of engineering, we have reached the point where we engineer the materials to suit the application.

          For example, we can choose from a vast range of types of steel. Or use aluminium, magnesium alloys, titanium, carbon composite or any of a vast range of plastics.

          And whilst there will be some variations in the strength, hardness and other properties of these materials, generally these are accounted for using pessimistic Safe Working Load (SWL) margins and quality control using automated processes.

          By contrast, the carpenter has to individually inspect each 2x4 to check for the presence of knots or insect damage that can seriously degrade the performance.

          In a few situations, the programmer has the luxury of specifying the format of raw materials (input files etc.), but more often than not he has to accept an existing format (XML, FASTA, jpg) regardless that it may be entirely inconvenient for this particular application. Further more, he cannot specify or predict the quality of the data.

        2. they have use the available skills and knowledge,

          These days, it is possible and very common place for non-experts to design components, and have software that converts those designs into CAD/CAM instructions that can be fed directly to automated machinery that manufactures it.

          You can even do this via the internet! You download a free CAD package; create a drawing of the part you need; view it in 3D; specify the material (steel, brass, aluminium, plastic), Get a price estimate with one-click. Order it with another.

          Imagine being able to do that for software?

        3. they are not machines,

          Actually, mostly they are machines. When I was doing my apprenticeship as a mechanical engineer 30 years ago, the production line for the average family car involved tens of thousands skilled & semi-skilled workers. Today, the same production line is run by a couple of hundred workers, mostly machine minders, logistics staff (who keeps the robots fed with parts), maintenance and quality control people. The rest is done by robots.

          In other fields of engineering it is pretty much the same story.

          Civil Engineering: Whether building a bridge or an office block or a ship, much of the raw materials and sub component assemblies are manufactured by automated machinery.

          Electronic engineering: Electrical & Electronic components are produced in huge clean-room factories with environmentally controlled atmostpheres tailored to the needs of the machines and processes, not the occasional human inspectors who have to go through decontamination processes and wear protective suits to enter.

          Chemical Engineering: Beyond the research labs, the processes involved are conducted in huge plants of tanks, pipes, reaction chambers and refraction stills. Monitored and controlled by computers. With the only human beings present being maintainance crews.

        4. and mass production helps but isn't a cure-all.

          30 years ago, the final finishing of car bodies was done by hand, 'wiping' the joints using molten lead. The paint was applied by a human sprayer. The final finish was inspected by a man with a bright light and a magnifying glass. Now all these processes have either been designed away, or are fulfilled by computer controlled robots.

          The only thing in software that is anything like mass production right now is the production of distribution media.

        Before software production can be called an engineering discipline, similar levels of automation will have to ensue. And it is already possible to some level.

        Take the vast majority of commercial webs sites. They have a database of things; those things have attributes and a price; the user needs to be presented with those attributes and given a means to search, select and compare them. Once their choices are made, the prices needs to be accumulated, their delivery and payment details collected, payment arranged and verified. Delivery arranged and tracked. E-bay, Amazon and GoogleShopping have already automated most of this.

        The same can be done with most other types of website. Facebook et al. mean that there is no need for most people to program their own 'homepage' anymore. With Google:Blogger|Groups|YouTube|Gmail|Calander|Docs, and their competitors, the question becomes what to share, not how.

        With the advent of the Google browser and the Google Web Toolkit, how long before designing a new website for just about any purpose becomes a point'n'click, drag'n'drop affair that takes care of the DB schema, scalability, validation, authorisation etc. and just leaves the 'programmer' to decide what questions need to be asked in what order and what pretty pictures and fonts to use?

        There will be some hold outs. The banks will continue to design their own, usually awful applications. The big traditional retailers will continue to have in-house software development teams. In the same way they continue to have their own trucking fleets, even though it would make economic sense and be greener to have a single distribution network for all of them. What sense does it make to have all the big supermarket chains sending their own trucks to each of the producers of breakfast cereals, to pick up the same produce?

        Software production will become an engineering discipline, but it isn't even vaguely one yet. And most of the so-called software engineering processes, are as akin to modern engineering processes in other fields, as the blacksmith shoeing a horse.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

      of course, programmers are much less likely to lose fingers due to misuse of their tools than are carpenters....

      Information about American English usage here and here. Floating point issues? Please read this before posting. — emc

        True, but maybe that's a double edged sword (or perhaps no edged is a better analogy :).

        People with no aptitude for carpentry tend to have a few minor but painful slips early on which convince them that some things are better left to those with a greater aptitude.

        Unfortunately, incompetence in programming does always effect such a change in attitudes.

        That's not to say that programming tools can't be abused. From people using Word as a program editor; to programming editors that evolve to be close to stand alone operating systems; text macro libraries that are so entirely opaque as to defy understanding; to make files so complex that they start to exhibit signs of Heisenberg Uncertainty; to 'simple' configuration mechanisms wrapped up in unfathomably deep OO hierarchies. The list goes on.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Programming is more like:
by johndageek (Hermit) on Sep 05, 2008 at 13:02 UTC
    I had to go with other because there was no all of the above.

    Programming is much like engineering - as you design your project you need to be aware of the real world applications and limitations while striving for the theoretical best.

    Programming is much like Carpentry/Masonry - You build according to plan except where the plan does not account for limitations imposed by the materials, site, tools or abilities.

    Programming is much like Gardening - you have grown your system to maturity and enjoy it, but you also see the things you need to do better next year(next time).

    Programming is much like Cooking - You follow the recipe but when opportunity is available substitutions can be made that will improve the end product (ok and some times you need to toss out that batch of soup)

    Programming is much like Painting/Drawing - There are moments of divine inspiration that make everything PERFECT! And if it doesn't you can erase/overpaint (sigh)

    Programming is much like sculpting - sometimes the base medium has a flaw or characteristic that makes it less than ideal for the given application, but we somehow almost always seem to make things work out.

    Programming is like Knitting/Weaving/Sewing - each thread we add to our tapestry has an effect on each of the others. Adding a bad thread in the wrong place can cause failure in unforeseen places.

    Programming is like rocket science - the more familiar you become with programming the less like rocket science it seems. But there is a point where sometimes while thinking about a program we do not realize how stupid we look sitting out in the rain (it WAS sunny when we started thinking).

    Programming is like Brain surgery - We do everything in our power to keep mistakes out of what we do but sometimes - rarely (we hope) - somebody dies :(

    So depending on the time, application, language, programmer, company, weather and all other things that affect us - programming can indeed be more like each of the above than any of the others.


      In some ways, programming is like parenting.

      If done really well, you're no longer responsible for it, it goes off on it's own, and makes you proud of it.

      Sadly, sometimes you outlive your child.
        I should've also said that the creation of the offspring can be very pleasurable, while the delivery is quite painful...
        And sometimes, no matter how well you try to raise your child, they do something bad when you least expect it. ;)

        Revolution. Today, 3 O'Clock. Meet behind the monkey bars.

        I would love to change the world, but they won't give me the source code

      ++, but at some point I have to disagree:
      Programming is like rocket science - the more familiar you become with programming the less like rocket science it seems.

      The more I learn about programming, the more it seems like rocket science to me.

      Sure, at some point I had that "I can code everything" feeling. And a few weeks later I thought about how I could possibly write a complex piece of software (think a good compiler, OCR, RDBMS, face recognition, an operating system that doesn't suck, ...) and I realized that it's not so easy.

      And the more I learned about programming, the more I saw the complexity in seemingly simple programs.

      Take a text editor as an example: it displays a few lines of text, allows you to scroll, to safe the files etc. Simple, right?

      But wait! Did it ever occur to you that the editor has to handle multi byte character encodings? even graphemes that are made out of multiple codepoints? converting between different encodings? autodetect character encodings? That it has to support right-to-left for arabic texts? That it might contain a syntax hilighting engine, a script language for configuration? that all key strokes could be configurable? that it should support vertically split windows on the text console?

      I think I could go on with my list of things that make a seemingly simple thing like a text editor a real challenge to program. (And fwiw vim supports all of the features above; and I think many other good text editors do).

      There are hundreds of other pieces of software that I thought were simple before I got into programming. Now I'm glad that others wrote those incredible helpful (and very often equally complex) programs, and that I don't have to do it all by myself.

Re: Programming is more like:
by tinita (Parson) on Sep 05, 2008 at 12:14 UTC
    Depends on the language.
    C programming is like making a puzzle - you really have to get all the pieces in the correct place, there is no other possibility. (Note that I actually don't know much C)
    Java is more like painting by numbers (don't know the englisch word, in german it's "Malen nach Zahlen"). It's a lot work but you can't get much wrong.
    PHP programming is like modern paintings - just throw some colour smudges on the canvas until it looks good and seems to do what you want. ;-)
    Perl - well Perl is just any art you want it to be, and fun =)
      PHP programming is like modern paintings - just throw some colour smudges on the canvas until it looks good and seems to do what you want. ;-)

      I like this analogy ;)

      Artists can make a lot of money with it, and there are some crazy people who admire their work, and you keep thinking "I could have done that myself in 10 seconds."

Re: Programming is more like:
by moritz (Cardinal) on Sep 05, 2008 at 10:57 UTC
    That reminds me of a professor who tried to teach us Density functional theory
    This is no rocket science, because it's much harder than rocket science.

    IMHO not quite applicable here, though ;-)

Re: Programming is more like:
by zentara (Archbishop) on Sep 05, 2008 at 12:56 UTC
    It's more like Virtual TinkerToys

    A male's interest changes as he grows.... first Tinkertoys....then onto sex.....finally back to Virtual Tinkertoys.

    I'm not really a human, but I play one on earth Remember How Lucky You Are
      Then virtual sex? 8-)
Re: Programming is more like:
by Moriarty (Abbot) on Sep 05, 2008 at 11:08 UTC

    I quite like the knitting/weaving/sewing analogy, although I'm more into crochet myself.

      Well you would get to knit one purl perl one!

      I'm quite partial to a bit of embroidery myself, although not the decorative needlework type.

Re: Programming is more like:
by tweetiepooh (Hermit) on Sep 05, 2008 at 15:00 UTC
    I said it's more like gardening.

    It requires skill, knowledge, care, attention, love, perseverance, money and so on.

    A garden is dependant on sun, rain, temperature. Your program is also dependant on external factors like data, users etc.

    A garden needs defending from parasites, disease, weeds. Your program needs defending from users, bad data, no data, management.

    It's also dynamic. It starts small and neat like a little plant and before you know it, it's taken over everything else, draining all resources and has a life of it's own.

      It's also dynamic. It starts small and neat like a little plant and before you know it, it's taken over everything else, draining all resources and has a life of it's own.

      ahh... you planted mint. You have to keep it in a sandbox pot, or it just takes over.

      But now you have me thinking ... are PHP, Java applets and JavaScript invasive species?

Re: Programming is more like:
by punch_card_don (Curate) on Sep 11, 2008 at 15:39 UTC
    Programming is more like:


    It starts with a lot of excitement about how great it's going to be. Then there's a lot of sweating and grunting trying to make it that good. Then when it's done, no matter how good it turned out, someone involved wishes it could be better.

    Time flies like an arrow. Fruit flies like a banana.
Re: Programming is more like:
by stonecolddevin (Parson) on Sep 06, 2008 at 01:57 UTC


    When things are going really well, programming is like building blocks to me. Things just keep going together, getting rearranged, and restacked, like Legos.

    That's when things are going well...otherwise it can be like untangling string. Which I hate.

Re: Programming is more like:
by Tux (Canon) on Sep 05, 2008 at 14:36 UTC

    I chose Sculpting as it was closest to what I would have chosen if it was there: Art. Again, this is a poll where tickboxes would have been fun. Why currently my mind thinks sculpting is more art than painting or drawing, I cannot explain. In the widest meaning of the word. Using your imagination and creativity to create something that is functional, effective and beautiful. Yes, style and layout do not only help maintainability, but also pleases the eye.

    Enjoy, Have FUN! H.Merijn
Re: Programming is more like:
by gregor42 (Parson) on Sep 09, 2008 at 12:25 UTC

    I chose Other - not because I cannot find similarities in all of the things listed. Oh how I do indeed.

    But I would offer simply is that I believe that programming is most like Writing.

    Ultimately is it simply an abstract way to express yourself.

    There are many formats, from ad writers to columnists to short stories to novels, etc..

    There are many styles.

    There are many languages.

    And if you want to compare popular fiction writers as Metaphors for programming styles then you can say interesting things about J.R.R. Tolkien and Philology for example...

    Wait! This isn't a Parachute, this is a Backpack!
Re: Programming is more like:
by blue_cowdawg (Monsignor) on Sep 10, 2008 at 23:45 UTC

    I picked carpentry....

    Really in my mind it is more like cabinetry making or boat building. In my mind to be a success at those you first have to build up your jigs and tools.

    Programming is sorta the same thing. Once you have your templates and tools in place and set up you can begin. Like boat building and cabinetry a good plan before you start can be a big help but in some really talented cases is not necessary.

    My grandfather for instance, who was a bricklayer and mason by trade, decided to build a boat one fine day. He cut down some Maine oaks, hew the timbers, stacked and dried them. When he felt the wood was ready he and my mother laid the frames for the boat out on my grandmother's kitchen floor. My grandmother wasn't amused by that but she knew better than try and stop my grandfather.

    Out of that came an 18 foot cabin cruiser that was never finished because my grandfather always had a better idea of how he wanted it configured. He built the boat without any plans.

    Peter L. Berghold -- Unix Professional
    Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg

      I hope you or someone else finished building the boat it deserved to be completed after all that hard work.

        By the time I was old enough to do such things, my Uncle (my grandfather's only son) had unfortunately neglected the boat to the point it rotted away. Neither of my grandfather's daughters or sons-in-law were interested in the boat at all.

        Something that to this day saddens me greatly. I caught my first fish on that boat (a five pound tautog at that) so the boat meant a lot to me. All the adults around me told me not to fuss about it.

        Peter L. Berghold -- Unix Professional
        Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
Re: Programming is more like:
by chexmix (Hermit) on Sep 05, 2008 at 14:23 UTC
    Much as I hate being a grammar nudge (I'm lying - I really don't hate it that much), doesn't "more like" require or at least imply a "than" clause afterwards, as in:

    "Programming is more like Mentos™ than it is like Pez™."


      My thoughts exactly. Well, except that I'd say programming is more like Pez™ than Mentos™. Just to be contrary.

        I can see your point, I suppose, but in the end I would have to plump for rephrasing the thing entirely and deciding that "programming is MOST like Chuckles™."

        And I specifically mean the black, licorice ones, because they are quite obviously the best.

        So we really don't need a poll at all. Q.E.D.

Re: Programming is more like:
by vrk (Chaplain) on Sep 10, 2008 at 13:00 UTC

    Programming is harder than rocket science, because it still doesn't have a firm mathematical machinery behind it. Yes, there is lambda calculus and other calculi, theory of infinite and finite automata, Boolean algebra, and other strands in mathematics that define the entire field. But what we miss is useful things rocket engineers can use: analysis and algebra. Set up the initial conditions and requirements as equations, and derive a solution, for instance (say) solving Newton's laws of motion for an accelerating rocket engine. We don't have any of that, much less laws of motion.

    There are several reasons why there is no such thing:

    • Social resistance. Your job is secure if you don't frame and divulge your knowledge explicitly.
    • Artificial complexity. It seems to be human nature to create order where it is not really needed (in terms of reaching the goal).
    • Real complexity. Many requirements are impossible to express with mathematical precision; some are fuzzy, some change frequently, some have temporal qualities that cannot be encoded in predicate logic, etc.
    • A part of programming is an art. Perhaps due to inadequate notation, or deficiencies in education, or simply because it requires a certain way of thinking that not everyone can do, you do need tacit knowledge to do anything.

    So even if you tried to be precise about the requirements, you will be swamped by (unnecessary) detail and complexity. Perhaps we just need to develop better abstractions.

    print "Just Another Perl Adept\n";

      (Sorry for be rather off-topic, but it's an important topic for me, so... no real excuse, I know ;-)

      Programming is harder than rocket science, because it still doesn't have a firm mathematical machinery behind it.

      I don't know about engineering, but in physics the mathematical machinery isn't as firm as one would think. Well in research papers it usually is, but not in the typical course.

      I've witnessed this several times, at various universities:

      teacher: Now we can write $this integral like $that student: Wait, /can/ we even do this transformation teacher: Well, the mathematicians know a list of conditions that determine if it's allowed, but I don't know them because it's allowed for all functions that physicists ever use.

      (For the interested, those conditions are usually "only a finite number of discontinuities).

      Which is perfectly fine, because I'd never be able to finish my studies if I only did mathematical operations that I have proven myself and that I know are allowed, but it doesn't really raise my level of confidence in mathematical foundations.

      When you talk about mathematics, keep in mind that it's still only humans that do it, and they can make mistakes, and even in mathematics they can have varying opinions.

Re: Programming is more like:
by Alien (Monk) on Sep 09, 2008 at 08:28 UTC
    I would go with voodoo !
Re: Programming is more like:
by peter-stefan (Initiate) on Sep 17, 2008 at 09:39 UTC
    Programming is like poetry.

    It is nice to savour good programs and their solutions.

    Greetings Peter
Re: Programming is more like:
by themage (Friar) on Sep 08, 2008 at 12:21 UTC
Re: Programming is more like:
by Anonymous Monk on Sep 05, 2008 at 11:19 UTC
    Engineering, rocket science, brain surgery, pimpin'
Re: Programming is more like:
by Illuminatus (Curate) on Sep 10, 2008 at 20:44 UTC
    The Tao...
Re: Programming is more like:
by sandeepbharmoria (Beadle) on Sep 07, 2008 at 04:18 UTC
    It's all about patience, trying and trying .... so Story of king Bruce is more like concept of programming......
Re: Programming is more like:
by drip (Beadle) on Sep 08, 2008 at 01:15 UTC
    Rocket Science, making sure the fuel is right to finish
Re: Programming is more like:
by wolfger (Deacon) on Sep 08, 2008 at 19:24 UTC
Re: Programming is more like:
by casiano (Pilgrim) on Sep 11, 2008 at 15:34 UTC
    For me, writing compilers is very much like gardening.

    Lexers eat streams of characters that they digest into tokens. Tokens are like food and water for compilers.

    Parsers - Syntax Analyzers - produce trees and sometimes forests. And many of those trees very much resemble flowers.

    If you are not careful enough while designing your grammar your trees grow wild.

    Later, during semantic analysis you decorate them with attributes, very much like a christmas tree.

    And much later - during machine independent optimization phases - you have to transform their shape, pruning them, forcing them to be the way you want (a bit like bonsais).

    Finally during code generation and machine dependent optimization bees and insects visit the trees producing the final translation.

    But at the end I feel that general purpose programming is more like writing mathematics.

    Each time you write a correct program (exists such thing?) you are attempting (via reasoning, verification and testing) to prove that your input-output function is the one your client requires. You are writing, somehow, a theorem.

Re: Programming is more like:
by blacksmith (Hermit) on Sep 15, 2008 at 15:28 UTC
    I had to say 'Other'. To be more descriptive, I would say like a hallucinogenic experience. (Not that I have ever had one. Well, unless you count some of the late nights that staring into the humming glow of a Carthode Ray Tube cause.) These hallucinations appear when I begin thinking of code, then, with the utmost confidence of knowing that my code will work, I begin and finish. Soon after the mind begins to sober and my eyes start to clear, I see it through the blur and glow... "Execution aborted due to compilation errors."
Re: Programming is more like:
by ashkelon (Initiate) on Sep 17, 2008 at 03:29 UTC
    Weaving is physical XOR-ing. I can't make a case for sewing or knitting... Those don't work for me, but weaving makes a lot of sense. Also composing counterpoint (music). Very like.
Re: Programming is more like:
by herveus (Prior) on Sep 10, 2008 at 11:06 UTC

    Cowboy Neal

Re: Programming is more like:
by fernandes (Monk) on Sep 11, 2008 at 21:52 UTC
    Sculpting because I need to have an initial idea of final product. Once started the work, I need touch it several times and in several positions. I need to see the problem from several angles, and smell it.
    This is just a shared felling...

      Do you never cut off too much?
      With sculpting wood and stone, it is hard to put it back on.
      With clay however, your creativity should know no bounds.

        Is more like hacking.

View List Of Past Polls

Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (2)
As of 2023-09-30 16:40 GMT
Find Nodes?
    Voting Booth?

    No recent polls found