Take the 2-minute tour ×

I am starting my first independent for profit venture. I am having a hard time deciding what language to use. I want to write my app in Perl, but I don't think it will be simple enough to compile. If I don't write it in Perl I will write it in C++.

The application will have many features, including wxwidgets interface, Deal with SDL, timers, some threading, and audio processing. The program itself will be somewhat complex, but not terribly large.

So my question's are:

  1. Can PAR, Perl2exe, or equivalent compile more than a basic test cases?
  2. Speed, and compilation aside why should I use C++ over Perl?

Edit: Some of my project specifications.

  • Multi Platform. I am expecting 50% or more of my users to own macs, with Most of the rest being Windows users. If possible I also want to support Linux since It is my everyday operating system.
  • Since it's multi Platform I need a unified GUI creation tool. It needs to be able to use basic types, and allow me to create custom event handlers, and custom GUI objects.
  • It needs audio processing. Read and play, wav's and/or mp3's. Also I will be using some custom algorithms to determine special properties of the audio files; things like tempo, patterns, and so on.
  • I would like but don't require SDL/OpenGL support.

Everything else is pretty mundane. Some different classes and containers. A few custom GUI controls.

share|improve this question
add comment

8 Answers

up vote 9 down vote accepted

Why not use a hybrid of both? It's generally the way a lot of development is going these days.

I'd suggest a Lua/C++ or a Python/C++ combo (I'm not sure how well a Perl/C++ combo works, but that may be a good option too).

Personally I've done a bunch with the Lua/C++ combo and it's pretty fantastic.

share|improve this answer
Interesting thought. How do you go about it? Extract out speed dependant and complex things to C++, and wrap it in your Lua/Python code? –  J.J. Oct 9 '08 at 4:14
Yes that's the best way. Also many times many things that seem speed dependent aren't that critical in reality. Also if your doing lots of math and Just swapping your Lua core to LuaCoCo core can increase the Lua side math 10-fold –  Robert Gould Oct 9 '08 at 4:51
I'm working on a project to make Perl/C++ an easier combination. Google my name and Perl for more information. –  Leon Timmermans Oct 9 '08 at 12:53
@Leon: K, will do. –  J.J. Oct 9 '08 at 16:40
Inline::CPP [ search.cpan.org/perldoc?Inline::CPP ] is the easiest way of tying Perl and C++ together, obviously this embeds C++ code into a mostly-Perl program. Leon's work is for the opposite, embedding Perl into a C++ program. As always, there's more than one way to do it. –  ephemient Oct 9 '08 at 17:08
add comment

Go with C++. Timers, threading, audio, SDL, wxwidgets, these are all things that Perl can do, but doesn't really excel at. Also, PAR or perl2exe are clunky mechanisms for distribution. They work, but they're not ideal. Meanwhile, C++ (and I highly encourage you to look at using Boost) would fit nicely into this role.

share|improve this answer
add comment

I'm both a C++ and Perl programmer. C++ is a nice language, but whenever I have the choice, I go with Perl since development simply proceeds so much more quickly.

A couple of comments:

  1. PAR, perlapp, and perl2exe are not compilers. They are packagers. There is no Perl compiler except perl itself. If you want some form of bytecode form of Perl code, you'll have to wait for Perl 6 on Parrot.
  2. I have used PAR to package an application with a total of about 500k SLOC, not including perl itself. It worked fine, ran the same speed as perl itself, but startup was slower. This was 2005. Since then, the startup performance has improved significantly if you install the Archive::Unzip::Burst module on the development machine where you package the program. I have successfully used PAR for various applications varying in size from tiny to the aforementioned 500k lines. If you need help with PAR, there's an active and friendly mailing list. Just do us and yourself the favour of not chiming in with "OMG, nothing works, help me, kthx!". People do that all the time (and sometimes still get help). :)
  3. Perl's threading isn't great. Check whether something like POE fits your bill instead. I'm a threads.pm user, but I'd rather not be. With appropriate apologies to the hard-working maintainer, Jerry D. Hedden.
  4. wxPerl is in a pretty good shape and there's a community around it. Naturally, since wxWidgets is C++, it's always a tad bit more current and complete.
  5. SDL Perl is a straight wrapper around the library. The (little) documentation assumes you already know it. In my experience, reading docs for a library in a different language can be a bit of a hassle.
  6. Timers are fine in perl: Time::HiRes
  7. Portability is hard. More so in C++ than in Perl, but it really always comes down to discipline and being able to test on many platforms.
  8. For Perl on Windows, make sure you check out Strawberry Perl.
