Neues Projekt: Ich habe Probleme beim Auswählen einer Sprache

Question

Ich beginne meine erste unabhängige für Profit-Venture. Mir fällt es schwer zu entscheiden, welche Sprache ich benutzen soll. Ich möchte meine App in Perl schreiben, aber ich denke nicht, dass es einfach genug ist, um es zu kompilieren. Wenn ich es nicht in Perl schreibe, schreibe ich es in C++.

Die Anwendung wird viele Funktionen haben, einschließlich wxwidgets Schnittstelle, Deal mit SDL, Timer, einige Threading und Audio-Verarbeitung. Das Programm selbst wird etwas komplex sein, aber nicht sehr groß.

Also meine Frage ist:

1. Kann PAR, Perl2exe oder gleichwertige kompilieren mehr als ein Testfall?
2. Geschwindigkeit und Kompilierung beiseite, warum sollte ich C++ über Perl verwenden?

---

Edit: Spezifikationen Einige meiner Projekt.

• Multiplattform. Ich erwarte 50% oder mehr meiner Benutzer, Macs zu besitzen, mit dem Rest der Mehrheit sind Windows-Benutzer. Wenn möglich, möchte ich auch Linux unterstützen, da es mein tägliches Betriebssystem ist.
• Da es Multi-Plattform ist, brauche ich ein einheitliches Tool zur GUI-Erstellung. Es muss in der Lage sein, grundlegende Typen zu verwenden, und ich kann benutzerdefinierte Ereignishandler und benutzerdefinierte GUI-Objekte erstellen.
• Es benötigt Audioverarbeitung. Lesen und abspielen, WAV's und/oder mp3's. Ich werde auch einige benutzerdefinierte Algorithmen verwenden, um spezielle Eigenschaften der Audiodateien zu bestimmen; Dinge wie Tempo, Muster und so weiter.
• Ich möchte, aber keine SDL/OpenGL-Unterstützung benötigen.

Alles andere ist ziemlich banal. Einige verschiedene Klassen und Container. Ein paar benutzerdefinierte GUI-Steuerelemente.

Answer 1

Warum nicht ein Hybrid von beiden verwenden? Es ist im Allgemeinen die Art und Weise, in der heutzutage viel entwickelt wird.

Ich würde vorschlagen, ein Lua/C++ oder ein Python/C++ - Combo (Ich bin mir nicht sicher, wie gut ein Perl/C++ - Combo funktioniert, aber das kann auch eine gute Option sein).

Persönlich habe ich eine Reihe mit der Lua/C++ - Kombination gemacht und es ist ziemlich fantastisch.

Answer 2

Gehen Sie mit C++. Timer, Threading, Audio, SDL, wxwidgets, das sind alles Sachen, die Perl machen kann, aber nicht wirklich übertrifft. Auch PAR oder Perl2exe sind klobig Mechanismen für die Verteilung. Sie funktionieren, aber sie sind nicht ideal. In der Zwischenzeit würde C++ (und ich kann Ihnen nur empfehlen, mit Boost zu arbeiten) gut in diese Rolle passen.

Answer 3

Ich habe PAR verwendet, um ein umfangreiches Perl/Tk-Programm für Windows zu packen. Es hat ein bisschen herumgespielt, aber es hat funktioniert.

Wenn Sie in Perl mindestens so erfahren sind wie in C++, sollte die Entwicklung in Perl schneller sein. Aber die Laufzeitgeschwindigkeiten für ein gleichwertiges Programm werden langsamer sein. Alle anderen Kriterien können erfüllt werden, also würde ich sagen, dass es auf die persönliche Entscheidung ankommt.

Answer 4

Persönlich? Ich sage, bleib nicht zu lange stehen. Es gibt Vor-und Nachteile in beide Richtungen, aber es klingt, als ob Sie gefährlich nah an "Analyse Paralyse stecken"."Wenn nichts anderes, drehen Sie eine Münze oder wählen Sie die, die Sie denken, hat den schönsten Namen.

Answer 5

Ich bin sowohl ein C + + und Perl-Programmierer. C + + ist eine nette Sprache, aber wann immer ich die Wahl habe, gehe ich mit Perl da die Entwicklung einfach mehr so ​​viel schneller geht

Ein paar Anmerkungen:.

