Nouveau projet: j'ai du mal à choisir une langue à utiliser

Question

Je commence ma première entreprise indépendante à but lucratif. J'ai du mal à décider quelle langue utiliser. Je veux écrire mon application en Perl, mais je ne pense pas qu'elle sera assez simple pour être compilée. Si je ne l'écris pas en Perl, je l'écrirai en C ++.

L’application comportera de nombreuses fonctionnalités, notamment l’interface wxwidgets , la gestion du langage SDL, des minuteries, des threads et traitement audio. Le programme lui-même sera un peu complexe, mais pas très volumineux.

Mes questions sont donc les suivantes:

1. PAR, Perl2exe ou son équivalent peuvent-ils compiler plus d’un scénario de test de base?
2. Vitesse et compilation à part, pourquoi devrais-je utiliser C ++ sur Perl?

Modifier: Certaines des spécifications de mon projet.

• Multi Platform. Je m'attends à ce que 50% ou plus de mes utilisateurs possèdent un Mac, le reste étant pour la plupart des utilisateurs de Windows. Si possible, je souhaite également prendre en charge Linux car il s’agit de mon système d’exploitation quotidien.
• Comme c'est une plate-forme multiple, j'ai besoin d'un outil de création d'interface graphique unifié. Il doit pouvoir utiliser les types de base et me permettre de créer des gestionnaires d'événements personnalisés et des objets d'interface graphique personnalisés.
• Cela nécessite un traitement audio. Lire et jouer, wav et / ou mp3. J'utiliserai également des algorithmes personnalisés pour déterminer les propriétés spéciales des fichiers audio. des choses comme le tempo, les motifs, etc.
• Je voudrais mais je n'ai pas besoin de la prise en charge de SDL / OpenGL.

Tout le reste est assez banal. Quelques classes et conteneurs différents. Quelques contrôles d’interface graphique personnalisés.

Answer 1

Pourquoi ne pas utiliser un hybride des deux? C’est généralement la façon dont beaucoup de développement se déroule de nos jours.

Je suggérerais un combo Lua / C ++ ou Python / C ++ (je ne suis pas certain de l'efficacité d'un combo Perl / C ++, mais cela pourrait également être une bonne option).

Personnellement, j’ai fait beaucoup de choses avec le combo Lua / C ++ et c’est vraiment fantastique.

Answer 2

Je suis à la fois programmeur C ++ et Perl. C ++ est un langage intéressant, mais chaque fois que j'ai le choix, je choisis Perl car le développement se déroule tellement plus rapidement.

Quelques commentaires:

1. PAR, perlapp et perl2exe ne sont pas des compilateurs. Ils sont emballeurs. Il n'y a pas de compilateur Perl sauf Perl lui-même. Si vous souhaitez utiliser une forme de code Perl en bytecode, vous devrez attendre Perl 6 sur Parrot.
2. J'ai utilisé PAR pour emballer une application avec un total d'environ 500k SLOC, sans perl lui-même. Cela fonctionnait bien, fonctionnait à la même vitesse que Perl, mais le démarrage était plus lent. C'était en 2005. Depuis lors, les performances de démarrage se sont considérablement améliorées si vous installez le module Archive :: Unzip :: Burst sur la machine de développement sur laquelle vous empaquetez le programme. J'ai utilisé avec succès PAR pour diverses applications de tailles différentes, allant des lignes minuscules aux lignes susmentionnées de 500k. Si vous avez besoin d'aide avec PAR, il existe une liste de diffusion active et conviviale. Faites juste nous et vous la faveur de ne pas sonner avec "OMG, rien ne fonctionne, aidez-moi, kthx!". Les gens le font tout le temps (et parfois, obtiennent encore de l'aide). :)
3. Le filetage de Perl n'est pas génial. Vérifiez si quelque chose comme POE correspond à votre facture à la place. Je suis un utilisateur de threads.pm, mais je préférerais ne pas l'être. Toutes nos excuses au responsable, Jerry D. Hedden.
4. wxPerl se porte plutôt bien et il y a une communauté autour. Naturellement, puisque wxWidgets est en C ++, il est toujours un peu plus actuel et complet.
5. SDL Perl est un wrapper direct autour de la bibliothèque. La (petite) documentation suppose que vous la connaissez déjà. D'après mon expérience, lire des documents pour une bibliothèque dans une langue différente peut être un peu fastidieux.
6. Les minuteries sont correctes en Perl: Time :: HiRes
7. La portabilité est difficile. Plus en C ++ qu'en Perl, mais cela revient toujours à la discipline et au fait de pouvoir tester sur de nombreuses plateformes.
8. Sous Windows, veillez à vérifier Strawberry Perl.

