Goodbye TCL

Discussion in 'Python' started by Ed Suominen, Apr 15, 2004.

  1. Ed Suominen

    Ed Suominen Guest

    I have debated about the wisdom of posting this message, knowing that a lot
    of people whom I respect may not like what I have to say. On the other
    hand, I wish that the person who told me "TCL is dead, try Python" two
    weeks ago had somehow been able to get that message through to me much
    earlier. As a longtime member of comp.lang.tcl who reluctantly considered
    that advice but wound up finding its results incredibly illuminating and
    productive, it seems only fair to pass it on.

    I am dictating this posting into a Linux application window using speech
    recognition software that is running under Windows in a VMware virtual
    machine. Every time I dictate a bit of text into a Tk text widget on the
    Windows side, that text is transmitted via a (virtual) TCP connection to a
    daemon on the Linux side that generates fake keystrokes via X events. I
    wrote the software that accomplishes this [1] over the course of the last
    week or so, one week after beginning my study of object-oriented and
    test-driven programming in general, more specifically of Python, and even
    more specifically of the Twisted network application framework for Python
    [2]. There was a lot of reading and head-scratching involved, but it was a
    fascinating experience.

    I have had extensive experience doing network application development with
    TCL, most visibly with Privaria [3]. That experience involved a great deal
    of low-level programming using the socket built-in function and its
    companions. In both cases, I searched far and wide for suitable TCL
    packages to do what I wanted but wound up just writing the stuff at a low
    level because the packages seemed inactive, demonstrated buggy behavior, or
    just didn't seem to do what I wanted. I spent many interesting but
    frustrating hours sniffing packets and working out the details of TCP-level
    communications -- buffer flushing, newline inconsistencies, blocking vs.
    non-blocking reads, etc.

    With this latest project, I was determined to see if Python was as widely
    supported and powerful as its advocates claimed. I was not disappointed.
    After quite a few hours of intense study (my first real exposure to
    object-oriented programming, see above) I found the language itself
    incredibly powerful, without the need for any external packages (which do
    you choose, itcl, snit, or what?) to tack OOP capability onto a language
    that is as procedural as the name of its function construct ("proc")
    implies.

    Namespaces in Python just happen; they don't need definition. If you
    "import" a "module," all of its "attributes," which are classes, methods
    (few), and variables (fewer) live in that module's name space unless you
    indicate otherwise (which you can easily do). The number of globals
    floating around is truly minimal, because defining classes that instantiate
    objects making things happen in methods of objects is the default in the
    way the language and its documentation (current and extensive) encourage
    you to program.

    But most significantly, I found, is that trying to reuse code that others
    have written is no longer a frustrating exercise in skipping past "Error
    404: Page Not Found" messages, pages that are found but haven't been
    updated in three years and feature code that only links to tclsh8.1, and
    packages that are TCL-only or manage to link but seem dangerously inactive,
    buggy, and unused. For my first Python application (written just before the
    one I'm using to dictate this) I needed to generate highly structured,
    highly specialized HTML from various bits of data in text files here and
    there. I found the HTML generation package in Python's standard library
    (yes, there is one, is extensive, and it comes with the interpreter) to be
    intuitive and powerful, in contrast to the tcllib tool that I wound up
    having to extend with my own hacks on too many occasions. (There's a more
    powerful TCL tool, but it doesn't seem to be active or widely used...)

    For this dictation application, I used the twisted application framework,
    which turns Python into an incredibly powerful networking and multitasking
    machine. It was very difficult to learn because its documentation does not
    keep up with its depth, and I wound up having to print and pore over a lot
    of source files to understand how it works. But once I overcame that
    learning curve I found that I could do amazing things with a few lines of
    highly modular code. I never even got close to the TCP packets. I just
    invoked a method of the "reactor" object that runs the whole show to listen
    for TCP connections on one side and make connections on the other and
    implemented various methods to send the data I needed. When new text
    materializes in the text widget, a periodically-polled method senses it and
    sends it to the other side. The other side tells its keystroke-typing
    object about the new text and lets that object take care of calling its own
    objects. All those objects' classes and method were unit tested
    concurrently with their development, based on a testing framework someone
    else wrote and is supporting. The whole things takes up about 800 lines of
    code, including extensive "docstrings" (essentially
    documentation-generating comments).

    I'm not writing all of this to rub it in, to thumb my noses at those left
    behind. But I think at some point people (like me, two weeks ago) should
    question why their particular programming language, operating system kernel
    (see, e.g., the Hurd), editor, etc. does not seem to be receiving as much
    attention as they would like. Sure, such people can tout the benefits of
    their particular choice and shake their heads in wonder at why others
    haven't discovered it or have left it behind, but they might well take an
    honest look at the question "why"? Perhaps there is a reason why Python has
    several dozen books with recent publication dates and nothing new seems to
    have been written about TCL for years. Perhaps there is a reason why the
    comp.lang.python newsgroup has several times the volume of this one and the
    typical Linux distribution has many times more Python-based applications
    than TCL-based ones. The reason may be that many people are finding one
    choice superior to the other.

    Finally, let me add that some of my observations may be inaccurate. Any such
    inaccuracies are unintentional and open to correction here. Hopefully this
    lengthy message will be received in the constructive spirit in which it was
    written.

    Ed Suominen

    [1] Very much in pre-release state, but available at
    http://www.ossri.org/projects.php
    [2] http://www.twistedmatrix.com/
    [3] http://www.privaria.org
    Ed Suominen, Apr 15, 2004
    #1
    1. Advertising

  2. Ed:

    I think your post is valuable. Instead of trying to invalidate your
    arguments, I will outline my reasons why I stick to Tcl. Then we can
    perhaps glimpse how strengths and weaknesses counterbalance.

    The main reasons I stick with Tcl are:

    1. Rock-solid stability. I'm too old to spare time wondering if
    frequent crashes in my software are my fault or the underlying
    technology's fault. Tcl largely removes this consideration from the
    equation. America Online's web server is written in Tcl. It is
    highly unlikely I will ever need to scale a product of mine to that
    level, so there's a lot of headroom for me.

    I have occasionally looked into new technologies, like Python, PHP,
    Ruby, etc; but I've noticed that if you look beyond the FAQ's deep
    into the developer mailing lists, you'll generally find statements
    like: 'development of the core is going really really well, and within
    the next few releases we actually expect it to be stable!' Hold me.

    I frequently use Tcl to write wrappers for other products to catch and
    compensate for their shortcomings. This would be pointless if it
    weren't for the fact that Tcl is at least an order of magnitude more
    stable and reliable than any other technology I've tried.

    2. Freedom from bugs. For years after college I did almost no coding
    because I was sick of the fact that I would have to rewrite literally
    everything I wrote two or three times to find a syntactically correct
    version that didn't hit a deadly bug. Imagine my surprise when my
    first Tcl scripts Just Worked. And the docs were accurate and
    complete too, so I didn't have to spend half my time
    reverse-engineering (another new experience). For this reason alone
    Tcl is almost single-handedly responsible for the fact that I am still
    working in the computer world.

    In ten years of Tcl scripting, I think I've encountered three bugs in
    the core. I found upon reporting that each one was already fixed in
    the latest version. I just don't bother to upgrade my core very often
    because of 1. and 2.

    3. Platform agnosticism. Since Tcl was originally designed to be
    embedded it play no favorites in terms of platform features. It's
    available on a wide variety of platforms and I suspect will be there
    on the platforms of the future in equally reliable forms. I started
    with computers on Unix as a student, as a professional worked first
    with Macintosh v 7, then on to Windows, and now a bit of everything
    (five *nix versions, four Win*s and handheld devices). AS/400 was in
    there somewhere. Tcl has been there every step of the way. I'm too
    old to relearn my chops every time a new OS fad blows through, and I
    don't want to have to predict winners and losers. I feel Tcl
    minimizes the likelihood I will have to.

    Here at work I suggested we use a free Tcl installer program rather
    than a for-pay Java one. Management chose the Java option. Why?
    Because the Java company officially supported all the platforms we
    needed to be on, and management felt they couldn't take the risk of
    going without assurances. It's turned out that the installer has
    required special handling or patches for every OS (and almost every OS
    version) we've tried it on, resulting in numerous gotchas and
    release-note warnings for our customers. And "official support" is a
    bulletin board where their engineers' response is always "we're
    working on it." Meanwhile my build and test scripts run merrily and
    without alteration everywhere.

    Alternative technologies tend nakedly to favor *nix, and seem only to
    offer a subset of function on other OS's grudgingly. Python and
    similar technologies treat platform-specific issues like pathnames and
    line terminators as special cases with their own commands or
    compensating strategies to handle them. Tcl largely handles them
    tranparently. It was years before I was even aware of some of these
    issues because Tcl handled them so well. Python uses ASCII as a
    default string encoding, but recently managed to bolt on a Unicode
    library (same with PHP I think). I haven't looked into its Shift-JIS
    suppport, which I need for work (and is included with Tcl).

    4. Tk. Other technologies say 'We don't have a native GUI interface,
    but there's a binding to the Tk library.' For all intents and
    purposes, Tk is the only game in town for cross-platform GUI
    scripting. When I'm using Tcl I know I have access to 100% of Tk's
    features and the latest Tk version. Is that true with other
    languages' bindings? I don't know, but if I had to bet money I'd say
    no.

    Tk follow's Tcl's logic, and it's a lot easier to program Tk
    interfaces when in the Tcl mindset then try to access Tk's features by
    switching gears from another language's mindset. I don't do GUI
    programming very often, but when I have to, it's nice to know that I
    can do it as a trivial extension of my existing Tcl skills.

    Ed, your voice-recognition project looks very interesting, and I look
    forward to using it when it's ready for prime time. I spend 90% of my
    time in front of a Windows computer (my boss's choice, not mine): how
    does it run on Windows? How stable is it? How does Twisted's event
    architecture compare to Tcl's?


    Steve Huntley
    Stephen Huntley, Apr 15, 2004
    #2
    1. Advertising

  3. Ed Suominen

    John Roth Guest

    "Stephen Huntley" <> wrote in message
    news:...
    > Ed:
    >
    > I think your post is valuable. Instead of trying to invalidate your
    > arguments, I will outline my reasons why I stick to Tcl. Then we can
    > perhaps glimpse how strengths and weaknesses counterbalance.
    >
    > The main reasons I stick with Tcl are:


    What's amusing is that every one of your arguements in favor
    of TCL are also arguements in favor of Python. This is, after
    all, 2004, not 1994. Languages don't get widespread use
    today unless either 1) some mega-mastodon is pushing them,
    like Java or C#, or 2) they just work out of the box, and
    solve real problems for the people using them.

    John Roth

    > 1. Rock-solid stability. I'm too old to spare time wondering if
    > frequent crashes in my software are my fault or the underlying
    > technology's fault. Tcl largely removes this consideration from the
    > equation. America Online's web server is written in Tcl. It is
    > highly unlikely I will ever need to scale a product of mine to that
    > level, so there's a lot of headroom for me.
    >
    > I have occasionally looked into new technologies, like Python, PHP,
    > Ruby, etc; but I've noticed that if you look beyond the FAQ's deep
    > into the developer mailing lists, you'll generally find statements
    > like: 'development of the core is going really really well, and within
    > the next few releases we actually expect it to be stable!' Hold me.
    >
    > I frequently use Tcl to write wrappers for other products to catch and
    > compensate for their shortcomings. This would be pointless if it
    > weren't for the fact that Tcl is at least an order of magnitude more
    > stable and reliable than any other technology I've tried.
    >
    > 2. Freedom from bugs. For years after college I did almost no coding
    > because I was sick of the fact that I would have to rewrite literally
    > everything I wrote two or three times to find a syntactically correct
    > version that didn't hit a deadly bug. Imagine my surprise when my
    > first Tcl scripts Just Worked. And the docs were accurate and
    > complete too, so I didn't have to spend half my time
    > reverse-engineering (another new experience). For this reason alone
    > Tcl is almost single-handedly responsible for the fact that I am still
    > working in the computer world.
    >
    > In ten years of Tcl scripting, I think I've encountered three bugs in
    > the core. I found upon reporting that each one was already fixed in
    > the latest version. I just don't bother to upgrade my core very often
    > because of 1. and 2.
    >
    > 3. Platform agnosticism. Since Tcl was originally designed to be
    > embedded it play no favorites in terms of platform features. It's
    > available on a wide variety of platforms and I suspect will be there
    > on the platforms of the future in equally reliable forms. I started
    > with computers on Unix as a student, as a professional worked first
    > with Macintosh v 7, then on to Windows, and now a bit of everything
    > (five *nix versions, four Win*s and handheld devices). AS/400 was in
    > there somewhere. Tcl has been there every step of the way. I'm too
    > old to relearn my chops every time a new OS fad blows through, and I
    > don't want to have to predict winners and losers. I feel Tcl
    > minimizes the likelihood I will have to.
    >
    > Here at work I suggested we use a free Tcl installer program rather
    > than a for-pay Java one. Management chose the Java option. Why?
    > Because the Java company officially supported all the platforms we
    > needed to be on, and management felt they couldn't take the risk of
    > going without assurances. It's turned out that the installer has
    > required special handling or patches for every OS (and almost every OS
    > version) we've tried it on, resulting in numerous gotchas and
    > release-note warnings for our customers. And "official support" is a
    > bulletin board where their engineers' response is always "we're
    > working on it." Meanwhile my build and test scripts run merrily and
    > without alteration everywhere.
    >
    > Alternative technologies tend nakedly to favor *nix, and seem only to
    > offer a subset of function on other OS's grudgingly. Python and
    > similar technologies treat platform-specific issues like pathnames and
    > line terminators as special cases with their own commands or
    > compensating strategies to handle them. Tcl largely handles them
    > tranparently. It was years before I was even aware of some of these
    > issues because Tcl handled them so well. Python uses ASCII as a
    > default string encoding, but recently managed to bolt on a Unicode
    > library (same with PHP I think). I haven't looked into its Shift-JIS
    > suppport, which I need for work (and is included with Tcl).
    >
    > 4. Tk. Other technologies say 'We don't have a native GUI interface,
    > but there's a binding to the Tk library.' For all intents and
    > purposes, Tk is the only game in town for cross-platform GUI
    > scripting. When I'm using Tcl I know I have access to 100% of Tk's
    > features and the latest Tk version. Is that true with other
    > languages' bindings? I don't know, but if I had to bet money I'd say
    > no.
    >
    > Tk follow's Tcl's logic, and it's a lot easier to program Tk
    > interfaces when in the Tcl mindset then try to access Tk's features by
    > switching gears from another language's mindset. I don't do GUI
    > programming very often, but when I have to, it's nice to know that I
    > can do it as a trivial extension of my existing Tcl skills.
    >
    > Ed, your voice-recognition project looks very interesting, and I look
    > forward to using it when it's ready for prime time. I spend 90% of my
    > time in front of a Windows computer (my boss's choice, not mine): how
    > does it run on Windows? How stable is it? How does Twisted's event
    > architecture compare to Tcl's?
    >
    >
    > Steve Huntley
    John Roth, Apr 16, 2004
    #3
  4. Ed Suominen

    Phil Dietz Guest

    Forget OO...
    TCL still doesn't have a standard database API in the core yet....
    Phil Dietz, Apr 16, 2004
    #4
  5. David N. Welton, Apr 16, 2004
    #5
  6. "John Roth" <> wrote in message news:<>...
    > "Stephen Huntley" <> wrote in message
    > news:...
    > > Ed:
    > >
    > > I think your post is valuable. Instead of trying to invalidate your
    > > arguments, I will outline my reasons why I stick to Tcl. Then we can
    > > perhaps glimpse how strengths and weaknesses counterbalance.
    > >
    > > The main reasons I stick with Tcl are:

    >
    > What's amusing is that every one of your arguements in favor
    > of TCL are also arguements in favor of Python. This is, after
    > all, 2004, not 1994. Languages don't get widespread use
    > today unless either 1) some mega-mastodon is pushing them,
    > like Java or C#, or 2) they just work out of the box, and
    > solve real problems for the people using them.
    >
    > John Roth


    I'm certain that Python is a lovely language with many uses. You're
    right saying that since 1994 many new technologies have just worked
    out of the box. The gotcha I have encountered is the problems you run
    into a year or so down the line, when you want to move to a new
    platform, or use an exotic character encoding, or scale up by an order
    of magnitude. This is where Tcl has shined for me.

    I would be curious to know what is the biggest-capacity Python network
    application in use? How does it scale in comparison with AOLServer?
    Any ideas?
    Stephen Huntley, Apr 16, 2004
    #6
  7. Ed Suominen

    Roy Smith Guest

    In article <>,
    (Stephen Huntley) wrote:

    > I would be curious to know what is the biggest-capacity Python network
    > application in use? How does it scale in comparison with AOLServer?
    > Any ideas?


    How about the one you're using to post your articles -- Google.
    Roy Smith, Apr 16, 2004
    #7
  8. Stephen> I would be curious to know what is the biggest-capacity Python
    Stephen> network application in use? How does it scale in comparison
    Stephen> with AOLServer? Any ideas?

    Off the top of my head I have no concrete examples, but you might want to
    skim these pages:

    http://www.twistedmatrix.com/services/success
    http://pythonology.org/success
    http://www.python-in-business.org/success/
    http://www.python.org/Quotes.html
    http://www.zope.org/Resources/ZopePowered/

    I believe people find solutions using the twisted framework scale very well.

    There's obviously some significant overlap between those pages (Google, ILM
    and NASA pop up multiple times), and clearly not all of them are using
    Python to develop large-scale websites but there are lots of interesting
    entries in a number of fields.

    the-whole-world-isn't-yet-a-website-ly, y'rs,

    Skip
    Skip Montanaro, Apr 16, 2004
    #8
  9. In article <>,
    Phil Dietz <> wrote:
    >Forget OO...
    >TCL still doesn't have a standard database API in the core yet....


    Was this intended as a contrast with Python?

    'Different way to say this: "database", in this sense,
    is a dirty subject, in that it's far more tied to grungy
    details of specific implementations than the masses
    generally realize, or than either Python or Tcl, both of
    which prize purity in their own ways, generally support.
    A general database abstraction is about as rarefied as a
    general GUI abstraction.
    --

    Cameron Laird <>
    Business: http://www.Phaseit.net
    Cameron Laird, Apr 16, 2004
    #9
  10. Ed Suominen

    ulis Guest

    Just to add one.

    ulis
    ulis, Apr 17, 2004
    #10
  11. Cameron Laird wrote:
    > 'Different way to say this: "database", in this sense, is a dirty
    > subject, in that it's far more tied to grungy details of specific
    > implementations than the masses generally realize, or than either
    > Python or Tcl, both of which prize purity in their own ways,
    > generally support. A general database abstraction is about as
    > rarefied as a general GUI abstraction.


    I had a quick look into general DB APIs in the past, and the response I
    got from the DB community at the time was "but this doesn't support this
    *vital* feature only implemented in one DB that 0.01% of users really
    need and therefore we could never ever use your proposal for a standard
    API". It's kind of discouraging.

    FWIW, I think some mostly-common subset of functionality is possible (if
    we assume SQL underneath; without that, you can't get anywhere) and it
    would be enough to get most of the low-end and casual users total
    satisfaction. And maybe this would encourage alteration in the high-end
    interfaces to be more like each other too.

    Donal.
    Donal K. Fellows, Apr 19, 2004
    #11
  12. In article <c60i7t$2aff$>,
    Donal K. Fellows <> wrote:
    >Cameron Laird wrote:
    >> 'Different way to say this: "database", in this sense, is a dirty
    >> subject, in that it's far more tied to grungy details of specific
    >> implementations than the masses generally realize, or than either
    >> Python or Tcl, both of which prize purity in their own ways,
    >> generally support. A general database abstraction is about as
    >> rarefied as a general GUI abstraction.

    >
    >I had a quick look into general DB APIs in the past, and the response I
    >got from the DB community at the time was "but this doesn't support this
    >*vital* feature only implemented in one DB that 0.01% of users really
    >need and therefore we could never ever use your proposal for a standard
    >API". It's kind of discouraging.
    >
    >FWIW, I think some mostly-common subset of functionality is possible (if
    >we assume SQL underneath; without that, you can't get anywhere) and it
    >would be enough to get most of the low-end and casual users total
    >satisfaction. And maybe this would encourage alteration in the high-end
    >interfaces to be more like each other too.
    >
    >Donal.
    >

    Yeah; I've written database abstractions, going back to before
    there was a Tcl. *I* like them fine. To me, though, they don't
    feel like something that belongs in the core.

    --

    Cameron Laird <>
    Business: http://www.Phaseit.net
    Cameron Laird, Apr 19, 2004
    #12
  13. Ed Suominen

    Jeff Hobbs Guest

    Roy Smith wrote:

    > In article <>,
    > (Stephen Huntley) wrote:
    >
    >
    >>I would be curious to know what is the biggest-capacity Python network
    >>application in use? How does it scale in comparison with AOLServer?
    >>Any ideas?

    >
    >
    > How about the one you're using to post your articles -- Google.


    This is no longer true - google did use Python at one point, but
    now it is reserved for internal company stuff only, as google
    really required hard-core C/C++ for the speed and scale at which
    it performs.

    --
    Jeff Hobbs, The Tcl Guy
    http://www.ActiveState.com/, a division of Sophos
    Jeff Hobbs, Apr 20, 2004
    #13
  14. Ed Suominen

    Peter Hansen Guest

    Jeff Hobbs wrote:
    > Roy Smith wrote:
    >> In article <>,
    >> (Stephen Huntley) wrote:
    >>
    >>> I would be curious to know what is the biggest-capacity Python network
    >>> application in use? How does it scale in comparison with AOLServer?
    >>> Any ideas?

    >>
    >> How about the one you're using to post your articles -- Google.

    >
    > This is no longer true - google did use Python at one point, but
    > now it is reserved for internal company stuff only, as google
    > really required hard-core C/C++ for the speed and scale at which
    > it performs.


    Doubtless you have real evidence to back up this claim?

    Proof that shows that you aren't just mistaken about where
    Python was ever used in that company? (Hint: it was never
    used to run the web servers themselves, of course, but was
    and still is used for the "gathering" side of things.)

    -Peter
    Peter Hansen, Apr 20, 2004
    #14
  15. > I would be curious to know what is the biggest-capacity Python network
    > application in use? How does it scale in comparison with AOLServer?
    > Any ideas?


    Before egroups was purchased by Yahoo (becoming Yahoo Groups), egroups
    was written in Python. Is a few million users a large enough scale?

    - Josiah
    Josiah Carlson, Apr 22, 2004
    #15
  16. In comp.lang.tcl Donal K. Fellows <> wrote:
    > Cameron Laird wrote:
    > > 'Different way to say this: "database", in this sense, is a dirty
    > > subject, in that it's far more tied to grungy details of specific
    > > implementations than the masses generally realize, or than either
    > > Python or Tcl, both of which prize purity in their own ways,
    > > generally support. A general database abstraction is about as
    > > rarefied as a general GUI abstraction.

    >
    > I had a quick look into general DB APIs in the past, and the response I
    > got from the DB community at the time was "but this doesn't support this
    > *vital* feature only implemented in one DB that 0.01% of users really
    > need and therefore we could never ever use your proposal for a standard
    > API". It's kind of discouraging.
    >
    > FWIW, I think some mostly-common subset of functionality is possible (if
    > we assume SQL underneath; without that, you can't get anywhere) and it
    > would be enough to get most of the low-end and casual users total
    > satisfaction. And maybe this would encourage alteration in the high-end
    > interfaces to be more like each other too.
    >
    > Donal.
    >


    Python has a nice relational database API standard, which
    seems to be well implemented across several databases, although
    I've only used the postgresql one myself.

    http://www.python.org/peps/pep-0249.html

    Cheers,
    Mark

    --
    Mark Harrison
    Pixar Animation Studios
    Mark Harrison, Apr 23, 2004
    #16
  17. Donal K. Fellows wrote:

    > Cameron Laird wrote:
    > I had a quick look into general DB APIs in the past, and the response
    > I got from the DB community at the time was "but this doesn't support
    > this *vital* feature only implemented in one DB that 0.01% of users
    > really need and therefore we could never ever use your proposal for a
    > standard
    > API". It's kind of discouraging.
    >
    > FWIW, I think some mostly-common subset of functionality is possible
    > (if we assume SQL underneath; without that, you can't get anywhere)
    > and it would be enough to get most of the low-end and casual users
    > total satisfaction.


    That's exactly the philosophy behind MySQL <g>

    Seriously, I think that any db frontend should start with the most
    simplistic approach possible. The niceties are way beyond most users
    anyway. This approach should also help getting most interfaces across
    the doorstep too, - as this is the most difficult distance.

    regards,
    --
    Leif Biberg Kristensen
    http://solumslekt.org/
    Validare necesse est
    Leif B. Kristensen, Apr 24, 2004
    #17
    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. Zed A. Shaw

    The Last Goodbye for #ruby-lang

    Zed A. Shaw, Nov 1, 2005, in forum: Ruby
    Replies:
    3
    Views:
    98
    Stephen Kellett
    Nov 1, 2005
  2. Sharon Machlis
    Replies:
    8
    Views:
    134
    Donald Anderson
    May 30, 2007
  3. Christophe Mckeon

    Goodbye Ruby - Hello Earth

    Christophe Mckeon, Apr 8, 2009, in forum: Ruby
    Replies:
    131
    Views:
    1,155
    Joel VanderWerf
    Jun 3, 2009
  4. Robert Schaaf

    Goodbye "Goodbye Ruby"

    Robert Schaaf, Apr 18, 2009, in forum: Ruby
    Replies:
    7
    Views:
    177
    Tom Cloyd
    Apr 18, 2009
  5. Mumia W.

    Inline::Tcl vs. Inline::Tcl

    Mumia W., Aug 23, 2006, in forum: Perl Misc
    Replies:
    0
    Views:
    137
    Mumia W.
    Aug 23, 2006
Loading...

Share This Page