Scripting in Python, Ruby, Perl? No, in C++!

January 29, 2007 at 9:46 pm · Filed under C++, Language Reviews, Tools Reviews Bookmark on del.icio.us

NOTE: there are a few posts about this tool in this blog already, but the cryptic name, cpsh, seems to have scared away some of you. Welcome back!

I have built something that is cool and useful, objectively speaking. That something is a shell - interactive or not - using C++. It does have a name, as well: cpsh.

What this means is that you can

evaluate C++ expressions and statements in a fail-safe context, with immediate response
create tiny C++ scripts and run them from file or standard input

This provides a perfect environment for understanding hairy semantic subtleties of C++ as well as learning all those nifty algorithm templates of the Standard Library. Such as realizing that there is no copy_if And, there is built-in support for the Boost Library, of which core parts will be part of the next version of the C++ standard.

More information and instructions on how to build or download prebuilt executables is found in the Google Project for cpsh. Download it for Windows or OS X and just get crazy with C++ constructs and uninstall those Python, Perl and Ruby environments immediately

C++ cpsh Language Reviews script Tools Reviews

Permalink

mhyst said,

March 31, 2008 @ 12:52 pm

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

davber said,

April 1, 2008 @ 1:17 am

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!

mhyst said,

April 1, 2008 @ 6:36 pm

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!

davber said,

April 1, 2008 @ 7:19 pm

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

davber said,

April 1, 2008 @ 7:21 pm

Ok, the Java-based implementation of Ruby is called JRuby, not “JRube.” Sorry for my fingers’ slipping up.

mhyst said,

April 5, 2008 @ 12:12 pm

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

davber said,

April 16, 2008 @ 6:24 pm

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

RSS feed for comments on this post · TrackBack URI

You must be logged in to post a comment.