Las guerras de los lenguajes de programación
Preguntas y responsabilidades para la comunidad de lenguajes de programación
Andreas Ste fi k
Universidad de Nevada, Las Vegas, EE. UU.
ste fi ka@gmail.com
Resumen
La disciplina de la informática tiene una historia larga y complicada con los
lenguajes de programación informática. Históricamente, los inventores han
creado productos lingüísticos por una amplia variedad de razones, desde
intentos de facilitar tareas específicas de dominio o logros técnicos, hasta
razones económicas, sociales o políticas. Como consecuencia, la industria de
los lenguajes de programación modernos ahora tiene una gran variedad de
lenguajes de programación incompatibles, cada uno de los cuales tiene una
sintaxis, semántica, conjuntos de herramientas únicos y, a menudo, sus
propias bibliotecas estándar, vida útil y costos. En este artículo, sugerimos
que las guerras de los lenguajes de programación, un término que describe la
amplia divergencia y el impacto de los diseños de los lenguajes, incluidas las
afirmaciones a menudo pseudocientíficas de que son buenos o malos,
pueden tener un impacto negativo en el mundo. Este amplio problema,
Descriptores de Sujeto y Categorias D.3 [ Programación
Idiomas]; H.1.2 [ Sistemas de información]: Sistemas de usuario / máquina -
Psicología del software
Términos generales Idiomas, factores humanos, experimentación
Palabras clave Las guerras de los lenguajes de programación; Estabilidad de la literatura
académica; Estándares de evidencia
1. Introducción
"Nos rodea y nos penetra; une a la galaxia ".
- Obi-Wan Kenobi en Star Wars
La sociedad moderna ha experimentado una transformación significativa con respecto a la
disciplina del descubrimiento científico. El advenimiento
El permiso para hacer copias digitales o impresas de todo o parte de este trabajo para uso personal o en el aula se
otorga sin cargo siempre que las copias no se hagan o distribuyan con fines lucrativos o comerciales y que las copias
lleven este aviso y la cita completa en la primera página. . Se deben respetar los derechos de autor de los
componentes de este trabajo que son propiedad de terceros distintos del autor. Se permite resumir con crédito.
Copiar de otra manera, o volver a publicar, publicar en servidores o redistribuir a listas, requiere permiso específico
previo y / o una tarifa. Solicite permisos a permissions@acm.org.
¡Adelante! 2014, 20-24 de octubre de 2014, Portland, OR, EE. UU.
Los derechos de autor pertenecen al propietario / autor (es). Derechos de publicación con licencia para ACM. ACM
978-1-4503-3210-1 / 14/10. . . $ 15,00.
http://dx.doi.org/10.1145/2661136.2661156
283
Stefan Hanenberg
Universidad de Duisburg-Essen, Alemania
stefan.hanenberg@icb.uni-due.de
de las computadoras ha dado lugar a industrias prósperas para la creación de ideas
nuevas e innovadoras. En biología, los chips que procesan conjuntos de datos tan
grandes que eran impensables hace 20 años ahora se analizan fácilmente. Los
psicólogos, los investigadores médicos, los físicos y toda la industria del software
utilizan regularmente los cálculos como parte fundamental del trabajo diario. Sin las
tecnologías que nuestra comunidad inventa como base fundamental, las innovaciones
en algunas disciplinas, como las del Gran Colisionador de Hadrones, serían
efectivamente imposibles de evaluar. En cierto sentido, los lenguajes de programación
unen a la galaxia, otorgando un papel crucial que ninguna otra disciplina puede
reclamar.
Como científicos de la computación, aunque tenemos muchos roles con respecto
a estas innovaciones, uno es quizás el más crucial:
somos los administradores de la computación. Por administrador, queremos decir que
los científicos informáticos, y especialmente los diseñadores de lenguajes de
programación, han creado productos que son fundamentales para los avances en casi
todas las áreas de la ciencia, que influyen enormemente en la informática académica y
provocan cambios sísmicos en toda la industria del software. Los lenguajes que
creamos proporcionan la base de cómo explicamos a la computadora lo que nos
gustaría que hiciera.
Desafortunadamente, como es cada vez más obvio para algunos, la disciplina
de las ciencias de la computación no ha podido o no ha querido resolver muchos de
los problemas básicos de los lenguajes de programación, quizás notablemente,
identificando el impacto de diseños de lenguaje específicos en las personas. Como
resultado, encontramos nuestra disciplina en una situación en la que diferentes
desarrolladores e investigadores dedican tiempo a un conjunto divergente de
productos lingüísticos. Debido a una variedad de factores complejos que
discutiremos, luego encontramos disputas acaloradas en diferentes lugares (por
ejemplo, academia, conferencias, oficinas) donde grupos en competencia
argumentan a favor o en contra de lenguajes o características particulares, a
menudo con poca evidencia para respaldar afirmaciones contrapuestas. En
términos generales, estos y muchos otros problemas forman la base de las guerras
de los lenguajes de programación, que causan una variedad de males sociales.
Considere por un momento lo que realmente ocurre hoy con respecto al uso del
lenguaje de programación en la práctica. En el mundo académico, los estudiantes aprenden
muchos productos lingüísticos, algunos de los cuales se abandonan, reemplazan o
cambian rápidamente. Los productos educativos se crean y promocionan incluso si los
inventores nunca
 presentó cualquier evidencia sobre el impacto del diseño en programadores o
estudiantes. En las comunidades profesionales, los problemas tienen similitudes. Para
los científicos de otros campos, los desarrolladores de la industria del software o los
estudiantes que comienzan, estas personas pueden asumir que los diseñadores han
examinado cuidadosamente las decisiones de diseño con evidencia, pero un análisis
sistemático en curso que hemos realizado sobre la literatura ha encontrado que esto es
casi nunca realmente cierto [43]. En efecto, el simple hecho de que nuestros principales
lenguajes no tengan evidencia que demuestre que su diseño tiene sentido es evidente
cuando nos damos cuenta de que, para los principiantes, un lenguaje generado
aleatoriamente es tan fácil de usar como Perl o Java [44].
Escribimos este trabajo porque el futuro de la ciencia y la industria del software
depende, en su nivel más profundo, de nuestra comunidad. Los científicos e ingenieros
de otros campos con los que trabajamos generalmente esperan que seamos una
comunidad científica, que usa evidencia, crea teorías y usa el proceso de revisión por
pares para promover la ciencia, no las creencias. Por lo tanto, aunque pensamos que el
enfoque de la comunidad lingüística en las matemáticas de los lenguajes de
programación es obviamente apropiado para los desafíos técnicos, aquí argumentamos
que este conocimiento es necesario, pero no suficiente, para resolver el caos observado
en el mundo del desarrollo de software. Por lo tanto, escribimos aquí sobre lo que
llamamos Las guerras de los lenguajes de programación, un concepto que describiremos
a lo largo de este ensayo.
¿Cuál es la contribución de este ensayo? Este ensayo contribuye de tres formas.
Primero, describimos los problemas que enfrenta la comunidad científica en general
debido a las guerras de los lenguajes de programación. En segundo lugar, definimos un
conjunto de preguntas para la comunidad de lenguajes de programación que deben ser
respondidas si los académicos se toman en serio la solución, incluso parcialmente, de los
principales problemas que existen en el diseño de lenguajes en la actualidad. Finalmente,
discutimos las responsabilidades que tiene la amplia comunidad informática con respecto a
las guerras de idiomas.
Estructura de este ensayo. En la siguiente sección, describimos las guerras del
“Y tenemos un solo mundo. Pero vivimos en otros diferentes ".
lenguaje en sí, enmarcando el problema y discutiendo sus múltiples facetas con
respecto a la sociedad moderna, incluida su base de evidencia actual. Luego,
definimos un conjunto de responsabilidades que tienen varios grupos o individuos con
respecto a las guerras de idiomas. Finalmente, las dos últimas secciones resumen y
concluyen este ensayo.
2. Enmarcando las guerras lingüísticas
“Las generaciones anteriores estaban absolutamente convencidas de que sus teorías
científicas eran casi perfectas, solo para que resultara que no habían entendido por
completo”.
- Pratchett, Stewart y Cohen, La ciencia del Mundodisco
En esta sección, el propósito principal es discutir, sin dejar de reconocer que nuestra
explicación de un problema social tan complejo no complacerá a todos los académicos,
cuáles son las guerras de los lenguajes de programación, incluidos los roles que las
personas juegan en ellas. Usando la analogía de las guerras del lenguaje, pasamos a un
análisis del espectro de puntos de vista que hemos escuchado en privado de los
académicos.
284
en eso. Finalmente, proporcionamos información sobre la base actual de la evidencia
en las guerras de idiomas.
Con esto en mente, nos corresponde hacer la pregunta obvia: ¿Cuáles son las
guerras del lenguaje de programación? Si bien nos negamos a proporcionar una
definición formal, creemos que las guerras lingüísticas tienen al menos tres
componentes fundamentales: 1) divergencia lingüística, 2) impacto lingüístico y 3)
comunidades lingüísticas. Aunque describimos estas ideas brevemente en los próximos
párrafos, cada una es muy compleja y se irá desarrollando a medida que continuemos
con este ensayo. Primero, observamos una divergencia extrema hoy en día en el
campo de los lenguajes de programación. Esta divergencia de idiomas ocurre en un
espectro que va desde lo engañosamente trivial (p. ej., ¿cuál debería ser la sintaxis de
un bucle?) hasta lo discutiblemente más profundo (p. ej., tipificación fuerte o débil, ¿qué
tipo de modelo de herencia?). Tenga en cuenta que nuestra afirmación no es que la
divergencia sea buena o mala; solo que existe. Los ejemplos de este tema se discutirán
extensamente a lo largo de este ensayo.
En segundo lugar, las guerras de idiomas están relacionadas con lo que denominamos
impacto del lenguaje. Esto incluye potencialmente impactos tanto positivos (por
ejemplo, soluciones de lenguaje creativo, características que impactan positivamente la
productividad humana) como impactos negativos (por ejemplo, duplicación de
esfuerzos, costo monetario social). El concepto de impacto del lenguaje es quizás uno
de los misterios más extraordinarios de toda la informática y no se comprende bien.
Este tema está en el corazón de nuestra sección sobre la base de la evidencia en el
diseño del lenguaje.
Finalmente, las guerras lingüísticas implican claramente comunidades lingüísticas. Con
esto queremos decir que involucran a una variedad de actores, con varios roles. Creemos
que discutir estos roles es importante para comprender el resto de este trabajo. Por lo
tanto, los describimos a continuación.
2.1 Funciones en las guerras lingüísticas
- Dire Straights, hermanos de armas
Usamos el término bastante militarizado de “guerras de lenguajes de programación”
a lo largo de este trabajo para describir la situación en el mundo del desarrollo de
software por dos razones. Primero, el término implica un papel de adversario en la
comunidad, o al menos uno de competencia. En segundo lugar, aunque casi nunca
se discute en la literatura académica revisada por pares, creemos que, a pesar de su
falta de formalización, muchos en la comunidad han escuchado el término de manera
informal.
Como parte de las guerras lingüísticas, tiene sentido pensar en los roles que
tienen los distintos actores y cómo estos roles impactan el éxito o el fracaso de los
productos lingüísticos. En esencia, reconocemos aquí que muchos participantes
individuales de las guerras de los lenguajes de programación, que naturalmente
abarcan una amplia gama de personas (por ejemplo, estudiantes, profesionales de
nivel de entrada, directores ejecutivos de grandes corporaciones), albergan
diferentes motivaciones para su participación. Si bien nuestra lista difícilmente
pretende abarcar todo, la aclaramos aquí.
como un ejemplo de las posibilidades, comenzando con lo que llamamos propietarios y
seguidores.
Primero, el concepto de propietario es literal: clasificamos este rol como el que
posee un lenguaje de programación. Por ejemplo, Microsoft, que posee C #, u Oracle,
que posee Java, o los desarrolladores principales de un lenguaje más pequeño, como
Ruby. Los propietarios, por definición, tienen un interés personal en el éxito de un
producto lingüístico (por ejemplo, fama, interés, creencias, dinero). Propietarios
contrastantes, tenemos seguidores, por lo que nos referimos a cualquier individuo
involucrado en un idioma, independientemente del éxito (por ejemplo, promocionarlo,
usarlo) o del fracaso (por ejemplo, denunciarlo). Si bien los seguidores pueden no tener
los mismos motivos que los propietarios, también pueden tener intereses creados. Por
ejemplo, aquellos que aprendieron a programar usando C, y que están familiarizados
con su sintaxis, podrían estar más dispuestos a adoptar un lenguaje similar a C, como
Java.
éxito de un producto lingüístico. Puede haber un espectro entre
dependiente y voluntario.
Si bien imaginamos que es obvio para la mayoría de los lectores, queremos
señalar que nuestra descripción de los roles apenas toca la superficie. Los
mencionamos al comienzo relativo de este artículo porque creemos que es
importante reconocer que la guerra de los lenguajes de programación tiene
participantes. Si bien nuestros roles no son exactos, nos brindan una línea de base
aproximada para pensar en los diversos grupos. Con esto en mente, ahora podemos
pasar a lo que llamamos el espectro de las guerras de idiomas: posibles resultados o
resultados de las guerras de idiomas.
2.2 Posibles resultados de las guerras lingüísticas
Comenzamos esta discusión con dos puntos de vista divergentes, cada uno de los cuales
es una posición extrema que hemos escuchado de los estudiosos sobre lo que detendría
las guerras de los lenguajes de programación. A la primera vista la llamamos “Un idioma

