I'll have the duck!

Discussion in 'Ruby' started by transfire@gmail.com, Jul 24, 2006.

  1. Guest

    I promised myself I'd shut-up for awhile, maybe I still should, but I
    just couldn't help myself with this one...

    Today I wrote

    data = data.transform

    but I meant to write

    data = transform(data)

    While I knew data would be hash, I certainly didn't want to write a new
    Hash method just for this --you reserve extensions for really general
    reusable stuff, right? Besides I wanted to remain open to duck typing
    and hence any hash-like object.

    That's when it hit me. We haven't yet taken the full duck type plunge.
    We've just strapped a quasi-duck onto an old oop type dog. We're still
    defining our methods base on types, not duck types. But what would
    defining on duck type mean intead? As it turns out it measn defining on
    method dependencies.

    Take #transform. Forget what "class" it belongs to. What does it do?
    For the sake of this dialog lets say it does this:

    def transform
    data.to_a
    end

    Simple. Now, if I want to call #transform on data, all it needs to do
    is repond_to #to_a. It need not matter at all what class it is. So
    imagine if you will, that instead of "classes" and "methods", we could
    define "ducks" and "quacks".

    duck to_a
    quack transform
    self.to_a
    end
    end

    Now anything that responded to #to_a could use #transform. I'm not sure
    how far this can be taken. Can classes be undone altogegther? But in
    anycase, it seems very cool, and I wonder what kind of overall effect
    it could have on coding?

    T.
    , Jul 24, 2006
    #1
    1. Advertising

  2. John Carter Guest

    duck == mixin

    Consider the Enumerable mixin.



    John Carter Phone : (64)(3) 358 6639
    Tait Electronics Fax : (64)(3) 359 4632
    PO Box 1645 Christchurch Email :
    New Zealand

    Carter's Clarification of Murphy's Law.

    "Things only ever go right so that they may go more spectacularly wrong later."

    From this principle, all of life and physics may be deduced.
    John Carter, Jul 24, 2006
    #2
    1. Advertising

  3. I much prefer its (less mature) derivative, Io. Everything is a
    message to something else, and everything is a prototype. Very
    simple, very powerful (even, dare I say, more powerful than Ruby,
    albeit a bit less pretty).

    - Jake McArthur

    On Jul 23, 2006, at 9:45 PM, Ron Jeffries wrote:

    > On Mon, 24 Jul 2006 08:09:58 +0900, wrote:
    >
    >> Now anything that responded to #to_a could use #transform. I'm not
    >> sure
    >> how far this can be taken. Can classes be undone altogegther? But in
    >> anycase, it seems very cool, and I wonder what kind of overall effect
    >> it could have on coding?

    >
    > there's a language called "self" that has no classes, only
    > prototypes. if you
    > can find some material on that, i think you'll find it interesting.
    >
    > regards,
    >
    > --
    > Ron Jeffries
    > www.XProgramming.com
    > I'm giving the best advice I have. You get to decide if it's true
    > for you.
    >
    Jake McArthur, Jul 24, 2006
    #3
  4. Jake McArthur wrote:
    > I much prefer its (less mature) derivative, Io. Everything is a
    > message to something else, and everything is a prototype. Very simple,
    > very powerful (even, dare I say, more powerful than Ruby, albeit a bit
    > less pretty).
    >
    > - Jake McArthur

    Actual, real programming languages with compilers or interpreters, a
    code base, applications and vibrant communities are for wimps! Give me
    an academic abstract language like the Pi-Calculus any day!

    :)

    Now that I think of it, Lisp was once an academic abstract language ...
    some bozo had to spoil it by writing an interpreter for the IBM 704.

    Speaking of languages, isn't FORTRAN 50 years old this year?
    M. Edward (Ed) Borasky, Jul 24, 2006
    #4
  5. On Monday 24 July 2006 11:40, John Carter wrote:
    > duck =3D=3D mixin
    >
    > Consider the Enumerable mixin.
    >


    Well... i don't think mixins are exactly that :)
    what trans proposes is more like excessive duck-typing

    imagine a duck
    you can make it quack
    and you know - what the duck quacks can be processes in many ways...

    Duck.quack.record.to_tape.copy.to_cd.send_to producer

    might be a bit excessive, but in essential that's it...
    i've learned that kind of 'method' in Dylan, where you define that stuff a =
    bit=20
    different - you have a kind of reversed dispatcher that adds classes to=20
    methods and decides which method to use given what object you operate on.

    little syntax help - the stuff in <> are classes, <duck> and <fish> are=20
    subclasses of <animal>

    ########################################

    define method to-s (animal :: <animal>)
    =A0 color(animal)
    end

    define method color (duck :: <duck>)
    =A0 "brown"
    end

    define method color (fish :: <fish>)
    =A0 "grey"
    end

    ########################################

    the methods are not added to the object - they look like that afterwards:
    (using ruby for that, so it looks a bit nicer ;)

    def color (x)
    =A0 if x =3D=3D=3D Animal
    =A0 =A0 if x =3D=3D=3D Fish
    =A0 =A0 =A0 "grey"
    =A0 =A0 elsif x =3D=3D=3D Duck
    =A0 =A0 =A0 "brown"
    =A0 =A0 end
    =A0 end
    end =A0


    don't want to hang around in dylan for too long, but this was a new way (at=
    =20
    least for me) to express methods...
    now, this could be driven further

    you could attach methods to objects that respond to specific methods

    ########################################

    methods to_a
    =A0 def compact
    =A0 =A0 delete_if{|e| e.nil? }
    =A0 end

    =A0 def sum
    =A0 =A0 inject{|s,v| s+v}
    =A0 end
    end

    class Foo
    =A0 def to_a
    =A0 =A0 [1,2,3,nil]
    =A0 end
    end

    =46oo.new.compact.sum
    # 6

    ########################################

    something like that...
    i find that is true ducktyping :)
    however... the beauty is in the eye of the beholder, so it might look=20
    butt-ugly to someone else :|

    i just kinda like the idea itself - the implementation in ruby would be=20
    enormous work (as i imagine it at least) - and would slow down ruby=20
    further...

    these assumptions are just in my honest opinion :) might as well be pretty=
    =20
    neat to integrate and work with... but i have my doubts...

    >
    >
    > John Carter Phone : (64)(3) 358 6639
    > Tait Electronics Fax : (64)(3) 359 4632
    > PO Box 1645 Christchurch Email :
    > New Zealand
    >
    > Carter's Clarification of Murphy's Law.
    >
    > "Things only ever go right so that they may go more spectacularly wrong
    > later."
    >
    > From this principle, all of life and physics may be deduced.
    Michael Fellinger, Jul 24, 2006
    #5
  6. =20

    > From: [mailto:]=20
    > Sent: Monday, July 24, 2006 1:10 AM
    >=20
    > [...]
    > Now anything that responded to #to_a could use #transform.=20
    > I'm not sure
    > how far this can be taken. Can classes be undone altogegther? But in
    > anycase, it seems very cool, and I wonder what kind of overall effect
    > it could have on coding?
    >=20
    > T.


    Like this *evil grin* ? (Ok, there are still classes...)
    ------------------------------------------------------------------------
    ----
    class Object
    def method_missing sym, *args
    @@ducks.select{|d| d.first =3D=3D sym}.each do |duck|
    return send(duck[1], *args) if duck.last.all?{|i|
    respond_to? i}
    end
    super
    end
    =20
    def self.duck sym, real , *interface
    (@@ducks ||=3D []) << [sym, real, interface]
    end
    end

    def i_next_to_s
    succ.to_s
    end

    def f_next_to_s
    ceil.to_s
    end

    Object.duck :next_to_s, :i_next_to_s, :succ, :to_s
    Object.duck :next_to_s, :f_next_to_s, :ceil, :to_s

    p(41.next_to_s) #=3D> "42"
    p('A'.next_to_s) #=3D> "B"
    p(5.5.next_to_s) #=3D> "6"
    ------------------------------------------------------------------------
    ----

    cheers

    Simon
    Kroeger, Simon (ext), Jul 24, 2006
    #6
  7. Alex Young Guest

    Robert Dober wrote:
    > On 7/24/06, <> wrote:

    <snip>
    >> and hence any hash-like object.

    >
    > Yeah great, you see that is what troubles me, it is completely cool to talk
    > about hash-like object, but what is a hash-like object? Which messages
    > must
    > a hash-like object respond to? All of Hash, I suppose, thus a subclass, or
    > only some, then we can talk about protocols again, but the failure to be
    > able to define the protocol just worries me.

    That's the whole point. Duck-typing means that your class only needs to
    define the methods (of Hash, in this case) that the called method
    (transform here) needs, *not* the whole Hash class, *without* having to
    specify a protocol. If you want to specify a protocol, there's one
    example of how to do it here:

    http://www.erikveen.dds.nl/monitorfunctions/index.html#6.0.0

    > Again very important: The failure to be able, not to have to, I am 100% for
    > the enabeling approach, but who enables constraints and protocol checking?

    See above. Second time I've used that link in this thread :)

    --
    Alex
    Alex Young, Jul 24, 2006
    #7
  8. Guest

    > Now anything that responded to #to_a could use #transform. I'm not
    sure
    > how far this can be taken. Can classes be undone altogegther? But in
    > anycase, it seems very cool, and I wonder what kind of overall effect
    > it could have on coding?


    :) I was thinking things like this a while ago, and a clever friend
    pointed me to predicate classes (see google). The idea with them is that
    you define a predicate such as "supports the method 'each'". You could
    call this predicate Enumerable. The predicate is a declaration of your
    interface requirements. You can then add methods to this Enumerable
    predicate class, such as min, max, inject, etc. From then, anything that
    is Enumerable will also support the things you put in to Enumerable.
    Pretty cool.

    I liked the idea, anyway. I like it because I think it would make it
    easier to take things that you've already got, things that someone has
    given to you perhaps, and say new things about them based on the fact
    that they've pretty much got the interface you're looking for (if they
    don't quite have the right interface, you can use predicate classes to
    give them the additional "glue" that they need).

    I also like it because I don't think that there's anything especially
    fundamental about classes. With predicate classes, all you're really
    saying is that "if I've got something that can do x and y, then I know
    that I can equally validly think of it as something that can do z".

    [I should point out here that I don't imagine Predicate Classes are "the
    answer"; I'm just pointing to them as being interesting.]

    Class hierarchies almost always seem arbitrary and task oriented to me.
    That works well when you've a particular task in mind, but I think it
    falls over when the task changes, or when you're more interested in the
    information in some objects, rather than what they are currently being
    used for.

    I also think they're an impediment to being agile because you're
    building up a hierarchy that may not exist. Sure, you can refactor, and
    perhaps you've got automated tools that do that, but you shouldn't need
    to. You, and any part of your program or someone else's, ought to be
    able to look at some existing objects in any way they choose. You should
    be able to say anything you like about your particular way of looking at
    those things.

    While I like Ruby a great deal (and I really mean that: it's made
    programming fun again, for me), I don't think contemporary OO is all
    that. Something that's wonderful about Ruby though, is that I think it's
    got every chance of being the platform in which people find that out,
    and find a better way.

    On the other hand, I could be wrong, in which case Ruby's already there :)

    Cheers,
    Benjohn
    , Jul 24, 2006
    #8
  9. Alex Young Guest

    Robert Dober wrote:
    > On 7/24/06, Alex Young <> wrote:
    >
    >>
    >> Robert Dober wrote:
    >> > On 7/24/06, <> wrote:

    >> <snip>
    >> >> and hence any hash-like object.
    >> >
    >> > Yeah great, you see that is what troubles me, it is completely cool to

    >> talk
    >> > about hash-like object, but what is a hash-like object? Which messages
    >> > must
    >> > a hash-like object respond to? All of Hash, I suppose, thus a subclass,

    >> or
    >> > only some, then we can talk about protocols again, but the failure

    >> to be
    >> > able to define the protocol just worries me.

    >> That's the whole point. Duck-typing means that your class only needs to
    >> define the methods (of Hash, in this case) that the called method
    >> (transform here) needs, *not* the whole Hash class, *without* having to
    >> specify a protocol. If you want to specify a protocol, there's one
    >> example of how to do it here:
    >>
    >> http://www.erikveen.dds.nl/monitorfunctions/index.html#6.0.0

    >
    >
    >
    > Well I have read that, kind of, it is a little bit heavy, too heavy I am
    > afraid.
    > I still do not get the point, are you saying I am right (let dogs life) or
    > are you saying I am wrong (let only ducks life).

    It's my opinion that opposition to duck-typing is a bad idea (especially
    when dealing with Ruby, given how pervasive it is), but that doesn't
    make it wrong. It is perfectly possible for both dogs and ducks to
    co-exist.

    > Mixins are another nice way to think about it
    >
    > class Dog
    > include Duck
    > ... # no this is *not* the Perl6 Thingy Jabbawalky operator ;)
    > end
    >
    > d = Puppet
    > d.implements? Duck ==> true

    If you're always supplying Duck's functionality as a mixin, you can do:

    Duck === d
    => true

    The beauty of duck-typing is that you don't have to, though.

    If you wanted an Object#implements? method which doesn't rely on
    implementation via mixin, you could do it like this:

    class Object
    def implements?(module)
    my_methods = Set.new(self.public_methods)
    module_methods = Set.new(module.instance_methods)
    return my_methods.superset?(module_methods)
    end
    end

    Again, that misses the point somewhat, though - duck-typing lets you not
    have to think about the concept of a defined interface (in the Module
    sense, at least). If your method only calls #foobar on a passed object,
    then that object only need respond to the #foobar method.

    > but maybe this is here already, gotta check.
    > Thx for your considerations
    > I repeat nevertheless
    > Ducks are great, unless they kill Dogs ;)

    You can always check the class of an object, and there are ways to make
    the syntax less cumbersome than it might otherwise be.

    --
    Alex
    Alex Young, Jul 24, 2006
    #9
  10. Alex Young Guest

    Robert Dober wrote:
    > On 7/24/06, Alex Young <> wrote:

    <snip>
    > The beauty of duck-typing is that you don't have to, though.
    >
    >
    > Yes I agree 100% but the not-so-beauty is that I cannot (veryeasily)
    >
    > If you wanted an Object#implements? method which doesn't rely on
    >
    >> implementation via mixin, you could do it like this:
    >>
    >> class Object
    >> def implements?(module)
    >> my_methods = Set.new(self.public_methods)
    >> module_methods = Set.new(module.instance_methods)
    >> return my_methods.superset?(module_methods)
    >> end
    >> end

    >
    > yes I could, why not, nice idea

    I think it does everything you're after.

    >
    > Again, that misses the point somewhat, though - duck-typing lets you not
    >
    >> have to think about the concept of a defined interface (in the Module
    >> sense, at least). If your method only calls #foobar on a passed object,
    >> then that object only need respond to the #foobar method.

    >
    > Is this really a feature, all the times, I do not think so.

    Absolutely. It's what makes the entire Enumerable module so useful.
    Every single Enumerable method works that way - the object only has to
    support the #each method for all of Enumerable's methods to be
    applicable. The #to_s method is similar - anything that supports #to_s
    has a whole raft of functionality available to it because methods know
    that they've got a way of treating it as a string.

    --
    Alex
    Alex Young, Jul 24, 2006
    #10
  11. Guest

    Hi --

    On Mon, 24 Jul 2006, Alex Young wrote:

    > If you're always supplying Duck's functionality as a mixin, you can do:
    >
    > Duck === d
    > => true
    >
    > The beauty of duck-typing is that you don't have to, though.


    I'd go further: the definition of duck typing is that you don't :)

    I think Dave Thomas was always pretty explicit about saying that duck
    typing, in practice as well as theory, is something one does *instead*
    of checking class/module ancestry. I think the use of Duck, duck,
    quack, etc. as class and method names is kind of misleading. It moves
    the class-checking approach into the "duck" namespace -- which means
    that "duck typing" gets redefined, and it also means that the thing
    originally called "duck typing" is left without a name.

    What it always comes down to for me is this: in Ruby, at the moment
    that you send a message to an object, you send a message to an object.
    No amount of checking of class membership -- not even, technically,
    the prior checking of respond_to? -- has any bearing on what happens
    when that message is sent.

    Duck typing is Dave's name for an approach to Ruby programming that
    attempts to live in harmony with this underlying state of things in
    Ruby, rather than covering it up or pretending it isn't there.

    There are two major ramifications of duck typing:

    1. it leads you to understand what's actually happening every
    time you call a method in Ruby;
    2. it points the way to interesting and productive things you
    can do to harness the way Ruby works, rather than fighting it.

    I've always agreed with Jim Weirich that Ruby is "a duck-typed
    language". In other words, as far as Ruby is concerned, everyone is
    duck typing: everyone is sending messages to objects, and those
    message-sending events are never connected directly to an object's
    ancestry. Hence #1 in the list above.

    As for #2 -- it's not that it's a mark of shame to use #is_a? and
    #respond_to?, but rather that Ruby does provide a programming
    environment in which it's possible, thanks to a design that eschews
    certain constraints, to do otherwise, with good results.

    Final note to Alex: much of what's here is in response to the whole
    thread, even though it's in a response to your post :)


    David

    --
    http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
    http://www.manning.com/black => RUBY FOR RAILS (reviewed on
    Slashdot, 7/12/2006!)
    http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
    => me
    , Jul 24, 2006
    #11
  12. Mat Schaffer Guest

    On Jul 23, 2006, at 10:59 PM, Jake McArthur wrote:

    > I much prefer its (less mature) derivative, Io. Everything is a
    > message to something else, and everything is a prototype. Very
    > simple, very powerful (even, dare I say, more powerful than Ruby,
    > albeit a bit less pretty).
    >
    > - Jake McArthur


    You piqued my curiosity with that. But "lo" is really hard to google
    for. Do you have any reference links?
    -Mat
    Mat Schaffer, Jul 24, 2006
    #12
  13. Alex Young Guest

    Robert Dober wrote:
    <snip>
    > Maybe we can fly. Maybe. But I do not believe so.
    > It just strikes me as if the community is throwing away so much by being,
    > forgive me to be blunt, intolerant about philosophies that are well known,
    > like early failing.
    > Although I said intolerant I want to add immediately that they are nicely
    > so, but quite firmely.

    Duck typing doesn't stop you from failing early. If you combine the
    #implements? method with the monitor-functions example from earlier in
    the thread, you've got quite a nice interface checker.

    You can have your duck and eat it too.

    --
    Alex
    Alex Young, Jul 24, 2006
    #13
  14. Rimantas Liubertas, Jul 24, 2006
    #14
  15. Alex Young Guest

    Mat Schaffer wrote:
    >
    > On Jul 23, 2006, at 10:59 PM, Jake McArthur wrote:
    >
    >> I much prefer its (less mature) derivative, Io. Everything is a
    >> message to something else, and everything is a prototype. Very
    >> simple, very powerful (even, dare I say, more powerful than Ruby,
    >> albeit a bit less pretty).
    >>
    >> - Jake McArthur

    >
    >
    > You piqued my curiosity with that. But "lo" is really hard to google
    > for. Do you have any reference links?

    http://www.iolanguage.com/about/

    --
    Alex
    Alex Young, Jul 24, 2006
    #15
  16. Mat Schaffer Guest

    On Jul 24, 2006, at 8:52 AM, Rimantas Liubertas wrote:

    >> You piqued my curiosity with that. But "lo" is really hard to google
    >> for. Do you have any reference links?

    >
    > Actually it is pretty easy to google: Io programming language ;)
    >
    > http://www.iolanguage.com/about/


    Right. io, not LO..... silly sans-serif fonts.
    Thanks!
    -Mat
    Mat Schaffer, Jul 24, 2006
    #16
  17. Guest

    Hi --

    On Mon, 24 Jul 2006, Robert Dober wrote:

    > On 7/24/06, Alex Young <> wrote:
    >>
    >> Robert Dober wrote:
    >> <snip>
    >> > Maybe we can fly. Maybe. But I do not believe so.
    >> > It just strikes me as if the community is throwing away so much by

    >> being,
    >> > forgive me to be blunt, intolerant about philosophies that are well

    >> known,
    >> > like early failing.
    >> > Although I said intolerant I want to add immediately that they are

    >> nicely
    >> > so, but quite firmely.

    >> Duck typing doesn't stop you from failing early. If you combine the
    >> #implements? method with the monitor-functions example from earlier in
    >> the thread, you've got quite a nice interface checker.
    >>
    >> You can have your duck and eat it too.

    >
    >
    > Nice 1.
    >
    > --
    >> Alex
    >>
    >>

    > Ah sorry I had the impression some are fairly opposed to that approach and
    > considered it unrubyfull. Maybe I am too *sensible*.


    I don't think I'd call interface-checking "duck typing", but if it
    helps you build the program you want, then you should probably do it.


    David

    --
    http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
    http://www.manning.com/black => RUBY FOR RAILS (reviewed on
    Slashdot, 7/12/2006!)
    http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
    => me
    , Jul 24, 2006
    #17
  18. Guest

    > You piqued my curiosity with that. But "lo" is really hard to google
    > for. Do you have any reference links?
    > -Mat


    http://www.iolanguage.com/

    Enjoy ;)

    --
    Fabio Aquotte
    , Jul 24, 2006
    #18
  19. wrote:
    > I also like it because I don't think that there's anything especially
    > fundamental about classes. With predicate classes, all you're really
    > saying is that "if I've got something that can do x and y, then I know
    > that I can equally validly think of it as something that can do z".


    The concept really piqued my interest, and since ruby gives us such nice
    metaprogramming abilities, why not do it?


    module DuckTyping
    @@quacks = Hash.new{ |h,k| h[k] = {} }

    def ducktype(*reqs, &block)
    o = Object
    before = o.methods
    o.class_eval(&block)
    after = o.methods

    for methodname in (after - before)
    @@quacks[methodname.to_sym][reqs] = o.instance_method(methodname.to_sym)
    o.send:)remove_method, methodname.to_sym)
    end
    end

    def ducktype_method(methodname)
    @@quacks[methodname.to_sym].each do |reqs, m|
    if reqs.all?{ |r| self.respond_to?(r) }
    return m
    end
    end
    return nil
    end

    def method_missing(methodname, *args, &block)
    if m = ducktype_method(methodname)
    m.bind(self).call(*args, &block)
    else
    super
    end
    end
    end
    Object.module_eval{ include DuckTyping }


    ducktype :quack do
    def quack_loudly
    quack.upcase
    end
    end


    class Duck
    def quack
    "quack!"
    end
    end

    class Dog
    def bark
    "woof!"
    end
    end

    Duck.new.quack_loudly #=> "QUACK!"
    Dog.new.quack_loudly #=> NoMethodError


    nifty?
    Daniel DeLorme, Jul 24, 2006
    #19
  20. Guest

    Daniel DeLorme wrote:
    > wrote:
    > > I also like it because I don't think that there's anything especially
    > > fundamental about classes. With predicate classes, all you're really
    > > saying is that "if I've got something that can do x and y, then I know
    > > that I can equally validly think of it as something that can do z".

    >
    > The concept really piqued my interest, and since ruby gives us such nice
    > metaprogramming abilities, why not do it?
    >
    > module DuckTyping
    > @@quacks = Hash.new{ |h,k| h[k] = {} }


    [snip cool code]

    > ducktype :quack do
    > def quack_loudly
    > quack.upcase
    > end
    > end
    >
    >
    > class Duck
    > def quack
    > "quack!"
    > end
    > end
    >
    > class Dog
    > def bark
    > "woof!"
    > end
    > end
    >
    > Duck.new.quack_loudly #=> "QUACK!"
    > Dog.new.quack_loudly #=> NoMethodError
    >
    >
    > nifty?


    Nicely done! Code worthy of experimentation. A lot of excellent
    comments in this thread too.

    I wonder then, if we take up John Carter's notion on duck as mixin,
    then Enumerable can be defined as:

    ducktype :each do
    def collect
    each{ |e| yield(e) }
    end
    ...
    end

    Although clearly the distinction between a mixin and a ducktype is the
    ducktypes global influence. Quite powerful! Yet, I do imagine that with
    this is place someone would call for selector namepsaces to reign in
    the abundant flocks ;) Onefurther step would have to be taken, at the
    very least. a means of constraining them to specific scopes. Perhaps
    that's a simple as limiting them the module space they are defined in?

    In any case very interesting. I really wonder just how far one can take
    this shift in paradigm?

    T.
    , Jul 24, 2006
    #20
    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. Duck Typing

    , Sep 16, 2003, in forum: Python
    Replies:
    10
    Views:
    670
    Steve Holden
    Sep 17, 2003
  2. Replies:
    15
    Views:
    553
    Isaac Gouy
    Sep 1, 2006
  3. Replies:
    2
    Views:
    304
    Terry Reedy
    Jan 28, 2008
  4. t7dgbnak

    Black Duck Outfitters!!! RIP OFF

    t7dgbnak, Apr 2, 2008, in forum: C Programming
    Replies:
    0
    Views:
    541
    t7dgbnak
    Apr 2, 2008
  5. Paddy
    Replies:
    1
    Views:
    384
    Paddy
    May 9, 2008
Loading...

Share This Page