Why I don't use Ruby.

Discussion in 'Ruby' started by TLOlczyk, Jul 1, 2004.

  1. TLOlczyk

    TLOlczyk Guest

    For a short period I used Ruby and found that I liked it very much,
    but gave it up after ashort while. Every so often I look for a new
    language to act as my "second" language, Each time Ruby pops
    into mind, but I immediately drop it.

    I thought I would explain why so that some of TPTB can think it over
    and decide if it might be worth while to make changes.

    The first comment I would make is that I base my desires on features
    provided in languages created in the functional programming community.
    Languages such as Scheme/SML/OCaml/Haskell. I find that these
    languages are oriented towards academia and research and often fall
    short for serious work. One of the biggest examples is the inability
    to provide systems which work the same on Unix and Windows. In
    effect most of these systems give short shrift to Windows. I preffer
    my code to work more or less the same on both types of OS.

    The main thing I am looking for is a basic environment similar to
    functional languages. In particular a ( native-code ) compiler and
    an extensible REPL. By REPL I mean read-eval-print-loop, a fancy
    word for interpreter. To make clear what I want, and why I think
    it is a superior approach, I will now explain how it is used.

    Typically you open the file you are working on in emacs,vi or
    an IDE. ( Typically it would be emacs or vi. The IDEs available
    tend to be too primitive. Other editors might do but I am not
    aware of them. ) The you split the session into two windows
    and start your REPL in one. You edit your file and send one
    "line" at a time to the REPL to be evaluated. By line I mean
    command. maybe a function definition, a class definition, a method
    definition, an assignment to a global variable... basically one
    "thought". You have problems so you debug the code. Then
    you send it again. Over and over, till it works right. ( Ok sometimes
    you have to restart the REPL, because you muck up something
    in the envornment. ) Sometimes to figure out what went wrong,
    say there is a global list and you want to see what's inside because
    you think it's wrong. You switch to the window with the REPL
    and you type the command to print the list.

    Afdter a while the file is complete. Then you compile it into a
    library file or application. This way you get the speed of a compiled
    program with the flexibility of an interpreted program. And in
    some cases you need the speed. In others you don't. In others
    you don't know (eg libwww). Of course it would be nice to be
    able to build new REPL with libraries incorporated, or at
    least specified on the commandline.

    It would also be nice to have an optional core/image.
    That way if I run tests where testing uses a lot of data,
    I can save images when i debug later stages and
    save myself some time initializing.






    The reply-to email address is .
    This is an address I ignore.
    To reply via email, remove 2002 and change yahoo to
    interaccess,

    **
    Thaddeus L. Olczyk, PhD

    There is a difference between
    *thinking* you know something,
    and *knowing* you know something.
    TLOlczyk, Jul 1, 2004
    #1
    1. Advertising

  2. il Thu, 01 Jul 2004 04:43:49 -0500, TLOlczyk <> ha
    scritto::


    This message may be trollish, but it seem it is'nt :)

    >The first comment I would make is that I base my desires on features
    >provided in languages created in the functional programming community.
    >Languages such as Scheme/SML/OCaml/Haskell. [..] In
    >effect most of these systems give short shrift to Windows. I preffer
    >my code to work more or less the same on both types of OS.



    have you tried DrScheme ? The GUI environment is based on wxwindows
    and runs quite fine on windows.

    >The main thing I am looking for is a basic environment similar to
    >functional languages. In particular a ( native-code ) compiler and
    >an extensible REPL. By REPL I mean read-eval-print-loop, a fancy
    >word for interpreter. To make clear what I want, and why I think
    >it is a superior approach, I will now explain how it is used.


    Why do you feel the need for a native code compiler,
    Do you expect better performances or something else?

    Anyway, about REPL env, that's what IRB is for:
    >> def f
    >> 10
    >> end

    => nil
    >> f

    => 10
    >>


    >Typically you open the file you are working on in emacs,vi or
    >an IDE. ( Typically it would be emacs or vi. The IDEs available
    >tend to be too primitive. Other editors might do but I am not
    >aware of them. ) The you split the session into two windows
    >and start your REPL in one.[..]


    I think ruby-mode.el allows this. I usually do this in different
    terminals, anyway, but that's quite subjective.

    >
    >Afdter a while the file is complete. Then you compile it into a
    >library file or application. This way you get the speed of a compiled
    >program with the flexibility of an interpreted program. And in
    >some cases you need the speed. In others you don't. In others
    >you don't know (eg libwww). Of course it would be nice to be
    >able to build new REPL with libraries incorporated, or at
    >least specified on the commandline.


    I'm not sure what you intended with the last statement, maybe
    irb -r mylib

    It's really agreeable that better performance would be nice. I think a
    JIT would be ok, anyway.

    If you feel that speed is such an important thing in your application
    field, and that current C libraries or ruby extension are not a good
    fit, I completely agree with you, ruby is not fine.

    OTOH IIRC there are some effort to build ruby2c, ruby2asm, and JIT
    compilers for ruby. I hope those will mature with time, but I
    understand you can't care about them.


    >It would also be nice to have an optional core/image.
    >That way if I run tests where testing uses a lot of data,
    >I can save images when i debug later stages and
    >save myself some time initializing.


    I'm not sure what you mean here. Do you want to freeze the interpreter
    in a given state? Or do you feel the need for some serialization
    format that can be retrieved at any time fast? (in this case Marshal
    could fit, maybe?)
    gabriele renzi, Jul 1, 2004
    #2
    1. Advertising

  3. I totally agree with you.

    "gabriele renzi" <> schrieb im Newsbeitrag
    news:...
    > il Thu, 01 Jul 2004 04:43:49 -0500, TLOlczyk <> ha
    > scritto::
    >
    >
    > This message may be trollish, but it seem it is'nt :)
    >
    > >The first comment I would make is that I base my desires on features
    > >provided in languages created in the functional programming community.
    > >Languages such as Scheme/SML/OCaml/Haskell. [..] In
    > >effect most of these systems give short shrift to Windows. I preffer
    > >my code to work more or less the same on both types of OS.

    >
    >
    > have you tried DrScheme ? The GUI environment is based on wxwindows
    > and runs quite fine on windows.
    >
    > >The main thing I am looking for is a basic environment similar to
    > >functional languages. In particular a ( native-code ) compiler and
    > >an extensible REPL. By REPL I mean read-eval-print-loop, a fancy
    > >word for interpreter. To make clear what I want, and why I think
    > >it is a superior approach, I will now explain how it is used.

    >
    > Why do you feel the need for a native code compiler,
    > Do you expect better performances or something else?
    >
    > Anyway, about REPL env, that's what IRB is for:
    > >> def f
    > >> 10
    > >> end

    > => nil
    > >> f

    > => 10
    > >>

    >
    > >Typically you open the file you are working on in emacs,vi or
    > >an IDE. ( Typically it would be emacs or vi. The IDEs available
    > >tend to be too primitive. Other editors might do but I am not
    > >aware of them. ) The you split the session into two windows
    > >and start your REPL in one.[..]

    >
    > I think ruby-mode.el allows this. I usually do this in different
    > terminals, anyway, but that's quite subjective.
    >
    > >
    > >Afdter a while the file is complete. Then you compile it into a
    > >library file or application. This way you get the speed of a compiled
    > >program with the flexibility of an interpreted program. And in
    > >some cases you need the speed. In others you don't. In others
    > >you don't know (eg libwww). Of course it would be nice to be
    > >able to build new REPL with libraries incorporated, or at
    > >least specified on the commandline.

    >
    > I'm not sure what you intended with the last statement, maybe
    > irb -r mylib
    >
    > It's really agreeable that better performance would be nice. I think a
    > JIT would be ok, anyway.
    >
    > If you feel that speed is such an important thing in your application
    > field, and that current C libraries or ruby extension are not a good
    > fit, I completely agree with you, ruby is not fine.
    >
    > OTOH IIRC there are some effort to build ruby2c, ruby2asm, and JIT
    > compilers for ruby. I hope those will mature with time, but I
    > understand you can't care about them.


    And, for real high performance requirements it's likely that Ruby -
    whether compiled to native or whatever - will not reach the mark that can
    be set languages like C and C++. The dynamic nature does cost some
    performance. If performance is paramount one either has to use another
    language or write an extension that does the performance critical things.

    > >It would also be nice to have an optional core/image.
    > >That way if I run tests where testing uses a lot of data,
    > >I can save images when i debug later stages and
    > >save myself some time initializing.

    >
    > I'm not sure what you mean here. Do you want to freeze the interpreter
    > in a given state? Or do you feel the need for some serialization
    > format that can be retrieved at any time fast? (in this case Marshal
    > could fit, maybe?)


    I'd use Marshal for that. I even once wrote a function that automatically
    loads the marshalled representation of a file if that is unchanged and
    otherwise loads the file. Marhshall is pretty fast indeed.

    Regards

    robert
    Robert Klemme, Jul 1, 2004
    #3
  4. Hello TLOlczyk,

    T> The main thing I am looking for is a basic environment similar to
    T> functional languages. In particular a ( native-code ) compiler and
    T> an extensible REPL. By REPL I mean read-eval-print-loop, a fancy

    The ruby language makes a native compiler almost useless. It's far to
    dynamic.

    T> word for interpreter. To make clear what I want, and why I think
    T> it is a superior approach, I will now explain how it is used.

    So you mean you want an image based language system like lisp, scheme
    or smalltalk.

    Right Ruby is not working this way. But it could work this way. I was
    experimenting with this feature in my Arachno Ruby IDE. But it is not
    possible just for the way many libraries are written.
    And trying to convince people to obey to at least a minimal coding
    standard is a waste of time, you can't even convince them that every
    file needs a

    if $0 == __FILE__
    -- to your main stuff here
    end

    statement around the code body. Otherwise its not useable by a lot of
    tools like the refactoring browser, exerb etc.



    --
    Best regards, emailto: scholz at scriptolutions dot com
    Lothar Scholz http://www.ruby-ide.com
    CTO Scriptolutions Ruby, PHP, Python IDE 's
    Lothar Scholz, Jul 1, 2004
    #4
  5. I've never used that code snippet... and I've never had problems with exerb.

    Why would it cause problems with exerb?

    -Rich

    > And trying to convince people to obey to at least a minimal coding
    > standard is a waste of time, you can't even convince them that every
    > file needs a
    >
    > if $0 == __FILE__
    > -- to your main stuff here
    > end
    >
    > statement around the code body. Otherwise its not useable by a lot of
    > tools like the refactoring browser, exerb etc.
    >
    >
    > --
    > Best regards, emailto: scholz at scriptolutions dot com
    > Lothar Scholz http://www.ruby-ide.com
    > CTO Scriptolutions Ruby, PHP, Python IDE 's
    >
    >
    richard lyman, Jul 1, 2004
    #5
  6. Hello richard,

    rl> I've never used that code snippet... and I've never had problems with exerb.

    rl> Why would it cause problems with exerb?

    One way to use "exerb" is to start your program and track the
    necessary files that are required to build the final exe. But if your application
    instead starts its main tasks and go into application loop and
    does not return it's not nice. Especially if this happens in one of
    the required libraries. In 90% percent of the cases it works fine, but
    this is the problem, that this means it fails in 10% of all usecases.

    Same is true with "rbb" the refactoring browser.

    --
    Best regards, emailto: scholz at scriptolutions dot com
    Lothar Scholz http://www.ruby-ide.com
    CTO Scriptolutions Ruby, PHP, Python IDE 's
    Lothar Scholz, Jul 1, 2004
    #6
  7. TLOlczyk <> wrote in message news:<>...
    > [....]


    why would anyone care that you are not using Ruby ?

    -klaus
    Klaus Momberger, Jul 1, 2004
    #7
  8. Obviously, there have already been a number of useful comments about
    irb, the Ruby interpreter; it is an invaluable part of my development
    and test cycle, as I'm sure it is for many other Ruby users on this
    list.

    As for the issue of persistent heap images, I agree that such a
    feature would be quite useful, especially when coupled with an
    interactive interpreter. I've worked in groups that used Common Lisp
    as their primary development language, and I have to say that
    distributing an application was almost embarassingly easy when
    compared to, say, compiling and linking C sources, or installing a
    Ruby application with diverse library and version requirements.

    For those who haven't had the pleasure, let me give a brief
    explanation. Most implementations of Common Lisp (as well as many
    Scheme dialects, Smalltalk implementations, and other
    functional/research languages) include the ability to perform a dump
    of the entire runtime heap memory space into an "image" file. That
    snapshot essentially contains the working state of the system, much
    like the dump of RAM a laptop saves to disk for "hibernation" mode.

    The value of this feature for distribution comes from being able to
    then transfer this image file to another system, load it into another
    instance of the runtime there, and resume working where you left off
    previously. Most implementations also allow you to specify a new
    toplevel entry point, allowing you to effectively pick a 'main()'
    function of your choosing when creating the image.

    The "Prevayler" family of object peristence models are, in effect, a
    limited (though incremental, rather than bulk) version of this idea.
    By building such peristence into the core runtime, though, you can
    trivially distribute new versions of both the core language, and
    applications built on top of it.

    However, there are issues with this approach. Unlike most Lisps and
    Smalltalks, Ruby is not a self-hosting system; the core runtime is
    implemented in C, and depends heavily on the system libraries and
    memory model of the underlying operating system. By using native
    structures like file handles, dynamic libraries, and virtual memory
    management pervasively, Ruby has more or less bound itself to the
    lifecycle and call conventions of a "native" application.

    However, it should be entirely possible to experiment with a limited
    form of the global-image class of persistence. There are two main
    paths I could see working. The more obvious would be performing a
    standard Marshal.dump on every object in the heap, saving the state of
    any serializable objects to disk (and allowing them to perform any
    cleanup necessary prior to shutdown).

    Less trivial, but potentially more interesting, would be to allocate
    new objects within mmap'ed address space, (effectively bypassing the
    native virtual memory system) which would allow a 'dump' operation to
    simply be implemented as a 'sync' on that space. Updates could be
    incremental, and have near the same performance as the native OS does
    with VM paging.

    Anyone with more language implementation experience care to weigh in
    on the feasibility of such a hack? I know that several "academic"
    languages already implement such functionality, and that as a
    garbage-collected language, Ruby should already have most of the
    infrastructure necessary to build it again.

    Okay, enough rambling. Back to work.

    Lennon
    Lennon Day-Reynolds, Jul 1, 2004
    #8
  9. TLOlczyk

    Curt Hibbs Guest

    Klaus Momberger wrote:
    >
    > TLOlczyk <> wrote in message
    > news:<>...
    > > [....]

    >
    > why would anyone care that you are not using Ruby ?


    As long as we not talking about comments from a troll, it can be very useful
    to know why as we factor such things (as appropriate) into future plans.

    Curt
    Curt Hibbs, Jul 1, 2004
    #9
  10. On Fri, 2 Jul 2004 01:42:55 +0900, Klaus Momberger <> wrote:
    [...]
    > why would anyone care that you are not using Ruby ?
    >
    > -klaus


    Perhaps because we would like to see more people using Ruby? Or even
    just because the sort of people who use "fringe" languages like Ruby
    tend to enjoy discussion of obscure details of implementation and
    semantics?

    Lennon
    Lennon Day-Reynolds, Jul 1, 2004
    #10
  11. TLOlczyk

    Ara.T.Howard Guest

    On Fri, 2 Jul 2004, Lennon Day-Reynolds wrote:

    > Perhaps because we would like to see more people using Ruby? Or even just
    > because the sort of people who use "fringe" languages like Ruby tend to
    > enjoy discussion of obscure details of implementation and
    > semantics?
    >
    > Lennon


    yes. yes.

    regards.

    -a
    --
    ===============================================================================
    | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
    | PHONE :: 303.497.6469
    | A flower falls, even though we love it;
    | and a weed grows, even though we do not love it.
    | --Dogen
    ===============================================================================
    Ara.T.Howard, Jul 1, 2004
    #11
  12. Robert Klemme a écrit :
    (snip)
    > And, for real high performance requirements it's likely that Ruby -
    > whether compiled to native or whatever - will not reach the mark that can
    > be set languages like C and C++. The dynamic nature does cost some
    > performance.

    Just for the record, Common Lisp is (more or less) as dynamic as Ruby,
    and some implementations produce really good and fast native code...
    (ok, perhaps not as fast as C !-)
    (snip)

    bruno
    bruno modulix, Jul 1, 2004
    #12
  13. OCaml is as dynamic as LISP and some implementations produce native
    code that _is_ as fast as C. It's quite amazing.

    On Fri, 2 Jul 2004 07:12:50 +0900, bruno modulix <> wrote:
    >
    > Robert Klemme a écrit :
    > (snip)
    > > And, for real high performance requirements it's likely that Ruby -
    > > whether compiled to native or whatever - will not reach the mark that can
    > > be set languages like C and C++. The dynamic nature does cost some
    > > performance.

    > Just for the record, Common Lisp is (more or less) as dynamic as Ruby,
    > and some implementations produce really good and fast native code...
    > (ok, perhaps not as fast as C !-)
    > (snip)
    >
    > bruno
    >
    >
    Carl Youngblood, Jul 1, 2004
    #13
  14. There are several reasons that Common Lisp can achieve much better
    performance than Ruby. First and foremost is the fact that Lisp-like
    languages in general have been around longer than C, and have been the
    subject of extensive work in optimization and native code generation.
    Second, CL, while being value-typed in a fashion similar to modern
    scripting languages, also supports type annotations, which allow the
    compiler to generate more efficient code for critical sections.

    Performance has much less to do which language selection than it does
    with abstraction and algorithm selection. Some languages (like C) are
    excellent for manipulating data at the level of individual pointers
    and registers, but require a great deal of infrastructure to approach
    the productivity of higher-level languages. If you were to write C
    code that emulated the Ruby object model, it would likely run in
    approximately equivalent time.

    Lennon

    On Fri, 2 Jul 2004 07:12:50 +0900, bruno modulix <> wrote:
    >
    > Robert Klemme a écrit :
    > (snip)
    > > And, for real high performance requirements it's likely that Ruby -
    > > whether compiled to native or whatever - will not reach the mark that can
    > > be set languages like C and C++. The dynamic nature does cost some
    > > performance.

    > Just for the record, Common Lisp is (more or less) as dynamic as Ruby,
    > and some implementations produce really good and fast native code...
    > (ok, perhaps not as fast as C !-)
    > (snip)
    >
    > bruno
    >
    >
    Lennon Day-Reynolds, Jul 1, 2004
    #14
  15. TLOlczyk

    James Britt Guest

    Klaus Momberger wrote:

    >TLOlczyk <> wrote in message news:<>...
    >
    >
    >>[....]
    >>
    >>

    >
    >why would anyone care that you are not using Ruby ?
    >
    >


    The Ruby community may not care if any one person decides not to use
    Ruby (unless, say, that one person were Matz).

    But it's in the interest of language development to hear when people
    have problems using the Ruby.

    Most of the time the reason is a bit more mundane: lack of a specific
    library of particular interest; low recognition value among so-called IT
    managers who only know what they read in E-Week; syntax that conflicts
    with some previously divined notion of the One True Way. That sort of
    thing.

    In some cases the concerns are legit (that is, they address issues that
    are likely of interest to more than a handful of users); sometimes
    theses issues can be addressed. And sometimes it is worth the trouble
    to address a correctable, legitimate issue.

    My recollection is that most of the so-called complaints come from folks
    with a C/Java/Python/Perl background and are unhappy when Ruby doesn't
    always map to their internal world view. Most of these have been
    discussed to death; a suggestion to search ruby-talk is usually the best
    response.

    I'm more interested when somebody from a functional or logic programming
    background gives Ruby a whirl and finds fault. It may, again, be an
    issue of cognitive dissonance, but there is still something to be
    learned from it.

    Unless someone is trolling (and it's not always easy to tell) I
    appreciate the effort to tell this crowd about possible ways to improve
    the language.

    James
    James Britt, Jul 1, 2004
    #15
  16. Hello Lennon,

    LDR> However, there are issues with this approach. Unlike most Lisps and
    LDR> Smalltalks, Ruby is not a self-hosting system; the core runtime is
    LDR> implemented in C, and depends heavily on the system libraries and
    LDR> memory model of the underlying operating system. By using native
    LDR> structures like file handles, dynamic libraries, and virtual memory
    LDR> management pervasively, Ruby has more or less bound itself to the
    LDR> lifecycle and call conventions of a "native" application.

    Sorry but here you miss the point, using file handles, DLL's and
    native structure does not mean anything for implementing an image
    based language (it's not a heap image by the way).

    LDR> However, it should be entirely possible to experiment with a limited
    LDR> form of the global-image class of persistence. There are two main
    LDR> paths I could see working. The more obvious would be performing a
    LDR> standard Marshal.dump on every object in the heap, saving the state of
    LDR> any serializable objects to disk (and allowing them to perform any
    LDR> cleanup necessary prior to shutdown).

    At the moment you can't dump methods and classes. So this would
    require a lot of work. We are not talking about data persistence here.

    LDR> Less trivial, but potentially more interesting, would be to allocate
    LDR> new objects within mmap'ed address space, (effectively bypassing the
    LDR> native virtual memory system) which would allow a 'dump' operation to
    LDR> simply be implemented as a 'sync' on that space. Updates could be
    LDR> incremental, and have near the same performance as the native OS does
    LDR> with VM paging.

    The current problem is the serialization of the program stack because
    there native C function calls and ruby calls are mixed. Okay we could
    dump only if there is nothing on the stack (which is the case when the
    program exits normally), and return to a special "main" function on
    the next start, but this is normally not that what you want in an
    image based language.

    LDR> Anyone with more language implementation experience care to weigh in
    LDR> on the feasibility of such a hack? I know that several "academic"
    LDR> languages already implement such functionality, and that as a
    LDR> garbage-collected language, Ruby should already have most of the
    LDR> infrastructure necessary to build it again.

    I think the technical implementation is not the difficult thing here,
    its the current state of libraries.

    Oh yes, i implemented an LISP system in about 50000 lines of Assembler
    code many many years ago. The core system, the VM, is not difficult to
    write, but we would need a complete rewrite of Ruby.


    --
    Best regards, emailto: scholz at scriptolutions dot com
    Lothar Scholz http://www.ruby-ide.com
    CTO Scriptolutions Ruby, PHP, Python IDE 's
    Lothar Scholz, Jul 2, 2004
    #16
  17. OCaml is, as far as I understand, actually much closer to C++ than
    CLOS/Ruby/Smalltalk in object model and dynamism. Its object model
    supports polymorphism, inheritance, and even parameterization, but
    does not really allow redefinition of methods and instance variables
    at runtime. In my usual thinking, "dynamic" and "statically typed" do
    not often go together.

    There's always going to be a certain amount of overhead incurred by
    using a "pure", message-based object model. You can either try to
    avoid it by having a restricted sub-language that can be turned into
    fast native code (Psyco, Objective C, etc.), or by doing runtime JIT
    compilation, with its implied assumption that changes to "hotspot"
    code will be infrequent enough to make code cache invalidation a minor
    cost compared to the savings provided by compilation.

    In effect, the current solution for Ruby closely mirrors Objective C,
    in that "high performance" code can be written in C (either using
    Inline, or as a standalone extension). Personally, now that I'm
    familiar with the Ruby C API, I don't really consider it to be that
    bad having to drop into another language for performance-critical
    code.

    Lennon
    Lennon Day-Reynolds, Jul 2, 2004
    #17
  18. Hello bruno,

    bm> Just for the record, Common Lisp is (more or less) as dynamic as Ruby,
    bm> and some implementations produce really good and fast native code...
    bm> (ok, perhaps not as fast as C !-)
    bm> (snip)

    No. You need to use things like (the 'Integer i) all the time, and if
    i would call this lisp anymore i don't know.

    And even if you go this way, your program will then be as save as a
    program in FORTH - or a C program where everything is casted to (void*)

    Lisp guys write some routines in this "typed Lisp", rubyist's write
    them in "C", so it's not so different.



    --
    Best regards, emailto: scholz at scriptolutions dot com
    Lothar Scholz http://www.ruby-ide.com
    CTO Scriptolutions Ruby, PHP, Python IDE 's
    Lothar Scholz, Jul 2, 2004
    #18
  19. --- TLOlczyk <> wrote:
    > [...]
    > The main thing I am looking for is a basic environment similar to
    > functional languages. In particular a ( native-code ) compiler and
    > an extensible REPL. By REPL I mean read-eval-print-loop, a fancy
    > word for interpreter. To make clear what I want, and why I think
    > it is a superior approach, I will now explain how it is used.
    >
    > Typically you open the file you are working on in emacs,vi or
    > an IDE. ( Typically it would be emacs or vi. The IDEs available
    > tend to be too primitive. Other editors might do but I am not
    > aware of them. ) The you split the session into two windows
    > and start your REPL in one. You edit your file and send one
    > "line" at a time to the REPL to be evaluated. By line I mean
    > command. maybe a function definition, a class definition, a method
    > definition, an assignment to a global variable... basically one
    > "thought". You have problems so you debug the code. Then
    > you send it again. Over and over, till it works right. ( Ok sometimes
    > you have to restart the REPL, because you muck up something
    > in the envornment. ) Sometimes to figure out what went wrong,
    > say there is a global list and you want to see what's inside because
    > you think it's wrong. You switch to the window with the REPL
    > and you type the command to print the list.
    > [...]


    My REPL looks like this:

    irb(main):005:0> test
    => true
    irb(main):006:0> load 'foo.rb'
    => true
    irb(main):007:0> test
    => true
    irb(main):008:0> load 'testcase.rb'
    => true
    irb(main):009:0> test
    => true
    irb(main):010:0> load 'foo.rb'
    => true
    irb(main):011:0> test
    => true
    irb(main):012:0> load 'foo.rb'
    => true
    irb(main):013:0> test
    => true
    irb(main):014:0> load 'testcase.rb'
    => true
    irb(main):015:0> test

    This is all intermixed with setting and examining particular
    variables and data structures. irb history and tab completion
    make the process faster than it appears here.





    __________________________________
    Do you Yahoo!?
    New and Improved Yahoo! Mail - Send 10MB messages!
    http://promotions.yahoo.com/new_mail
    Jeff Mitchell, Jul 2, 2004
    #19
  20. Carl Youngblood <> writes:

    > On Fri, 2 Jul 2004 07:12:50 +0900, bruno modulix <> wrote:
    >>
    >> Robert Klemme a écrit :
    >> (snip)
    >> > And, for real high performance requirements it's likely that Ruby -
    >> > whether compiled to native or whatever - will not reach the mark that can
    >> > be set languages like C and C++. The dynamic nature does cost some
    >> > performance.

    >> Just for the record, Common Lisp is (more or less) as dynamic as Ruby,
    >> and some implementations produce really good and fast native code...
    >> (ok, perhaps not as fast as C !-)
    >> (snip)
    >>
    >> bruno
    >>

    > OCaml is as dynamic as LISP and some implementations produce native
    > code that _is_ as fast as C. It's quite amazing.


    It's definitely not as dynamic as Lisp. It's entirely statically
    typed: types do not exist at runtime. It has very few facilities for
    introspection. The performance of its generated code and garbage
    collector crucially depends on its static type system.

    Not to say OCaml is a bad language for it. Dynamicity is a very nice
    property -- but so is fast code. For me, the trade-off tends to favor
    dynamicity, but if it didn't, I would love to use OCaml.

    Except the lack of overloading would probably drive me crazy.

    mikael
    Mikael Brockman, Jul 2, 2004
    #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. DP
    Replies:
    0
    Views:
    1,130
  2. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    863
    Mark Rae
    Dec 21, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,764
    Smokey Grindel
    Dec 2, 2006
  4. jalkadir
    Replies:
    2
    Views:
    367
  5. Daniel Berger
    Replies:
    4
    Views:
    105
    Daniel Berger
    Sep 28, 2008
Loading...

Share This Page