Answer 3

Allez en C ++. Les minuteries, les threads, l’audio, le SDL, les wxwidgets, voilà toutes les choses que Perl peut faire, mais n’excelle pas vraiment. En outre, PAR ou perl2exe sont des mécanismes de distribution peu pratiques. Ils travaillent, mais ils ne sont pas idéaux. Dans l'intervalle, C ++ (et je vous encourage vivement à utiliser Boost ) s'intégrerait parfaitement à ce rôle.

Answer 4

La méta-programmation est une bonne raison d'utiliser Perl.

Perl est suffisamment flexible pour vous permettre d’écrire du code pour écrire du code (c’est ainsi que Moose fait sa magie). Vous gagnerez du temps et réduirez le nombre de bugs nécessaires pour écraser.

La grande raison d'utiliser Perl est le CPAN.

Answer 5

J'ai utilisé PAR pour emballer un important programme Perl / Tk pour Windows. Il a fallu un peu de bidouillage, mais cela a fonctionné.

Si vous êtes au moins aussi expérimenté en Perl qu'en C ++, le développement en Perl devrait être plus rapide. Mais les vitesses d'exécution d'un programme équivalent seront plus lentes. Tous les autres critères peuvent être satisfaits par l'un ou l'autre, alors je dirais que c'est un choix personnel.

Answer 6

Personnellement? Je dis de ne pas rester coincé trop longtemps dessus. Il y a des avantages et des inconvénients à aller dans un sens ou dans l'autre, mais il semble que vous soyez sur le point de risquer de rester coincé dans une "paralysie de l'analyse". Si rien d’autre, lancez une pièce ou choisissez celle qui, selon vous, porte le plus joli nom.

Answer 7

La fonction est importante. Le code, quelle que soit la langue, fera des choses similaires, surtout si vous utilisez les mêmes bibliothèques et composants. Sauf si vous avez la fonction exacte élaborée à l'aide de bibliothèques et de kits d'outils, protégez-la en Perl.

Il existe un argument selon lequel le développement prendra moins de temps dans un langage dynamique. Il existe des problèmes similaires en Perl et en C ++, qui consiste à placer une liste déroulante au bon endroit, à la renseigner avec les bonnes valeurs et à modifier correctement l'état du programme à partir des entrées de l'utilisateur.

Si Perl ne le fait pas sur certaines plateformes, transformez le code en C ++.

Il existe probablement des indications utiles pour cette approche:

1. Cela signifie que vous écririez probablement le prototype avec OO Perl. Une fois que les fonctionnalités de haut niveau sont définies sur une plate-forme, à condition que vous puissiez aller aussi loin en Perl, le C ++ est plus ou moins une optimisation.

2. Peut-être pourriez-vous limiter le prototype à plus ou moins assimilable C ++. Mais je ne suis pas sûr à ce sujet, vous pouvez décomposer une map en une boucle ou même simplement la remplacer par une fonction de filtrage appelée par un pointeur de fonction pour une fonction de test.

Answer 8

Ecrivez votre fonctionnalité principale en C ++, puis le front-end de votre application dans l'outil de la plate-forme en question, à savoir Cocoa pour Mac OS X, .NET / Delphi / MFC pour Windows, etc.

C’est ma façon préférée de développer des applications de bureau multiplates-formes. Bien sûr, je sais très peu de choses sur ce que vous essayez d'accomplir, donc c'est peut-être trop gros pour vous.