share|improve this answer
Thanks for that information. Ephimient & you have disproved the rumours I have heard. Licencing wise is it ok to Package Perl with my commercial app? I Don't mind linking to Perl.org, or PAR, but I want to make sure I am in the legal clear. –  J.J. Oct 9 '08 at 13:49
It's totally legal. That's essentially the reason perl carries the dual Artistic+GPL licensing terms. One other thing: Don't think PAR jumps through hoops to hide your source code. Try "unzip foo.exe" where foo.exe is a PAR-packaged executable. See also: Filter::Crypto module. –  tsee Oct 9 '08 at 13:57
add comment

I've use PAR to package up a substantial Perl/Tk program for Windows. It took a bit of fiddling, but it worked.

If you're at least as experienced in Perl as in C++, development in Perl should be faster. But the runtime speeds for an equivalent program will be slower. All the rest of your criteria can be satisfied by either, so I'd say it comes down to personal choice.

share|improve this answer
add comment

A great reason to use Perl is meta-programming.

Perl is flexible enough to let you write code to write code (this is how Moose does its magic). You'll save time and reduce the number of bugs you need to squash.

THE great reason to use Perl is CPAN.

share|improve this answer
add comment

Personally? I say don't get stuck on this for too long. There are pros and cons of going either way, but it sounds like you're getting dangerously close to being stuck in "analysis paralysis." If nothing else, flip a coin or choose the one you think has the prettiest name.

share|improve this answer
Thank you for the insightful comment. I have been planning and researching. Much of the time on this question and going over the pro/cons for several weeks. –  J.J. Oct 9 '08 at 4:36
Excellent response. I, myself, am prone to analysis paralysis and the important thing is to do is start. –  Darrel Oct 30 '08 at 13:36
add comment

Function is important. Code, regardless of language, will do similar things, especially if using the same libraries and components. Unless you have the exact function worked out through libraries and toolkits, prototype it in Perl.

There is an argument that development will take less time in a dynamic languages. There are similar issues in Perl and C++ in getting a dropdown in the right place, filling it with the right values, making the proper change in the program state from user input.

If Perl isn't getting it done on certain platforms, transform the code to C++.

There are probably some pointers that would aid in this approach:

  1. That means that you would probably write the prototype with OO Perl. Once you have the high-level functionality nailed down on one platform--provided that you can get that far in Perl--then C++ is more or less an optimization.

  2. Perhaps you might restrain the prototype to more or less cognates of C++. But I'm not sure about this, you can decompose a map into a loop or even just replace it with a filter function called with a function pointer for a test function.

share|improve this answer
You can write a novel in Chinese and a novel in English that both tell the same story, but if you write it in English and translate it into Chinese, it's obvious. Each language has different idioms. OO Perl is such horrendously bad C++ that it's not even funny. C++ is similarly horrible Perl. Limiting yourself to the subset that both contain actually ignores the question of "which is better" by trying to make both equivalent when they are not. –  Patrick Niedzielski Sep 21 '12 at 11:13
add comment

Write your core functionality in C++, then write the front-end for your application in the tool for the platform in question, i.e., Cocoa for Mac OS X, .NET/Delphi/MFC for Windows, etc.

This is my preferred way of developing cross-platform desktop applications. Of course, I know so very little about what you're trying to accomplish, so it may be too fat for you.

share|improve this answer
add comment

Your Answer


