Nuevo proyecto: Tengo problemas para elegir un idioma para usar

Question

Estoy comenzando mi primera empresa independiente con fines de lucro. Estoy teniendo dificultades para decidir qué idioma usar. Quiero escribir mi aplicación en Perl, pero no creo que sea lo suficientemente simple de compilar. Si no lo escribo en Perl, lo escribiré en C++.

La aplicación tendrá muchas características, incluida la interfaz wxwidgets, acuerdo con SDL, temporizadores, algunos subprocesos y procesamiento de audio. El programa en sí será algo complejo, pero no terriblemente grande.

Así que mi pregunta son:

1. Puede PAR, perl2exe, o equivalente recopilar más de casos de prueba básicos?
2. Velocidad, y compilación aparte ¿por qué debería usar C++ sobre Perl?

---

Editar: Algunos de mis especificaciones del proyecto.

• Plataformas múltiples. Estoy esperando que el 50% o más de mis usuarios posean Mac, y la mayoría del resto son usuarios de Windows. Si es posible, también quiero apoyar a Linux ya que es mi sistema operativo de todos los días.
• Dado que es multiplataforma, necesito una herramienta de creación de GUI unificada. Necesita poder usar tipos básicos y permitirme crear manejadores de eventos personalizados y objetos personalizados de GUI.
• Necesita procesamiento de audio. Leer y jugar, wav y/o mp3. También usaré algunos algoritmos personalizados para determinar propiedades especiales de los archivos de audio; cosas como tempo, patrones, etc.
• Me gustaría pero no necesito soporte SDL/OpenGL.

Todo lo demás es bastante mundano. Algunas clases y contenedores diferentes. Algunos controles personalizados de GUI.

Answer 1

¿Por qué no utilizar un híbrido de ambos? En general, es la forma en que se está desarrollando mucho en estos días.

Sugeriría un combo Lua/C++ o Python/C++ (no estoy seguro de qué tan bien funciona un combo Perl/C++, pero esa también puede ser una buena opción).

Personalmente he hecho un montón con el combo Lua/C++ y es bastante fantástico.

Answer 2

Ir con C++. Timers, threading, audio, SDL, wxwidgets, estas son todas las cosas que Perl puede hacer, pero que en realidad no son excelentes. Además, PAR o perl2exe son mecanismos torpes para la distribución. Ellos trabajan, pero no son ideales. Mientras tanto, C++ (y recomiendo encarecidamente que use Boost) encajaría muy bien en este rol.

Answer 3

He usado PAR para empaquetar un importante programa Perl/Tk para Windows. Tomó un poco de toquetear, pero funcionó.

Si tiene al menos tanta experiencia en Perl como en C++, el desarrollo en Perl debería ser más rápido. Pero las velocidades de tiempo de ejecución para un programa equivalente serán más lentas. El resto de sus criterios pueden ser satisfechos por cualquiera, entonces yo diría que se trata de una elección personal.

Answer 4

¿No? Yo digo que no te metas en esto por mucho tiempo. Existen pros y contras de ir en cualquier dirección, pero parece que te estás acercando peligrosamente a la parálisis del análisis."Si nada más, voltea una moneda o elige la que creas que tiene el nombre más bonito.

Answer 5

Soy un programador de C++ y Perl. C++ es un lenguaje agradable, pero cada vez que tengo la opción, voy con Perl ya que el desarrollo sólo procede de manera mucho más rápida

Un par de comentarios:.

1. pAR, PerlApp y perl2exe no son compiladores son empaquetadores no hay compilador de Perl, excepto en sí Perl Si desea... alguna forma de bytecode del código de Perl, tendrás que esperar Perl 6 en Parrot.
2. Tengo uso d PAR para empaquetar una aplicación con un total de aproximadamente 500k SLOC, sin incluir perl. Funcionó bien, corrió la misma velocidad que Perl, pero el arranque fue más lento. Esto fue en 2005. Desde entonces, el rendimiento de inicio ha mejorado significativamente si instala el módulo Archive :: Unzip :: Burst en la máquina de desarrollo donde empaqueta el programa. He utilizado con éxito PAR para varias aplicaciones que varían en tamaño desde las más pequeñas hasta las 500k líneas antes mencionadas. Si necesita ayuda con PAR, hay una lista de correo activa y amigable. Solo haznos a nosotros y a ti el favor de no estar de acuerdo con "OMG, nada funciona, ayúdame, ¡kthx!". La gente lo hace todo el tiempo (y a veces aún recibe ayuda). :)
3. El enhebrado de Perl no es genial. Compruebe si algo como POE se ajusta a su factura. Soy un usuario de threads.pm, pero prefiero no serlo. Con las disculpas apropiadas al mantenedor trabajador, Jerry D. Hedden.
4. wxPerl está en una muy buena forma y hay una comunidad a su alrededor. Naturalmente, dado que wxWidgets es C++, siempre es un poco más actual y completo.
5. SDL Perl es un contenedor directo alrededor de la biblioteca. La (pequeña) documentación supone que ya la conoce. En mi experiencia, leer documentos para una biblioteca en un idioma diferente puede ser un poco molesto.
6. Los temporizadores están bien en perl: Time::HiRes
7. La portabilidad es difícil. Más aún en C++ que en Perl, pero siempre se trata de disciplina y de poder probar en muchas plataformas.
8. Para Perl en Windows, asegúrate de echar un vistazo a Strawberry Perl.

Answer 6

La función es importante. El código, independientemente del idioma, hará cosas similares, especialmente si usa las mismas bibliotecas y componentes. A menos que tenga la función exacta resuelta a través de bibliotecas y kits de herramientas, protéjuela en Perl.

Existe un argumento de que el desarrollo tomará menos tiempo en un lenguaje dinámico. Hay problemas similares en Perl y C++ al obtener un menú desplegable en el lugar correcto, llenándolo con los valores correctos, realizando el cambio apropiado en el estado del programa a partir de la entrada del usuario.

Si Perl no lo hace en ciertas plataformas, transforme el código en C++.

Probablemente hay algunos consejos que le ayudarán en este enfoque:

1. Eso significa que es probable que escribir el prototipo con OO Perl. Una vez que tenga la funcionalidad de alto nivel incorporada en una plataforma, siempre que pueda llegar tan lejos en Perl, entonces C++ es más o menos una optimización.

2. Quizás pueda restringir el prototipo a más o menos cognados de C++.Pero no estoy seguro de esto, puede descomponer un map en un bucle o incluso simplemente reemplazarlo con una función de filtro llamada con un puntero de función para una función de prueba.

Answer 7

Escriba su funcionalidad del núcleo en C++, a continuación, escribir el front-end para su aplicación en la herramienta para la plataforma en cuestión, es decir, Cocoa para Mac OS X, .NET/Delphi/MFC para Windows, etc.

Esta es mi forma preferida de desarrollar aplicaciones de escritorio multiplataforma. Por supuesto, sé muy poco acerca de lo que estás tratando de lograr, por lo que puede ser demasiado gordo para ti.

Answer 8

Una gran razón para usar Perl es la meta-programación.

Perl es lo suficientemente flexible como para permitirle escribir código para escribir código (así es como Moose hace su magia). Ahorrará tiempo y reducirá la cantidad de errores que necesita aplastar.

LA gran razón para usar Perl es CPAN.