Comments on: Scripting in Python, Ruby, Perl? No, in C++! http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/ Functional functional programming - Haskell, Ruby, Erlang, Scala... Mon, 04 Jan 2010 21:38:57 -0500 http://wordpress.org/?v=2.8.4 hourly 1 By: davber http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/comment-page-1/#comment-569 davber Wed, 16 Apr 2008 22:24:07 +0000 http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-569 Hey, I intended to move my blog to an Amazon EC2 instance I use, but decided midway to leave it where it is. That is why it was down for a few days. I will try to find some performance metrics for JRuby and Jython w.r.t. Java. Actually, a more fair comparison would be between JRuby, Jython and Groovy, since they all need a lot of indirections to deal with the dynamic semantics of those languages. If I do not find any good metrics, I will run some tests myself. Thanks for staying in spite of the blog going through the motions for a few days :) Hey, I intended to move my blog to an Amazon EC2 instance I use, but decided midway to leave it where it is. That is why it was down for a few days.

I will try to find some performance metrics for JRuby and Jython w.r.t. Java. Actually, a more fair comparison would be between JRuby, Jython and Groovy, since they all need a lot of indirections to deal with the dynamic semantics of those languages.

If I do not find any good metrics, I will run some tests myself.

Thanks for staying in spite of the blog going through the motions for a few days :)

]]> By: mhyst http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/comment-page-1/#comment-556 mhyst Sat, 05 Apr 2008 16:12:56 +0000 http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-556 I couldn't visit this page for a few days. Are you having problems with it? Perhaps it was off for maintenance? Returning to your comment... Programers are nonconformist people. Always rewriting things. lol I haven't any doubts about the benefits of having Ruby or Python written entirely in Java. There are a lot of Java tools that now are available to JRuby and Jython (mostly application server tools). But how many times are we goind to reinvent the wheel? Haven said that... how slow are going to be the programs writen in JRuby or Jython? Before: machine I couldn’t visit this page for a few days. Are you having problems with it? Perhaps it was off for maintenance?

Returning to your comment… Programers are nonconformist people. Always rewriting things. lol I haven’t any doubts about the benefits of having Ruby or Python written entirely in Java. There are a lot of Java tools that now are available to JRuby and Jython (mostly application server tools). But how many times are we goind to reinvent the wheel?

Haven said that… how slow are going to be the programs writen in JRuby or Jython?

Before:
machine

]]> By: davber http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/comment-page-1/#comment-555 davber Tue, 01 Apr 2008 23:21:42 +0000 http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-555 Ok, the Java-based implementation of Ruby is called JRuby, not "JRube." Sorry for my fingers' slipping up. Ok, the Java-based implementation of Ruby is called JRuby, not “JRube.” Sorry for my fingers’ slipping up.

]]> By: davber http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/comment-page-1/#comment-554 davber Tue, 01 Apr 2008 23:19:28 +0000 http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-554 Well, to be fair against some interpreted languages (i.e., languages whose "reference implementation" is an interpreter, since a language per se is neither interpreted nor compiled, it just is ;-)), they usually handle the parsing once, building a parse structure and/or a (high-level) abstract instructions. This family of parse-once interpretative languages include Python (.py ---> .pyc); note that these intermediate forms are rough enough not to earn the label "abstract machine code" (compared to CLI code or Java bytecode), so they still fall under the interpretative umbrella. Additionally, most interesting sessions (such as an in-process web service module; think mod_perl or mod_ruby) live for quite some time, so the initial parsing itself might not be a big deal; the step-by-step interpretation of that internal format is usually quite slow, though. What I said in the preceding paragraph is that it is not - generally - the re-parsing that hurts performance but the actual internal execution of that semi-digested code. To further appreciate the fact that a language per se is not interpretative, look at Ruby, whose Java bytecode implementation is almost complete (the omitted explicit continuation passing, for instance.) That implementation carries another name, JRube, but is implementing Ruby. Or, Python, in its Jython incarnation. I am having fun, and hope you never lose you programming soul :-) Well, to be fair against some interpreted languages (i.e., languages whose “reference implementation” is an interpreter, since a language per se is neither interpreted nor compiled, it just is ;-) ), they usually handle the parsing once, building a parse structure and/or a (high-level) abstract instructions. This family of parse-once interpretative languages include Python (.py —> .pyc); note that these intermediate forms are rough enough not to earn the label “abstract machine code” (compared to CLI code or Java bytecode), so they still fall under the interpretative umbrella. Additionally, most interesting sessions (such as an in-process web service module; think mod_perl or mod_ruby) live for quite some time, so the initial parsing itself might not be a big deal; the step-by-step interpretation of that internal format is usually quite slow, though.