Si bien los propietarios y seguidores pueden tener sus propias motivaciones, para gobernarlos a todos”, la idea en la que la única solución posible a las guerras de
idiomas es que todos los posibles desarrolladores en todas las condiciones posibles usen
definimos tres roles adicionales que pueden desempeñar cualquiera de los grupos: 1) creyentes
el mismo idioma. A continuación, nos movemos a lo opuesto de esta vista, que
2) dependientes, y 3) voluntarios. En el primer caso, imaginamos a los creyentes como
llamaremos "copos de nieve únicos", donde todos los desarrolladores, en todas las
aquellos que encuentran convincente el diseño de un lenguaje en particular. Esto
condiciones posibles, son tan únicos que necesitan su propio lenguaje de programación.
podría ser hipotéticamente un individuo que piensa que C # es mejor que Java (o
Señalamos estos extremos por dos razones: 1) en realidad escuchamos afirmaciones
viceversa), que las funciones lambda son importantes para que un lenguaje tenga (o
como esta de diseñadores de lenguajes, académicos y desarrolladores, 1
no), o que una sintaxis particular es elegante (o no). La creencia de dichos individuos
puede o no estar basada en evidencia.

y 2) tales puntos de vista son difíciles de creer para nosotros sin evidencia que los

Un segundo papel es el de los dependientes. En este caso, tomamos a estos apoye; al discutirlos, nos damos cuenta del hecho de que es necesario considerar

individuos como aquellos que necesitan un idioma en particular para completar su puntos de vista más equilibrados. Esto nos lleva a nuestra primera pregunta de

trabajo o que de otra manera requieren el éxito de un idioma por una razón externa. investigación:

Por ejemplo, si una casa de desarrollo de software tiene un millón de líneas, por el
En el futuro, ¿en qué punto del espectro se
bien del argumento, código PHP correcto escrito en el back-end de un servidor,
RQ entre "Un idioma para gobernarlos a todos" y
entonces dependen del éxito financiero de PHP (Facebook podría servir como
¿Es deseable tener “copos de nieve únicos”?
ejemplo). Este puede ser el caso independientemente de si un grupo posee la
tecnología del lenguaje. Llamamos a los de esta categoría dependientes financieros.

2.2.1 Un idioma para gobernarlos a todos

En este mismo sentido, los estudiantes también son dependientes en el sentido de "Un Anillo para gobernarlos a todos, Un Anillo para encontrarlos, Un Anillo para traerlos a todos
y en la oscuridad atarlos".
que normalmente se les exige que utilicen productos lingüísticos elegidos para ellos por
- El Señor de los Anillos
los profesores. Si bien esto es normal, es importante reconocer que a veces los
estudiantes necesitan años para aprender un lenguaje como C ++ de manera
Una creencia que hemos escuchado comúnmente entre los diseñadores, académicos y
competente. Como tal, con ese tiempo invertido, los estudiantes dependen del éxito del
usuarios de lenguajes de programación es la visión errónea sobre las guerras de los
lenguaje o sus construcciones. Llamamos a las personas en esta situación dependientes
lenguajes de que cualquier solución debe dar cuenta de todas las tareas posibles en todas
intelectuales. Obviamente, los dos no son mutuamente excluyentes.
las condiciones posibles. Rechazamos esta visión, encontrándola poco más que una

caracterización de los posibles resultados de las guerras lingüísticas. En esta sección,

discutimos esta creencia, que llamamos "Un idioma para gobernarlos a todos".
Finalmente, el opuesto lógico de los dependientes son los voluntarios. En este grupo,
los programadores pueden experimentar con un lenguaje de programación o utilizarlo de
Considere por un momento por qué la creencia de Un lenguaje para gobernarlos es
otro modo por sus propias razones. Dichos usuarios pueden pertenecer a categorías
inválida en su forma más pura. Vemos muchas razones posibles, pero señalamos solo
como los primeros en adoptar, que prueban Swift de Apple porque quieren. Del mismo
algunas que consideramos importantes, a saber: 1) los humanos varían, 2) los dominios
modo, pueden disfrutar utilizando una variedad de productos lingüísticos por motivos
de los problemas varían y 3) incluso un lenguaje perfecto, si se creó (de alguna manera),
personales. El punto es que los voluntarios son aquellos que tienen poco interés personal
podría no ser adoptado. Primero, mientras que algunos desarrolladores
práctico, financiero o intelectualmente, en el

1 Por cortesía profesional, pedimos a los lectores que no nos pregunten qué personas han hecho tales

afirmaciones; nos negamos a decir.

