Evidencia empírica para elegir el paradigma de programación para abordar un problema

11

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?

Comunidad
fuente
1
Buscar en la Web para la ingeniería de software basadas en la evidencia muestra los enlaces abundancia
mosquito
@gnat EBSE se trata de resumir sistemáticamente la literatura y sacar conclusiones generales sobre cómo podríamos mejorar la práctica. Mi pregunta es si esa literatura existe; si hay suficiente para que las revisiones sistemáticas o los metaanálisis sean productivos.

Respuestas:

12

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.

Thomas Owens
fuente
La sección sobre la integridad de Turing ignora las compensaciones, que es lo que quiero ver en público y comparado. Déjame darte un ejemplo específico. Mucha gente me dice que la programación funcional es excelente para evitar errores de concurrencia. Ahora encontramos que Scheme es, como Pascal, Turing completo. Por lo tanto, debería ser posible escribir código seguro de concurrencia de manera procesal. Convenido. ¿Pero es genial ? ¿Hay ventajas en elegir un método? ¿Se pueden medir tales ventajas?
1
@GrahamLee Confirmar o rechazar su hipótesis requiere evidencia objetiva, que no existe. Existen razones subjetivas para crear un nuevo paradigma y un nuevo modelo de representación de las mismas capacidades computacionales, y esto no se limita a los lenguajes de programación, sino también a la representación matemática subyacente de dichos lenguajes . Esas razones objetivas incluyen apuntar a un grupo demográfico particular (matemático computacional versus analista de negocios; su forma de pensar es diferente requiere un paradigma diferente).
Thomas Owens
2
@Thomas: su implicación de que las prácticas de programación son exclusivamente opacas para la ciencia es peculiar. Hay mucha investigación en curso. Un ejemplo muy citado es el grupo de investigación de Lutz Prechelt . No conozco el área lo suficientemente bien como para saber si alguien ha abordado las preguntas específicas de Graham, pero no hay razón para creer que no sean manejables para el tipo de métodos utilizados por Prechelt y otros.
Cris
1
@ Chris No creo que sean opacos para la ciencia. Sin embargo, creo que hay algunas cosas que cuando usted, como dice Graham en la pregunta, agrega "muchas advertencias y suposiciones" a la investigación, ya no es útil para los profesionales. En ese punto, desde una perspectiva práctica, en las trincheras, es simplemente más efectivo basar sus decisiones en la historia y la experiencia. Tener datos buenos, duros y válidos es algo muy bueno. Pero llega un punto en que es demasiado difícil de obtener o solo es válido en una situación muy específica que no es útil para la industria.
Thomas Owens
1
@ Thomas, lo dudo. La práctica médica general es al menos tan situacional y sensible al contexto como lo es la ingeniería de software, y, er, la evidencia está aumentando que la GP basada en evidencia produce mejoras medibles. Es en gran medida una cuestión de la cantidad y calidad de la investigación.
Cris
7

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:

Dennis Ritchie alentó la modularidad diciendo a todos y cada uno que las llamadas a funciones eran realmente muy baratas en C. Todos comenzaron a escribir pequeñas funciones y modularizar. Años después descubrimos que las llamadas a funciones seguían siendo caras en el PDP-11, y el código VAX a menudo pasaba el 50% de su tiempo en la instrucción CALLS. ¡Dennis nos había mentido! Pero fue demasiado tarde; todos estábamos enganchados ...

- Steve Johnson

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.

Karl Bielefeldt
fuente
"la calidad del código es algo muy subjetivo", coincidió: hay que tener cuidado con lo que se mide, y la percepción es un factor importante. Pero la percepción, como muchas otras cosas, también es maleable: observe el aumento y la caída y el aumento de la programación funcional para ver que lo que las personas piensan de cómo trabajan no está directamente relacionado con su forma de trabajar. También he estado releyendo recientemente TAOUP. Parte de mi motivación para esta pregunta es ver en la literatura temprana soluciones a problemas actuales en la ingeniería de software.
+1, "El segundo problema es que el 50% de los desarrolladores tienen un talento de programación inferior al promedio". Esta oración es un alivio para mí. Es mejor que muchas pastillas que probé :)
NoChance
3

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.

GlenPeterson
fuente
2

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:

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

Ahora busque PARADIGM y cuente las etiquetas

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

Si quieres profundizar, http://cse.csusb.edu/dick/lab.html y espero que te ayude ...

