Elegir un lenguaje de programación sistemáticamente [cerrado]

Estoy buscando una metodología para elegir un idioma. No estoy pidiendo opiniones sobre idiomas. Se me ha encomendado el proceso de comparar el idioma actual de nuestra tienda con otros que están disponibles. Somos una tienda de desarrollo web por cierto.

Nuestro CEO desea obtener un informe técnico completo sobre todos los idiomas disponibles en la web, de qué idioma principal derivan (por ejemplo, jsp es de java, que es de c / c ++). Necesito crear una matriz con todos los factores clave de un idioma en particular y las deficiencias de ese idioma. ¿El lenguaje está limitado por la plataforma, está diseñado para programación funcional, de procedimiento u OO o puede usarse con algún paradigma de programación?

También necesito tener información menos técnica, como el tamaño del grupo de talentos para un idioma determinado y el salario medio en ese grupo. ¿Cómo verá el mercado nuestra elección?

Comenzamos a buscar un consultor que nos ayudara a comprender todas estas cosas, pero descubrimos que la mayoría de los consultores provienen de un entorno de desarrollo y, a menudo, parece que la respuesta es " xxx es el mejor lenguaje porque es el que yo he usado más en los últimos n años y nunca me ha decepcionado. Podrías complementarlo con yyy para el front end y usar la biblioteca zzz "

Me siento abrumado con esta tarea y siento que el mejor curso de acción, dado lo que nuestro CEO está buscando, es mirar en el mundo académico y contratar a un profesor sin experiencia de desarrollo real para que venga y nos "enseñe". sobre todos los idiomas posibles.

¿Alguien más ha tenido que pasar por este ejercicio? Si es así, ¿puede compartir los pasos o la metodología que utilizó para realizar el proceso?

@FrustratedWithFormsDesigner insinuó esto arriba, seré más directo: te han acusado de una tarea costosa pero inútil.

Sospecho que el CEO está buscando evidencia objetiva e irrefutable que respalde su elección de idioma. El problema es que la preferencia del lenguaje está cargada con demasiados factores subjetivos y extrínsecos para que el documento sea significativo y mucho menos útil.

Dicho de otra manera, si hubiera un lenguaje ideal, todos lo usarían en lugar de esos lenguajes defectuosos "objetivamente". También muestra un cierto grado de microgestión que debería ser responsabilidad de los ingenieros que tendrán que hacerlo funcionar. Erlang podría ser el "objetivamente mejor", pero si nadie lo sabe, agregue un costo inicial de 6 meses / ingeniero y 6 meses más / ingeniero para ganar competencia.

Como no tengo tu trabajo, no me preocupa perderlo, aunque es posible que lo hagas. Le daría al CEO un documento sobre la Tesis de la Iglesia Física-Turing Luego me reuniría con los ingenieros superiores y obtendría su opinión no rigurosa ni objetiva sobre lo que debería usarse y le diría al CEO que eso es lo que debe usar. A cambio, usted promete que los ingenieros se mantendrán fuera de las reuniones de la junta, los directores financieros, los métodos de contabilidad, la selección de vicepresidentes, etc. Hay una razón por la que nos especializamos, y él no tiene más lugar en las preferencias de ingeniería que usted en su dominio.

Algunas pinceladas amplias a tener en cuenta:

Popularidad del idioma

Esto realmente no debería importar, porque la popularidad no necesariamente equivale a productividad, expresividad o cualquiera de las otras cualidades del idioma que importan más, pero esta consideración a menudo supera todas las demás consideraciones porque:

1. Es más fácil encontrar desarrolladores de software en un lenguaje popular.
2. Es más fácil encontrar herramientas y bibliotecas en un lenguaje popular.
3. Los tomadores de decisiones no entienden las compensaciones lingüísticas, por lo que tomarán una decisión segura ("muchas empresas usan este idioma, por lo que debe ser bueno").

Aplicabilidad al dominio del problema

Cualquier programa puede escribirse en cualquier lenguaje de programación completo de Turing, pero algunos idiomas son más adecuados para ciertos dominios problemáticos que otros. Si está escribiendo aplicaciones web, probablemente gravitará a idiomas y herramientas que sean adecuados para eso, y lo más probable es que sean lenguajes orientados a objetos.

Por otro lado, si va a escribir software que se basa principalmente en investigaciones o matemáticas, probablemente gravitará hacia lenguajes que adopten paradigmas funcionales .

Y, por supuesto, hay de todo. Muchos idiomas admiten múltiples paradigmas, y algunos patrones de software existen únicamente para superar las limitaciones en aquellos idiomas que carecen de ciertas características o paradigmas.

Expresividad y productividad.

Algunos idiomas son más expresivos que otros. Lo que se puede escribir en un idioma usando mil líneas de código se puede escribir en un lenguaje más expresivo usando cien líneas de código. La desventaja es que las cien líneas de código probablemente estén escritas en un lenguaje menos popular, por personas con mayor experiencia.