285
tomará el hecho obvio de que los desarrolladores tienen una variación natural en sus
necesidades y habilidades como un argumento a favor de la visión de los copos de nieve
únicos, es importante reconocer que los desarrolladores varían, reconociendo también que
esta variación no es tan alta como muchos creen. Por ejemplo, en los estudios de los
autores sobre diseño de lenguaje, normalmente publicamos información demográfica en
nuestros experimentos. Sin embargo, aunque hablamos poco de ello en estos trabajos,
nos parece que la variación entre la mayoría de las muestras es menos importante que la
amplia variación demográfica.
Por ejemplo, considere que los niños en la escuela en muchos países ahora están
aprendiendo ciencias de la computación a una edad cada vez más joven, en parte
porque organizaciones como Code.org han ayudado a crear conciencia, pero también
porque muchos educadores se dan cuenta de que viven en los 21 años. S t siglo: la
programación es ahora una habilidad fundamental y básica. Es probable que muchos
estudiantes jóvenes quieran resolver problemas que sus mayores no quieren, como tal
vez querer aprender a programar animaciones o juegos, o cualquier otra variedad de
actividades. Por otro lado, los programadores profesionales que trabajan en la NASA
obviamente tienen diferentes necesidades, que probablemente requieren diferentes
lenguajes o bibliotecas. Dicho de manera más cruda, abrigamos dudas de que casi
cualquier aplicación seria creada por profesionales se realice en Alice o Scratch, y
mucho menos en la próxima generación de transbordadores espaciales, pero también
reconocemos que los niños pueden aprender los fundamentos de la programación con
tales herramientas. Esto nos lleva a una pregunta de investigación:
¿Qué diseños de idioma ayudan al usuario más grande?
RQ base posible bajo el mayor número de circuitos
circunstancias?
En segundo lugar, aparte de las necesidades de los usuarios, debemos considerar
que los científicos y la industria privada utilizan lenguajes de programación para una
amplia variedad de objetivos. Esto incluye aplicaciones tan variadas como bioingeniería,
física, videojuegos o edición de películas, entre muchas otras demasiado numerosas
para mencionarlas. Si bien está claro que muchas aplicaciones se pueden crear con
lenguajes que existen en la actualidad (por ejemplo, muchas aplicaciones están escritas
en Java o C ++), algunos dominios de aplicaciones pueden beneficiarse de tener un
lenguaje de programación único. Si bien se podrían señalar muchas áreas potenciales,
creemos que una obvia es el análisis sintáctico, donde herramientas como Antlr
proporcionan formas concisas de representar reglas de análisis sintáctico que pueden
ser realmente complejas cuando se escriben a mano en un lenguaje como C o Java.
Admitimos, sin embargo, que no conocemos evidencia concreta sobre este punto,
tampoco podemos determinar con ningún tipo de certeza matemática exactamente qué
dominios pueden requerir un nuevo lenguaje y cuáles no. Sospechamos que, cuando se
escribe la historia, el número de veces que los autores han afirmado que se necesitaba
un nuevo lenguaje específico de dominio se considerará una exageración significativa.
Desde otra perspectiva, con nuestro tercer punto, Meyerovich y Rabkin
[32] señalan que por qué se adopta un lenguaje de programación es una
cuestión compleja que involucra muchos factores, incluidos algunos
aparentemente
286
mundano como el lenguaje en el que se programó previamente, evidencia de lo
que antes llamamos dependencia intelectual. Incluso un lenguaje de alguna
manera perfecto puede no ser adoptado. Las razones para no adoptar un
lenguaje tan perfecto podrían depender, entre muchos factores posibles, de las
observaciones del mercado o de los efectos de la red. Por ejemplo, si los
desarrolladores asumen que cierto lenguaje se mantendrá durante décadas o
es de uso común, trabajar con él puede percibirse como más razonable, a
pesar de las imperfecciones percibidas o reales. Esto nos lleva a la siguiente
pregunta de investigación:
RQ ¿Qué lenguajes específicos de dominio benefician a
mans?
Esta pregunta implica varias perspectivas diferentes. Esto incluye al menos
estimaciones sobre el futuro del lenguaje, la disponibilidad de los desarrolladores, la
capacidad de aprendizaje, la usabilidad u otros conceptos. Para dar un ejemplo
específico, no conocemos evidencia de que el lenguaje de programación R haga que
las estadísticas sean más fáciles de lograr que tener una API de estadísticas, con
características similares, incorporada en otro lenguaje. Dado esto, si se necesita R
requiere más evidencia que pruebas de que un cálculo estadístico particular, o una
característica del lenguaje, funciona o es rápido.
2.2.2 Copos de nieve únicos
El Señor dijo: “Si como un solo pueblo que habla el mismo idioma han comenzado a
hacer esto, entonces nada de lo que planean hacer les será imposible. Ven,
bajemos y confundamos su idioma para que no se entiendan ”.
- Génesis 11: 6–7, Nueva Versión Internacional
Si tomamos el opuesto lógico de Un lenguaje para gobernarlos todos, obtenemos lo
que llamamos copos de nieve únicos: la idea de que todos los desarrolladores
necesitan un lenguaje de programación único para todas las tareas posibles. Antes
de discutir el tema, señalamos que esta visión es refutada por evidencia empírica en
la literatura. Discutimos dos cuestiones, a saber, que 1) no está respaldado por la
evidencia existente y que 2) errar demasiado cerca de la visión de Unique Snow fl
akes en la sociedad puede tener consecuencias negativas, especialmente para la
comunidad científica.
En primer lugar, y lo que es más importante, creemos que ya existe evidencia en la
literatura que muestra que es poco probable que el punto de vista de Unique Snow fl
akes sea válido. Considere por un momento cómo tendrían que verse los datos
empíricos para que fueran razonables. Es decir, los desarrolladores necesitan variar
tanto que no se puedan tomar medidas consistentes; esta vista no es lo que
observamos a partir de mediciones cuidadosas del comportamiento del programador
hasta ahora.
Por ejemplo, considere el estudio de Rossbach et al. [39], que mostró una
diferencia de casi 8 veces en las tasas de errores entre una solución de software
basada en memoria transaccional en comparación con bloqueos de grano fino o
curso. O considere eso,
en casi todas las réplicas de estudios sobre tipificación estática o dinámica (por
ejemplo, con o sin un entorno de desarrollo, con o sin documentación, el uso de
genéricos), esa tipificación estática parece aumentar la productividad del
programador en promedio [12, 25, 31]. En estudios de principiantes, las diferencias
en la sintaxis tienen un poder explicativo significativo, a juzgar por los valores eta
reportados por los estudios, al decir por qué observamos que algunos lenguajes son
más fáciles de entender y usar inicialmente que otros [44]. Dicho de manera sucinta,
cada estudio, y cada estudio futuro, que documente que los programadores, en
promedio, obtienen mejores resultados o peores con una característica del lenguaje
sobre otra, refuta cada vez más la visión del mundo de Unique Snow fl akes.
En segundo lugar, incluso si toda la evidencia anterior es incorrecta, parcial o
defectuosa de manera importante, esto no implica automáticamente que debamos
promover la visión de los copos de nieve únicos. La sociedad moderna requiere que
los programadores trabajen juntos y parece demasiado obvio que si todos los
programadores tuvieran su propio lenguaje, la colaboración sería más difícil, si no
imposible. Dicho de otra manera, incluso si las personas tienen necesidades únicas
mensurables en todas o en muchas condiciones, esto no implica que la sociedad
obtenga un beneficio tangible de la divergencia extrema de idiomas.
Creemos que un área tangible que puede no beneficiarse de la divergencia
es la sintaxis. Históricamente, aunque pocos cuestionan la creatividad asociada
con la creación de nuevos productos lingüísticos, es importante reconocer que
los artículos suelen estudiar una característica, al tiempo que combinan ideas
nuevas e interesantes con modificaciones de las antiguas. Por ejemplo, muchos
lenguajes de programación varían la forma de escribir un bucle, sin evidencia de
que el enfoque sea "mejor" ni, a menudo, incluso con razones públicas por las
que la sintaxis es diferente de otras alternativas. Creemos que los académicos y
los profesionales deben exigir más evidencia de los académicos sobre estos
temas, especialmente cuando los diseñadores de idiomas hacen afirmaciones.
Esto es especialmente cierto dada la evidencia documentada de varios estudios
que muestran que la sintaxis tiene un impacto significativo en los novatos [8, 9,
2.3 ¿Cuál es el impacto social de las guerras lingüísticas?
Otro tema de importancia con respecto a las guerras más amplias de los lenguajes de
programación es su impacto en el mundo en general. Este efecto es difícil de cuantificar,
en parte porque los científicos informáticos a menudo parecen encontrar que hablar de las
guerras del lenguaje es un tabú en la investigación revisada por pares, y en parte porque
se ha realizado poca investigación científica sobre las guerras del lenguaje como un
fenómeno en sí. En esta sección, si bien admitimos en primer lugar que la evidencia sobre
el impacto social de las guerras del lenguaje es difícil de reunir, damos un primer intento
de discutir lo que vemos como las consecuencias de este problema. Centramos nuestros
esfuerzos en cuestiones que creemos que son importantes para la academia y la industria,
incluida la duplicación de esfuerzos y costos.
En el ámbito académico, creemos que pocos científicos informáticos han llegado a un
acuerdo con lo fracturada que está la comunidad de lenguajes de programación. Considere
una breve encuesta realizada por el actual
287
autores de alquiler. Si bien no conocemos un análisis sistemático de los tipos y tipos
de lenguajes de programación utilizados en los colegios y universidades de los
Estados Unidos o del mundo, puede resultar esclarecedor capturar esta información
a escala global. Si bien fue un comienzo ciertamente inadecuado, comenzamos un
análisis de este tipo realizando una breve encuesta de 39 colegios y universidades
en el medio oeste, analizando solo qué idiomas usaban estas escuelas en el curso
introductorio. De estos, se utilizaron aproximadamente 9 lenguajes de
programación, incluidos C, C ++, Alice, VB, Python, Java, C #, COBOL y ADA. La
evidencia de que cada una de estas opciones tiene sentido, como un todo o en
términos de características individuales del lenguaje, no puede establecerse a partir
de la literatura.
Dejando a un lado las diferencias en la instrucción dentro de la academia, la industria
también está muy fracturada en lo que respecta al uso de lenguajes de programación, tanto en
lo que respecta a las variaciones en la adopción (como se ha estudiado recientemente) como
en lo que respecta a bibliotecas y conjuntos de herramientas. Por ejemplo, en NetBeans 7.4,
contamos un total de 466 conjuntos de herramientas diferentes disponibles para su uso como
bibliotecas Javascript. Estos kits de herramientas, que son básicamente pequeñas adiciones a
Javascript, brindan a los desarrolladores capacidades listas para usar para codificar en la web.
Para la mayoría de los estudiosos, esto no debería sorprender y la situación es similar para
otros idiomas. En la práctica, cuando los desarrolladores adoptan un lenguaje, generalmente
obtienen acceso a bibliotecas y extensiones estándar muy grandes, para bien o para mal.
Algunos pueden considerar esto solo una expresión de la creatividad de nuestra comunidad y,
en la superficie, este punto de vista puede parecer atractivo. Sin embargo, nos preocupa que
una divergencia tan grande esté reduciendo la productividad a escala social.
En segundo lugar, dada la cantidad de lenguajes, conjuntos de herramientas y
marcos, parece claro que existe una duplicación de esfuerzos en la comunidad de
lenguajes de programación. Como ejemplo trivial, si bien pensamos que los círculos
académicos a menudo tienen controles y contrapesos en el proceso de revisión por pares
para garantizar la originalidad de los artículos académicos, esto parece ser prácticamente
inexistente con el software que crea nuestra comunidad. Tenga en cuenta que para los
nuevos lenguajes, se vuelven a implementar construcciones como tablas hash, listas, API
de red, API de voz u otras bibliotecas disponibles, lo que nos lleva a nuestra siguiente
pregunta de investigación:
Del tiempo empleado en desarrollar programación
RQ idiomas, qué porcentaje se gastó en reinventar
ing la misma solución (por ejemplo, un HashTable en Java frente a C #)?
Si bien hay poco debate sobre si los cambios en los idiomas pueden tener
beneficios, a veces incluso cambios menores en nuevos idiomas (por ejemplo,
diferencias en las estructuras de bucle) o, en algunos casos, problemas de patentes o
derechos de autor, influyen en la posibilidad de reutilizar partes de una biblioteca
estándar. Naturalmente, esto lleva a corporaciones como Oracle (o Sun) a crear todo el
JDK, mientras que otras crean todo .NET, una obvia duplicación de esfuerzos. Cuando
miramos más ampliamente, en las bibliotecas estándar de C ++, bibliotecas para Ruby,
Perl, Python u otras tecnologías, y
Además, si observamos las API que los desarrolladores de proyectos más pequeños
vuelven a implementar una y otra vez en diferentes idiomas, sospechamos que la
comunidad en su conjunto se beneficiaría si se redujera la duplicación de esfuerzos en
todos los sectores tecnológicos.
Para las empresas de software, existe una perspectiva diferente, que depende de
las limitaciones del mercado. Si, por ejemplo, Microsoft decide desarrollar un lenguaje
como C # como competidor del lenguaje de programación Java, 2 la duplicación de
esfuerzos debe haberse considerado inicialmente que valía la pena el costo. Sin
embargo, para los desarrolladores individuales que realmente usan un idioma y
necesitan escribir un código similar en uno diferente, la duplicación de código
correspondiente se vuelve problemática. Parece ser especialmente grave tan pronto
como se requiere que varios clientes escriban el mismo código o fragmentos de código
similares en diferentes idiomas; en otras palabras, mientras que las empresas pueden
beneficiarse discutiblemente de la duplicación, es posible que los clientes no. Esto lleva
a otra pregunta de investigación:
De todo el tiempo utilizado en el desarrollo de software
RQ ¿Qué porcentaje se gastó en reimplementación?
¿Estás buscando la misma solución en un idioma diferente?
Con la idea en mente de que muchos diseñadores de lenguajes y adoptadores
de nuevos lenguajes han reinventado la rueda muchas veces a lo largo de la
historia, también queremos señalar que no está del todo claro si esta duplicación de
esfuerzos valió la pena. Por ejemplo, abrigamos dudas de que una implementación
más de una tabla hash, en un idioma nuevo, debería considerarse automáticamente
positiva. De manera similar, abrigamos dudas de que valga la pena investigar o
financiar una forma más de escribir un bucle en la sintaxis del lenguaje central, a
menos que el nuevo método también tenga en cuenta las guerras lingüísticas en
general, utilizando evidencia para tomar decisiones o cambios. Sin embargo, antes
de que podamos comenzar a preguntarnos si una inversión vale la pena, debemos
comenzar a medirla, lo que nos lleva a la siguiente pregunta:
¿Cuál es el costo total a lo largo de la historia de
RQ Desarrollando todos los lenguajes de programación de computadoras,
apoyo a bibliotecas y herramientas?
Dado que existen muchos lenguajes, otra preocupación que tenemos sobre las
guerras de los lenguajes de programación es que parece razonable afirmar que los
grupos que cambian los lenguajes de programación, lo cual es común debido a la
velocidad a la que cambia nuestra disciplina, deben en última instancia rehacer el
trabajo y adaptar su tecnologías (por ejemplo, portabilidad). En algunos casos, estos
procedimientos de transferencia son sencillos. Por ejemplo, moverse entre nuevas
versiones de Java o C ++ puede requerir esfuerzo, pero podría decirse que sería
menos esfuerzo que convertir desde Fortran
2 ver, por ejemplo, los artículos correspondientes como http: //
news.cnet.com/2100-1001-242268.html\&title=
Microsoft-brewing-Java-like-language \ & desc = - +
CNet + artículo
288
a Perl. En el mundo académico, la situación es similar. Cuando los miembros de la facultad
cambian los productos de lenguaje, digamos de C ++ a Java, como ha sido común en los
últimos años, los libros de texto, los tutoriales para partes de las bibliotecas estándar, las
diapositivas, las tareas y los ejemplos deben cambiar al nuevo enfoque. Esto nos lleva a
nuestra próxima pregunta de investigación:
¿Cuál es la productividad histórica total perdida?
RQ cambiando / actualizando lenguajes de programación
en varios entornos (por ejemplo, académico, industrial, militar)?
Además, si imaginamos que, con el tiempo, los diseñadores de lenguajes y los
académicos se volvieron cada vez más dependientes de pruebas válidas y reproducibles
para tomar decisiones, es lógico pensar que al menos algunos aspectos del diseño del
lenguaje dejarían de reproducirse en nuevos lenguajes. Por ejemplo, aunque nuestras
pruebas solo abarcan un pequeño conjunto de posibles soluciones en comparación con el
conjunto, los datos empíricos que hemos recopilado nos llevan a algunas conclusiones.
Considere las cuatro construcciones de bucle alternativas enumeradas en la Figura 1,
que muestra la salida de la palabra "Hola-" y una variable de contador en la pantalla 10
veces.
Los diseñadores de nuevos lenguajes podrían pensar que cambiar la
sintaxis de un bucle es una expresión de creatividad, pero sospechamos que
está más en línea con la ignorancia de la evidencia disponible [8, 9, 44]. Si
bien nos referimos a ningún idioma en particular, un idioma matemáticamente
correcto y razonable puede ser difícil de entender. Dada la amplia proliferación
de productos que creamos para la academia y la industria del software, si un
constructo es claro es una decisión que debe basarse en evidencia sólida, no
solo en opiniones y argumentos. En este caso, la evidencia en los estudios es
clara: la palabra "para" tiene poco sentido para los principiantes, por razones
que deberían ser obvias, en comparación con palabras como "repetir". Más
importante aún, si la sintaxis de un idioma es diferente, la biblioteca estándar
también debe ser diferente, lo que a menudo conduce a la duplicación de
esfuerzos y reinventa la rueda.
Si los diseñadores de lenguajes crearan lenguajes con
RQ una base de pruebas cada vez mayor, lo que
¿El impacto sería durante el próximo siglo?
En general, nuestro punto en esta sección es que las guerras de idiomas están
teniendo un impacto significativo en la sociedad en su conjunto. Desde nuestra
perspectiva, el impacto es en gran medida negativo. Si bien los problemas sociales nunca
se pueden resolver con un grupo de investigación, y las guerras lingüísticas son un
problema profundo con muchos factores, es necesario investigar el impacto en la sociedad
si queremos que las generaciones futuras no miren hacia atrás en nuestro trabajo con
sorpresa, preguntándose por qué Nos llevó tanto tiempo incluso realizar un estudio sobre,
por ejemplo, la sintaxis de un bucle. Este tema de la base de la evidencia es el siguiente
tema de discusión en este trabajo.
 i=0
repetir 10 veces
yo = yo + 1
producción " Hola- "+ i
fin
(a) Quórum
1 a: 10 hacer: [: i |
Programa de transcripción:
'Hola-', (yo como Entero)].
(c) Smalltalk
Figura 1. Estilos de bucle en varios lenguajes de programación que generan una cadena y una variable de contador.
2.4 El diseño del lenguaje necesita una base de evidencia más sólida
"No sabes nada, Jon Snow".
- Ygritte, Juego de tronos
En los últimos años, muchos autores han mostrado una creciente preocupación por la
estabilidad de la evidencia en la informática académica, incluido el diseño de lenguajes
de programación. Sin embargo, antes de sumergirnos en el diseño de lenguajes,
primero tomemos un pequeño desvío hacia el campo de la ingeniería de software, ya
que los autores de esta comunidad probablemente iniciaron la tendencia a volver a
analizar la historia de nuestras prácticas de evidencia con un ojo crítico.
A mediados de la década de 1990, Tichy argumentó que el campo de la ingeniería
de software estaba en desorden, en gran parte porque los autores publicaban
continuamente trabajos no basados en pruebas. Por no basado en evidencia, lo que se
quería decir era que incluso las revistas de prestigio publicaban lo que equivalía a
artículos de opinión, no respaldados por datos y observaciones [50]. Como dice Tichy:
Hay muchas teorías informáticas que no se han probado. Por
ejemplo, se piensa que la programación funcional, la programación
orientada a objetos y los métodos formales mejoran la productividad
del programador, la calidad del programa o ambos. Es sorprendente
que ninguna de estas afirmaciones obviamente importantes se haya
probado sistemáticamente, a pesar de que todas tienen 30 años y se
ha invertido mucho esfuerzo en desarrollar lenguajes de programación
y técnicas formales.
Esta afirmación de Tichy no era de opinión, derivada de una lectura
cuidadosa y catalogación de la literatura en comparación con otras disciplinas. No
hay una forma agradable de decirlo: Tichy mostró evidencia de que la ingeniería
de software como disciplina exhibía prácticas pseudocientíficas. Otras disciplinas
usaban datos y observaciones, mientras que los ingenieros de software usaban
anécdotas, y a veces los autores argumentaban en contra incluso de la idea de la
experimentación. Como señala Tichy, muchos en ese momento argumentaron
que la experimentación era,
289
Hola x):-
(X> 10,!);
( escribir( 'Hola' - X), Siguiente es X + 1, hola
(Próximo)).
: -hola (1).
(b) Prólogo
para (int i = 1; i <= 10; i ++) {
System.out.println ("Hola-" + i);
}
(d) Java
“Inapropiados, demasiado difíciles, inútiles e incluso dañinos”: argumentos que creemos
coinciden estrechamente con los planteados por algunos investigadores del lenguaje en
la actualidad. Un trabajo reciente que exploraba ideas similares encontró que el campo
de la ingeniería de software todavía está muy rezagado en su rigor académico [26].
Si bien las prácticas de evidencia en la ingeniería de software se han
investigado desde mediados de los 90, esto aún no se ha completado por completo
en la comunidad de diseño de lenguajes de programación. Por ejemplo, mientras
algunos están familiarizados con trabajos que resumen la literatura sobre
principiantes [23] o usuarios finales [27], estos trabajos hablan sobre lo que hay en
la literatura, pero no investigan si lo que está en la literatura es correcto o exhibe
un conocimiento estable. en el que se puede confiar. En la literatura, sin embargo,
varios académicos han afirmado que nuestra comunidad tiene problemas similares.
Esto incluye al menos a Tichy, Markstrum [30] y Hanenberg [16].
Hasta donde sabemos, sin embargo, el primer trabajo para intentar documentar
formalmente las prácticas de evidencia de la comunidad de lenguajes de
programación fue realizado recientemente por los autores actuales y nuestros
colaboradores de investigación [43]. Este trabajo es preliminar, solo evalúa talleres
académicos sobre diseño de lenguaje, pero los resultados mostraron evidencia clara
de que la comunidad no estaba utilizando técnicas de recolección de evidencia de
alta calidad. Se está trabajando en lugares más prestigiosos, como OOPSLA, ICFP
u otros, pero nuestra sospecha al mirar los aproximadamente 1700 otros artículos
que hemos catalogado hasta ahora, además de los discutidos en el trabajo citado,
es que la evidencia practica de hecho, puede ser peor en estos lugares. En
resumen, con notables excepciones, La comunidad de lenguajes de programación
ha utilizado pocos datos empíricos sobre el impacto de los productos utilizados por
millones de personas en casi toda su historia. Esta desafortunada observación nos
obliga a cuestionar seriamente la validez científica de cualquier afirmación hecha por
un diseñador de lenguaje que no tiene datos reales a mano que podamos verificar y
replicar. Esto nos lleva a una pregunta de investigación con respecto a las prácticas
de evidencia de la comunidad de lenguajes de programación en su conjunto:
 ¿Cómo podemos incrementar el lenguaje de programación
RQ medir los estándares de evidencia de la comunidad de diseño?
Admitimos fácilmente que no sabemos la respuesta a la pregunta
anterior, pero queremos ofrecer algunas especulaciones limitadas que otros
pueden explorar libremente, con suerte para refutar o mejorar nuestras
suposiciones. Una posibilidad de por qué la comunidad lingüística no ha
estado reuniendo pruebas rigurosas, más allá de las consideraciones
técnicas, es que en el mundo académico hay pocos incentivos para
hacerlo. Los artículos se pueden publicar quizás incluso más fácilmente con
pequeños cambios incrementales en el trabajo existente. Además, dado
que las instituciones académicas a menudo se basan considerablemente
en el recuento de artículos, literalmente el número de artículos que un
académico publica como métrica, se desalienta directamente a los
académicos de trabajar para aliviar problemas difíciles y de larga data que
podrían requerir años de arduo estudio si conduce a sólo una, o unas pocas
publicaciones. En otras palabras,
Dejando de lado las cuestiones de evidencia, si bien la literatura es actualmente
escasa, dado que los autores actuales han tenido un contacto considerable con la
comunidad lingüística, queremos dejar claro un hecho: desde nuestra perspectiva,
aunque puede que no haya mucha evidencia en la literatura al respecto. a cuestiones
como el impacto del lenguaje, creemos que los diseñadores de lenguajes preocuparse
profundamente por estos temas. Creemos que una forma en el futuro en que podría ser
posible avanzar así es en la creación de un catálogo formal de características del
lenguaje, su impacto en las personas y pruebas estándar reproducibles, con la
evidencia correspondiente. Por ejemplo, en psicología, los científicos han creado el
DSM-5 [1], una colección rigurosa de procedimientos de evaluación para una variedad
de condiciones psicológicas. Con los lenguajes de programación, la creación de una
colección estándar de todas las evaluaciones realizadas sobre sistemas de tipos,
sintaxis u otras características y documentos sobre cómo replicarlos fácilmente, podría
contribuir en gran medida a brindar a los diseñadores de lenguajes información
científica confiable, replicable y sobre el impacto. Esto nos lleva a nuestra siguiente
pregunta:
¿Podemos crear un catálogo usando el DSM5 [1]
RQ como ejemplo, para pruebas fiables de lenguaje
¿impacto?
3. Mayordomía y responsabilidades
"Ahora, naturalmente, como muchos de nosotros, me resisto a cambiar demasiado las viejas
formas".
- Kazuo Ishiguro, Los restos del día
Dado que los diseñadores de lenguajes son los administradores de la computación en
el sentido de que nuestra comunidad desarrolla productos fundamentales para los que
se basa el software del mundo,
290
Tiene sentido preguntar cuáles son nuestras responsabilidades. En esta
sección, miramos las guerras de los lenguajes de programación desde un punto
de vista diferente. Si bien reconocemos que este problema puede ser uno de
los más desafiantes en la informática, que no tiene una solución fácil o sencilla,
discutimos aquí un posible camino a seguir. En este contexto, discutimos cómo
varias comunidades pueden contribuir a aliviar aspectos de las guerras
lingüísticas durante el próximo siglo.
Por lo tanto, ahora miramos a los individuos y las comunidades, discutiendo su
papel en las guerras de idiomas, incluyendo dónde han tenido éxito o fracasado. A lo
largo de este proceso, proporcionamos nuestra opinión sobre las posibles actividades
que podrían emprender y que pueden ayudar a largo plazo. Si bien debería ser obvio,
no tenemos todas las respuestas, ni pretendemos tener algún tipo de garantía de que
nuestras sugerencias sean beneficiosas. Sin embargo, señalamos que muchas
comunidades están haciendo poco para investigar o solucionar un problema social
importante en nuestra disciplina.
3.1 Responsabilidades de los investigadores individuales
Los académicos académicos individuales tienen una serie de responsabilidades en las
universidades modernas, incluidas sus obligaciones para trabajar hacia soluciones a
problemas realmente difíciles. Argumentamos en esta sección que los académicos e
investigadores individuales tienen un papel crucial que desempeñar en las guerras de idiomas.
En esta sección, brindamos sugerencias tangibles que creemos que pueden ayudar a los
académicos individuales a contribuir.
3.1.1 Proporcionar evidencia del impacto de un problema
"Dime una última cosa", dijo Harry. "¿Es esto real? ¿O ha estado sucediendo esto dentro de mi
cabeza? " [...] "Por supuesto que está sucediendo dentro de tu cabeza, Harry, pero ¿por qué
diablos debería eso significar que no es real?"
- JK Rowling, Harry Potter y las Reliquias de la Muerte
Los informáticos y los investigadores de lenguajes de programación son
expertos en construir ejemplos que ilustren una situación que podría
considerarse un problema. Normalmente, el enunciado de un problema se utiliza
como trampolín para explicar una posible solución. Como ejemplo, considere el
primer artículo sobre programación orientada a aspectos [24], que se originó en
el diseño de lenguajes de programación, métodos formales, protocolos de
meta-objetos, pruebas de caja gris, construcción de compiladores, etc. Por qué
se desarrolló AOP, no podemos encontrar evidencia en la literatura de que el
problema original se basara en evidencia documentada. Por supuesto,
entendemos muy bien por qué este suele ser el primer paso en la ciencia. Sin
embargo, si bien pensar en un problema potencial es importante primero Paso,
la ciencia moderna en otras disciplinas, cuando se publica en revistas
importantes, suele exigir a los autores profundizar, un paso que a veces se pasa
por alto en nuestra disciplina. Esto nos lleva a la primera responsabilidad de un
académico individual en diseño de lenguaje:
 Las declaraciones de problemas deben incluir reproducciones
Resp. prueba ducible, verificable, de que el
El problema tiene impacto.
Hay diferentes formas de identificar si un problema tiene impacto, que incluyen al
menos: 1) experimentos controlados, 2) estudios de campo, 3) análisis de repositorios
de códigos, 4) encuestas y otras técnicas. Todos estos métodos nos permiten
evidenciar que una situación particular tiene un impacto suficiente como para que pueda
ser detectada y replicada por otros grupos de investigación. Estas técnicas a menudo
pueden con fi rmar, y lo que es más importante, refutar, que un problema es importante,
lo que puede probarse intentando detectar un daño. Por ejemplo, si los académicos
identifican la pérdida de rendimiento en el comportamiento en tiempo de ejecución de
los sistemas informáticos, la pérdida de productividad en los desarrolladores de
software humanos, la disminución de la capacidad de aprendizaje con los estudiantes,
la pérdida de capacidad de mantenimiento u otros factores, estos calificarían. Por lo
general, aunque debería ser evidente, cuanto mayor es el impacto del lenguaje,
3.1.2 Proporcionar evidencia de que una solución ayuda
“Lo comprobé muy a fondo”, dijo la computadora, “y esa es definitivamente la
respuesta. Creo que el problema, para ser sincero contigo, es que nunca has sabido
realmente cuál es la pregunta ".
- Reflexión profunda en la Guía del autoestopista de Douglas Adam para
Galaxia
Si continuamos con el ejemplo de AOP, encontramos que la orientación hacia el espectador
es una técnica que ahora se discute comúnmente en la literatura. Algunos miembros de la
comunidad investigadora han argumentado que su éxito es paradójico [45]. Por un lado,
parece claro que las preocupaciones transversales son reales; realmente podemos
encontrar ejemplos, como el registro, en los que una solución AOP se siente más limpia o
más agradable. O podemos discutir grandes bases de código y la posible necesidad de
"Entonces, supongo, ahora tenemos que empezar de nuevo y empezar a reconstruir todo, como
entretejer código en todas ellas, lo que resulta atractivo para algunos estudiosos.
Sin embargo, considere las investigaciones empíricas sobre la
programación orientada a especialistas realizadas por académicos que son
independientes del grupo de investigación original [2, 11, 12, 17]. En tal
caso, cuando la situación se considera más detenidamente y se pide a los
desarrolladores reales que programen utilizando las nuevas técnicas, los
beneficios declarados de AOP no son compatibles. Las mediciones
cuidadosas refutan las opiniones de la comunidad de AOP de que tales
técnicas son útiles, lo que debería dar una pausa a cualquier académico
que piense cuidadosamente si el problema original fue impactante o si las
soluciones propuestas ayudan. Curiosamente, sin embargo, el primer
experimento a escala de un grupo de investigación independiente sobre
AOP pareció tener lugar más de una década después del artículo original.
En ese momento, los jóvenes académicos que trabajan por la tenencia y la
promoción, si estaban involucrados en tal comunidad,
291
Considere otro ejemplo, en este caso el uso de genéricos. El estudio de Parnin
et al. muestra la frecuencia con la que se utilizan los tipos genéricos en Java [34].
Si bien los aspectos técnicos de los genéricos se publicaron en una gran variedad
de lugares (ver
ej., [3, 21, 33] entre muchos otros), los resultados de este estudio indican que
los genéricos se usan relativamente poco, aunque debe mencionarse que en
una versión extendida del estudio, los autores ven al menos alguna tendencia al
alza [ 35]. 3 Otros ejemplos de tales estudios son el de Gil y Lenz [15] donde los
autores estudian la frecuencia de sobrecarga de métodos en las definiciones de
clase o el estudio de Callau et al. [5], donde los autores estudian el uso de
características de lenguaje dinámico en Smalltalk.
Una característica interesante de los estudios anteriores es que las
construcciones del lenguaje se están probando mucho después de que se inventaron.
Sin embargo, incluso antes de estos estudios, muchos afirmaron que los constructos
eran útiles y, en algunos casos, tenían un impacto mundial. Para dar un ejemplo de
hoy, muchos lenguajes de programación están integrando características de
programación funcional. Sin embargo, cuando analizamos todos los artículos escritos
en ICFP, lo que hemos hecho internamente y codificado formalmente, esta comunidad
argumenta consistentemente que la programación funcional es beneficiosa, pero
tampoco proporciona evidencia, aparte de las de fi niciones puramente técnicas
—necesario, obviamente, pero no suficiente . Tichy parece tener razón; nuestras
comunidades están integrando características sin evidencia. Esto nos lleva a nuestra
segunda responsabilidad:
Resp. Los académicos individuales deben comprender significativamente
aumentar sus estándares de evidencia.
3.1.3 Si no está roto, no lo arregle
nuestras casas, pero ... estaba pensando que tal vez en lugar de casas podríamos vivir en tipis,
porque es mejor en muchos aspectos".
- Richie Norris en Mars Attacks
En la sección anterior, discutimos que los académicos individuales deben desafiarse a
sí mismos para proporcionar una cantidad cada vez mayor de datos y evidencia en
artículos académicos, especialmente con respecto a la evidencia de si una solución de
lenguaje tiene impacto, funciona y realmente ayuda a la comunidad en su conjunto. .
En esta sección, nos enfocamos en un problema diferente que debe ser considerado
por investigadores y académicos de lenguajes de programación individuales, a saber:
solo cambie aquellas características del lenguaje para las cuales exista evidencia
observable directa de que deberían serlo.
Considere un ejemplo hipotético. Suponga que un diseñador de lenguajes acaba de
inventar una nueva característica de lenguaje de programación. Esta característica, se
afirma, es beneficiosa. Asumir como
3 En términos de impacto humano, un estudio mostró que los genéricos ayudan a los desarrolladores que usan una
API que usa genéricos en comparación con los tipos sin procesar en la descripción de la interfaz (ver [19]).
bueno, por el bien del argumento, que este erudito siguió nuestras pautas de las
secciones anteriores. Proporcionaron una prueba formal de que la función
funcionaba, realizaron un ensayo controlado aleatorio con seres humanos que
demostraron que la función tuvo un impacto positivo y realizaron encuestas con
socios de la industria, que colectivamente proporcionaron una base sólida de
evidencia. De esto, concluiríamos que el investigador ha realizado su debida
diligencia, obteniendo plausiblemente varias publicaciones y haciendo su trabajo
como académico de manera adecuada.
Supongamos ahora, sin embargo, que este erudito amplía su trabajo,
incorporándolo a un nuevo lenguaje con su propio compilador. Para construir un
compilador de este tipo, el académico tiene al menos dos opciones: 1) reconocer que
no siempre es posible, incorporar la característica en un lenguaje existente con la
característica incorporada, o 2) construir un nuevo lenguaje que incluya la
característica. Dadas nuestras observaciones de la literatura de investigación y los
lenguajes de programación en el campo, abrigamos dudas de que los académicos
estén tomando decisiones sensatas aquí, que ejemplificamos comenzando con una
discusión de Java y Boo.
Consideremos primero Java, donde encontramos varias formas diferentes de
iterar sobre una colección (por ejemplo, for-loop, while loop sobre un iterador, sintaxis
foreach desde Java 5). Estos métodos albergan los mismos objetivos semánticos,
iterar, pero son sintácticamente diferentes. Cuando los diseñadores de idiomas
cambian el idioma, características como esta parecen aparecer cuando surgen
nuevas versiones. Aunque parece comúnmente aceptado que el objetivo principal de
Java 5 era la introducción de tipos genéricos, por ejemplo, aparecieron nuevas
construcciones de sintaxis sin evidencia de respaldo a favor o en contra de su uso
[19].
Considere como otro ejemplo el lenguaje Boo y su modelo Python. Primero,
Boo anuncia explícitamente diferencias como el sistema de tipos estáticos y la
inferencia de tipos. Como se sabe ahora, existe alguna evidencia de que los
sistemas de tipo estático, al menos aquellos con un sistema de tipo declarativo,
ayudan a los desarrolladores a ser más productivos en una amplia variedad de
condiciones (por ejemplo, con un IDE, sin un IDE, con documentación, sin
documentación ) [12, 25, 31, 37, 42, 46–48]. Por lo tanto, aunque los inventores de
Boo pueden haber conocido o no la evidencia, esta decisión parece estar
respaldada.
En segundo lugar, mientras que los autores de Boo, por lo que podemos determinar,
no proporcionan ninguna evidencia, Boo también introduce una serie de cambios
accidentales o espontáneos, como diferentes usos de las importaciones. 4 O, Boo tiene lo
que llama Generator Expressions, un bucle "for in", para usar la terminología del autor
del Manifiesto de Boo. Además, Boo permite al programador apagar el sistema de tipos
estáticos (llamado Duck Typing), una decisión que no está respaldada por la literatura
sobre sistemas de tipos. El autor de Boo describe esto de la siguiente manera:
A veces es apropiado renunciar a la red de seguridad
proporcionada por la escritura estática. Tal vez solo desee explorar
una API sin preocuparse demasiado por
4 Ver
https://github.com/bamboo/boo/wiki/
Gotchas-para-usuarios de Python para una descripción más completa de las diferencias entre
Boo y Python
292
firmas de métodos o tal vez está creando código que habla con
componentes externos como objetos COM. De cualquier manera, la
elección es tuya, no mía.
Teniendo en cuenta que los estudios mencionados anteriormente muestran que
el tipado estático ayuda a la hora de explorar una API, y teniendo en cuenta que
ningún otro estudio muestra lo contrario, la declaración anterior sobre la
conveniencia de renunciar a la seguridad del tipado estático para explorar una API
debe llamarse fácticamente incorrecto. Si bien existe evidencia en este caso, donde
no hay ninguna, las afirmaciones deben verificarse para ver si cumplen con las
pruebas científicas de corrección. Más importante aún, para los autores de
lenguajes de programación, se debe evitar el cambio espontáneo de las
características de los lenguajes de programación sin evidencia. Si bien no tenemos
ninguna duda de que algunos encontrarán tales cambios en una exploración
inofensiva, creemos que las divergencias de lenguaje no basadas en evidencia,
como esta, son de utilidad discutible y pueden afectar el mantenimiento del
software a largo plazo. Por lo tanto,
Resp. No cambie las funciones de idioma sin respaldo
ing evidencia.
3.2 Responsabilidades de la comunidad de lenguajes de programación
“Empiece por hacer lo necesario; luego haz lo que sea posible; y de repente estás
haciendo lo imposible ".
- Francisco de Asís
Si bien estas responsabilidades estaban dirigidas a académicos, investigadores o
diseñadores de lenguajes individuales, como aquellos que inventan nuevas
construcciones, creemos que es importante discutir las responsabilidades de la
comunidad de lenguajes de programación. Por comunidad de lenguajes de
programación, nos referimos a aquellos académicos, autores o diseñadores que
aceptan nuevos lenguajes o anuncian nuevos lenguajes para su uso en la enseñanza
y la investigación. En esta sección, también estamos sirviendo nuestra discusión a las
juntas de revisión de lenguajes de programación en conferencias, revistas y
académicos en agencias de financiamiento. Si bien admitimos fácilmente que los
académicos, y mucho menos los autores individuales, solo pueden hacer mucho para
atacar un problema tan complejo como las guerras de idiomas, es ingenuo pensar que
una comunidad no puede progresar durante largos períodos de tiempo. Por lo tanto,
describimos aquí nuestros pensamientos sobre lo que se puede hacer,
3.2.1 Imponer la ciencia al caos
"Imponemos orden en el caos de la evolución orgánica. Existes porque lo
permitimos y terminarás porque lo exigimos ”.
- Soberano, Mass Effect
Tanto en un contexto industrial como educativo, se realiza o financia poco trabajo
académico para evaluar las guerras de idiomas.
Comunidades enteras en la National Science Foundation están dedicadas a la
informática educativa, pero estos programas generalmente no tratan este tema, a
pesar de que esto puede llevar a decisiones peculiares causadas por el estado de la
práctica. Por ejemplo, el excelente plan de estudios de la escuela secundaria,
Exploring Computer Science, incluye una variedad de lenguajes de programación.
Esta decisión, de utilizar más de un lenguaje de programación en un plan de estudios
para niños relativamente pequeños, es un reflejo de la disciplina, para bien o para
mal. En esta sección, discutimos los tipos de investigación que creemos que las
agencias de financiamiento, los comités de programas académicos y las revistas
sobre diseño de lenguajes deberían ser alentadores.
En primer lugar, si bien alguien ajeno a la comunidad informática podría
reflexionar con razón por qué no lo hemos hecho todavía, necesitamos un análisis
significativamente más competitivo entre las herramientas del lenguaje. En
conferencias como ECOOP, OOPSLA, POPL, etc., los lenguajes C, C #, Java,
JavaScript, Python, Haskell, Scala, OCAML, F #, Scheme y Lisp son comúnmente
discutidos. Si bien el uso de un idioma en particular siempre está bien para los
académicos que exploran el mundo que los rodea, desde nuestra perspectiva, las
guerras de idiomas han sido causadas, al menos en parte, por la falta de pruebas
formales que comparen aspectos de los productos del lenguaje. Si bien entendemos
que algunos en estas comunidades son matemáticos o diseñadores, las decisiones
relacionadas con el impacto del lenguaje aún requieren evidencia. Esto nos lleva a
nuestra primera responsabilidad con la comunidad:
Resp. Investigar si las características del lenguaje se benefician
programadores en la práctica.
En segundo lugar, los comités deben fomentar una mayor investigación del
misterio y las implicaciones de las guerras lingüísticas. Esto incluye analizar cómo la
divergencia de idiomas está afectando a otras disciplinas. Como solo un ejemplo,
creemos que sería bueno saber cómo la divergencia de idiomas está afectando a los
químicos o físicos. Además, sabemos muy poco sobre cómo la divergencia de
productos lingüísticos está afectando la educación o la industria del software en
general. Si bien pensamos que el resultado de las guerras de idiomas es
probablemente negativo, argumentaríamos que ningún erudito lo sabe realmente: los
científicos de la computación no investigan uno de los problemas más impactantes en
toda la ciencia de la computación. Para ser claros, hemos escuchado a muchos
académicos en nuestra comunidad argumentar, si el lector disculpa una
generalización, que el libre mercado lo resolverá por sí solo. Rechazamos este
argumento, encontrándolo ingenuo. Si el mercado libre pudo resolver las guerras de
idiomas, probablemente ya lo habría hecho. Esto nos lleva a nuestra próxima
responsabilidad:
Investigar la divergencia de lenguajes de programación.
Resp:
Para dar una idea de cómo sería una investigación de las guerras de
idiomas, los estudios podrían analizar ambos idiomas en su conjunto y sus
características. Un buen punto de partida para analizar las características del
lenguaje serían las que ya están
293
disponible en la mayoría de los lenguajes (por ejemplo, bucles, efectos secundarios,
funciones o procedimientos, paso de parámetros, etc.) y las técnicas para estos
estudios probablemente incluirían experimentos controlados. Sin embargo, los
estudios previamente mencionados por Parnin et al, Gil y Lenz, Callau et al, y Souza
[5, 15,
34, 41] que estudiar el uso de las características del lenguaje en los repositorios de código
existentes puede darnos información sobre el uso, aunque determinar la causalidad suele
ser más fácil con el primero por razones bien conocidas.
Por último, las revistas y conferencias de idiomas dedican demasiado
tiempo a investigar temas que, a nuestro juicio, son de menor importancia.
Por ejemplo, las pruebas de solidez de tipo son comunes. Sin embargo,
parece que nunca nos preguntamos: "¿Importa la solidez del tipo?" Si bien no
dudamos de las pruebas, ya que son evidentes por sí mismas, abrigamos
dudas de que la publicación continuada de pruebas de solidez tipográfica
impulsará el estado del arte de una manera significativa e importante, al
tiempo que reconocemos que a veces son necesarias para hacer un punto.
Esto es cierto en nuestra opinión, especialmente, porque muchos de los
lenguajes de programación más populares no son de tipo sonido. Si bien la
solidez del tipo es solo un ejemplo, debemos decir que es obviamente cierto
que las matemáticas son cruciales en el diseño del lenguaje, pero en muchas
disciplinas (por ejemplo,
3.2.2 Llevar a cabo un trabajo de divulgación para difundir afirmaciones
verificables sobre el diseño del lenguaje
"Siempre se brindará ayuda en Hogwarts a quienes la soliciten".
- JK Rowling, Harry Potter y la cámara secreta
Incluso si los científicos trabajan diligentemente en las guerras del lenguaje durante
décadas en un entorno académico, parece poco probable que realmente tenga un
impacto en la práctica a menos que trabajemos con diseñadores de idiomas existentes
fuera de la disciplina. Creemos que este trabajo de difusión debe tomar dos formas con la
comunidad: 1) necesitamos convencer a los diseñadores de lenguajes corporativos de lo
que es verdadero y falso, y 2) se necesita presentar más trabajo sobre cómo el diseño del
lenguaje impacta a los humanos o la sociedad en general, dado que esto es un principio
fundamental de los lenguajes de programación.
En el primer punto, tomemos como ejemplo nuestra discusión anterior sobre Boo o
Java. Por un lado, las nuevas características de dichos lenguajes generalmente no se
basan en pruebas de su importancia. Por otro lado, a menos que la comunidad de
investigadores, después de haber realizado dichos estudios, lleve a cabo actividades de
divulgación para enseñar a los diseñadores por qué sus características tienen éxito o
fallan, y qué diseños tangibles solucionan el problema, poco cambiará.
Desde nuestra perspectiva, las grandes salas de conferencias podrían ayudar mediante la
realización de talleres u otro trabajo de divulgación donde los diseñadores de idiomas
corporativos sean bienvenidos y se les enseñe sobre el impacto del lenguaje. No queremos decir,
en el sentido más estricto, que debamos enseñar cómo ejecutar experimentos, ya que los
diseñadores individuales como el autor de Boo probablemente tengan pequeños mecanismos.
nismo para ejecutarlos incluso si quisieran. Sin embargo, queremos decir que los
diseñadores de lenguajes y los estudiantes en el aula deben aprender lo que
muestra la mejor evidencia disponible con respecto al diseño de lenguajes.
En segundo lugar, la comunidad de investigadores necesita mucho más trabajo para
estudiar el impacto del diseño del lenguaje. Como consecuencia, la comunidad
investigadora debe asegurarse de que los métodos centrados en el ser humano se
apliquen en gran medida en las publicaciones sobre lenguajes de programación. Se
debe fomentar que las presentaciones en conferencias o talleres contengan elementos
sobre los estudios centrados en el ser humano o el impacto del lenguaje en general y
esta información debe compartirse más allá de la academia. Esto es importante, ya que
imaginamos que algunos académicos afirman que es suficiente si se estudia una nueva
construcción del lenguaje utilizando métodos centrados en el ser humano y que no es
necesario realizar un trabajo de divulgación. Sin embargo, en la práctica, muchas
grandes corporaciones son propietarias de los productos lingüísticos que utiliza la
comunidad en la práctica: dependen financieramente. Si la comunidad académica
realizara los estudios, pero no realizara actividades de divulgación, parece plausible que
los socios corporativos lo ignoren. De las dos declaraciones anteriores concluimos la
siguiente responsabilidad de la comunidad investigadora:
Enseñar, comunicar y fomentar métodos centrados en el ser humano
Resp.
en el diseño de lenguajes de programación para una amplia variedad
de audiencias.
3.3 Responsabilidades de la industria del software
Ahora que hemos discutido las responsabilidades de los diseñadores o académicos de
idiomas individuales y de la comunidad lingüística, creemos que es importante señalar
que problemas tan abrumadores como las guerras de idiomas no pueden, y no serán,
resueltos solo por la academia. Los usuarios de tecnologías de lenguajes de
programación, incluidos todos, desde científicos que trabajan en otras disciplinas
hasta diseñadores de videojuegos en Electronic Arts, también tienen
responsabilidades con respecto a este problema. Discutimos estas responsabilidades
en esta sección, centrándonos en 1) la necesidad de más o mejor evidencia sobre
cómo se utilizan los idiomas en la industria, y 2) la responsabilidad de la industria de
exigir mejores pruebas a los diseñadores de idiomas.
3.3.1 Cuéntele al mundo cómo usa sus idiomas
Probablemente una de las responsabilidades más cruciales de la industria del
software es decirnos con más precisión qué lenguajes son de uso común y
cómo se usan. Si bien puede parecer obvio, solo se puede obtener una imagen
de los problemas reales con las guerras de idiomas si lo comprendemos mejor.
Algunos pueden creer que ya tenemos respuestas a esta pregunta, pero aquí
argumentamos que nuestras respuestas son más débiles de lo que
necesitamos.
Por ejemplo, una de las formas más comunes de evaluar los lenguajes
utilizados es un recurso como el índice de Tiobe (como, por ejemplo, se utiliza
en [18, 32, 41]). Este índice se utiliza a menudo como indicador de cómo las
lenguas juegan un
294
papel en el mercado, aunque existen serias críticas que creemos no deben pasarse por
alto. 5 En otras palabras, no sabemos lo suficiente sobre cómo se utilizan los idiomas
en la práctica, lo que dificulta que nuestra comunidad oriente las prioridades de
investigación para satisfacer las necesidades del mercado. Sin esa información, los
eruditos a menudo están en la oscuridad, lo que nos lleva a nuestra primera
responsabilidad:
Resp. Hacer públicos los datos sobre el uso del idioma.
3.3.2 Evidencia de la demanda
No le pague al barquero. Ni siquiera fijes un precio. No le pagues al barquero
hasta que te lleve al otro lado ".
- Chris de Burgh, no le pagues al barquero
Albergamos pocas dudas de que la industria del software en sí misma no puede, o no
puede, realizar de manera realista el tipo de recopilación de pruebas académicas que
se requeriría para conocer el impacto del diseño del lenguaje en la práctica. Las
pruebas matemáticas generalmente las resuelven los académicos y los ensayos
controlados aleatorios a menudo deben ser realizados por grupos independientes del
interés económico propio. Por lo tanto, si bien la industria del software no puede
realizar estudios por sí misma, antes de adoptar productos de lenguaje, instamos a la
industria del software a exigir más evidencia y abandonar los productos / características
del lenguaje que no estén a la altura de las expectativas científicas razonables.
Como ejemplo, considere la nueva especificación para C ++ 11, o el prometedor C
++ 14. En este estándar, el comité ISO de C ++ realizó una serie de cambios en un
lenguaje utilizado en todo el mundo. Incluso un escaneo rápido de la página de
wikipedia de C ++ 11 tiene una sección denominada "Mejoras en la usabilidad del
lenguaje central", una afirmación sorprendentemente específica de los escritores de la
página. Dado que Wikipedia no es una fuente perfecta, si nos fijamos en el borrador de
la especificación de ISO, la palabra "usabilidad" se usa solo una vez, 6 y en su contexto
de uso, probablemente no significaban usabilidad humana.
Lo que nos parece interesante acerca de los cambios en C ++, sin embargo,
es que el comité de ISO parece haber realizado cambios sin evidencia. No está
claro si el estándar es mejor o peor desde un punto de vista centrado en el ser
humano. Considere, por ejemplo, la adición de lenguaje de funciones lambda.
Por un lado, podría parecer que agregar esta característica de lenguaje es
positivo, dado que otros lenguajes han agregado esta característica
recientemente, quizás más notablemente Java JDK
8. Sin embargo, no encontramos ningún registro de la realización de experimentos, no hemos
encontrado ningún dato y, por lo que sabemos, no encontramos ningún registro de
recopilación de pruebas. No hemos publicado
5 ver
por ejemplo http://lambda-diode.com/
programación / el-índice-tiobe-no-tiene-sentido,
http://blog.timbunce.org/2009/05/17/
tiobe-index-is-being-gamed /
6 El borrador de trabajo gratuito se puede encontrar en http: //www.open-std.
org / jtc1 / sc22 / wg21 / docs / papers / 2012 / n3337.pdf
datos recopilados sobre esta característica del lenguaje, pero creo que no está
claro si tiene un gran impacto en la práctica. Esto nos lleva a otra responsabilidad
de la industria del software:
Grupos como ISO y empresas que apoyan
Resp. ellos, deben basar sus decisiones en pruebas.
Queremos ser claros al decir que, si bien reconocemos que tales comités a
menudo tienen que depender del juicio de expertos, C ++ se ha establecido durante
décadas. Cuando se diseñó por primera vez, es comprensible que Stroustrup no
estuviera realizando ensayos controlados aleatorios. Décadas más tarde, sin
embargo, es lamentable que grupos tan grandes e importantes como ISO no estén
utilizando evidencia científica. Si bien algunos de los cambios en la especificación de
C ++ 11 nos “parecen” inofensivos (por ejemplo, agregar una tabla hash a la biblioteca
estándar), otros parecen confusos o de valor cuestionable. En última instancia, es
lamentable que los estándares de evidencia no fueran más altos para algo tan
obviamente importante como cambiar C ++.
Sin embargo, nuestro punto, aparte de los comités o las funciones, es que la
industria tiene un papel que desempeñar en este proceso. Grupos como Microsoft o IBM
que construyen compiladores de C ++ deberían pedir pruebas a ISO y, de lo contrario,
mantenerse firmes porque la productividad de sus desarrolladores depende de un buen
diseño. Google mostró esto con bastante claridad en su último artículo en ICSE [40],
mostrando evidencia de que los errores individuales del compilador estaban afectando
la productividad de los desarrolladores en la empresa. Argumentamos que el comité de
C ++ 14 está siendo pseudocientífico si no está usando el método científico para hacer
la próxima versión. La ejecución de estudios de usuarios es bastante fácil de lograr y
vemos pocas excusas aceptables.
3.4 Responsabilidades de las instituciones educativas
Creemos que las instituciones educativas también tienen un papel importante que
desempeñar en las guerras de idiomas. En última instancia, los académicos deciden qué
productos lingüísticos aprenderá la próxima generación de informáticos y deben educar a
los estudiantes para que utilicen la evidencia al pensar en ellos. Por tanto, los educadores
juegan un papel significativo en las guerras de idiomas y tienen importantes
responsabilidades. Discutimos estos aquí.
3.4.1 Analizar el impacto del lenguaje con los estudiantes
Si bien la comunidad de educación en ciencias de la computación tiene varios roles
importantes (por ejemplo, participación, trabajo con personas con discapacidades,
computación en las escuelas primarias, el impacto del género), estudiar el impacto del
diseño del lenguaje de programación es algo raro en esta comunidad. Esto es interesante
porque, si bien está claro que muchos están interesados en las herramientas visuales, en
nuestra mini revisión de las universidades en el medio oeste, vimos que pocas
universidades realmente usan herramientas visuales para enseñar a los estudiantes
universitarios, casi siempre favoreciendo más lenguajes de programación de propósito
general.
Primero, incluso en lo que respecta a los lenguajes de programación visual, aunque
sabemos que los editores dirigidos por sintaxis [49], o herramientas más modernas como
Alice [6, 36], Scratch [29, 38], o tal vez
295
Los sistemas de programación de usuario final [27] han existido por algún
tiempo, la evidencia de sus beneficios no es tan convincente como algunos
podrían pensar. Por ejemplo, es crucial reconocer que las herramientas
visuales pueden ayudar inicialmente a los principiantes (aunque no para los
ciegos), específicamente a promover la transferencia del aprendizaje de los
sistemas visuales a los lenguajes de programación basados en texto. Esto
ha sido con fi rmado de forma independiente y utilizando diferentes
metodologías con al menos la herramienta ALVIS [20] y Alice [7]. Por otro
lado, un estudio de Garlick y Cankaya comparó el uso de Alice en un curso
introductorio con un grupo de control que comenzó con pseudocódigo, y
encontró que el grupo de Alice tuvo una caída estadísticamente significativa
en las calificaciones [14]; un tipo de estudio muy diferente con un resultado
muy diferente al discutido por Dann et al. [7]. Esto es interesante,
pensamos,
Con una herramienta como Scratch, parece haber poca evidencia rigurosa sobre
el uso de la herramienta en comparación con otras que existían antes. Nos parece
extraño dado el considerable financiamiento de la National Science Foundation para
promover actividades de participación [4, 13, 29, 38, 51]. Si bien no hacemos
afirmaciones sobre Scratch de ninguna manera, nos sorprendió saber que la mayoría
de los artículos publicados que investigamos contenían una recopilación de evidencia
muy limitada, aunque muchos, a pesar de esto, elogiaron la herramienta. Por otro
lado, un estudio analizó 536 proyectos de Scratch y encontró que los estudiantes
aprendieron conceptos de programación usando Scratch a lo largo del tiempo. Esto
puede parecer aceptable hasta que nos demos cuenta de que el estudio no contó con
un grupo de control [28]. Recordamos al lector, como describe Kaptchuk, que el uso
de grupos de control ayuda a descartar cuestiones importantes como el fraude o
cuestiones más mundanas como la incorrección [22]. Más importante aún, dado que
los estudiantes pasan la mayor parte de su carrera académica utilizando más
productos de propósito general que Alice o Scratch, es lamentable que se realicen tan
pocas investigaciones sobre los productos que la gente usa más en el aula o en el
campo.
Esto nos lleva a nuestra primera responsabilidad con la comunidad educativa:
Realizar análisis competitivos de programación.
Resp. idiomas con estudiantes de todos los niveles de la
oleoducto demic.
En segundo lugar, necesitamos tener una mejor idea de cómo se utilizan los lenguajes
de programación en el mundo académico a nivel internacional. Tal como está ahora,
sabemos sorprendentemente poco sobre cómo se utilizan los productos lingüísticos en la
práctica. El trabajo en el compromiso se ha centrado en la escuela secundaria utilizando Alice
o Scratch, principalmente, pero no está claro cuánto se usan estas herramientas en la
universidad o por cuánto tiempo. Si bien algunas escuelas los usan en un curso introductorio,
tenemos pocos datos para respaldar las decisiones que se están tomando, y mucho menos
las consecuencias de esas decisiones. Esto nos lleva a una responsabilidad:
 Resp. Trace cuidadosamente el uso del lenguaje en la academia.