What I said in the preceding paragraph is that it is not – generally – the re-parsing that hurts performance but the actual internal execution of that semi-digested code.

To further appreciate the fact that a language per se is not interpretative, look at Ruby, whose Java bytecode implementation is almost complete (the omitted explicit continuation passing, for instance.) That implementation carries another name, JRube, but is implementing Ruby. Or, Python, in its Jython incarnation.

I am having fun, and hope you never lose you programming soul :-)

]]> By: mhyst http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/comment-page-1/#comment-553 mhyst Tue, 01 Apr 2008 22:36:39 +0000 http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-553 I agree with you about C++ expressiveness. C++ used to be my prefered language and it still holds a lot of weight on my "programming soul". Java became my first language for practical reasons (references are far easy to manage compared with pointers (less versatile though, I know)). But I think everybody should learn C/C++ before even smelling other languages. Interpreted languages tend to be slow. The reason is obvious: every time you run an interpreted program it has to be parsed. Have fun! I agree with you about C++ expressiveness. C++ used to be my prefered language and it still holds a lot of weight on my “programming soul”. Java became my first language for practical reasons (references are far easy to manage compared with pointers (less versatile though, I know)). But I think everybody should learn C/C++ before even smelling other languages.

Interpreted languages tend to be slow. The reason is obvious: every time you run an interpreted program it has to be parsed.

Have fun!

]]> By: davber http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/comment-page-1/#comment-552 davber Tue, 01 Apr 2008 05:17:59 +0000 http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-552 Hey! A confession: I do use Ruby and Python, and, yes, even Perl sometimes, although the need for the latter tool is getting smaller with Ruby, Python and Groovy in my hands. The main reason - for me - to use C++ for "scriptable" tasks is *not* its speed, but rather the expressiveness of the language. There are meta constructs available that you do not find in a lot of languages - most dynamic languages, for instance, resort to reflection rather than meta constructs - and that really only exist in languages like Haskell and Scala. And speed and native - no FFI - access to all C-based code is nice. Again, I like Ruby and Python. A lot of really slow languages are implemented in C, by the way ;-) Take care! Hey!

A confession: I do use Ruby and Python, and, yes, even Perl sometimes, although the need for the latter tool is getting smaller with Ruby, Python and Groovy in my hands.

The main reason – for me – to use C++ for “scriptable” tasks is *not* its speed, but rather the expressiveness of the language. There are meta constructs available that you do not find in a lot of languages – most dynamic languages, for instance, resort to reflection rather than meta constructs – and that really only exist in languages like Haskell and Scala.

And speed and native – no FFI – access to all C-based code is nice.

Again, I like Ruby and Python.

A lot of really slow languages are implemented in C, by the way ;-)

Take care!

]]> By: mhyst http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/comment-page-1/#comment-551 mhyst Mon, 31 Mar 2008 16:52:32 +0000 http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-551 You're against Phyton, Perl and Ruby? Why? lol I mean, I, as most programmers, like fast languages, but we don't rely on assembly always. I use assembly mostly for small projects. Why not using Phyton, Perl or Ruby. The three were developed in C. Best regards You’re against Phyton, Perl and Ruby? Why? lol

I mean, I, as most programmers, like fast languages, but we don’t rely on assembly always. I use assembly mostly for small projects.

Why not using Phyton, Perl or Ruby. The three were developed in C.

Best regards

]]>