Re: (and scheme lisp) x Python and modern langs [was Re: gossip, GuySteel, Lojban, Racket]

Discussion in 'Python' started by Xah Lee, Sep 27, 2010.

  1. Xah Lee

    Xah Lee Guest

    2010-09-27

    > For instance, this is far more convenient:


    > [x+1 for x in [1,2,3,4,5] if x%2==0]


    > than this:


    > map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))


    How about this:

    LC(func, inputList, P)

    compared to

    [func for myVar in inputList if P]

    the functional form is:

    • shorter
    • not another idiysyncratic new syntax

    --------------------

    now, a separate issue. Suppose we want some “list comprehensionâ€
    feature in a functional lang.
    Normally, by default this can be done by

    filter( map(func, inputList), Predicate)

    but perhaps this usage is so frequent that we want to create a new
    fuction for it, to make it more convenient, and perhaps easier to make
    the compiler to optimize more. e.g.

    LC(func, inputList, Predicate)

    this is about whether a lang should create a new convenient function
    that otherwise require 2 function combinations. Common Lisp vs Scheme
    Lisp are the typical example of extreme opposites.

    note, there's no new syntax involved.

    --------------------

    Now, let's consider another separated issue related to so-called “list
    comprehensionâ€.
    Suppose we decided that generating list by a filter is so frequently
    used that it worth it to create a new func for it.

    LC(func, inputList, Predicate)

    Now, in functional langs, in general a design principle is that you
    want to reduce the number of function unless you really need. Because,
    any combination of list related functions could potentionally be a new
    function in your lang. So, if we really think LC is useful, we might
    want to generalize it. e.g. in

    LC(func, inputList, Predicate)

    is it worthwhile say to add a 4th param, that says return just the
    first n? (here we presume the lang doesn't support list of infinite
    elements) e.g.

    LC(func, inputList, Predicate, n)

    what about partition the list to m sublists?

    LC(func, inputList, Predicate, n, m)

    what about actualy more generalized partition, by m sublist then by m1
    sublist then by m2 sublist?

    LC(func, inputList, Predicate, n, list(m,m1,m2,...))

    what about sorting? maybe that's always used together when you need a
    list?

    LC(func, inputList, Predicate, n, list(m,m1,m2,...), sortPredcate)

    what if actually frequently we want LC to map parallel to branches?
    e.g.

    LC(func, inputList, Predicate, n, list(m,m1,m2,...), sortPredcate,
    mapBranch:True)

    what if ...

    you see, each of these or combination of these can be done by default
    in the lang by sequenceing one or more functions (i.e. composition).
    But when we create a new function, we really should think a lot about
    its justification, because otherwise the lang becomes a bag of
    functions that are non-essential, confusing.

    In summary:

    • “list comprehension†is a bad jargon.

    • The concept of “list comprehension†is redundant. There's no
    justification for the concept to exist except historical.

    • The syntax of “list comprehension†in most lang is ad hoc syntax.

    for those who find imperative lang good, then perhaps “list
    comprehension†is good, because it adds another idiosyncratic syntax
    to the lang, but such is with the tradition of imperative langs. The
    ad hoc syntax aids in reading code by various syntactical forms and
    hint words such as “[... for ... in ...]â€.

    Xah ∑ xahlee.org ☄
     
    Xah Lee, Sep 27, 2010
    #1
    1. Advertising

  2. Xah Lee

    namekuseijin Guest

    On 27 set, 16:06, Xah Lee <> wrote:
    > 2010-09-27
    >
    > > For instance, this is far more convenient:
    > > [x+1 for x in [1,2,3,4,5] if x%2==0]
    > > than this:
    > > map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))

    >
    > How about this:

    [snip]

    how about this: read before replying.
     
    namekuseijin, Sep 27, 2010
    #2
    1. Advertising

  3. Xah Lee

    Xah Lee Guest

    On Sep 27, 12:11 pm, namekuseijin <> wrote:
    > On 27 set, 16:06, Xah Lee <> wrote:> 2010-09-27
    >
    > > > For instance, this is far more convenient:
    > > > [x+1 for x in [1,2,3,4,5] if x%2==0]
    > > > than this:
    > > > map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))

    >
    > > How about this:

    >
    > [snip]
    >
    > how about this:  read before replying.


    hum???

    i read your post quite carefully, and rather thought i replied well.
    In fact, i really wanted to tell you “read before replying” before but
    refrained from making any of that expression.

    here's 2 previous posts about list compre.
    http://groups.google.com/group/comp.lang.lisp/msg/145f6ecf29ebbdaf
    http://groups.google.com/group/comp.lang.lisp/msg/62ca84062c9fcdca

    Xah
     
    Xah Lee, Sep 27, 2010
    #3
  4. Xah Lee

    namekuseijin Guest

    On 27 set, 18:39, Xah Lee <> wrote:
    > On Sep 27, 12:11 pm, namekuseijin <> wrote:
    >
    > > On 27 set, 16:06, Xah Lee <> wrote:> 2010-09-27

    >
    > > > > For instance, this is far more convenient:
    > > > > [x+1 for x in [1,2,3,4,5] if x%2==0]
    > > > > than this:
    > > > > map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))

    >
    > > > How about this:

    >
    > > [snip]

    >
    > > how about this:  read before replying.

    >
    > hum???
    >
    > i read your post quite carefully, and rather thought i replied well.


    I don't think so. You completely missed the point where I agreed
    about filter map being more convenient when calling predefined
    functions and also the detailed explanation of why do in scheme is not
    imperative at all.
     
    namekuseijin, Sep 28, 2010
    #4
  5. Xah Lee

    Xah Lee Guest

    xah wrote:
    > in anycase, how's “do†not imperative?


    On Sep 28, 6:27 am, namekuseijin <> wrote:
    > > how's “do†a “named let� can you show example or reference of that
    > > proposal? (is it worthwhile?)

    >
    > I'll post it again in the hope you'll read this time:
    >
    > "
    > (do ((i 0 (+ 1 i))  ; i initially 1, (+ 1 i) at each "step"
    >      (r 0 (+ i r))) ; r initially 0, (+ i r) at each "step"
    >   ((> i 5) r))      ; when i>5, return r
    > => 15
    >
    > it's merely a macro (syntax) that gets transformed into this:
    > (let loop ((i 0)
    >            (r 0))
    >   (if (> i 5) r
    >     (loop (+ 1 i) (+ i r))))
    > => 15
    >
    > which is merely a macro that essentially gets transformed into this:
    > ((lambda (loop)
    >    (loop loop 0 0))
    >  (lambda (loop i r)
    >    (if (> i 5) r
    >        (loop loop (+ 1 i) (+ i r)))))
    > => 15
    >
    > which, as you can see, is merely function application.  There's
    > nothing there except evaluation of arguments, application of arguments
    > to function and function return.  It's not because they chose `do', or
    > `for' or `while' for naming such syntax, that it behaves the same as
    > their imperative homographs."
    >
    > > as i said, regarding do: “do†in general in any lang is simply
    > > impreative. We don't even have to know the details. I don't care
    > > whatnot **** proposal from whatnot lisp of what's actually going on.
    > > If it is named “doâ€, it is imperative.

    >
    > It's not:  one can name factorial do.  It's just a name.  Who doesn't
    > like do?  It's short, to the point...


    ultimately, all lang gets transformed at the compiler level to become
    machine instructions, which is imperative programing in the ultimate
    sense.

    You say that “do†is merely macro and ultimately function application.
    But to what level should we go down this chain on how the language
    actually works when evaluating a function in source code?

    any functional lang, quickly becomes imperative when compiled to some
    intermediate code or interpreted. In a sense, it can't be any other
    way. Functions are abstract mathematical ideas, while “do†loop or any
    instruction are actual steps of algorithms.

    Xah ∑ xahlee.org ☄
     
    Xah Lee, Sep 28, 2010
    #5
  6. Xah Lee

    Xah Lee Guest

    2010-09-28

    On Sep 28, 12:07 pm, namekuseijin <> wrote:
    > On 28 set, 14:56, Xah Lee <> wrote:
    >
    > > ultimately, all lang gets transformed at the compiler level to become
    > > machine instructions, which is imperative programing in the ultimate
    > > sense.

    >
    > > You say that “do†is merely macro and ultimately function application.
    > > But to what level should we go down this chain on how the language
    > > actually works when evaluating a function in source code?

    >
    > > any functional lang, quickly becomes imperative when compiled to some
    > > intermediate code or interpreted. In a sense, it can't be any other
    > > way. Functions are abstract mathematical ideas, while “do†loop or any
    > > instruction are actual steps of algorithms.

    >
    > That is true as of Mathematica too.  Difference being that do in
    > scheme is pretty-much user-level syntax.  If you look in most (good)
    > implementations sources, do and let are defined in scheme itself, not
    > C or lower-level:  C code only deals with transforming lambda
    > application and tail calls into proper gotos.
    >
    > So, as far as we're talking about scheme, haskell or Mathematica code,
    > it's all functional in its abstraction context.
    >
    > do syntax does allow for imperative commands to be issued in scheme,
    > just like let.  It does not mean it was used in said examples nor that
    > do is automatically inherently imperative just because of choice of
    > name.  imperative do -> (do (steppers ...) (final-condition? result)
    > malign-imperative-code-here ...)
    >
    > so, now that we got it clear why do in scheme is not (inherently)
    > imperative why were you bashing useful (at times) functional syntax in
    > the form of list comprehensions again?


    le's get precise. The argument i want to make, is this:

    • “list comprehension†is a very bad jargon; thus harmful to
    functional programing or programing in general. Being a bad jargon, it
    encourage mis-communication, mis-understanding.

    • “list comprehension†is a redundant concept in programing. The
    concept is of historical interest. e.g. when people talk about the
    history of computer languages. The LC can simply be filter(map(func,
    list), predicate).

    • The special syntax of “list comprehension†as it exists in many
    langs, are not necessary. It can simply be a plain function, e.g
    LC(function, list, filter).

    I gave a stand-alone explanation of these points at:
    http://groups.google.com/group/comp.lang.lisp/msg/329b3b68ff034453

    Do you disagree or agree with the above?

    This is the point _I_ want to argue about, but you don't seem to admit
    any part of it, but you seems to want to discuss about “do†in Scheme
    lisp being functional.

    So, perhaps we can now focus on this subject:

    The “do†in Scheme lisp is not imperative, or, it can be considered as
    functional.

    Alright. To be honest, i haven't had enough experience to comment on,
    but in general, i understand the example you've given, and i disagree.

    Full report on your argument on this is given at:
    http://groups.google.com/group/comp.lang.lisp/msg/87a987070e80231f

    Now, in your message (quoted above), you made further argument on
    this. I think the main point is this, quote:

    «do syntax does allow for imperative commands to be issued in scheme,
    just like let. It does not mean it was used in said examples nor that
    do is automatically inherently imperative just because of choice of
    name. imperative do -> (do (steppers ...) (final-condition? result)
    malign-imperative-code-here ...)»

    i don't think your argument is forceful enough.

    It appears that by this argument you even say that “let†is not
    functional.

    Here, the issue verges on what is functional? What is a function? If a
    function in lisp is defined as macro, does it ceases to be considered
    as a function? Likewise, if a lisp's has “for†loop that is defined as
    a macro, is that “for†now considered a function?

    this is getting quite iffy. What level or aspect are we considering?
    In each lang, usually they define certain terms specifically to the
    lang, and to various degree of precision. For eample, the term
    “object†means very different things in a technical way in different
    langs. Same for the word “functionâ€, “keywordâ€, “commandâ€, “moduleâ€,
    “package†...

    So, overall, i consider your argument for “do†in Scheme lisp being
    functional is weak, or trivial. It seems to be a pet peeve. You got
    annoyed because i seem to have ignored it entirely. But i got annoyed
    by you because you don't get the point about what i consider more
    significant opinion on “list comprehensionâ€, which you totally ignored
    and kept at hacking the “do†in Scheme lisp.

    Xah ∑ xahlee.org ☄
     
    Xah Lee, Sep 28, 2010
    #6
  7. Xah Lee

    namekuseijin Guest

    On 28 set, 19:38, Xah Lee <> wrote:
    > • “list comprehension” is a very bad jargon; thus harmful to
    > functional programing or programing in general. Being a bad jargon, it
    > encourage mis-communication, mis-understanding.


    I disagree: it is a quite intuitive term to describe what the
    expression does.

    > • “list comprehension” is a redundant concept in programing. The
    > concept is of historical interest. e.g. when people talk about the
    > history of computer languages. The LC can simply be filter(map(func,
    > list), predicate).


    I agree it is redundant. Like pretty much all syntax: all one needs
    is a way to define functions and to apply function to arguments (or
    assignment and pre-defined loops for imperative folks). Syntax may
    still be more convenient, though.

    Which is strange since you were an ardent syntax lover a few
    iterations ago.

    > • The special syntax of “list comprehension” as it exists in many
    > langs, are not necessary. It can simply be a plain function, e.g
    > LC(function, list, filter).


    I disagree. Syntax may be redundant, but it is there to be
    convenient.

    I'll quote it again:
    "For instance, this is far more convenient:
    [x+1 for x in [1,2,3,4,5] if x%2==0]
    than this:
    map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))

    but on the other hand, this is more convenient:
    map(inc,filter(evenp,[1,2,3,4,5]))

    (ignoring the lines of code for inc and evenp, of course. But as
    long
    as they are used in many parts, it *is* more convenient)

    In short, list comprehensions are useful syntatic expressions
    returning lists as long as you don't care for the short functions
    used
    in them."

    > «do syntax does allow for imperative commands to be issued in scheme,
    > just like let. It does not mean it was used in said examples nor that
    > do is automatically inherently imperative just because of choice of
    > name. imperative do -> (do (steppers ...) (final-condition? result)
    > malign-imperative-code-here ...)»
    >
    > i don't think your argument is forceful enough.
    >
    > It appears that by this argument you even say that “let” is not
    > functional.


    In the case of Lisps, it depends on context: let is an expression
    returning a value, but Lisps are not purely functional languages and
    you *may* use imperative statements in the body, resulting in useful
    side-effect computations.

    That's why I said do is no more imperative than let: 1) because it
    *is* let and 2) because Lisps *allow* imperative constructs in the
    body of lambdas. do is not inherently imperative in the same sense
    Lisp/Scheme is not inherently imperative: they allow you to do purely
    functional evaluation of expressions but also to tint the computations
    with side-effects... your choice.

    > So, overall, i consider your argument for “do” in Scheme lisp being
    > functional is weak, or trivial. It seems to be a pet peeve.


    It is a pet peeve in that you call `do' imperative without arguments
    while a few other Schemers call `do' imperative on the basis of
    political bickering. Nobody gives `do' a chance of the base of it
    being what it is: a macro transform into let. Any imperative
    programming you do with `do' will get the same effect as if you do the
    same imperative programming with let. Imperative or functional, it's
    up to the user, not inherently from any language construct.

    > You got
    > annoyed because i seem to have ignored it entirely. But i got annoyed
    > by you because you don't get the point about what i consider more
    > significant opinion on “list comprehension”, which you totally ignored
    > and kept at hacking the “do” in Scheme lisp.


    It's because I don't think I have much to comment on list
    comprehensions other than being useful syntax at times for an
    expression returning a list.
     
    namekuseijin, Sep 29, 2010
    #7
  8. Xah Lee

    Xah Lee Guest

    On Sep 29, 11:02 am, namekuseijin <> wrote:
    > On 28 set, 19:38, Xah Lee <> wrote:
    >
    > > • “list comprehension†is a very bad jargon; thus harmful to
    > > functional programing or programing in general. Being a bad jargon, it
    > > encourage mis-communication, mis-understanding.

    >
    > I disagree:  it is a quite intuitive term to describe what the
    > expression does.


    what's your basis in saying that “list comprehension†is intuitive?

    any statics, survery, research, references you have to cite?

    to put this in context, are you saying that lambda, is also intuitive?
    “let†is intuitive? “for†is intuitive? “when†is intuitive? I mean,
    give your evaluation of some common computer language termilogies, and
    tell us which you think are good and which are bad, so we have some
    context to judge your claim.

    For example, let us know, in your view, how good are terms: currying,
    lisp1 lisp2, tail recursion, closure, subroutine, command, object. Or,
    perhaps expound on the comparative merits and meaning on the terms
    module vs package vs add-on vs library. I would like to see your view
    on this with at least few paragraphs of analysis on each. If you, say,
    write a essay that's at least 1k words on this topic, then we all can
    make some judgement of your familiarity and understanding in this
    area.

    Also, “being intuitive†is not the only aspect to consider whether a
    term is good or bad. For example, emacs's uses the term “frameâ€. It's
    quite intuitive, because frame is a common english word, everyone
    understands. You know, door frame, window frame, picture frame, are
    all analogous to emacs's “frame†on a computer. However, by some turn
    of history, in computer software we call such as “window†now, and by
    happance the term “window†also has a technical meaning in emacs, what
    we call “split window†or “pane†today. So, in emacs, the term “frameâ€
    and “window†is confusing, because emacs's “frame†is what we call
    “windowâ€, while emacs's “window†is what me might call a pane of a
    split window. So here, is a example, that even when a term is
    intuitive, it can still be bad.

    as another example, common understanding by the target group the term
    is to be used is also a important aspect. For example, the term
    “lambdaâ€, which is a name of greek char, does not convey well what we
    use it for. The word's meaning by itself has no connection to the
    concept of function. The char happens to be used by a logician as a
    shorthand notation in his study of what's called “lambda
    calculus†(the “calculus†part is basically 1700's terminology for a
    systematic science, especially related to mechanical reasoning).
    However, the term “lambda†used in this way in computer science and
    programing has been long and wide, around 50 years in recent history
    (and more back if we trace origins). So, because of established use,
    here it may decrease the level of what we might think of it as a bad
    jargon, by the fact that it already become a standard usage or
    understanding. Even still, note that just because a term has establish
    use, if the term itself is very bad in many other aspects, it may
    still warrant a need for change. For one example of a reason, the
    argon will be a learning curve problem for all new generations.

    You see, when you judge a terminology, you have to consider many
    aspects. It is quite involved. When judging a jargon, some question
    you might ask are:

    • does the jargon convey its meaning by the word itself? (i.e. whether
    the jargon as a word is effective in communication)

    • how long has been the jargon in use?

    • do people in the community understand the jargon? (e.g. what
    percentage)

    each of these sample questions can get quite involved. For example, it
    calls for expertise in linguistics (many sub-fields are relevant:
    pragmatics, history of language, etymology), practical experience in
    the field (programing or computer science), educational expertise
    (e.g. educators, professors, programing book authors/teachers),
    scientific survey, social science of communication...

    also, you may not know, there are bodies of professional scientists
    who work on terminologies for publication. It is not something like “O
    think it's good, becus it is intuitive to me.â€.

    I wrote about 14 essays on various jargons in past decade. You can
    find them on my site.

    i removed your arguments on other parts about “list comprehensionâ€,
    because i didn't find them valuable. (barely read them) However, i
    appreciate your inputs on the “do†in Scheme lisp has a functional
    usage, and some other misc chat info from the beginning of this thread
    on comp.lang.lisp.

    Xah ∑ xahlee.org ☄
     
    Xah Lee, Sep 29, 2010
    #8
  9. Xah Lee

    namekuseijin Guest

    On 29 set, 17:46, Xah Lee <> wrote:
    > On Sep 29, 11:02 am, namekuseijin <> wrote:
    >
    > > On 28 set, 19:38, Xah Lee <> wrote:

    >
    > > > • “list comprehension” is a very bad jargon; thus harmful to
    > > > functional programing or programing in general. Being a bad jargon, it
    > > > encourage mis-communication, mis-understanding.

    >
    > > I disagree:  it is a quite intuitive term to describe what the
    > > expression does.

    >
    > what's your basis in saying that “list comprehension” is intuitive?


    it generates a list from syntax comprehended in list-like syntax!

    > any statics, survery, research, references you have to cite?


    how about common sense?

    > to put this in context, are you saying that lambda, is also intuitive?


    No.

    > “let” is intuitive?


    yes, it's focking everyday term used in the same way: let this be
    this and that be that and thus...

    > “for” is intuitive?


    yes, it's focking everyday term used in the same way: for this and
    this and this do that...

    > “when” is intuitive?


    when this, then that?

    common sense, Xah!

    > For example, let us know, in your view, how good are terms: currying,
    > lisp1 lisp2, tail recursion, closure, subroutine, command, object.


    These terms have a technical meaning coming from historic events in
    the areas they are used. It's like that in all areas, you may also
    bash medicine jargon if you want.

    Though subroutine, command and object are pretty intuitive by common
    sense alone.

    > perhaps expound on the comparative merits and meaning on the terms
    > module vs package vs add-on vs library. I would like to see your view
    > on this with at least few paragraphs of analysis on each.


    They are all the same shit. These were developed by managers and
    buzzwriters... ;)

    > Also, “being intuitive” is not the only aspect to consider whether a
    > term is good or bad. For example, emacs's uses the term “frame”. It's
    > quite intuitive, because frame is a common english word, everyone
    > understands. You know, door frame, window frame, picture frame, are
    > all analogous to emacs's “frame” on a computer. However, by some turn
    > of history, in computer software we call such as “window” now, and by
    > happance the term “window” also has a technical meaning in emacs, what
    > we call “split window” or “pane” today. So, in emacs, the term “frame”
    > and “window” is confusing, because emacs's “frame” is what we call
    > “window”, while emacs's “window” is what me might call a pane of a
    > split window. So here, is a example, that even when a term is
    > intuitive, it can still be bad.


    emacs is all FUBAR in more than one way. being intuitive is not
    exactly what it is known for... ;)

    well, I shouldn't be bashing it, my vim is not that funky among
    commoners anymore anyway... :p

    > I wrote about 14 essays on various jargons in past decade. You can
    > find them on my site.


    yeah, I've read them once in a while...
     
    namekuseijin, Sep 30, 2010
    #9
  10. Xah Lee

    Seebs Guest

    Re: (and scheme lisp) x Python and modern langs [was Re: gossip,Guy Steel, Lojban, Racket]

    On 2010-09-30, namekuseijin <> wrote:
    > it generates a list from syntax comprehended in list-like syntax!


    Okay, help me out here. (Killed the crossposting.)

    I am not understanding how the word applies. I'm fine with it, but I don't
    see any relation at all between the thing called a list comprehension and
    the word "comprehension" as I normally understand it.

    Who or what is doing the comprehending? Is this a sense of "comprehension"
    other than "to understand"? It seems like it's perhaps related to
    "comprehensive". However, I've never seen "comprehension" used to refer
    to anything other than understanding prior to encountering "list
    comprehensions".

    [... hmm. maybe time to go searching...]

    Looking around, it seems this is from mathematical jargon, to wit,
    "set comprehensions". Since I hadn't run into that jargon, I had no
    clue what the etymology was, and "comprehended" is not a verb I would
    ever have used with this. However, looking around, it appears that
    this usage also occurs in the same jargon; once you've got one of them
    the other follows.

    I guess the key, though, is that this is purely jargon, and jargon from
    another field -- not all programmers have done all mathematics. I even
    took a ton of bonus math in college, but happened not to have done anything
    where this terminology was used. So the usage is, pardon the pun,
    incomprehensible to me to begin with, and saying it's called a
    comprehension because it's comprehended doesn't help -- that's two forms
    of the same unfamiliar jargon.

    Of course, the jargon is pretty reasonable as such goes, in no small
    part because of the plain English sense of "comprehensive" in the
    sense of covering something completely, so it's not awful.

    But from where I'm coming, it would be every bit as obvious to call it
    a "list exhaustion", by analagous derivation from "exhaustive".

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Sep 30, 2010
    #10
    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:
    798
    Views:
    10,477
    Raffael Cavallaro
    Nov 1, 2003
  2. Mark Wilson

    Fwd: Python syntax in Lisp and Scheme

    Mark Wilson, Oct 4, 2003, in forum: Python
    Replies:
    0
    Views:
    282
    Mark Wilson
    Oct 4, 2003
  3. alisha alisha

    Gossip Protocol in Python

    alisha alisha, Nov 15, 2011, in forum: Python
    Replies:
    0
    Views:
    236
    alisha alisha
    Nov 15, 2011
  4. John Knight
    Replies:
    5
    Views:
    139
    Vincent Foley
    Aug 4, 2005
  5. Replies:
    13
    Views:
    191
    Kev Jackson
    Oct 26, 2005
Loading...

Share This Page