Desde nuestra perspectiva, necesitamos un mapa de este tipo para comprender
las guerras de idiomas. Creemos que proporcionaría al menos lo siguiente: 1) una
estimación más precisa del uso en la academia y las escuelas K-12, y 2) al
identificar las escuelas y universidades que utilizan productos lingüísticos
particulares, podemos trabajar juntos para realizar ensayos controlados en
capacidad de aprendizaje del lenguaje de programación lo mejor que podamos. Por
ejemplo, sería bueno saber si las escuelas que comienzan con lenguajes de
programación visual tienen estudiantes con un rendimiento más alto, en promedio,
que las que no lo hacen, al final de su programa de estudios. Dichos estudios
podrían ayudarnos a determinar si el impacto positivo documentado por Dann et al.
[7] o el impacto negativo documentado por Garlick y Cankaya [14] tiene
implicaciones más allá del primer curso en la universidad.
3.4.2 Enseñar métodos empíricos a estudiantes de lenguaje de
programación
La generación actual de estudiantes de ciencias de la computación en la academia rara
vez, o nunca, se compromete con la evidencia sobre el impacto del lenguaje, con la
excepción de que algunas universidades pueden ofrecer un curso de interacción entre
humanos y computadoras. Si bien no estamos pidiendo más HCI, los cursos actuales
sobre lenguajes de programación suelen seguir el enfoque en el que los estudiantes
prueban muchos lenguajes para darles una descripción general o una introducción a lo
que hay disponible. Otros cursos de lenguaje de programación enseñan características
formales de ciertas construcciones del lenguaje de programación.
Desde nuestra perspectiva, este modelo de enseñanza de lenguajes de
programación es desafortunado para un mundo donde la cantidad de lenguajes y
bibliotecas es tan abrumadora. Hacemos un llamado a repensar nuestro enfoque
para enseñar lenguajes de programación a los estudiantes, uno que reconozca que
el impacto del diseño de lenguajes en las personas es un principio fundamental de
los lenguajes de programación.
Específicamente, proponemos que los cursos de lenguaje de
programación deberían ser más estrictos en la enseñanza de lo que realmente
funciona y deberían disipar el mito de que el lenguaje no importa para la
productividad. Dicho de otra manera, los académicos que imparten cursos de
idiomas deben informar a los estudiantes que los sistemas de tipo estático
mejoran la productividad del desarrollador en una amplia variedad de
condiciones (por ejemplo, con o sin un IDE, sin documentación, con
documentación), los sistemas de paralelismo basados en subprocesos
provocan más errores que el software memoria transaccional, y esa sintaxis
puede causar una diferencia de orden de magnitud en la precisión entre los
estudiantes, resultados para los cuales ya hemos citado ensayos controlados
aleatorios como evidencia. Los autores de libros de texto de lenguajes de
programación, entonces, deberían intentar dar a los estudiantes una visión
completa de la evidencia,
296
Enseñe a los estudiantes sobre las guerras del lenguaje,
Resp. ing argumentos basados en evidencia en el debate.
4. Resumen y discusión
"A lo largo de la historia, cada misterio, alguna vez resuelto, ha resultado ser ... no mágico".
- Tim Minchin, Tormenta
Este ensayo es un primer intento de enmarcar el debate sobre lo que a menudo
se denomina coloquialmente las guerras de los lenguajes de programación.
Esta lucha fue natural para la comunidad informática en sus inicios, cuando no
teníamos experiencia, pero esto ya no es cierto. A principios del 21 S t siglo, ya
sabemos cómo hacer mucho con respecto al diseño de lenguajes y
necesitamos usar esto como un filtro objetivo de lo que ya existe. Además,
creemos que estamos duplicando esfuerzos a una escala demasiado grande, lo
que debe ser investigado y considerado cuidadosamente.
Quizás las extensiones recientes de C ++ son un buen ejemplo de lo que creemos
que salió mal. En el caso de C ++, se siguen inventando nuevas construcciones. Si
bien pocos dudarían de que la innovación puede ser positiva, estos constructos no
tienen base empírica. Incluso en el mundo académico, los académicos están
expresando menos escepticismo del que creemos que deberían hacia las anécdotas y
afirmaciones, al mismo tiempo que muestran demasiado escepticismo hacia la
experimentación, una verdad irónica, dado que técnicas como los ensayos controlados
aleatorios son el estándar de oro en casi todas las demás disciplinas científicas. Dicho
esto, imaginamos que nuestros buzones de correo electrónico dicen: "Pero sí, así es
como se hace". Nuestro argumento es que la forma en que se hace no tiene sentido.
Somos científicos, no albañiles.
La falta de una base de evidencia confiable es el núcleo de las guerras del
lenguaje y es posible que tengamos que hacer cambios en nuestra disciplina para
solucionar el problema. Esto puede incluir alteraciones en las políticas de revisión por
pares, ajustes en la educación y una creciente falta de voluntad para aceptar
afirmaciones hechas por diseñadores de lenguaje que no basan sus decisiones de
diseño en datos científicos verificables y replicables. Esto es importante porque las
guerras de idiomas pueden ser parte de la duplicación de esfuerzos más masiva de la
historia. Como tal, es una mala administración si continuamos ignorando el problema a
perpetuidad.
Imaginamos que un gran número de participantes en las guerras lingüísticas, no
importa lo que hayamos dicho en este ensayo ni cómo lo hayamos dicho, objetarán
utilizando anécdotas o experiencias personales. Imaginamos que los investigadores
nos dirán que no pueden proporcionar evidencia de todos sus pasos o que encuentran
que la recopilación de pruebas de grupos banales o de control no es importante.
Imaginamos que otros eruditos nos dirán que no debemos preocuparnos: la evidencia
empírica es solo una tendencia poco saludable en la investigación del diseño del
lenguaje y desaparecerá pronto. Dada la historia de la ciencia, que tiende hacia
mediciones empíricas cada vez más fiables, tenemos nuestras dudas.
 Parece plausible que los argumentos de la comunidad lingüística sean similares. comunidad de las ciencias de la computación, mientras que otras quizás nunca se