Richard John Botting
fuente
1

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.

  • en primer lugar, si no eres miembro de la ACM, entonces probablemente no puedas leer el enlace anterior, que cubre el primer problema: no toda la investigación existente está realmente disponible para los profesionales.
  • gran parte de la práctica de ingeniería de software se desarrolla en secreto como parte de procesos comercialmente confidenciales, por lo que no hay visibilidad sobre lo que funcionó o no para esas personas.
  • la ingeniería de software es una práctica especializada, por lo que es difícil (no imposible, simplemente difícil) organizar un estudio adecuadamente cegado.
  • Las diferentes partes del ciclo de vida del software afectan los resultados de los demás en una medida que es difícil de controlar en cualquier experimento.
  • Como lo demuestran las discusiones aquí, muchos profesionales no ven "la literatura" (o el lado académico de la ingeniería de software en general) como relevante para su trabajo.

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
2
del resumen del artículo citado, el énfasis es mío: "El factor de habilidad significa que los experimentos de ingeniería de software son vulnerables al sesgo del sujeto y del experimentador . El factor del ciclo de vida significa que es difícil determinar cómo se comportarán las tecnologías una vez implementadas . Conclusiones: la ingeniería de software se beneficiaría de adoptando lo que pueda del enfoque de la evidencia siempre que se trate de los problemas específicos que surgen de la naturaleza de la ingeniería de software ". A lo que añadiría: ¡buena suerte con eso! ;)
Steven A. Lowe
Steven: parte de la motivación detrás de EBSE es pasar de "puedo adivinar los siguientes problemas, por lo tanto, rechazaré cualquier posibilidad de que su solución funcione" para analizar los resultados por sus propios méritos. Hay mucho más en un artículo que su resumen.
2
Agradezco tu entusiasmo. La ciencia médica y el desarrollo de software son disciplinas radicalmente diferentes. Si bien la analogía es interesante, apenas es innovadora. El documento completo está disponible aquí labada.inf.utfsm.cl/~gvaldes/ESE/docs/… La Sección 5 refleja el desajuste de impedancia mencionado en el resumen. Un mapeo más directo de las técnicas médicas sería depurar los sistemas existentes, no construir nuevos. ;) Si quieres crear mejores productos, crea mejores equipos. La gente es mucho más importante que las herramientas (cf Peopleware)
Steven A. Lowe
1
Anexo: el sitio EBSE tiene información útil, dur.ac.uk/ebse/evidence.php sería especialmente útil para los nuevos en el campo SE, pero tome las encuestas con un bloque de sal, porque (1) la evidencia disponible es escaso y (2) los resultados promedio pueden no ser relevantes para el desempeño de su equipo de individuos específicos con habilidades y aptitudes altamente especializadas.
Steven A. Lowe
0

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"

Woot4Moo
fuente
¿Cómo elijo si contratar un equipo de programadores Java o un equipo de programadores C? ¿Debería volver a entrenarlos en Clojure? Una vez que he elegido mi algoritmo, ¿qué arquitectura es la "mejor" forma de encapsularlo en una solución de software, para valores dados de "mejor"?
@GrahamLee ver mi actualización
Woot4Moo
Siento que estamos discutiendo el mismo problema pero a diferentes niveles de abstracción. "Usar las fortalezas del equipo que tienes" hubiera significado nunca construir una computadora, porque Bletchley Park no tenía a nadie con fuerza para construir computadoras. A veces tienes que decir "podríamos crear una mejor solución si usáramos esto "; lo que busco es la información sobre esos casos.
0

Diferentes paradigmas conducen a diferentes soluciones. El mejor ajuste depende en gran medida de:

  • la solución
  • el equipo de desarrollo
  • el entorno operacional

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.

Steven A. Lowe
fuente
1
Entonces, ¿está fuera del alcance de un arquitecto buscar trabajo previo sobre el cual construir su opinión? Probablemente no, de ahí la cuestión de si se pueden encontrar esos resultados y dónde.
2
Si hubiera un estudio definitivo con un método experimental razonable, los resultados del estudio podrían ser interesantes; tal como está, estas respuestas parecen indicar que cualquier estudio no tiene valor, independientemente del método que sea demasiado poco científico para mi gusto
jk.
3
@ Steven: la palabra para no confiar en los resultados de un estudio verdaderamente definitivo es 'superstición'. Quizás lo que realmente quiere decir es que no cree que alguna vez pueda haber estudios definitivos en SE (cuya declaración obviamente requeriría una gran cantidad de evidencia bien respaldada).
Cris
1
La calidad de un método de software está en qué tan bien se ajusta a la necesidad humana local. En general, no está limitado por las leyes de la física (Scotty). Pasará mucho tiempo antes de que el 'software' [disciplina] logre destilar sus leyes fundamentales inmutables. Por ejemplo, consulte "Métricas de calidad del software: tres métricas perjudiciales y dos métricas útiles" en ppi-int.com/newsletter/SyEN-046.php#feature y ppi-int.com/newsletter/SyEN-047.php#feature
Philip Oakley
1
@Cris: Para el registro, no, no creo que pueda haber un estudio verdaderamente definitivo en esta área; ver apéndice. La idea de que se puede utilizar un estudio "definitivo" en lugar del juicio experto para tomar una decisión arquitectónica crítica es "apelar a la autoridad", que es una forma de falacia lógica :) En mi experiencia, y no estoy haciendo una cobija acusaciones, solo una observación: la búsqueda de tales cosas suele ser un intento de evitar la responsabilidad de una decisión o un intento de apoyar una decisión que ya se ha tomado.
Steven A. Lowe