Muchas de las líneas de código presentes en lenguajes orientados a objetos utilizados para escribir aplicaciones de línea de negocio son ceremoniales. Esta ceremonia, aunque cuesta tiempo y esfuerzo para desarrollarse, también proporciona una estructura visible que de otro modo no sería evidente en un lenguaje más expresivo. Permite a las personas con menos experiencia de la que de otro modo necesitarían trabajar en el código con una cantidad reducida de riesgo.

La era de los múltiples idiomas.

Concluiré afirmando que el deseo de decidir sobre un solo idioma puede ser un falso dilema. Las solicitudes de hoy a menudo se escriben, no en una, sino en muchos idiomas. Cada idioma tiene sus propias fortalezas y (en teoría) está específicamente diseñado para la tarea que se está utilizando. Algunos dominios problemáticos (como la lógica del navegador web o el acceso a la base de datos) requieren idiomas específicos.

Hay razones comerciales para elegir un idioma, y ​​hay razones de ingeniería para elegir un idioma, y ​​los dos no siempre se encuentran. Es probable que arrojar razones académicas empeore las cosas. Dudo que un profesor pueda ayudarlo de la manera que lo necesite.

Los hechos sobre la ascendencia y las características de un idioma son bastante fáciles de encontrar. Probablemente podría pasar un día en wikipedia para completar la mayor parte de eso. El tamaño del grupo de talentos y el salario son más difíciles, porque la mayoría de las personas no se consideran programadores de un solo idioma. Las compañías que usan idiomas menos populares como Scala esperan contratar buenos programadores generales que no tengan experiencia específica en el idioma. A juzgar por algunas presentaciones que he visto, esa estrategia parece haber funcionado bien.

Incluso conocer los hechos todavía te deja con una elección bastante subjetiva. Su CEO va a querer reducirlo a una métrica aproximada, algo así como dólares por función. Para obtener una imagen precisa, tendrás que hacer algunos prototipos, luego hablar sobre lo fácil que fue aprender, lo rápido que fue escribir un prototipo una vez que aprendiste lo básico, lo fácil que crees que sería mantenerlo , y cuán ampliamente aplicable cree que sería para el tipo de trabajo que normalmente realiza.

En lugar de tratar de abarcar todos los lenguajes, buscaría representantes de los diferentes paradigmas de programación y tipos de marcos, e implementaría un prototipo en cada uno.

Aquí hay una lista aproximada de categorías de back-end:

• Microsoft (Puede tener subcategorías. No sé nada de ellas).
• OOP de peso pesado, como Drupal.
• OOP ligero, como la botella de pitón.
• Juega / levanta / scalatra usando Scala.
• Juega / levanta usando Java.
• Como la primavera.
• Struts-like.
• Como rieles.
• Basado en Haskell.
• Node.js

En el frente:

• JavaScript estilo OOP
• JavaScript de estilo funcional, como con el subrayado
• JavaScript de estilo reactivo, como con Bacon
• Kit de herramientas web de Google
• Olmo

Pasar un día o dos en cada categoría, implementando un prototipo simple, le tomaría un par de meses, después de lo cual tendría una idea mucho mejor de las fortalezas y debilidades de cada una. Quizás podría descartar algunas más rápidamente en función de la cultura o experiencia de su empresa.

Como se trata de un informe comercial, también me tomaría un tiempo buscar en Google cosas como "¿Qué idioma utiliza <empresa>", sustituyendo varias empresas que admira? Muchos de ellos han escrito sus propios documentos sobre por qué tomaron decisiones específicas de idioma, lo que sería una excelente referencia para que usted incluya.

Identifique y cueste las deficiencias inherentes a su proceso de desarrollo existente como $ A. Identifique el costo de cambiar a cualquier otro proceso de desarrollo como $ B.

Si $ A es menor que $ B, deténgase.

Si sus deficiencias conocidas superan el costo del cambio (¡y eso es un gran si!), Analice las deficiencias en detalle y comience a buscar cambios en el lenguaje / entorno de desarrollo / proceso de desarrollo que los aborde, uno que no presente otros problemas más costosos.

Para ser honesto, a menos que actualmente esté tratando de desarrollar aplicaciones web en Fortran, el único impacto que tendrá el lenguaje que use será en el costo de los contratistas que use para llenar los vacíos. La corriente principal y los procesos de desarrollo / herramientas / desarrollo maduros ya han resuelto la mayoría de los problemas a los que es probable que se enfrenten, ya que las herramientas más populares, nuevas y sexys vienen con los entrenadores y contratistas más caros, pero las soluciones menos maduras. Y si tiene deficiencias que justifiquen tal cambio, es poco probable que su elección de idioma las aborde por completo.

Sin embargo, si la rentabilidad no es el objetivo principal aquí, entonces debe tener en cuenta el estigma de ser considerado anticuado frente a los elogios de ser vanguardista. Pídale a su jefe los valores en dólares que usará para esta parte de la ecuación.