Los desarrolladores de productos lingüísticos que no son académicos, que no tienen cumplan. Sin embargo, imploramos a la comunidad que actúe. Las posibles soluciones a

formación en diseño de estudios ni ningún mecanismo para realizar experimentos, las guerras de idiomas no son mágicas.
dirán con razón que no tienen forma de seguir nuestras sugerencias. Por supuesto,
esto es justificable, pero los desarrolladores que no pueden contribuir a la recopilación 5. Conclusión
de evidencia deberían al menos informarse sobre lo que muestra la evidencia. En
otras palabras, si un diseñador de lenguaje no puede recopilar evidencia sobre la “Soy y siempre seré el optimista, el que espera grandes esperanzas y el soñador de

sintaxis, debe seguir los datos existentes. Si no tienen formación en estudios sobre
sueños inverosímiles”.

sistemas de tipos, deberían volver a colaborar o seguir la evidencia.

- Doctor Who, Undécimo Doctor, Temporada 6, Episodio 6

Mientras escribimos la parte final de este ensayo, sin albergar ilusiones

La industria del software también puede oponerse. Quizás la industria erróneas de que afectará al mundo de una manera sustancial, agregamos

argumentará que no puede esperar a obtener pruebas porque necesita una responsabilidad final, que decimos con toda sinceridad y total seriedad:

