New project: I am having troubles picking a language to use.

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.