El wiki de C2 tiene una discusión sobre la Evidencia Empírica para la Programación Orientada a Objetos que básicamente concluye que no hay nada más que apelar a la autoridad. Esto fue editado por última vez en 2008. La discusión aquí parece confirmar esto: las preguntas sobre si OO está desactualizado , cuando la programación funcional es una mala elección y las ventajas y desventajas de AOP se responden con las opiniones de los contribuyentes sin depender de la evidencia.
Por supuesto, las opiniones de profesionales establecidos y reputados son bienvenidas y valiosas, pero son más plausibles cuando son consistentes con los datos experimentales. ¿Existe esta evidencia? Sé que la ingeniería de software basada en evidencia es una cosa, pero ¿puedo practicarla en este contexto? Específicamente, si tengo un problema particular Pque quiero resolver escribiendo software, ¿existe un conjunto de conocimientos, estudios e investigaciones que me permitan ver cómo el resultado de resolver problemas Pha dependido de la elección del paradigma de programación?
Sé que el paradigma que aparece como "la respuesta correcta" puede depender de las métricas a las que presta atención un estudio en particular, en qué condiciones el estudio se mantiene constante o varía, y sin duda también en otros factores. Eso no afecta mi deseo de encontrar esta información y evaluarla críticamente.
Queda claro que algunas personas piensan que estoy buscando una solución de "girar la manivela", una máquina de salchichas en la que pongo información sobre mi problema y de la que surge una palabra como "funcional" o "estructurada". Esta no es mi intención. Lo que estoy buscando es investigar cómo, con muchas advertencias y suposiciones a las que no me referiré aquí, pero sí una buena literatura sobre el tema, ciertas propiedades del software varían según el problema y la elección del paradigma.
En otras palabras: algunas personas dicen que "OO da una mejor flexibilidad" o "los programas funcionales tienen menos errores" - (parte de) lo que estoy pidiendo es la evidencia de esto. El resto es pedir evidencia en contra de esto, o las suposiciones bajo las cuales estas declaraciones son verdaderas, o evidencia que demuestre que estas consideraciones no son importantes. Hay muchas opiniones sobre por qué un paradigma es mejor que otro; ¿Hay algo objetivo detrás de alguno de estos?
fuente
Respuestas:
Para la toma anterior, vea la Revisión 1 de esta respuesta . Sin embargo, los comentarios y ediciones de la pregunta aclaran aún más lo que busca la pregunta y me permiten ser más claro.
Sí, la ingeniería de software basada en evidencia (EBSE) es una cosa. Parece haber algunos esfuerzos hacia las bases de datos EBSE, como este en la Universidad de Durham y SEED, que fue iniciado por un profesor en Cal Poly . Todos estos esfuerzos, así como los discutidos en una serie de documentos que se pueden encontrar a través del servidor IEEE Xplore o la Biblioteca Digital ACM(se requiere suscripción o compra para muchos artículos en ambos), se basan en medicina basada en evidencia. Proporcionan revisiones de literatura de datos empíricos publicados (observación y experimento). De hecho, la inclusión de "revisión de literatura" en una cadena de búsqueda en cualquier búsqueda de publicación arroja información sobre la mayoría de los temas: más de 14000 visitas en el ACM y más de 1000 en la base de datos IEEE (cuando se limita solo a temas informáticos).
Al observar los tipos generales de temas discutidos en estas bases de datos EBSE y revisiones de literatura, veo un hilo común: tienden a ser independientes de la tecnología. El énfasis parece centrarse principalmente en el proceso y la metodología en lugar de las herramientas específicas utilizadas para llevar a cabo la ingeniería de software.
Entonces, este concepto existe en la ingeniería de software. La academia conoce el concepto basado en evidencia y puede aplicarlo con éxito a la ingeniería de software.
Específicamente, la pregunta aborda la aplicación de técnicas EBSE a la selección de un paradigma parece difícil, debido a la gran cantidad de variables involucradas, lo que obliga a hacer suposiciones y reduce la capacidad de repetir el experimento u observación. Se dice correctamente en la pregunta: "qué paradigma aparece como" la respuesta correcta "puede depender de las métricas a las que presta atención un estudio en particular, en qué condiciones el estudio se mantiene constante o varía, y sin duda también en otros factores" . Aunque eso no significa que estudiar qué paradigma es el "mejor" en una situación dada, hace que cualquier tipo de revisión de la literatura de estos documentos sea increíblemente difícil de completar y aún así extraer información a través de ellos.
Definitivamente, no existe una solución de "girar la manivela" para elegir un paradigma.
Dado un paradigma de programación, puede encontrar estudios en las diversas bases de datos académicas y de la industria sobre cómo ese paradigma influye en varios aspectos del desarrollo de software (calidad, defectos, eficiencia, etc.) en varias condiciones específicas, que van desde el conocimiento y la experiencia del equipo al dominio del problema. Cualquier trabajo riguroso debe identificar claramente las condiciones bajo las cuales se recopilaron los datos y los supuestos. El problema se convierte en tratar de aislar los factores que lo hacen bueno en cada una de esas condiciones.
Académicamente, hay algunas declaraciones que son fáciles de investigar. Por ejemplo, la afirmación de que el paradigma funcional se adapta bien a las aplicaciones que requieren concurrencia se deriva del teorema de Church-Rosser . Debido a esto, es probable que un sistema de software escrito en un lenguaje funcional tenga menos defectos relacionados con la concurrencia que el mismo sistema escrito en un lenguaje de procedimiento u orientado a objetos.
Sin embargo, desde un punto de vista práctico, un equipo de software no siempre puede usar "la mejor" herramienta o técnica para el trabajo solo porque la investigación lo indique. Aunque nos esforzamos por producir sistemas de software de la más alta calidad, operamos dentro de las limitaciones. A menudo, veo estas limitaciones minimizadas (o incluso eliminadas de la ecuación) cuando discuto la efectividad de cualquier metodología.
Como profesional, cuando estoy involucrado en la elección de tecnologías para usar, trato de identificar las mejores herramientas posibles. Pero luego me limito a lo que el equipo que tengo conoce y entiende bien. Volviendo a mi ejemplo anterior, si tengo un equipo bien versado en la creación de aplicaciones simultáneas en C ++ y no tengo experiencia en Haskell, no tiene sentido proponer la construcción del sistema en Haskell, ya que probablemente no pueda hacer restricciones de horario y presupuesto, y mi calidad probablemente sufrirá debido a la falta de experiencia en la cadena de herramientas.
En resumen, la ingeniería de software basada en evidencia es generalmente algo bueno que existe y las revisiones de literatura existen y están fácilmente disponibles. Sin embargo, hay aspectos de la ingeniería de software donde la aplicación de enfoques basados en evidencia ofrece poco valor. La selección de un paradigma de programación para un esfuerzo de desarrollo a gran escala es uno de estos.
Si desea averiguar cómo la orientación a objetos aborda la reutilización o los defectos en la programación funcional, encontrará fácilmente publicaciones sobre ellos. Sin embargo, no encontré (ni confiaría) una publicación que fuera capaz de abordar con eficacia la selección de paradigmas en la amplia gama de proyectos de ingeniería de software del mundo real.
fuente
He estado leyendo The Art of Unix Programming por Eric S. Raymond. Tiene algunas ideas históricas muy interesantes sobre cosas que ahora damos por sentado. Cita algunos buenos estudios del software IEEE que utilizan evidencia empírica como la densidad de defectos. Esa podría ser una buena fuente si está buscando estudios de estilo académico.
Incluso las técnicas como la modularización utilizando funciones no siempre fueron una práctica común. Una de mis citas favoritas del libro hasta ahora:
Sin embargo, realmente hay dos problemas para volverse demasiado empírico. El primero es que la calidad del código es algo muy subjetivo. El código puede ser terrible y aún así ser correcto. La percepción de las personas de un paradigma de programación es una métrica muy válida, porque el código está escrito para que las personas lo lean tanto como para las computadoras, si no más.
El segundo problema es que el 50% de los desarrolladores tienen un talento de programación por debajo del promedio. No importa si su desarrollador principal es más productivo utilizando la programación funcional si la "chusma" tiene dificultades para escribir software de trabajo que lo use, y mucho menos un software hermoso y bien diseñado. Del mismo modo con los lenguajes de programación TMTOWTDI , su desarrollador principal todavía va a escribir código limpio y modular, pero los codificadores menos talentosos escriben ruido de línea debido a la falta de estructura impuesta.
Es por eso que creo que OOP ha alcanzado la cima en popularidad a pesar de sus deficiencias. No es tan restrictivo que obstaculiza a los más talentosos, pero su estructura proporciona una forma concisa de comunicarse e imponer buenos principios de diseño a los menos talentosos.
En nuestra línea de trabajo, tenemos una tendencia a evaluar una solución basada demasiado en sus méritos técnicos. Un esfuerzo exitoso también tiene que dar cuenta del lado humano de la ecuación.
fuente
Hay concursos de programación que utilizan un sistema de clasificación por computadora y le permiten escribir en varios idiomas y publicar todo tipo de resultados y cosas. Apuesto a que tienen buenos datos para ti. Aquí hay una lista de 8: http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/
Me imagino que puede hacer comparaciones significativas de soluciones a problemas muy simples y claros, como la suma de cuadrados o series de Fibonacci, o dibujar una línea recta usando el algoritmo de línea de Bresenham. La mayoría de las tareas de programación del mundo real no tienen publicaciones de objetivos tan claras y cada idioma tiene sus puntos clave. Gran parte del beneficio de un idioma es subjetivo. Puede encontrar datos más significativos al encuestar la felicidad del programador y del cliente que contando líneas de código o números de defectos.
Recuerdo que cuando pasé medio día escribiendo uno de mis primeros programas Awk, pensé que me habría llevado una semana completa hacer lo "mismo" en Java. Pero eso se debe a que mi solución Java se habría centrado en ser robusta, ya que la solución Awk era rápida y sucia y requería algunos ajustes manuales en la entrada y la salida, y era realmente desechable cuando terminé. Awk y Java son geniales, pero no por lo mismo.
Supongo que lo que digo es que para las aplicaciones del mundo real, comparar idiomas o herramientas de manera significativa es extremadamente difícil: el viejo problema de las manzanas y las naranjas. ¡Buena suerte! Me encantaría ver lo que descubres.
fuente
He estado estudiando diferentes formas de desarrollar software durante más de 30 años. Hay una escasez de buena evidencia publicada sobre la elección de un paradigma.
Puse una gran bibliografía ASCII de búsqueda. Esto incluye muchos documentos y artículos IEEE y ACM. Etiqueto los artículos con el tipo de evidencia proporcionada. Aquí están las etiquetas más comunes:
Ahora busque PARADIGM y cuente las etiquetas
Si quieres profundizar, http://cse.csusb.edu/dick/lab.html y espero que te ayude ...
fuente
Parece que en muchos casos no hay un corpus de investigación lo suficientemente grande o de calidad suficiente como para permitir conclusiones generales acerca de si una práctica en ingeniería de software es mejor que otra. Estaba buscando específicamente investigación para trabajar en diferentes paradigmas, pero la falta de disponibilidad no se limita a ese ámbito, por lo que formularé mi respuesta en un sentido más amplio.
Un artículo de 2004, Ingeniería de software basada en evidencia de Kitchenham et al , cubre de manera bastante sucinta los beneficios que se derivan de un enfoque basado en evidencia y los problemas con su implementación en la ingeniería de software. No discutiré el lado de los beneficios aquí (está claro por la pregunta que me gustaría poder trabajar de esta manera), pero los problemas son relevantes como respuesta a la pregunta que hice.
Entonces la respuesta que busco es "no", la evidencia que estoy buscando probablemente no existe. Debería elegir mi paradigma basado en los criterios populares existentes de lo que sé, lo que es genial y la opinión experta.
fuente
No creo que este tipo de estudio exista. Uno podría creer que no es el paradigma de programación lo que importa tanto como el algoritmo real que se utiliza. Por ejemplo, dado cualquier sistema no trivial, uno que se basa en algoritmos de espacio pequeño, el versículo uno que se basa en algoritmos de tiempo pequeño generaría diferentes métricas. El que tenga el mejor momento probablemente se considerará más válido, a menos que el espacio sea un problema, entonces lo inverso es cierto. Me parece similar a pavimentar una carretera. Si bien el algoritmo o la receta para hacer los materiales es constante en todos los procesos, sería posible que una empresa piense que pavimentar dos carriles a la vez (uno a cada lado de la carretera) es mejor que pavimentar dos carriles en el mismo lado de la carretera a la vez . Al final del día, no importa, ya que el proceso de hacer la parte superior negra sigue siendo el mismo, La única diferencia es el enfoque. Volviendo a la programación, si tiene un equipo de desarrolladores de C, escriba el código de manera procesal, si tiene un equipo de desarrolladores de Java, escríbalo en OO. No se obsesione con el paradigma tanto como con la implementación del algoritmo. Porque al final del día puedes escribir Java como C e intentar escribir C como Java.
ACTUALIZAR
Para responder al comentario, Graham me dejó:
Supongo que por arquitectura te refieres al paradigma de programación. Si va a utilizar Clojure, tal vez debería contratar a un equipo de programadores de Clojure. Sin embargo, basado en una búsqueda rápida, Clojure es un lenguaje basado en Java que resulta ser funcional. Dada esa información, tomaría los programadores de Java (ya que técnicamente pueden escribir Java y le dará los mismos resultados) o buscar programadores funcionales como los desarrolladores de Haskell. Ahora, en términos de elegir lo que es mejor, depende completamente de su equipo. Nunca tendría un equipo de expertos en bases de datos relacionales que organizara una solución en la nube para mí ni un equipo de programadores funcionales que crearan una solución orientada a objetos para mí. Tienes que usar las fortalezas del equipo, no tienes la visión glorificada que tienes en tu cabeza para lo que un equipo "debería"
fuente
Diferentes paradigmas conducen a diferentes soluciones. El mejor ajuste depende en gran medida de:
No conozco ningún estudio definitivo, e incluso si hubiera uno, no confiaría en él.
Ese es el trabajo del arquitecto.
Reemplazar la sabiduría del arquitecto con las conclusiones posiblemente irrelevantes de un estudio es una receta para el desastre.
Nota: un comentario menciona decidir sobre "el algoritmo" y luego elegir el idioma. Los algoritmos son el mecanismo estructural central para los lenguajes de procedimiento. Los lenguajes orientados a objetos se centran en clases y patrones de colaboración / comunicación. Si está convencido (como arquitecto) de que una solución centrada en algoritmos es 'la mejor', entonces quédese con lenguajes de procedimiento o funcionales.
Anexo: no confiar en los estudios no es 'superstición', es sentido común. Los experimentos científicos deben ser objetivos y repetibles. Los proyectos de software son muy subjetivos, pero peor aún, son experimentos irrepetibles . Simplemente no puede implementar un proyecto X con el equipo Y, medir los resultados y luego retroceder el tiempo, borrar recuerdos y volver a hacer el mismo proyecto con el mismo equipo. La información descubierta o implícita en los estudios puede ser útil para el arquitecto, pero nunca puede ser definitiva.
fuente