soluciones rápidas a sus problemas. Los propietarios de idiomas pueden

decirnos que los estudios no ahorrarán dinero y, por lo tanto, no les importa.
Necesitamos pensar más profundamente sobre el pro-
Ambos argumentos son ingenuos. Lo que vemos en la industria actualmente es
Resp. guerras del lenguaje gramatical, antes de dejar un
que las casas de desarrollo utilizan un enfoque políglota para el desarrollo de
lío para que la próxima generación lo limpie.
software. Es perfectamente normal que un profesional haga una afirmación
como, "Usamos PHP en el backend, con un front-end de Javascript, generando
La guerra de los lenguajes de programación es un gran mal social que causa
HTML y CSS3, usando SQL para nuestra base de datos y una capa intermedia
serios problemas en nuestra disciplina. Creemos que los autores de estos idiomas
JSON". Además, empresas como Microsoft, Google, IBM u Oracle parecen no
realmente quieren mejorar la forma en que el mundo computa, pero nuestra
tener problemas para reinventar sus propias bibliotecas estándar. No tenemos
arrogancia, ignorancia y falta de voluntad para transigir en algunos de los temas más
pruebas pero sería difícil creer que esto es económico o que a estas empresas
básicos de nuestros días ha dejado a nuestra comunidad en un desorden significativo.
no les importa el costo. Una industria del lenguaje basada en evidencia podría, si
Duplicamos esfuerzos masivamente. Reinventamos la rueda constantemente.
jugamos a largo plazo, hacer que tales esfuerzos sean cada vez menos
Dejamos a los científicos de otras disciplinas desconcertados por nuestras prácticas y
necesarios.
estándares de evidencia. Necesitamos hacer algo con las guerras de los lenguajes de
programación. Los últimos cientos de años han sido testigos de una enorme
innovación, en gran parte debido a las observaciones empíricas de la naturaleza. Para
Imaginamos que las instituciones educativas nos dirán que la solicitud de evidencia es
problemas como las guerras del lenguaje, que no se resolverán con una prueba más o
contraproducente y que realizar estudios de investigación en el aula es demasiado difícil.
la magia del libre mercado, debemos unirnos a la comunidad científica en general,
También sospechamos de muchos investigadores de la educación, y con razón,
desafiarnos a no basar nuestras decisiones en la fe, la esperanza y el amor; actuando
imaginamos que incluso si llevaran a cabo tales estudios, los diseñadores de lenguaje
sobre lo que en nuestra opinión es el elefante en la habitación.
probablemente ignorarían la evidencia de todos modos (una afirmación que los autores han

escuchado muchas veces). Además, aunque reconocemos que los estudios en el aula

