Article on ARTIMA

Discussion in 'Ruby' started by Peter Hickman, Sep 29, 2003.

  1. There is the start of a series of articles on ARTIMA with Matz.

    www.artima.com

    However they interleave (!) their interviews and publish one a week so you
    will have to keep comming back. But that is not a bad thing, this is a very
    good site even if you are not a Java programmer with many lenghty interviews
    top language designers.
     
    Peter Hickman, Sep 29, 2003
    #1
    1. Advertisements

  2. Yukihiro Matsumoto: "... But in fact we need to focus on humans, on how
    humans care about doing programming or operating the application of the
    machines. We are the masters. They are the slaves."

    Bill Venners: For the time being anyway.

    Yukihiro Matsumoto: For the time being anyway, until the age of Terminator.

    LOL :)
     
    Peter C. Verhage, Sep 29, 2003
    #2
    1. Advertisements

  3. Peter Hickman

    Ben Giddings Guest

    Heh. Isn't it great? Ruby is fun to write, and Matz is fun to read. :)

    I guess one reason I like Ruby is because I agree with him on so many
    points. Programming should be flexible and fun. You shouldn't think too
    much about what the computer is doing under the hood. Doing something
    simple should be simple. I also like that he's very honest that Ruby is
    designed by him for him, and if it works well for other people that's
    great, but it really is his language and if it doesn't act the way you
    expect, want, or hope... well make your own language!

    Ben
     
    Ben Giddings, Sep 29, 2003
    #3
  4. Peter Hickman

    Bob X Guest

    From the talkback:

    "Ruby is over 10 years old, very popular in Japan, gaining popularity in
    other parts of the world, have thousands of users and hundreds of hackers.
    However, the implementation (Ruby has only 1 currently, written in C) is
    pretty weak. It's slow, does not support native threads, does not do JIT
    compilation (not even bytecode), needs a better GC, etc. It is especially so
    if we compare it with Java and Smalltalk, who have gotten real good
    implementations (JIT compilers, fast GC, threads, etc) nowadays."

    Comments?
     
    Bob X, Sep 30, 2003
    #4
  5. Peter Hickman

    Phil Tomson Guest

    I saw this comment as well. I think it's a valid concern. In the area of
    performance Ruby is falling behind. Smallscript shows that you can have
    high-performance dynamic language implementations.

    Let's hope that Rite comes along soon...

    Phil
     
    Phil Tomson, Sep 30, 2003
    #5
  6. Peter Hickman

    Sean O'Dell Guest

    Let me also add that hand-grenades make terrible hammers. Discuss.

    Sean O'Dell
     
    Sean O'Dell, Sep 30, 2003
    #6
  7. Peter Hickman

    Kingsley Guest

    Well I don't know if this comment is factually correct or whether it is just a
    re-iteration of an anti-ruby chinese whisper.

    But If David Garamond the author is right in what he says, then I would much
    prefer people to aknowledge this and work to improve it, than retort with
    over-exaggerated claims about how wrong he is.

    Positive criticism should be welcomed, embraced and seen as an opportunity for
    advancement.

    Thats my thoughts anyway

    Kingsley
     
    Kingsley, Sep 30, 2003
    #7
  8. Peter Hickman

    Ben Giddings Guest

    Slow: yup, slower than Python, C, Assembly and most other things... not a
    big issue for me most of the time, however.

    Does not support native threads: not a major issue for me, but maybe for
    some people it is.

    Does not do JIT compilation or bytecode: nope... not a major issue for me

    Needs a better GC: really? Not for me.

    All in all, I think the criticisms are valid, but I don't care. The way I
    use Ruby these problems haven't come up. It's like someone saying that my
    swiss army knife doesn't have a saw. If I ever need a saw that will make
    my swiss army knife less useful, but until I need one, it doesn't really
    interest me.

    I think the 10 years of development is a bit of a red herring though. I
    don't know how intense the development has been over those 10 years, but it
    is now at version 1.8, wheras Python is at 2.3 and Perl is at 5.8. For an
    open-source type project where there is one main developer, no massive
    funding, etc. it isn't surprising that certain tweaks (JIT, bytecode,
    speed) haven't been added yet. I'd be curious to see how Ruby 1.8 fares
    against Python 1.8 (if it existed) though.

    I am curious though. Regarding Ruby the environment, rather than Ruby the
    language, what is it that people would most want? Native threads?
    Bytecode compilation? Speed increases? More memory-efficient GC?

    Ben
     
    Ben Giddings, Sep 30, 2003
    #8
  9. First, let me say that the original posting very clearly represents my
    sentiments. Ruby the language rocks, the implementation... not so much.
    Me neither, but without even thinking contientiously about it runtime
    performance has influence on when I find ruby suitable for a project. If
    ruby could be made a faster performer it would make more projects ruby
    projects.
    On Windows threading is *the* issue, if you ask me. It simply doesn't work.
    It is incredibly counter-intuitive, as a thread model, that a *blocked*
    thread prevents the other threads from running. Bizarre. Perfectly
    comprehensible considering the implementation, but it just makes threading
    on windows suck.
    Well who cares how it is implemented, you already addressed your lack of
    concern for the runtime speed.
    I was not aware of this problem either.
    You know that different projects assign version numbers differently. It is
    way more fair to count the number of years a language has existed. In the
    end it only matters to you what is a fair comparison because you (and I)
    love ruby. To everyone else only one thing matters: what is best for them
    now!
    1) Native threads.
    1.1) A thread safe interpreter.
    2) Speed (somehow, don't care, bytecode, jit, whatever)

    But then again, we can talk all we want, we are getting all this for free
    and getting smarter for working with it, and I for one am very grateful for
    all of it, even if there are a few blemishes on this particular ruby
    (implementation).

    Cheers,

    Thomas
     
    Thomas Sondergaard, Oct 1, 2003
    #9
  10. Hello Bob,


    BX> "Ruby is over 10 years old, very popular in Japan, gaining popularity in
    BX> other parts of the world, have thousands of users and hundreds of hackers.
    BX> However, the implementation (Ruby has only 1 currently, written in C) is
    BX> pretty weak. It's slow, does not support native threads, does not do JIT
    BX> compilation (not even bytecode), needs a better GC, etc. It is especially so
    BX> if we compare it with Java and Smalltalk, who have gotten real good
    BX> implementations (JIT compilers, fast GC, threads, etc) nowadays."

    BX> Comments?

    100% ACK. The poster described the technical problems of ruby very
    well. And they are a reason for not choosing the language in some
    projects.

    I really don't like native threads programming at the low level that
    most languages offer (introduced 30 years ago - mutexes, semaphores
    etc). Eiffel and TCL have much better way separating
    threads and using message passing as the only way for communication.
    I wish someone would take a look at TCL how to implement it, but the
    current C implementation of ruby is such a hack that it is impossible to
    add something like this.

    And another thing is very important and should really be done if ruby
    wants to escape the hacker world:

    A Formal description of the language (you know the "language lawyer"
    section of the python documentation). JRuby and Ruby are not the same
    in some details and this is the result of the lack of specification.
     
    Lothar Scholz, Oct 1, 2003
    #10
  11. Peter Hickman

    Hal Fulton Guest

    This interests me. David Alan Black and I have discussed it more
    than once.

    But I'm not sure Matz likes the idea of a formal language spec. Or
    perhaps he would say the spec already exists, and it is written
    in C.

    Matz? What would you think of a formal spec as long as 1) the content
    was OK'd by you and 2) you didn't have to write it?

    Hal
     
    Hal Fulton, Oct 1, 2003
    #11
  12. Hi,

    In message "Re: Article on ARTIMA"

    |Matz? What would you think of a formal spec as long as 1) the content
    |was OK'd by you and 2) you didn't have to write it?

    Definitely it's good to have, unless it slows down the language
    evolution.

    matz.
     
    Yukihiro Matsumoto, Oct 1, 2003
    #12
  13. Peter Hickman

    Rasputin Guest

    None of those interest me personally, except perhaps the GC
    issue - can't say I've seen that and last month I had 2 AI
    tic-tac-toe players going head to head on a 425x425 board, and didn't
    have problems. Each Square was an instance of a 'Square' class, and I was
    running a testsuite against it so there were plenty of setup/teardown
    calls to exercise GC :)

    I wouldn't try to argue about performance because it's good enough
    for me. I suspect most people wouldn't have a problem either.
    Unfortunately it seems to be one of those pissing contest issues
    like a PCs Mhz value....

    For me the main concern about a language is how easy it is to write and
    maintain programs in it, and Ruby kicks seven shades out of any other
    language I've used for that.

    (C/Java/Perl/shell/PHP/FORTRAN/V**ual B**ic).
     
    Rasputin, Oct 1, 2003
    #13
  14. Peter Hickman

    Jim Freeze Guest

    A formal spec is be good for the rest of us, and eventually
    it will speed development because more people will have
    access to understanding the internals of the language.

    But, a formal spec will slow progress down initially (however,
    it may also clear up muddy thinking). And it will need
    to be under constant revision (albeit hopefully minor).
     
    Jim Freeze, Oct 1, 2003
    #14
  15. Peter Hickman

    Kingsley Guest

    One of the reasons I love Ruby is because of how I feel when I code in it. I
    feel happy.

    I wasn't a programmer and still don't think of myself as a programmer as I
    have been a tester for a long time, but in trying to learn various different
    languages like C or Java I found it pretty hard going and never managed to
    stick it out for long.

    I think this is mainly due to the language syntax - I never really could
    understand it fully and there seemed to be words I had to type which didn't
    seem to make sense to me. Ruby seemed to remove all this mystery with its
    intuitive and easy to understand syntax.

    Being a Martial Arts student for over 20 years now - I liken it to Bruce Lee's
    assessment of classical Martial arts - he focused on stripping away all the
    unnecessary and redundant structures and worked on improving the simplest way
    to achieve the goal. He believed in evolution and that anything that remains
    static and unchanging would soon wither.

    I found some things in Life are designed to fit the individual - becoming a
    taylor made solution, like Wing Chun - one of the blocks works becuase you
    hold your arm in the correct position for your body - some styles make
    everyone hold their arm in the same position - no wonder they don't work as
    fluidly and effectively considering all the different shapes and sizes of
    people out there.

    I find Ruby to be one of those things in life that feels like its designed to
    fit the individual - I'm not straining to understand all the time, instead it
    all feels natural and unrestricted. So there's a lot to be said for Matz
    concentration on this side of the language. Intuitive design is extremely
    important. I feel Ruby fits my personality and character very well - becoming
    an extension of myself almost, rather than an external tool. In fact I might
    even go so far as to say I can find self-expression in my Ruby Code. (I don't
    know if this is unusual for a programmer to feel?)

    As for Ruby's apparent 'issues' mentioned above well I can see how they might
    hold back the explosion of Ruby into a commercial / enterprise arena. But
    seeing as I'd rather not code in anything else, I'd love Ruby to go in that
    direction. So If these issues are being addressed thats more strings to the
    bow.

    Where I work there are a couple of people who I feel sure also love Ruby -
    people such as Martin Fowler and Dan North. Now If I could just give them
    something more to justify using Ruby in future projects then maybe our
    company would consider it. Which would make me very happy.

    Anyway - I seemed to have typed more than I anticipated

    as Hal Fulton so aptly named his book 'The Ruby Way', I am now beginning to
    understand the 'Ruby Way'.

    Where in programming I once struggled with interdiction, In Ruby I find
    accessibility, and where I once stumbled in the jungle of Syntax, In Ruby I
    step lightly, frreely and above all happily.

    Kingsley
     
    Kingsley, Oct 1, 2003
    #15
  16. Hello Joe,


    JC> Putting aside the fact that on Windows there are some really pathological
    JC> threading issues... does the fact that Ruby doesn't support "native threads"
    JC> means Ruby will not take advantage of multiple processors (and
    JC> pseudo-multiprocessors, like Intel's HyperThreading)? I don't know much

    Yes thats right !
    One of the reasons why it is not the best language for larger server
    applications where at least dual processors are very common. Of couse
    you can use multiple processes, but then you will see much harder IPC
    and caching problems if you don't use one fat central database server.

    JC> about the microprocessor industry but from what little I know, it seems like
    JC> at least some of the big companies are looking to multiple cores and other
    JC> parallelism at the thread level for their future chips.

    That's right and it's the right way. But i think the NUMA architecture
    will win (long term future). With NUMA (Non unified memory
    architecture) you don't have a shared memory anymore - so the ruby way
    is not so bad.
     
    Lothar Scholz, Oct 2, 2003
    #16
  17. Yes, it is. If an application implements threading at the "user-space"
    level, then the kernel sees the app as one thread, and therefore cannot
    distribute processing over multiple physical processors.
    Yep, I'd agree with this too. With the proviso, of course, that the vast
    majority of programs are not multi-threaded internally, and therefore
    don't run any faster on multi-cpu systems no matter what.
    Numa does have shared memory; it's just that memory "local" to the CPU
    is faster to access than memory "local" to some other CPU. I do think
    NUMA is going to win on very big servers, but is unlikely to come to a
    desktop system - though I'm not an expert here.



    Have you heard of the "Parrot" project? A team of developers are
    building an open-source high-performance virtual machine for
    "interpreted" languages. Their initial target is Perl6, but the
    expicitly want to support other languages including Python and Ruby.
    "Ideally, Parrot can be used to support other dynamic, bytecode-compiled
    languages such as Python, Ruby and Tcl."

    There are some really smart people working on this one, and the project
    is coming along nicely it seems.

    Re parrot, see:
    * http://www.parrotcode.org/
    * http://dev.perl.org/perl6/
    * http://www.sidhe.org/~dan/blog/archives/000151.html


    I presume Parrot supports kernel-level multithreading, though I guess
    some of the Ruby libraries would need work on threadsafety to run
    correctly in kernel-threading-mode...

    There was a project called "Cardinal" to implement Ruby on Parrot.
    It appears to be defunct though (so appropriate for us Monty Python fans
    :). Or maybe just dormant until Parrot is more advanced...

    Re Ruby on Parrot, see:
    * http://www.rubyxml.com/parrot/parrot_notes.html
    * http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/76623
    * http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/76552
    * http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/29980
    * http://www.rubygarden.org/ruby?CardinalProject


    Does anyone here know any more on the status of ruby-for-parrot
    projects?


    Cheers,

    Simon
     
    Simon Kitching, Oct 3, 2003
    #17
  18. Hello Simon,

    Friday, October 3, 2003, 2:42:54 AM, you wrote:

    SK> Have you heard of the "Parrot" project? A team of developers are
    SK> building an open-source high-performance virtual machine for
    SK> "interpreted" languages. Their initial target is Perl6, but the
    SK> expicitly want to support other languages including Python and Ruby.

    Yes i heard about it, isn't it the VM machine for the GNU-Hurd shell,
    released next year.

    SCNR.
     
    Lothar Scholz, Oct 3, 2003
    #18
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.