1. PAR, PerlApp und perl2exe sind nicht Compiler Sie Verpacker sind Es gibt keine Perl-Compiler außer Perl selbst ist, wenn Sie wollen... Irgendeine Form von Bytecode-Form von Perl-Code, müssen Sie auf Perl 6 auf Parrot warten.
2. Ich habe Verwendung d PAR zum Verpacken einer Anwendung mit insgesamt ca. 500.000 SLOC, ohne Perl selbst. Es funktionierte gut, lief die gleiche Geschwindigkeit wie Perl selbst, aber der Start war langsamer. Das war 2005. Seitdem hat sich die Startleistung erheblich verbessert, wenn Sie das Archive :: Unzip :: Burst-Modul auf dem Entwicklungscomputer installieren, auf dem Sie das Programm packen. Ich habe erfolgreich PAR für verschiedene Anwendungen verwendet, die in der Größe von winzig bis zu den oben erwähnten 500k Linien variieren. Wenn Sie Hilfe bei PAR benötigen, gibt es eine aktive und freundliche Mailingliste. Gib uns und dir selbst den Gefallen, nicht mit "Oh Gott, nichts geht, hilf mir, kthx!" Die Leute machen das die ganze Zeit (und manchmal bekommen sie immer noch Hilfe). :)
3. Perl Threading ist nicht so toll. Prüfen Sie, ob etwas wie POE Ihrer Rechnung entspricht. Ich bin ein threads.pm Benutzer, aber ich möchte nicht sein. Mit entsprechenden Entschuldigungen an den hart arbeitenden Betreuer Jerry D. Hedden.
4. wxPerl ist in einem ziemlich guten Zustand und es gibt eine Gemeinschaft um ihn herum. Da wxWidgets C++ ist, ist es natürlich immer ein bisschen aktueller und vollständiger.
5. SDL Perl ist ein geradliniger Wrapper um die Bibliothek herum. Die (kleine) Dokumentation geht davon aus, dass Sie es bereits wissen. Meiner Erfahrung nach kann das Lesen von Dokumenten für eine Bibliothek in einer anderen Sprache ein wenig mühsam sein.
6. Timer sind in Perl fein: Time::HiRes
7. Portabilität ist schwer. Mehr in C++ als in Perl, aber es kommt immer darauf an, auf vielen Plattformen zu disziplinieren und zu testen.
8. Für Perl unter Windows, überprüfen Sie bitte Strawberry Perl.

Answer 6

Funktion ist wichtig. Code wird unabhängig von der Sprache ähnliche Aufgaben ausführen, insbesondere wenn dieselben Bibliotheken und Komponenten verwendet werden. Wenn Sie die genaue Funktion nicht über Bibliotheken und Toolkits ausgearbeitet haben, prototypieren Sie sie in Perl.

Es gibt ein Argument, dass die Entwicklung in dynamischen Sprachen weniger Zeit in Anspruch nimmt. Es gibt ähnliche Probleme in Perl und C++, wenn Sie an der richtigen Stelle eine Dropdown-Liste erstellen und sie mit den richtigen Werten füllen, um den Programmstatus durch Benutzereingaben zu ändern.

Wenn Perl es auf bestimmten Plattformen nicht ausführt, wandeln Sie den Code in C++ um.

Es gibt wahrscheinlich einige Hinweise, die in diesem Ansatz unterstützen würde:

1. Das bedeutet, dass Sie wahrscheinlich den Prototyp mit OO Perl schreiben würde. Sobald Sie die High-Level-Funktionalität auf einer Plattform festgelegt haben - vorausgesetzt, dass Sie in Perl so weit kommen - ist C++ mehr oder weniger eine Optimierung.

2. Vielleicht könnten Sie den Prototyp auf mehr oder weniger C++ - Verweise beschränken.Aber ich bin mir da nicht sicher, Sie können eine map in eine Schleife zerlegen oder sogar nur durch eine Filterfunktion ersetzen, die mit einem Funktionszeiger für eine Testfunktion aufgerufen wird.

Answer 7

Schreiben Sie Ihre Kernfunktionalität in C++, dann schreiben Sie die Front-End für Ihre Anwendung im Werkzeug für die Plattform in Frage, das heißt Cocoa für Mac OS X, .NET/Delphi/MFC für Windows, etc. .

Dies ist meine bevorzugte Methode zur Entwicklung von plattformübergreifenden Desktop-Anwendungen. Natürlich weiß ich so wenig über das, was Sie erreichen wollen, also könnte es für Sie zu dick sein.

Answer 8

Ein guter Grund, Perl zu verwenden, ist Meta-Programmierung.

Perl ist flexibel genug, um Code schreiben zu können, um Code zu schreiben (so macht Moose seine Magie). Sie sparen Zeit und reduzieren die Anzahl der Bugs, die Sie zum Squash brauchen.

Der große Grund, Perl zu verwenden, ist CPAN.