pueden ser difíciles (véase, por ejemplo, Enbody y Punch [10]), las ciencias médicas lo

tienen dramáticamente más difícil que nosotros: si nuestros estudios fallan, nadie muere.

Sin embargo, aunque obviamente imperfectas por muchas razones, otras disciplinas logran
Expresiones de gratitud
un progreso tangible a lo largo del tiempo utilizando datos empíricos, un hecho que nuestra

comunidad no debe ignorar. Nos gustaría agradecer a Bruce Horn por sus comentarios sobre los borradores de
este trabajo, además de todos los revisores anónimos. Los comentarios detallados que
recibimos fueron extraordinariamente útiles para revisar y mejorar este ensayo.

Finalmente, todos somos muy conscientes de que la mayoría de nuestras

sugerencias no serán tomadas en serio por muchos académicos de nuestra
comunidad. Muchos nos dirán que no necesitan usar evidencia para obtener la
tenencia y la promoción, y probablemente tengan razón, dado que tales
procedimientos a veces se basan en contar documentos en lugar de leerlos. Incluso
hemos escuchado, desafortunadamente, a algunos académicos más jóvenes hacer
argumentos como, "Me complace que necesitemos usar evidencia, pero si lo hago, no
podré publicar mis artículos, porque POPL nunca lo tomará en serio". Es lamentable
Referencias
[1] Asociación AP. Manual diagnóstico y estadístico de hombres
Trastornos del tal DSM-V-TR. American Psychiatric Publishing, Arlington, VA,
quinta edición, 2013.
[2] M. Bartsch y R. Harrison. Un estudio exploratorio del efecto
de programación orientada a aspectos sobre mantenibilidad. Control de calidad del

que cualquier erudito de nuestra historia haya pensado que tal afirmación podría ser software, 16 (1): 23–44, 2008.

