Re: Resistance to switching software

Discussion in 'C Programming' started by Alf P. Steinbach, Oct 3, 2005.

  1. * Laurie Fineman:
    >
    > As old timers will recall, back in the '80s and somewhat into the
    > '90s there was a long-running, heated debate over which language
    > was best among the two most popular: Basic or Pascal.


    Ah, multiply cross-posted trolling! That's good -- good, good, good! --
    if it can increase the traffic in the [comp.human-factors] group!

    But the debate wasn't about Basic versus Pascal, it was about Pascal versus C,
    e.g. <url: http://www.lysator.liu.se/c/bwk-on-pascal.html> (Brian Kernighan on
    why Pascal certainly isn't his favorite language), and in addition there was a
    non-debate over the issue over whether Basic was a programming language or
    not, at all, e.g. Edsger Dijkstra "It is practically impossible to teach good
    programming to students that have had a prior exposure to BASIC: as potential
    programmers they are mentally mutilated beyond hope of regeneration.", <url:
    http://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html>.

    Btw., "human factors" refers to how humans interact with computers and
    possibly other things, it doesn't refer to the human condition. ;-)


    > ...
    > As a software developer, the same seems true of app software. My
    > #1 marketing problem is getting people to try something new once
    > they have learned to use their existing software. Nobody wants to
    > learn to do most of the same things differently, but most
    > operators don't seem to want to admit that. Some do, and some
    > have good arguments due to their superior "at application"
    > perspective, but I also get arguments that seem rather trivial or
    > don't make much sense.
    >
    > In both cases, I think it is obvious that this is one reason
    > software marketers give students, etc. incentives to use a
    > product - the developers know that once they learn a certain
    > language or application, it tends to become "the best."
    >
    > Has anyone else experienced this? I wonder what legitimate
    > techniques work to get people to switch software? Also, when is
    > this justified? Of course there is a productivity loss while
    > learning a new product, and a developer can hardly be objective
    > in thinking their own product is better.


    CP/M, MS-DOS and Windows spring to mind as examples, although not of
    application software.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Oct 3, 2005
    #1
    1. Advertising

  2. [OT] Re: Resistance to switching software

    Alf P. Steinbach wrote:
    > * Laurie Fineman:
    > >
    > > As old timers will recall, back in the '80s and somewhat into the
    > > '90s there was a long-running, heated debate over which language
    > > was best among the two most popular: Basic or Pascal.

    >
    > Ah, multiply cross-posted trolling! That's good -- good, good, good! --
    > if it can increase the traffic in the [comp.human-factors] group!



    <snip>

    I thought from the title ("Resistance to switching software") this was
    going to be a telecommunications post!


    --
    Nick Keighley

    A coding theorist is someone who doesn't think Alice is crazy.
    Nick Keighley, Oct 3, 2005
    #2
    1. Advertising

  3. Alf P. Steinbach

    rhnlogic Guest

    Alf P. Steinbach wrote:
    > But the debate wasn't about Basic versus Pascal,
    > it was about Pascal versus C,


    Depends on which debate about which point in computer history.

    Before "teaching languages" there were debates between teaching
    Fortran, Cobol or assembly. Then, when the first teaching
    languages appeared, I remember some schools trying to choose
    between either Basic or Pascal. C didn't really join the mix
    until after Unix started to become deployed widely outside of
    AT&T and UC Berkeley. Some colleges also offered APL as an
    introductory programming language.

    As for a preference for using a known language, some cognitive
    illusion seems to cause programmers to underestimate how long
    it would take to accomplish a task using a known language or
    development system, and overestimate how long it would take to
    become equally competent in a new language or system. However,
    it seems that the converse error in estimation, usually
    attributed to a management decision, can occasionally result
    in even larger engineering disasters.

    I learned Fortran first, then C; but have a preference for Basic
    as a teaching language because it doesn't hide the dirty details
    of the actual compute engine behind too much abstraction. In my
    opinion, structure and other good programming practices should be
    taught separately from the introductory programming language, and
    not just "hidden" within a language definition or implementation.


    IMHO. YMMV.
    --
    Ron
    http://www.nicholson.com/rhn/basic
    rhnlogic, Oct 3, 2005
    #3
  4. Alf P. Steinbach

    Skarmander Guest

    Followups to comp.lang.basic.misc.

    rhnlogic wrote:
    <snip>
    > I learned Fortran first, then C; but have a preference for Basic
    > as a teaching language because it doesn't hide the dirty details
    > of the actual compute engine behind too much abstraction.


    What? That's the world turned upside down. Just because the most
    primitive versions of Basic only offer GOTO and maybe FOR-NEXT as a
    means of changing control flow doesn't mean it's not hiding anything,
    let alone not offering tons of abstraction.

    On the contrary, most versions of Basic I've seen hardly care what types
    your variables have (but *will* use types), will gladly convert between
    integers and floating-point values (and strings, in extreme cases) and
    do all sorts of other high-level stuff you have to ask for in most
    languages and certainly won't get for free on most real-world computers
    (or theoretical ones, for that matter).

    You want programming without dirty details hidden? Use some abstract
    assembly language. Knuth's MIX and MMIX architectures spring to mind.
    Unless you really just want to get filthy, then you can use an actual
    architecture. I recommend the Intel 8086, since everybody loves
    segments. :)

    > In my opinion, structure and other good programming practices should
    > be taught separately from the introductory programming language, and
    > not just "hidden" within a language definition or implementation.
    >
    >

    Problem is, how can you teach good programming practices without knowing
    what programming is? How can you learn what programming is without a
    language, even a highly idealized one? How do you know what programming
    practices transcend languages if you don't know any, or just one?

    There are, for starters, tons of bad programming practices you can
    acquire in Basic. But learning how to avoid them doesn't make you a
    better programmer -- it just makes you a better Basic programmer. Other
    languages may not even offer you the opportunity for making avoidable
    mistakes, and good for them, too. They may offer you abstractions Basic
    cannot even implement effectively, and won't help you understand.

    There *are* general principles you can learn and subsequently apply to
    whatever language you're working in. But trying to work them out in
    either a void or one language, with all its idiosyncrasies, seems
    hopeless to me. Basic may win out only because there never was one
    Basic, so just about any pseudo-language that's sufficiently abstract
    looks like Basic. Doesn't mean the ability to actually execute your
    programs that comes with using a "real" language like that is a bonus.

    > IMHO. YMMV.


    I'll say. Don't get me wrong, I'm not knocking Basic here. I grew up on
    that, and contrary to what Dijkstra would have you believe, I survived. :)

    S.
    Skarmander, Oct 4, 2005
    #4
  5. Alf P. Steinbach

    Nameless Guest

    "rhnlogic" wrote in message
    news:...
    > [snipped]
    > In my opinion, structure and other good programming practices
    > should be taught separately from the introductory programming
    > language, and not just "hidden" within a language definition
    > or implementation.


    There's a lot of sense in what you say here. Gone are the
    days when students were instructed to write conceptual
    outlines as a prerequisite to writing code in any language.
    A conceptual outline will necessarily involve structure and
    in many cases highlight the need for good, well-defined
    programming practices, such as splitting tasks into smaller
    self-contained ones.

    A conceptual outline is "language-free" insomuch that it
    may be used as the basis for programming in the language of
    one's choice. It follows that a conceptual outline is not
    pseudocode which, because of its imperative form, may
    (inadvertently) bind one to a specific programming paradigm
    or methodology.

    --
    Mail sent to this email address is deleted unread
    on the server. Please send replies to the newsgroup.
    Nameless, Oct 4, 2005
    #5
  6. In article <u_q0f.779$as3.399@amstwist00>,
    "Nameless" <> wrote:

    > Gone are the days when students were instructed to write conceptual outlines
    > as a prerequisite to writing code in any language.
    > A conceptual outline will necessarily involve structure and in many cases
    > highlight the need for good, well-defined programming practices, such as
    > splitting tasks into smaller self-contained ones.


    As long as one does not automatically generate code from the model, I
    would think that the Unified Modeling Language (UML; see
    <http://en.wikipedia.org/wiki/Unified_Modeling_Language>) takes that
    outline role.

    Reinder
    Reinder Verlinde, Oct 4, 2005
    #6
  7. Alf P. Steinbach

    Flash Gordon Guest

    Reinder Verlinde wrote:
    > In article <u_q0f.779$as3.399@amstwist00>,
    > "Nameless" <> wrote:
    >
    >>Gone are the days when students were instructed to write conceptual outlines
    >>as a prerequisite to writing code in any language.
    >>A conceptual outline will necessarily involve structure and in many cases
    >>highlight the need for good, well-defined programming practices, such as
    >>splitting tasks into smaller self-contained ones.

    >
    > As long as one does not automatically generate code from the model, I
    > would think that the Unified Modeling Language (UML; see
    > <http://en.wikipedia.org/wiki/Unified_Modeling_Language>) takes that
    > outline role.


    Although this is good stuff it is *not* topical on comp.lang.c (I don't
    know about the other groups. Here on comp.lang.c we deal with C language
    issues, not general programming design or algorithm issues.

    I'm redirecting follow ups to exclude comp.lang.c, please honour this
    for further discussion of this topic.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Oct 4, 2005
    #7
  8. Alf P. Steinbach

    Nameless Guest

    "Reinder Verlinde" wrote in message
    news:...
    > In article <u_q0f.779$as3.399@amstwist00>,
    > "Nameless" <> wrote:
    >
    >> Gone are the days when students were instructed to write
    >> conceptual outlines as a prerequisite to writing code in any
    >> language. A conceptual outline will necessarily involve
    >> structure and in many cases highlight the need for good,
    >> well-defined programming practices, such as splitting tasks
    >> into smaller self-contained ones.

    >
    > As long as one does not automatically generate code from the
    > model, I would think that the Unified Modeling Language (UML;
    > see <http://en.wikipedia.org/wiki/Unified_Modeling_Language>)
    > takes that outline role.


    No, the UML binds one to a specific methodology. Besides,
    as a language it is known to have a steep learning curve
    which may not be appropriate in the actual teaching
    environment. Far better to use natural language such that
    students may concentrate on the task at hand.

    I urge you to reread the last paragraph of my prior message,
    which you have omitted, it is implicit on this matter. ;)

    --
    Mail sent to this email address is deleted unread
    on the server. Please send replies to the newsgroup.
    Nameless, Oct 4, 2005
    #8
  9. Alf P. Steinbach

    swansnow Guest

    Hmmm, If I may chime in as a programmer, and former teacher...

    For teaching, it depends on the age of the learner. For little kids
    (<9yo), Logo wins, hands down - minimal syntax, graphical environment,
    makes numbers concrete, requires problem-solving even at the very
    beginning. Logo is a real language, a variant of Lisp (which is a
    functional language, not imperative like BASIC).

    For Older kids, I would start with an emphasis on problem solving. As a
    consequence, I'd use a very easy language like Perl or Python (some
    people use Scheme, Alice, or other "teaching" languages). I would
    choose Perl or Python because they are real languages, but their basic
    syntax and usage is intuitive. Python in particular encourages
    structure (or so I hear, I'm thinking about learning it, so I know only
    a bit about it).

    Only after a student understands how to solve problems, and understands
    how to think algorithmically, and understands the concepts of
    repitition, and abstraction, *then* would I introduce a more
    complicated language like Java.

    Our family homeschools, and this is the general course I think I'll do
    with my kids, depending on interest and aptitude. We're just starting
    on Logo now.

    -Corinna
    swansnow, Oct 4, 2005
    #9
  10. In article <u_q0f.779$as3.399@amstwist00>,
    "Nameless" <> wrote:

    > Gone are the days when students were instructed to write
    > conceptual outlines as a prerequisite to writing code in any
    > language. A conceptual outline will necessarily involve
    > structure and in many cases highlight the need for good,
    > well-defined programming practices, such as splitting tasks
    > into smaller self-contained ones.


    I replied in article
    <news:>:

    RV> As long as one does not automatically generate code from the
    RV> model, I would think that the Unified Modeling Language (UML;
    RV> see <http://en.wikipedia.org/wiki/Unified_Modeling_Language>)
    RV> takes that outline role.

    In article <DPu0f.793$as3.73@amstwist00>, "Nameless"
    <> replied:

    > No, the UML binds one to a specific methodology. Besides,
    > as a language it is known to have a steep learning curve
    > which may not be appropriate in the actual teaching
    > environment. Far better to use natural language such that
    > students may concentrate on the task at hand.
    >
    > I urge you to reread the last paragraph of my prior message,
    > which you have omitted, it is implicit on this matter. ;)


    That paragraph reads:

    > A conceptual outline is "language-free" insomuch that it
    > may be used as the basis for programming in the language of
    > one's choice. It follows that a conceptual outline is not
    > pseudocode which, because of its imperative form, may
    > (inadvertently) bind one to a specific programming paradigm
    > or methodology.


    Can you give a concrete example of such a conceptual outline that would
    be useful in learning people what programming is?

    I have trouble visualizing anything that does not also include some
    choice of programming methodology (e.g. 'object-oriented', 'functional',
    'data-flow')

    I think any concrete-enough introduction to programming must make some
    methodology choice. And yes, UML is complex, but so is English. You do
    not need to learn all of UML in order to 'talk' it.

    One disadvantage of choosing UML would be that, although it claims to be
    universal over all methodologies, UML is best geared towards O-O
    development.

    Reinder
    Reinder Verlinde, Oct 4, 2005
    #10
  11. Followups restricted to comp.human-factors. This is probably OT there,
    but it's wildly OT in all the other groups to which it's been posted.
    The OP needs to attend remedial Usenet classes.

    In article <>, "swansnow" <> writes:
    >
    > For Older kids, I would start with an emphasis on problem solving. As a
    > consequence, I'd use a very easy language like Perl or Python (some
    > people use Scheme, Alice, or other "teaching" languages). I would
    > choose Perl or Python because they are real languages, but their basic
    > syntax and usage is intuitive.


    Indeed, what could be more intuitive than:

    #! /usr/bin/perl
    open (OUT, ">outfile") || die "can't open outfile\n";
    while (<>)
    {
    @lexitems = split /([<>])/;
    foreach $lexitem (@lexitems)
    {
    if (! $list{$lexitem})
    {
    print OUT $lexitem;
    $list{$lexitem} = 1;
    }
    }
    }

    And that's a very simple (and not very useful) Perl program; and
    while I rarely use Perl, I don't see any particularly non-idiomatic
    constructions there.

    Perl may be easy for beginners. It may serve well as a teaching
    language. But I don't see any evidence that it's in any way
    "intuitive" for beginning programmers. "Intuitive" is generally
    shorthand for "corresponding in a relatively apparent manner to
    something familiar", and I doubt many non-programmers are familiar
    with Perl's freewheeling and idiosyncratic use of punctuation marks,
    for example.

    In any event, I suspect "intuitive" is a false benefit in a
    programming language. COBOL was designed to be intuitive by
    mimicking English syntax (and to a much lesser extent semantics) and
    by attempting to model what was then considered good programming
    practice (eg by requiring a definition of data structures up front).
    While there are still defenders of COBOL, and it's still widely used
    (which is nice, since it butters my bread), few people are prepared
    to advocate for it as a teaching language. More tellingly, if you
    read comp.lang.cobol or similar forums, you'll see that COBOL
    professionals rarely put much effort into making their code
    "intuitive" or striving to imitate natural language with it. They
    use constructions that are comfortable and efficient in COBOL - in
    other words, idiomatic ones.

    Programming is not a matter of mimicking writing instructions for
    people, or mathematics, or other human activities, any more than
    carpentry or litigation are. It's a problem domain in its own
    right, and while there are certainly deep and important connections
    to other problem domains, I don't believe that the way to learn to
    program is by pretending it's something else.

    Thus programming languages should seek to be useful as programming
    languages first, and not to appeal to some other need. A hammer
    may serve the purpose of a stone; that doesn't mean it should be
    designed to be used as in the same manner as a stone.

    (Frankly, I'm not particularly persuaded by arguments that software
    in general should be "intuitive", either. But that's another
    matter.)

    --
    Michael Wojcik

    Unlikely prediction o' the day:
    Eventually, every programmer will have to write a Java or distributed
    object program.
    -- Orfali and Harkey, _Client / Server Programming with Java and CORBA_
    Michael Wojcik, Oct 4, 2005
    #11
  12. Alf P. Steinbach

    Nameless Guest

    "Reinder Verlinde" wrote in message
    news:...
    > In article <u_q0f.779$as3.399@amstwist00>,
    > "Nameless" <> wrote:
    >
    >> Gone are the days when students were instructed to write
    >> conceptual outlines as a prerequisite to writing code in any
    >> language. A conceptual outline will necessarily involve
    >> structure and in many cases highlight the need for good,
    >> well-defined programming practices, such as splitting tasks
    >> into smaller self-contained ones.

    >
    > I replied in article
    > <news:>:
    >
    > RV> As long as one does not automatically generate code from the
    > RV> model, I would think that the Unified Modeling Language (UML;
    > RV> see <http://en.wikipedia.org/wiki/Unified_Modeling_Language>)
    > RV> takes that outline role.
    >
    > In article <DPu0f.793$as3.73@amstwist00>, "Nameless"
    > <> replied:
    >
    >> No, the UML binds one to a specific methodology. Besides,
    >> as a language it is known to have a steep learning curve
    >> which may not be appropriate in the actual teaching
    >> environment. Far better to use natural language such that
    >> students may concentrate on the task at hand.
    >>
    >> I urge you to reread the last paragraph of my prior message,
    >> which you have omitted, it is implicit on this matter. ;)

    >
    > That paragraph reads:
    >
    >> A conceptual outline is "language-free" insomuch that it
    >> may be used as the basis for programming in the language of
    >> one's choice. It follows that a conceptual outline is not
    >> pseudocode which, because of its imperative form, may
    >> (inadvertently) bind one to a specific programming paradigm
    >> or methodology.

    >
    > Can you give a concrete example of such a conceptual outline
    > that would be useful in learning people what programming is?


    No, that would require a presentation far beyond that which
    would be desirable or possible in a newsgroup message. Hmmm,
    this might be a good theme for a website; I'll notify the
    newsgroup(s) when it is up and running. ;)

    > I have trouble visualizing anything that does not also include
    > some choice of programming methodology (e.g. 'object-oriented',
    > 'functional', 'data-flow')
    >
    > I think any concrete-enough introduction to programming must
    > make some methodology choice.


    Well, you certainly shouldn't avoid concretizing the subject
    matter under way, preferably with examples from different
    paradigms and methodologies. But the onus should remain on
    problem solving techniques, in particular the breakdown of
    a proposed (small) system into its constituent parts and
    *why* it should be so constructed.

    That said, if you are running a course on, say, Pascal, then
    it would be rather pointless rambling on about Haskel or ML.

    > And yes, UML is complex, but so is English. You do
    > not need to learn all of UML in order to 'talk' it.


    The difference is that young potential programmers already
    have a number of years behind them with their mother tongue.
    Therefore, no distractions from the matter at hand. Students
    may well learn industrial system modelling techniques at a
    later time; they will feel more comfortable and be better
    prepared by first learning how to write conceptual outlines.

    > One disadvantage of choosing UML would be that, although it
    > claims to be universal over all methodologies, UML is best
    > geared towards O-O development.


    Indeed, the Wiki article you mentioned explicity states that
    it is related to OO-software development. UML emerged and
    grew out of such development needs. But yes, UML does claim
    to be a lot of things, often too much, which easily leads to
    disorientation within the system.

    --
    Mail sent to this email address is deleted unread
    on the server. Please send replies to the newsgroup.
    Nameless, Oct 5, 2005
    #12
  13. Then Michael Wojcik says:
    >
    >Followups restricted to comp.human-factors. This is probably OT there,


    Nope. Read thread title - group title.

    >but it's wildly OT in all the other groups to which it's been posted.
    >The OP needs to attend remedial Usenet classes.


    The OP, me, posted a question about the difficulty of getting
    people to switch software with the prime example the old Basic v.
    Pascal debate. No mention of C. The groups were:

    comp.human-factors
    comp.lang.basic.misc
    comp.lang.pascal.delphi.misc

    If that ain't right then it's a charter agenda. Not my problem
    to solve.

    The 2nd poster in the thread:

    (Alf P. Steinbach)

    Changed groups to:

    comp.human-factors
    comp.lang.basic.misc
    comp.lang.pascal.delphi
    misc,comp.lang.c

    Therein lies your problem. S/he also called *my* post a
    troll.

    I replied switching *back* to the originals. Other's didn't.
    Laurie Fineman, Oct 5, 2005
    #13
  14. Resistance to switching programming language (Was: Resistance to switching software)

    "Nameless" <> writes:

    > A conceptual outline will necessarily involve structure and in many
    > cases highlight the need for good, well-defined programming
    > practices, such as splitting tasks into smaller self-contained ones.


    Yes. But the structure of that conceptual outline is likely to
    reflect your programming experience, and thus the programming
    languages you are used to.

    I can at least see that effect in my own work, where I have a strong
    tendency to formulate a problem in terms of types. - Something that
    definitely seems to be more typical for my "de facto language", Ada,
    than of languages with more relaxed type systems or non-procedural
    languages.

    > A conceptual outline is "language-free" insomuch that it may be used
    > as the basis for programming in the language of one's choice.


    Yes. But the conceptual outline written by a Prolog programmer is
    likely to be dramatically different from that written by a C or Ada
    programmer.

    > It follows that a conceptual outline is not pseudocode which,
    > because of its imperative form, may (inadvertently) bind one to a
    > specific programming paradigm or methodology.


    Although I try not to generate pseudocode, when I sketch the outline
    of a problem, but I still find that I tend to think in terms of my
    programming habits.

    Jacob
    --
    <URL: small-talk://work/hallway-meeting/...>
    Jacob Sparre Andersen, Oct 5, 2005
    #14
  15. Alf P. Steinbach

    Flash Gordon Guest

    Laurie Fineman wrote:

    > The OP, me, posted a question about the difficulty of getting
    > people to switch software with the prime example the old Basic v.
    > Pascal debate. No mention of C. The groups were:
    >
    > comp.human-factors
    > comp.lang.basic.misc
    > comp.lang.pascal.delphi.misc
    >
    > If that ain't right then it's a charter agenda. Not my problem
    > to solve.


    <snip others changing group list>

    It is *still* not topical on comp.lang.c and that is not *our* problem.
    Please EVERYONE take comp.lang.c off the list except for any discussion
    of what is topical, topicality always being on topic. I have already
    posted one polite request for people to do this.

    Here on comp.lang.c we discuss programming in standard C, we don't
    discus design (except peripherally), algorithms (except peripherally),
    system specifics, the merits of other languages or anything else that is
    being discussed in this thread.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Oct 5, 2005
    #15
  16. In article <>, "Laurie Fineman" <> writes:
    > Then Michael Wojcik says:
    > >
    > >Followups restricted to comp.human-factors. This is probably OT there,

    >
    > Nope. Read thread title - group title.


    I think it's debatable, but perhaps "probably" was too strong.

    > >but it's wildly OT in all the other groups to which it's been posted.
    > >The OP needs to attend remedial Usenet classes.

    >
    > The OP, me, posted a question about the difficulty of getting
    > people to switch software with the prime example the old Basic v.
    > Pascal debate.


    I'd still consider that excessive crossposting, and I'd consider it
    OT for comp.lang.basic.misc (it's at best tangentially related to
    BASIC as a language) and comp.lang.pascal.delphi.misc (the connection
    to Delphi is extremely tenuous). The BASIC/Pascal debate would be
    on-topic in, say, alt.folklore.computers.

    > No mention of C. The groups were:
    >
    > comp.human-factors
    > comp.lang.basic.misc
    > comp.lang.pascal.delphi.misc
    >
    > If that ain't right then it's a charter agenda. Not my problem
    > to solve.


    It's your problem as a responsible Usenet user to post only to groups
    where your message is topical, and to eschew excessive crossposting.
    That certain behaviors are mandated by law or custom does not relieve
    someone of responsibility for practicing them.

    > The 2nd poster in the thread:
    >
    > (Alf P. Steinbach)
    >
    > Changed groups to:
    >
    > comp.human-factors
    > comp.lang.basic.misc
    > comp.lang.pascal.delphi
    > misc,comp.lang.c
    >
    > Therein lies your problem.


    Right you are, and my apologies for not checking the original post
    to confirm which groups it was originally posted to. Alf's the
    real culprit. (No surprise there; he's hardly the most courteous
    Usenet denizen.)

    --
    Michael Wojcik

    O sometimes, nevertheless,
    The labourer at his instrument or tractor,
    Bending into a state of merge with objects,
    Finds the same love that, from a machine of sex,
    Steps down as Venus to her invoker. -- George Barker
    Michael Wojcik, Oct 5, 2005
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    124
    Views:
    2,014
    Robert C. Martin
    Nov 12, 2005
  2. prospring
    Replies:
    0
    Views:
    609
    prospring
    Nov 23, 2005
  3. Caleb

    Wind Resistance

    Caleb, Apr 10, 2007, in forum: Java
    Replies:
    7
    Views:
    553
    Christian
    Apr 10, 2007
  4. John
    Replies:
    0
    Views:
    900
  5. John
    Replies:
    0
    Views:
    1,005
Loading...

Share This Page