Nuevo proyecto: tengo problemas para elegir un idioma para usar

Question

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

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

Entonces mis preguntas son:

1. ¿Puede PAR, Perl2exe o equivalente compilar más que un caso de prueba básico?
2. Velocidad y compilación aparte ¿por qué debería usar C ++ sobre Perl?

---

Editar: Algunas de las especificaciones de mi proyecto.

• Plataforma múltiple. Espero 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 admitir Linux, ya que es mi sistema operativo cotidiano.
• Dado que es multiplataforma, necesito una herramienta de creación de GUI unificada. Debe poder usar tipos básicos y permitirme crear controladores de eventos personalizados y objetos GUI personalizados.
• Necesita procesamiento de audio. Leer y reproducir, wav y / o mp3. También utilizaré algunos algoritmos personalizados para determinar las 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 de GUI personalizados.

Answer 1

¿Por qué no usar un híbrido de ambos? En general, es la forma en que avanza mucho el desarrollo 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

Soy programador de C ++ y Perl. C ++ es un lenguaje agradable, pero cada vez que tengo la opción, elijo Perl, ya que el desarrollo simplemente avanza mucho más rápido.

Un par de comentarios:

1. PAR, perlapp y perl2exe no son compiladores. Ellos son empacadores. No hay compilador de Perl, excepto el propio Perl. Si desea algún tipo de código de bytes del código Perl, tendrá que esperar a Perl 6 en Parrot.
2. He usado PAR para empaquetar una aplicación con un total de aproximadamente 500k SLOC, sin incluir el propio Perl. Funcionó bien, corrió a la misma velocidad que Perl, pero el inicio 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 pequeñas hasta las mencionadas líneas de 500k. Si necesita ayuda con PAR, hay una lista de correo activa y amigable. Solo haznos a ti y a ti mismo el favor de no intervenir con '' OMG, nada funciona, ¡ayúdame, kthx! ''. La gente hace eso todo el tiempo (y a veces todavía recibe ayuda). :)
3. Los hilos de Perl no son geniales. Comprueba si algo como POE se ajusta a tu factura. Soy un usuario de threads.pm, pero prefiero no serlo. Con las disculpas correspondientes al responsable de mantenimiento, Jerry D. Hedden.
4. wxPerl está en 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 complicado.
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 en realidad siempre se reduce a la disciplina y la capacidad de probar en muchas plataformas.
8. Para Perl en Windows, asegúrese de revisar Strawberry Perl.

Answer 3

Ve con C ++. Temporizadores, subprocesos, audio, SDL, wxwidgets, estas son todas las cosas que Perl puede hacer, pero realmente no se destacan. Además, PAR o perl2exe son mecanismos torpes para la distribución. Funcionan, pero no son ideales. Mientras tanto, C ++ (y le recomiendo que considere usar Boost ) encajaría perfectamente en este rol.

Answer 4

Una buena razón para usar Perl es la metaprogramación.

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

La gran razón para usar Perl es CPAN.

Answer 5

He usado PAR para empaquetar un programa sustancial Perl / Tk para Windows. Tomó un poco de violín, 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 ejecución para un programa equivalente serán más lentas. Todos los demás criterios se pueden satisfacer por cualquiera de ellos, por lo que diría que se trata de una elección personal.

Answer 6

¿Personalmente? Yo digo que no te quedes atascado en esto por mucho tiempo. Hay ventajas y desventajas de ir en cualquier dirección, pero parece que te estás acercando peligrosamente a estar atrapado en "parálisis de análisis". Por lo menos, lanza una moneda o elige la que creas que tiene el nombre más bonito.

Answer 7

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 elaborada a través de bibliotecas y kits de herramientas, prototipo en Perl.

Hay un argumento de que el desarrollo llevará menos tiempo en lenguajes dinámicos. Hay problemas similares en Perl y C ++ al obtener un menú desplegable en el lugar correcto, llenándolo con los valores correctos, haciendo el cambio adecuado en el estado del programa desde la entrada del usuario.

Si Perl no lo está haciendo en ciertas plataformas, transforme el código a C ++.

Probablemente hay algunos indicadores que ayudarían en este enfoque:

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

2. Quizás podría 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 reemplazarlo con una función de filtro llamada con un puntero de función para una función de prueba.

Answer 8

Escriba su funcionalidad principal en C ++, luego escriba 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 sobre lo que está tratando de lograr, por lo que puede ser demasiado gordo para usted.