cierta. Si la afirmación es realmente cierta, es una farsa. Imaginamos que algunas de
nuestras sugerencias podrían llevar años de introspección por parte del
[3] G. Bracha, M. Odersky, D. Stoutamire y P. Wadler. Mak-
ing el futuro a salvo para el pasado: agregando genérico al lenguaje de
programación java. En Actas de la Conferencia ACM SIGPLAN de 1998 sobre
sistemas de programación orientada a objetos, lenguajes y aplicaciones
(OOPSLA '98), Vancouver,

297
 Columbia Británica, Canadá, 18 al 22 de octubre de 1998, páginas 183–
200. ACM, 1998.
[4] K. Brennan y M. Resnick. Historias desde cero
comunidad: Conexión con ideas, intereses y personas. En Actas del 44 ° Simposio
Técnico de ACM sobre Educación en Ciencias de la Computación, SIGCSE '13,
páginas 463–464, Nueva York, NY, EE. UU., 2013. ACM.
[5] O. Callaú, R. Robbes, É. Tanter y D. Röthlisberger. Cómo
(y por qué) los desarrolladores utilizan las características dinámicas de los lenguajes de
programación: el caso de smalltalk. Ingeniería de software empírica, 18 (6): 1156-1194,
2013.
[6] S. Cooper. El diseño de Alice. Trans. Computación. Educ.,
10 (4): 15: 1–15: 16, noviembre de 2010.
[7] W. Dann, D. Cosgrove, D. Slater, D. Culyba y S. Cooper.
Transferencia mediada: Alice 3 a java. En Actas del 43 ° simposio técnico de
ACM sobre educación en informática,
SIGCSE '12, páginas 141–146, Nueva York, NY, EE.UU., 2012. ACM.
[8] P. Denny, A. Luxton-Reilly y E. Tempero. Toda la sintaxis
los errores no son iguales. En Actas de la 17a conferencia anual de ACM sobre
innovación y tecnología en la educación informática, ITiCSE '12, páginas
75–80, Nueva York, NY, EE. UU.,
2012. ACM.
[9] P. Denny, A. Luxton-Reilly, E. Tempero y J. Hendrickx.
Comprender la barrera sintáctica para principiantes. En Actas de la decimosexta
conferencia anual conjunta sobre innovación y tecnología en la educación
informática, ITiCSE '11, páginas 208–212, Nueva York, NY, EE. UU., 2011.
ACM.
[10] RJ Enbody y WF Punch. Rendimiento de python cs1
estudiantes en cursos cs de nivel medio que no son de Python. En Actas del 41 °
simposio técnico de ACM sobre educación en informática, SIGCSE '10, páginas
520–523, NuevaYork, NY, EE. UU.,
2010. ACM.
[11] S. Endrikat y S. Hanenberg. Es un programa orientado a aspectos
¿Está realizando una inversión gratificante en futuros cambios de código? Un
estudio socio-técnico sobre el tiempo de desarrollo y mantenimiento. En Actas de la
19a Conferencia Internacional sobre Comprensión de Programas del IEEE 2011, ICPC
'11, páginas 51–60, Kingston, CA, 2011. IEEE Computer Society.
[12] S. Endrikat, S. Hanenberg, R. Robbes y A. Ste fi k. Cómo
¿La documentación de la API y la escritura estática afectan la usabilidad de la API? En
36th International Conference on Software Engineering, ICSE '14, Hyderabad, India
- 31 de mayo - 7 de junio de 2014, páginas 632–
642. ACM, 2014.
[13] LP Flannery, B. Silverman, ER Kazakoff, MU Bers,
P. Bontá y M. Resnick. Diseño de scratchjr: apoyo al aprendizaje de la primera
infancia a través de la programación informática. En
Actas de la 12a Conferencia Internacional sobre Diseño de Interacción y
Niños, IDC '13, páginas 1–10, Nueva York, NY, EE. UU., 2013. ACM.
[14] R. Garlick y EC Cankaya. Usando Alice en CS1: A quan-
experimento titativo. En Actas de la Decimoquinta Conferencia Anual sobre
Innovación y Tecnología en la Educación en Ciencias de la Computación, ITiCSE
'10, páginas 165–168, Nueva York, NY,
2010. ACM.
298
[15] J. Gil y K. Lenz. El uso de la sobrecarga en programas java.
En Actas de la 24a Conferencia Europea sobre Programación Orientada a
Objetos, ECOOP'10, páginas 529–551, Berlín, Heidelberg, 2010.
Springer-Verlag.
[16] S. Hanenberg. Fe, esperanza y amor: un ensayo sobre ciencia del software
negligencia de la ence de los factores humanos. En Actas de la Conferencia
Internacional ACM sobre lenguajes y aplicaciones de sistemas de programación
orientados a objetos, OOPSLA '10, páginas 933–946, Nueva York, NY, 2010. ACM.
[17] S. Hanenberg, S. Kleinschmager y M. Josupeit-Walter.
¿La programación orientada a aspectos aumenta la velocidad de desarrollo del
código transversal? Un Estudio Empírico. En Proceedings of Empirical Software
Engineering and Measurement (ESEM) 2009, páginas 156–167, 2009.
[18] M. Hills, P. Klint y J. Vinju. Un estudio empírico de php
uso de funciones: una perspectiva de análisis estático. En Actas del Simposio
internacional de 2013 sobre pruebas y análisis de software, ISSTA 2013, páginas
325–335, Nueva York, NY, EE. UU.,
2013. ACM.
[19] M. Hoppe y S. Hanenberg. ¿Se benefician los desarrolladores de
tipos genéricos ?: Una comparación empírica de tipos genéricos y sin formato en
java. En Actas de la Conferencia Internacional 2013 ACM SIGPLAN sobre
lenguajes y aplicaciones de sistemas de programación orientados a objetos, OOPSLA
'13, páginas 457–
474, Nueva York, NY, EE.UU., 2013. ACM.
[20] CD Hundhausen, SF Farley y JL Brown. Puede dirigir
¿La manipulación reducir las barreras a la programación informática y promover la
transferencia de formación ?: Un estudio experimental. Transacciones ACM sobre la
interacción humana entre computadoras, 16 (3): 1–40,
2009.
[21] A. Igarashi, BC Pierce y P. Wadler. Featherwieght java:
Un cálculo básico mínimo para java y gj. En Actas de la Conferencia ACM
SIGPLAN de 1999 sobre sistemas de programación orientada a objetos,
lenguajes y aplicaciones (OOPSLA '99), Denver, Colorado, EE. UU., 1-5 de
noviembre de 1999, páginas 132–
146. ACM, 1999.
[22] TJ Kaptchuk. Ignorancia intencional: una historia de ciegos
evaluación y controles de placebo en medicina. Boletín de Historia de la
Medicina, 72 (3): 389–433, 1998.
[23] C. Kelleher y R. Pausch. Bajando las barreras a la
gramming: Una taxonomía de entornos y lenguajes de programación para
programadores novatos. Encuestas de ACMComputing,
37 (2): 83-137, 2005.
[24] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, CV
Lopes, J.-M. Loingtier y J. Irwin. Programación Orientada a Aspectos. En ECOOP,
páginas 220–242, 1997.
[25] S. Kleinschmager, S. Hanenberg, R. Robbes, É. Tanter y
A. Ste fi k. ¿Los sistemas de tipo estático mejoran la capacidad de mantenimiento de los
sistemas de software? Un Estudio Empírico. En IEEE 20th International Conference on
Program Comprehension, Passau, Alemania, 11-13 de junio de 2012, ICPC'12, páginas
153–162. Sociedad de Informática IEEE, 2012.
[26] A. Ko, T. LaToza y M. Burnett. Una guía práctica para con-
experimentos controlados de herramientas de ingeniería de software con participantes
humanos. Ingeniería de software empírica, páginas 1–32,
2013.
[27] AJ Ko, R. Abraham, L. Beckwith, A. Blackwell, M. Burnett,
M. Erwig, C. Scaffi di, J. Lawrance, H. Lieberman, B. Myers,
MB Rosson, G. Rothermel, M. Shaw y S. Wiedenbeck. El estado del arte en
ingeniería de software para usuarios finales. Computación ACM. Surv., 43 (3): 21:
1–21: 44, abril de 2011.
[28] J. Maloney, M. Resnick, N. Rusk, KA Peppler y YB
Kafai. Diseños de medios con scratch: lo que los jóvenes urbanos pueden aprender
sobre programación en un club de computadoras. En Actas de la Octava Conferencia
Internacional sobre la Conferencia Internacional para las Ciencias del Aprendizaje -
Volumen 3, ICLS'08, páginas 81–82. Sociedad Internacional de Ciencias del
Aprendizaje,
2008.
[29] J. Maloney, M. Resnick, N. Rusk, B. Silverman y E. East-
mond. El entorno y el lenguaje de programación scratch.
Trans. Computación. Educ., 10 (4): 16: 1–16: 15, noviembre de 2010.
[30] S. Markstrum. Reclamos de juego: una historia de programación
Afirmaciones y evidencia de diseño de lenguaje: un trabajo posicional en progreso. En Evaluación
y usabilidad de lenguajes y herramientas de programación, PLATEAU '10, páginas 7:
1–7: 5, Nueva York, NY, EE.UU., 2010. ACM.
[31] C. Mayer, S. Hanenberg, R. Robbes, É. Tanter y A. Ste fi k.
Un estudio empírico de la influencia de los sistemas de tipo estático en la
usabilidad del software indocumentado. En Actas de la 27a Conferencia Anual ACM
SIGPLAN sobre Programación Orientada a Objetos, Sistemas, Lenguajes y
Aplicaciones, Tucson, AZ, EE. UU., 21 al 25 de octubre de 2012, OOPSLA'12,
páginas 683–702. ACM, 2012.
[32] LA Meyerovich y AS Rabkin. Análisis empírico de
adopción del lenguaje de programación. SIGPLAN No., 48 (10): 1–
18 de octubre de 2013.
[33] M. Naftalin y P. Wadler. Genéricos y colecciones de Java -
acelerar el proceso de desarrollo de Java. O'Reilly, 2006.
[34] C. Parnin, C. Bird y ER Murphy-Hill. Genéricos de Java
Adopción: cómo se introducen, promocionan o ignoran las nuevas funciones. En Actas
de la 8va Conferencia de Trabajo Internacional sobre Repositorios de Software de
Minería, MSR 2011 (Colocado con ICSE), Waikiki, Honolulu, HI, EE. UU., 21-28
de mayo,
2011, Actas, páginas 3–12. IEEE, 2011.
[35] C. Parnin, C. Bird y ER Murphy-Hill. Adopción
y uso de genéricos java. Ingeniería de software empírica,
18 (6): 1047–1089, 2013.
[36] R. Pausch. Alice: La pasión de un moribundo. En SIGCSE '08: Pro-
finales del 39 ° Simposio Técnico SIGCSE sobre Educación en Ciencias de la
Computación, páginas 1–1, Nueva York, NY, 2008. ACM.
[37] P. Petersen, S. Hanenberg y R. Robbes. Un empírico
comparación de sistemas de tipos estáticos y dinámicos en el uso de api en
presencia de un ide: Java vs. groovy con eclipse. En
22a Conferencia Internacional sobre Comprensión de Programas, ICPC 2014,
Hyderabad, India, 2-3 de junio de 2014, páginas 212–
222. ACM, 2014.
[38] M. Resnick, J. Maloney, A. Monroy-Hernández, N. Rusk,
E. Eastmond, K. Brennan, A. Millner, E. Rosenbaum, J. Silver,
B. Silverman e Y. Kafai. Scratch: Programación para todos.
Comunicaciones de la ACM, 52 (11): 60–67, 2009.
[39] CJ Rossbach, OS Hofmann y E. Witchel. ¿Es transac-
¿La programación tradicional es realmente más fácil? SIGPLANot., 45 (5): 47–
299
[39] CJ Rossbach, OS Hofmann y E. Witchel. ¿Es transac-
¿La programación tradicional es realmente más fácil? SIGPLANot., 45 (5): 47–
56, enero de 2010.
[40] H. Seo, C. Sadowski, S. Elbaum, E. Aftandilian y R. Bow-
didge. Errores de compilación de los programadores: un caso de estudio (en google).
En Actas de la 36a Conferencia Internacional de Ingeniería de Software, ICSE 2014,
páginas 724–734, Nueva York, NY, EE. UU., 2014. ACM.
[41] C. Souza y E. Figueiredo. ¿Cómo utilizan los programadores
tipificación nacional ?: Un estudio empírico. En Actas de la XIII Conferencia
Internacional sobre Modularidad, MODULARITY '14, páginas 109–120, Nueva
York, NY, EE. UU., 2014. ACM.
[42] S. Spiza y S. Hanenberg. Nombres de tipo sin tipo estático
comprobar ya mejorar la usabilidad de las apis (siempre que los nombres de los
tipos sean correctos): un estudio empírico. En 13th International Conference on
Modularity, MODULARITY '14, Lugano, Suiza, 22-26 de abril de 2014, páginas
99–108. ACM,
2014.
[43] A. Stefik, S. Hanenberg, M. McKenney, AA Andrews, SK
Yellanki y S. Siebert. ¿Cuál es la base de la evidencia de las decisiones de
factores humanos en el diseño del lenguaje? un estudio empírico sobre talleres de
lenguaje de programación. En Actas de la 20a Conferencia Internacional de
Comprensión de Programas del IEEE 2014, ICPC '14, páginas 223–231. Sociedad
de Informática IEEE, 2014.
[44] A. Ste fi k y S. Siebert. Una investigación empírica sobre
sintaxis del lenguaje de programación. Trans. Computación. Educ.,
13 (4): 19: 1–19: 40, noviembre de 2013.
[45] F. Steimann. El paradójico éxito de la producción orientada a aspectos
gramática. En OOPSLA '06: Actas de la 21a conferencia anual ACM SIGPLAN
sobre sistemas de programación orientada a objetos, lenguajes y
aplicaciones, páginas 481–497, Nueva York, NY, 2006. ACM Press.
[46] M. Steinberg. ¿Cuál es el impacto de los sistemas de tipo estático?
en tareas de mantenimiento? Un estudio empírico de las diferencias en el tiempo de
depuración utilizando lenguajes tipados estática y dinámicamente. Tesis de maestría,
Instituto de Informática y Sistemas de Información Empresarial, Universidad de
Duisburg-Essen, enero de 2011.
[47] M. Steinberg y S. Hanenberg. ¿Cuál es el impacto de la estática
sistemas de tipo en la depuración de errores de tipo y errores semánticos? Un estudio
empírico de las diferencias en el tiempo de depuración utilizando lenguajes tipados
estática y dinámicamente. inédito.
[48] A. Stuchlik y S. Hanenberg. Sistema de tipo estático vs dinámico
tems: Un estudio empírico sobre la relación entre tipos y tiempo de desarrollo.
En Actas del séptimo simposio sobre lenguajes dinámicos, DLS '11, páginas
97–106, Portland, Oregón, EE. UU., 2011. ACM.
[49] T. Teitelbaum y T. Reps. El sintetizador del programa Cornell:
un entorno de programación dirigido por sintaxis. Comun. ACM,
24 (9): 563–573, septiembre de 1981.
[50] W. Tichy. ¿Deberían los científicos informáticos experimentar más? Com-
computadora 31 (5): 32–40, 1998.
[51] I. Utting, S. Cooper, M. Kölling, J. Maloney y M. Resnick.
Alice, greenfoot y scratch: una discusión. Trans. Computación. Educ., 10 (4): 17: 1–17:
11, noviembre de 2010.