A menos que sea inevitable, es una mala idea usar varios idiomas. Debe elegir un lenguaje de programación principal, utilizándolo para el sistema principal, mientras usa lenguajes especializados cuando el principal no es adecuado.
Este es un error importante que muchas personas cometen al diseñar el back-end: ir felices con el idioma. Para más del 99% de los programas que escribo, uso Java para el back-end.
Escribimos una pequeña parte de una de nuestras aplicaciones en C (aproximadamente 150 líneas de 100k líneas), con uno de nuestros triunfos de reescritura en los últimos 1.5 años que implica descubrir cómo eliminar la necesidad de esas 150 líneas de C.
- ¿PHP tiene marcos front-end o back-end?
- ¿Debo continuar con el desarrollo front-end o cambiar al backend?
- ¿Cuáles son los pros y los contras en la implementación de código frontend y backend en dos aplicaciones Heroku separadas?
- ¿Cuál es la mejor solución de fondo para una aplicación basada en chat como WhatsApp?
- ¿Son condicionales y booleanos la misma cosa?
La eliminación solucionó casi todos los problemas de errores operativos en el sistema. Ver la respuesta de Marcas Neal a Joel Spolsky escribió una publicación de blog muy compartida “Cosas que nunca debes hacer, Parte I”, sugiriendo que reescribir grandes proyectos puede ser un gran error. ¿Ha habido momentos en que no fue así?
En cuanto a la cuestión práctica de los proyectos de desarrollo reales, si * DEBE * tratar con varios idiomas, a menudo se queda atascado usando archivos como fuentes de datos intermedias.
En el sistema descrito anteriormente, por ejemplo, tuvimos que usar un archivo temporal para cerrar la brecha entre Java y un ejecutable en C, porque JNI no pudo manejarlo por razones de seguridad.
Como estaba basado en la web, nos enfrentamos a todo tipo de problemas de concurrencia desagradables y difíciles de resolver … No es un asunto trivial rastrear sesiones en múltiples ejecutables en varios idiomas.
Debe tener una excelente gestión de compilación y sistemas de control de versiones, mucho mejor que Make y Git. Por eso usamos Aegis / Cook; ningún otro sistema de gestión de cambios o herramienta de gestión de dependencias (la clase de herramienta creada) maneja las cosas correctamente.
