¿Por qué las computadoras no pueden programarse por sí mismas?

¿Quién dice que no pueden programarse ellos mismos?
¿Quién dice que no lo hacen ya?

¡Porque lo hacen totalmente !

Esto va a ser largo Correa en.
Entonces probablemente estés viendo esta página de Quora. Asumiré que estás en Chrome / Firefox. Haga clic derecho y haga clic en “Ver código fuente de la página”.
Probablemente verá un gran muro de código, así:

Observe la barra de desplazamiento: ¡hay mucho más allí abajo!

¿Crees que algún pobre pobre realmente pasó horas escribiendo todo eso? Diablos no! Este es un código que un grupo de computadoras se reunieron y escribieron por sí mismas.

Casi todo el Internet funciona así hoy en día. Nadie diseña sitios web y páginas web escribiendo todo el código HTML. Tenemos herramientas que hacen eso por nosotros.

¿Quieres más? ¿Crees que esto no es “programación”?

Está bien, es posible que hayas oído hablar de las bases de datos, ¿verdad? MySQL y demás? Digamos que tiene algunos datos de ventas: el nombre de un vendedor y la cantidad de ventas que ha realizado. Ahora, desea averiguar la mediana del número de ventas realizadas por estas personas. Puede escribir un programa para calcular la mediana, o puede dejar que la aplicación de la base de datos escriba el programa por usted.

Al escribir una consulta, así:

[código] SELECCIONE Mediana de ventas DESDE
(SELECCIONE a1.Name, a1.Sales, COUNT (a1.Sales) Rank
DESDE Total_Sales a1, Total_Sales a2
DONDE a1.Sales agrupar por a1.Name, a1.Sales
ordenar por a1.Sales desc) a3
DONDE Rango = (SELECCIONAR (COUNT (*) + 1) DIV 2 DESDE Total_Sales) [/ código]

Acabas de preguntar a la base de datos cuál es la mediana, y escribirá un programa correspondiente, lo ejecutará y te dará el resultado. ¿Y la razón por la que usamos bases de datos en lugar de escribir el programa nosotros mismos? Debido a que está especializado para tales propósitos, será más rápido que el código de un chico promedio.

¡Vamos aún más profundo!

Muy bien, tal vez tenías algo así como un programa C / Java / Python.
Tengamos un ejemplo de programa Python.

  def addcubes (x, y):
     volver x * x * x + y * y * y

 imprimir addcubes (24, 42) 

El programa anterior primero crea una función que toma dos números de entrada, agrega sus cubos y devuelve el resultado. Además, imprime la salida de addcubes(24, 42) . Ejecutas esto y listo, ves 87912 en tu pantalla.

¿Crees que escribiste el programa que hizo ese cubing y agregando? ¿Crees que fue Python quien hizo la computación y la adición?
No
Esto es lo que realmente sucedió: el intérprete de Python examinó su código, creó un código de bytes para hacer lo que quería hacer y, finalmente, se convirtió en un montón de instrucciones de ensamblaje y luego en binario: 1 y 0.

Son estos 1’s y 0’s los que son el programa real. Python es un programa que analiza el código fuente de Python y escribe un programa para hacer lo que desea, lo que le ahorra la molestia de escribir realmente código de ensamblado / binario.

¡Eso no es lo que quise decir!

Quizás no creas que se trata de computadoras que escriben programas. ¡Te lo aseguro! En toda la historia de la informática, ¿en qué crees que hemos estado trabajando las personas de CS? ¡Abstracción! Los primeros programadores realmente tenían que escribir los 1 y los 0. Luego tuvimos ensamblador, y C, y cada vez más lenguajes abstractos y de alto nivel.

Según los patrones de programación, deberíamos poder generar programas basados ​​en los requisitos especificados por un lenguaje de muy alto nivel

Los idiomas mencionados anteriormente son los idiomas más importantes que está buscando.
Y cada vez más alto a medida que pasa el tiempo. Quiero decir, vamos hombre, han pasado como 60 años desde que Computer Science ha existido.
¡Danos tiempo, te conseguiremos tu Jarvis y HAL9000 y GLaDoS!

Luego están los sistemas operativos. Windows y Android y OS X y Ubuntu. Si desea reproducir un archivo de video, no se preocupe por nada más que hacer doble clic en él. Después de eso, el sistema operativo se hace cargo e invoca el reproductor apropiado, y luego el reproductor multimedia se hace cargo, traduciendo el archivo a píxeles y señales de audio que envía al sistema operativo que se envían al monitor y los altavoces.

Luego está todo el campo de la inteligencia artificial y el aprendizaje automático. Tome cualquiera de las tareas como traducción, filtrado de spam, minería de sentimientos, etc. Estos son programas creados por nosotros diciéndonos, hey, aquí hay un montón de inglés, esto es lo que parece traducido al francés, y a partir de ahí en la computadora tomar cualquier texto en inglés y traducirlo al francés (aunque no siempre perfectamente). Así es como funciona Google Translate.

tl; dr

El punto es que, al final, antes de que una computadora pueda hacer algo, debes decirle qué hacer. Y necesitas decirlo muy claramente y sin ambigüedades. Es esta “revelación” que usted puede encontrar objetable. Y estamos en eso! A medida que las computadoras evolucionan, decirle a una computadora qué hacer se ha vuelto cada vez más sencillo. Hasta el punto que literalmente puedo “decirle” a mi teléfono que “llame a papá” y lo hará.

Entonces, sí, las computadoras se programan totalmente. Los has estado dando por sentado.

Descargo de responsabilidad: soy un estudiante de tercer año de CS, así que en su mayoría sé de lo que estoy hablando aquí. Aún así, si encuentra algún error, ¡dígamelo!

No hay ningún problema fundamental: las computadoras pueden programarse totalmente . Simplemente no muy bien. Todavía. Necesita más investigación.

Afortunadamente, eso es exactamente lo que está sucediendo: la programación automática ha visto un renacimiento académico como síntesis de programas en los últimos años. Este trabajo (o lo que he visto de él, ¡hay un sesgo de selección serio en curso!) Lo realizan principalmente investigadores de lenguaje de programación, por lo que lo encontrarán en conferencias de PL como PLDI. (Por ejemplo, veo al menos cuatro documentos sobre síntesis de la sesión de 2014).

¿Entonces, cuál es el problema? Bueno, en realidad hay muchos problemas, pero agruparé arbitrariamente la mayoría de ellos en dos categorías: interfaz y escala. El problema de la interfaz es cómo permitir que los usuarios le digan a la computadora lo que quieren programar. No podemos usar el lenguaje natural porque la PNL todavía no está allí, y hacer que funcione es un problema por separado extremadamente difícil por sí solo. ¿Asi que que hacemos? El problema de la escala es hacer que las computadoras escriban programas más grandes. Los enfoques actuales de propósito general pueden escribir código no trivial, incluso crear nuevos algoritmos, pero solo para problemas muy pequeños. Tal vez, si no tiene prisa, pueden escribir 100 instrucciones, a menudo con restricciones significativas (como “sin bucles”). ¿Cómo extendemos esto a problemas más grandes y más significativos?

Una cosa muy interesante es cuán diferentes son estos dos problemas, todo mientras están fundamentalmente entrelazados. El problema de la interfaz es, al menos en parte, una cuestión de diseño de la interfaz de usuario, que limita con la psicología en lugar de la CS. El problema de la escala es profundamente técnico y requiere algoritmos inteligentes y herramientas sofisticadas. Y sin embargo, como veremos, los dos terminan profundamente relacionados, con interfaces diseñadas para facilitar la búsqueda y sistemas específicos desarrollados para adaptarse a un determinado flujo de trabajo. Esto lo convierte en un campo fascinante.

Interfaz

El primer problema que tenemos es que, para que una computadora te escriba un programa, tiene que saber lo que necesitas. Y necesita saberlo con suficiente detalle para asegurarse de que realmente esté escribiendo algo útil y correcto. Necesitamos un buen sistema para la especificación del programa . Además, para ser útil, esta especificación tiene que ser más fácil de crear que el programa real. ¡Sería bastante inútil si decirle a la computadora lo que querías fuera tan difícil como programarlo tú mismo!

Hay algunos enfoques diferentes para escribir especificaciones que vale la pena pensar. Quizás lo más directo (¡pero no lo más usable!) Es aceptar una especificación lógica , una descripción de lo que el programa debería hacer en algún tipo de lógica formal. Esto es útil porque especificaciones como esta pueden ser más fáciles de escribir, mantener y modificar que los programas reales. Por otro lado, usar la lógica directamente es bastante extraño para la mayoría de las personas, y estas especificaciones pueden ser bastante incómodas.

Un enfoque muy similar es aceptar una especificación ejecutable , que es solo un programa. Espera, dices, ¿cuál es el punto de la programación automática si primero tienes que darle un programa? Bueno, a diferencia de su programa real, la especificación no tiene que preocuparse por el rendimiento . ¡E incluso puede estar en un idioma completamente diferente! Es mucho más fácil esbozar una versión lenta de su algoritmo que implementar una versión real y optimizada. Esto también abre otro uso interesante para estas técnicas de programación automática: en lugar de aceptar la entrada del usuario directamente, se pueden aplicar a programas ya existentes. Por ejemplo, un proyecto transfiere programas entre diferentes conjuntos de instrucciones utilizando el programa existente como una especificación ejecutable para sintetizar un programa en la otra arquitectura.

Otra técnica es el boceto , donde el usuario proporciona parte del programa final con algunas partes que faltan. El sintetizador luego llena estos espacios en blanco. Esto les permite especificar el resto del programa usando aserciones e invariantes : solo pueden afirmar condiciones dentro del boceto, y el sintetizador genera un código que hace que las condiciones siempre se cumplan. Esto también se puede combinar fácilmente con la técnica anterior de tener una especificación ejecutable; Una invariante muy común es que una función se comporta exactamente como otra proporcionada por el usuario. Además de ser una interfaz interesante, los bocetos también amplían en gran medida el tamaño de los programas que pueden generarse automáticamente al permitir que los humanos suministren las partes “obvias”, ¡partes que no siempre son obvias para las computadoras ! El sintetizador Sketch de Berkeley es la herramienta principal que utiliza este enfoque.

La técnica final que cubriré aquí es la programación por demostración . Este es un poco diferente de los demás porque es muy interactivo. La idea es que el usuario suministre algunos pares de entrada / salida y el compilador genere un programa que sea consistente con ellos. Luego, el programa puede preguntarle al usuario qué hacer en entradas ambiguas específicas, hasta que el usuario esté satisfecho con el resultado final. Un gran ejemplo de programación mediante demostración en la práctica es Flash Fill, una función de Excel 2013 originalmente de Microsoft Research.

El punto es que hay muchas maneras diferentes para que el usuario interactúe con un sistema de programación automática, ¡incluidas muchas que no cubrí o que aún no se han inventado! Todos estos tienen características diferentes tanto desde el punto de vista del usuario como desde el punto de vista del rendimiento.

Escala

En el fondo, la síntesis de programas es solo una búsqueda elegante a través del espacio de todos los programas posibles. Un espacio increíblemente increíblemente grande. Uno que aumenta a un ritmo exponencial muy rápido con la duración del programa que desea generar.

Ahora, podrías intentar forzar a este espacio por fuerza bruta. Genere una secuencia de instrucciones, ejecútelo a través de una serie de pruebas y, si no es correcto, pase a la siguiente secuencia. Al final, terminarás buscando linealmente en todas las cadenas de hasta n instrucciones. Claramente, este no es un enfoque ideal, pero eso es lo que realmente hizo un sistema anterior (en un Intel 8086). Y podría generar programas muy optimizados de 4 a 13 instrucciones de longitud que, aunque no son excelentes, ya son útiles. Además, tiene una sólida garantía de que generó el programa más corto posible para una tarea determinada que, con una arquitectura lo suficientemente simple, también significa que es el programa más rápido posible. Muy genial.

Por supuesto, para aplicaciones prácticas, queremos generar programas más largos, idealmente mucho más largos. Hay algunos enfoques modernos interesantes que mejoran significativamente el rendimiento de esta búsqueda, pero todavía están luchando contra el mismo espacio fundamentalmente exponencial, lo que significa que todavía son bastante limitados. A través de un esfuerzo hercúleo, una heurística inteligente y una tonelada de potencia de cómputo en bruto, podemos generar programas de propósito general de 20, 40 o incluso 100 instrucciones de longitud. Mejor, pero aún limitado. Por lo tanto, además de ampliar la escala mejorando la búsqueda subyacente, mucha investigación también trata de escalar aumentando la utilidad de las longitudes que podemos generar; con un poco de inteligencia, ¡puede hacer que 40 instrucciones sirvan de mucho!

Un enfoque reciente que ha demostrado ser sorprendentemente efectivo, y que ha ahorrado a los investigadores de PL una gran cantidad de problemas, está utilizando los sistemas existentes de satisfacción de restricciones para hacer la búsqueda real. El uso de solucionadores SAT y SMT existentes nos permite aprovechar los avances recientes en esas tecnologías, que fueron motivados en gran medida por usos similares para la verificación y síntesis de hardware. Los solucionadores SAT son programas que pueden verificar si se puede satisfacer una fórmula booleana (un conjunto de variables combinadas con AND y OR lógicos). Es decir, verifica si hay alguna asignación a las variables que hace que toda la fórmula sea verdadera. Los solucionadores SMT amplían SAT con “teorías”, tipos distintos de booleanos, lo que nos permite resolver restricciones sobre cosas como los números. Un sintetizador que usa uno de estos solucionadores compila un programa hasta una fórmula lógica, que incluye variables para las partes que deben sintetizarse, y luego lo pasa al solucionador que devuelve valores válidos para esas variables. Finalmente, todo esto se puede extraer nuevamente en un programa completo en el código fuente original.

En la práctica, existen algunos desafíos particulares con el uso de este enfoque. El método exacto utilizado para codificar un programa como una fórmula lógica puede tener efectos gigantescos sobre cuánto tiempo lleva una búsqueda. Los diferentes solucionadores SMT también exponen diferentes capacidades que los hacen más o menos apropiados para diversas tareas. Algunos proyectos pueden salirse con la suya utilizando un solucionador de propósito muy general como Z3, mientras que, en el otro extremo, proyectos como Berkeley’s Sketch (mencionado anteriormente) tienen sus propios solucionadores especialmente optimizados para la síntesis de programas.

Otro enfoque reciente es utilizar una búsqueda aleatoria basada en Markov-Chain Monte Carlo (MCMC) para generar programas. Esto renuncia a algunas de las garantías de un sistema de fuerza bruta o basado en un solucionador, a cambio de manejar mejor ciertos tipos de problemas. En particular, este enfoque puede aprovechar cierta estructura en el conjunto de instrucciones en el que está trabajando, como instrucciones que hacen casi, pero no del todo, las mismas cosas. Esto resulta ser muy poderoso cuando se apunta a x86, que está bastante hinchado en comparación con la mayoría de las otras arquitecturas. STOKE, el sistema que introdujo este enfoque, manejó los cientos de instrucciones disponibles en x86 mejor que los sistemas basados ​​en solucionadores. Desafortunadamente, este enfoque no se aplica tan bien a otras arquitecturas más pequeñas y tiene algunas partes con las que es difícil trabajar: necesita una noción de cuándo un programa es “casi” correcto. La mayoría de las veces, por supuesto, un programa es correcto o completamente incorrecto, y es bastante difícil adivinar qué tan cerca está. STOKE hace esto ejecutando un montón de pruebas y contando cuántas pasan, pero esto no se traduce bien en otros sistemas.

Además de mejorar el núcleo, la búsqueda subyacente, también podemos mejorar nuestra escala cambiando el alcance de los programas que generamos. Sketch, por ejemplo, hace esto mediante partes generadas de un programa proporcionado por el usuario en lugar de todo. Esto permite al usuario especificar la estructura aproximada del resultado final (como “tendrá dos para la indexación de bucles en estas dos matrices”). Ante esto, Sketch evita perder tiempo generando las piezas “obvias” y puede enfocarse exclusivamente en las partes que causan problemas a los humanos. 100 instrucciones van mucho más allá cuando se centran exclusivamente en puntos de acceso y lógica difícil en lugar de abarcar todo su programa.

Otro ejemplo sería cambiar el idioma en el que está trabajando. Un enfoque muy común es limitarnos al código de línea recta : sin ramas ni bucles. Esto hace la vida mucho más fácil para el sistema de búsqueda, a expensas de una menor generalidad. Por supuesto, el código de línea recta sigue siendo útil porque puede optimizar bucles internos estrechos que tienen efectos descomunales en el rendimiento de todo el programa.

Una opción más interesante es crear un lenguaje específico de dominio completo para su tarea, con límites estrictos en el flujo de control. Este es el enfoque que adopta Flash-Fill para generar eficientemente el código de manipulación de cadenas: debajo de las cubiertas, construye el programa en un lenguaje de manipulación de cadenas que (si no recuerdo mal) solo permite un único bucle externo y limita las operaciones que puede realizar . Esto realmente reduce el espacio de búsqueda al enfocar el solucionador solo en las operaciones que importan. En Flash-Fill, el lenguaje subyacente no es ni remotamente usable por los humanos, lo cual está bien porque nunca está expuesto al usuario. En cambio, el usuario solo ve el resultado del programa generado ejecutado en sus datos.

También podríamos compensar tiempos de ejecución largos calculando previamente funciones útiles con anticipación. Está bien tener un proceso que demore días en ejecutarse en un clúster grande si los resultados pueden ser reutilizados por diferentes personas varias veces. Un proyecto particularmente interesante en este sentido genera optimizaciones de mirilla que luego pueden usarse en un compilador de optimización.

Otras herramientas utilizan la misma tecnología para otros fines, como la depuración interactiva o las herramientas. No necesariamente escriben código para usted, pero usan la misma lógica para asesorarlo mientras trabaja.

Conclusión

De todos modos, el punto central es que las computadoras pueden escribir software por sí mismas, y que esta tecnología está bajo investigación activa. Con el tiempo, ambos hemos mejorado los sistemas para sintetizar código y hemos encontrado nuevos usos para los existentes. La mayoría de los avances aún son algo rudimentarios, y es poco probable que su uso sea real en el corto plazo, pero algunas tecnologías específicas como Flash-Fill ya han encontrado su camino en los productos de consumo .

¡Es un campo muy bueno para ver!

La respuesta de Kaushal Hooda toca algunos de los puntos relevantes.

Lo que agregaré es que el problema no es la computadora, son las personas .

El dominio del conocimiento humano y las expectativas es vasto. Las personas también tienen diferentes modelos mentales de las cosas, diferentes capacidades de manejo de abstracción, diferentes enfoques de comunicación y lo más importante, diferentes requisitos y diferentes expectativas de esos requisitos. Entonces, incluso si la expresión que uso para describir algo que necesito es la misma que usaste, lo que necesito podría ser muy diferente de lo que haces. (Piense en todas las opiniones interminables sobre Apple vs Microsoft UI / UX … ¡no puede complacer a la mayoría de ellas!)

Para evitar tal confusión, tenemos los lenguajes de programación de alto nivel (4GL) y las abstracciones asociadas con eso. Casi cualquier API / entorno como python / matlab / c # / java … encapsula los bloques de construcción básicos que puede mezclar y combinar para que la computadora cree lo que necesita.

Entonces, cuando ‘programa’ en un entorno de alto nivel, todo lo que hace es decirle a la computadora qué tipo de comportamiento necesita, y la computadora lo implementa por usted.

¡Pero obviamente te referías a la programación basada en lenguaje natural!
Y sí, puedo escribir un programa que programe todo para usted, siempre que pueda encontrarme usuarios que describan todo lo que quieran de la misma manera, en el mismo procedimiento, tengan los mismos requisitos todo el tiempo, usando el mismo lenguaje natural. construye todo el tiempo! ¡Búscame ese usuario y él te dirá que mis computadoras pueden programarse por sí mismas!

Pero eso ya lo sabías. Volviendo a su pregunta real, nadie ha resuelto el problema de la representación del conocimiento abstracto y la derivación de implicaciones todavía. Todo lo que hace el aprendizaje supervisado / no supervisado es utilizar métricas estadísticas para obtener un juicio (dado el conocimiento previo de que esto era eso, entonces, ¿cuál es la probabilidad de que esto sea también eso?). Entonces, aunque posee el conocimiento (M LOC), no sabe cómo interpretar ese conocimiento y luego no sabe cómo representarlo para las funciones de costo de su algoritmo genético.

El lenguaje funciona estadísticamente y la inferencia funciona a través de una combinación de estadísticas, estructura y lógica, la comunicación / escritura / texto siempre es ineficiente con muchas variables ocultas y símbolos y ruido caídos. Por lo tanto, es difícil crear representaciones formales utilizando datos estadísticos que pueden pasarse a verificadores lógicos o de reglas.

Esto solía ser un área activa de investigación hasta que apareció Google / FB y distrajo a todos con juguetes creados usando inferencias estadísticas basadas en modelos. Claro que son interesantes, pero ahora tenemos una generación de niños que equiparan el aprendizaje automático con la estimación estadística / hadoop / computación distribuida o a gran escala, etc. Lea algunos de los trabajos más recientes de Minsky / Chomsky (finales de la década de 2000 hasta ahora) sobre este tema.

En cierto modo, ya hemos enseñado a las computadoras a comprender c ++ y realmente todos los lenguajes en forma de compiladores e intérpretes. Un compilador o un intérprete hace un muy buen trabajo al tomar un programa escrito por humanos y decidir si está dentro de los límites del lenguaje. Al igual que su cerebro lee un fragmento de código y lo convierte en señales eléctricas que fluyen a diferentes partes de su cuerpo, la computadora puede interpretar el código a través de pequeñas señales eléctricas para realizar alguna acción significativa.

Probablemente esta no sea una respuesta muy satisfactoria y supongo que tiene más curiosidad sobre las perspectivas de que las computadoras escriban su propio código y luego lo usen para escribir más código, etc. Algunos programas ya existen para generar automáticamente bloques de código. Estas técnicas funcionan realmente bien cuando hay un conjunto específico de entradas y salidas para el problema en cuestión. Donde las computadoras y la automatización en general tienden a tener dificultades es cuando tienes un problema ambiguo que resolver con entradas y salidas desconocidas. Un programa de computadora podría escribir fácilmente otro programa si le di algunos números y le digo que encuentre una manera de sumarlos para igualar una suma específica. Sin embargo, la idea de que una computadora pueda “comprenderse a sí misma” es algo que un humano apenas puede atravesar su sistema, y ​​mucho menos describir ese problema como entradas y salidas para una computadora.

Aunque algunos no estarían de acuerdo, creo que algún día existirá un conjunto lo suficientemente grande de datos etiquetados de problemas que los humanos han resuelto en código, para que una computadora pueda ver todos los ejemplos pasados ​​y aprender. Esto se hace a través del proceso de aprendizaje automático y sería muy difícil. Pero tal vez sea la mejor oportunidad para algún día lograr el escenario ambiguo que usted describe.

Editar: al leer la descripción actualizada de su pregunta, estoy bastante seguro de que esta respuesta ya está dentro de los límites de su comprensión. Quizás beneficiará a algunas personas que aún no ven el problema tan claramente.

Creo que podría dar otra perspectiva. (Nota: no consideremos que el compilador ordinario tenga la capacidad de autoprogramarse aquí porque Kaushal Hooda ya habló de eso)

El programador (bueno, al menos yo) permite que las computadoras se programen a sí mismas todo el tiempo.
Según la correspondencia de Curry-Howard, cada teorema es un programa y viceversa. Y algunos asistentes de prueba permiten cierto grado de automatización de prueba. Ahora dime qué obtuvimos después de combinarlos. Programa de automatización! ¡Exactamente!
Un compilador que, en cierto sentido, escribe una parte de sí mismo:
¿Cuáles son las aplicaciones asesinas para tipos dependientes en lenguajes de programación de propósito general?
Además, aquí hay algunos códigos coq que escribí.
lolisa / COQ_code
Como puede ver, algunas de las funciones son “escritas” por coq usando programación automática.

Entonces, ¿por qué no vemos el código generado por coq / agda / idris en uso amplio?
El problema de satisfacción booleana es NP completo.
La aritmética previa a la hamburguesa tiene al menos una complejidad de O (2 ^ (2 ^ N)).
La lógica de primer orden es semi-decidible.
Y estoy seguro de que el cálculo de la construcción es más expresivo que la lógica de primer orden.

¿Esto significa que la computadora nunca podrá escribir un programa práctico?
Tal vez no. El orden de crecimiento es el orden de crecimiento, no la velocidad: dada una entrada lo suficientemente pequeña, el solucionador de problemas NP puede funcionar más rápido que funcionar en O (n). Tal vez la computadora solo necesita un poco de optimización para alcanzar el rendimiento humano.

El problema principal es “¿Cómo le dices a la computadora lo que quieres?”

Incluso para que un humano haga software para usted, debe darles algún tipo de especificación. Un lenguaje de programación no es más que una forma detallada de explicar sus especificaciones para que una computadora lo entienda.

Podemos crear interfaces de programación de nivel superior, que pueden hacer fragmentos de software más grandes con menos instrucciones, e incluso dejar que la computadora adivine de manera educada dónde hay ambigüedad en las instrucciones, como lo hacemos en lenguaje natural.

Puede parecer más y más como lenguaje natural y cada vez menos como código a medida que avanzamos, pero seguirá siendo una programación humana, es decir, le dirá a la computadora lo que necesita que haga.

El segundo problema es “¿Cómo te imaginas lo que quieres?”

Ni los usuarios ni los ingenieros realmente tienen una idea clara de lo que necesitan / quieren por adelantado.

Es un poco como una pintura. Comienzas con una pequeña idea sobre el panorama general, pero no puedes pensar en cada detalle, y a medida que surgen nuevas restricciones pequeñas y surgen nuevas ideas, incluso el panorama general puede cambiar bastante desde tu primera idea como lo dibujas Una ilustración es el diseño IHM (p. Ej., Diseño web), donde el panorama general es una especie de dibujo real, aunque interactivo.

La mejor solución que hemos encontrado hasta ahora en TI se llama Agile: iterar sobre pequeñas piezas de software, dejar que el cliente lo intente, averiguar qué necesita ser cambiado y cuál debería ser el próximo paso.

Es un proceso completo, y probablemente siempre estará presente, y se llamará programación o desarrollo de software, tan alto como sea.

El tercer problema son las abstracciones con fugas.

Cuanto más alto sea su interfaz de programación, más problemas surgen.

Habrá detalles que su abstracción de alto nivel no tendrá en cuenta y deberá especificar un nivel inferior. A veces tendrá que salirse de los caminos trillados y personalizar su generalización de alto nivel puede ser más largo que especificar todos los detalles desde cero.

Ese es un problema con algunos marcos y algunas de las interfaces de programación de más alto nivel que tenemos actualmente, o con el desarrollo de una aplicación desde otro código de aplicación como un CMS. A veces funcionan bien y ahorran mucho tiempo, pero para algunos proyectos simplemente no son la herramienta adecuada.

Obtendremos más herramientas como esa y más soluciones comunes de código abierto para comenzar desde CMS o ERP, pero mientras el software también se trate de crear cosas totalmente nuevas, no serán suficientes.

Ver la ley de las abstracciones permeables

Esto es posible para pequeños bits de lógica.
¿Conectarlos para que sean útiles y para hacer que las cosas sucedan en el mundo real? increíblemente duro

¿Recuerdas ese tropo de Hollywood sobre cómo solo usamos el 10% de nuestro cerebro (última película Lucy)? Lo que hacemos con la mayoría de nuestro cerebro es reconocer y manipular patrones. La ciencia médica ha tardado décadas en darse cuenta de cuánto de nuestro cerebro se usa para cosas que ni siquiera nos damos cuenta de que lo hacemos tan bien .

Si no te das cuenta de cuánto trabajo se dedica a hacer algo, no lo valoras. Los buenos programadores suelen ser las personas que obtienen puntajes increíblemente altos en las pruebas de reconocimiento de patrones.

Otro lugar donde los programadores usan sus habilidades de reconocimiento de patrones es entender lo que hace el código. El código fuente abierto, como la mayoría de los códigos, no está bien descrito. Se necesita mucho análisis para comprender las consecuencias del uso del código y sus efectos secundarios.

Estas consecuencias se multiplican: piense en ello como construir con legos, pero de vez en cuando hay un ladrillo que explota, o uno que se desmorona cuando se aprieta.

Luego está el efecto de capas: lea la fabulosa respuesta larga de Kaushal Hooda para explicar eso.

Descargo de responsabilidad: soy un desarrollador de software con más de 30 años de experiencia, más de 40 años leyendo SF y aprendiendo neurología y psicología. Algunos de los anteriores pueden estar muy equivocados. Usas tu cerebro para decidir.

Imagine que su automóvil adquirió de repente la sensibilidad, ahora que ya no necesita conducir usted mismo. Impresionante, ¿verdad?

Pero a la mañana siguiente, cuando esté listo para el trabajo, encontró su camino de entrada vacío, ya que su automóvil decidió conducir a Las Vegas por diversión.

No es tan agradable como imaginamos que podría ser. Resulta que todo este negocio de adquisición de conocimiento, aunque agradable en el papel, puede ser bastante incómodo si realmente sucede.

La mayoría de la gente tiene una comprensión intuitiva de eso, es por eso que las historias con AI como villanos se venden bien. Nadie realmente espera que Skynet se vuelva a programar para lanzar todas las ojivas nucleares, pero es una buena película.

Realmente no queremos que nuestras herramientas tengan voluntad propia. Queremos que el control final descanse en nosotros.

Afortunadamente, la realidad coincide con nuestro verdadero deseo aquí: no estamos ni cerca de ser capaces de otorgar libre albedrío a nuestras herramientas. Pero si podemos o no, lo que significa lo anterior es que tenemos que proporcionar información a las herramientas para lograr lo que queremos . Es decir, no importa cuán capaz sea una herramienta, alguien le ha proporcionado el objetivo que está tratando de lograr. Incluso cuando los autos sin conductor están completamente listos, los pasajeros aún deben ingresar la dirección de destino.

Obviamente, ingresar la dirección de destino es mucho más fácil que tener que aprender y dominar cómo conducir, y en última instancia, eso es lo que hacen este tipo de preguntas: ¿cómo podemos hacer que la programación sea tan fácil que alguien ingrese una dirección de destino final? ¿No podemos necesitar aprender a programar, o cómo podemos eliminar a los programadores de la ecuación?

Es decir, ¿cómo puede alguien decir: “Quiero un sitio como el que construyó Quora” y, de repente, aparece un competidor de Quora del genio en la computadora.

Excepto que la programación es mucho más complicada que conducir a un lugar. Para ver por qué, hagamos otro ejercicio de pensamiento.

Supongamos que ahora necesita otro automóvil, ya que su automóvil antiguo se ha hecho grande en Las Vegas y ya no volverá a ser su chofer.

Por lo tanto, puede comprar uno que esté dentro de su presupuesto. Incluso si no está muy bien, es probable que haya muchos automóviles diferentes, usados ​​o nuevos, que estén dentro de su presupuesto, y le llevará un tiempo revisarlos para tomar su decisión. Probablemente pueda aceptar que tomará un esfuerzo decente para comprar y hacer esta compra, y este esfuerzo es más difícil que conducir.

Excepto, ¿dónde está la diversión en eso? ¿Por qué comprar un automóvil cuando puede construir uno usted mismo?

Si construye un automóvil usted mismo, puede hacerlo exactamente como lo desea. Puede tener 5 ruedas, 7 asientos para el automóvil, 3 puertas, un motor de cohete y cualquier otro tipo de artilugios y comodidades que desee en su automóvil. Sí, puede tener una piscina en su automóvil, o convertirla en un bote si lo desea.

Ahora, ¿cómo vas a hacer eso? Si tiene inclinación mecánica, puede diseñar todo usted mismo, comprar los componentes y ensamblarlos. Pero si los componentes que necesita son muy diferentes de lo que está disponible en el mercado, tendrá que hacer los componentes usted mismo, lo que requerirá que comprenda un montón de técnicas de física, química y fabricación que probablemente le tomarán algunas vidas. valor de los aprendizajes.

Lo suficientemente difícil? Esto está más allá de las capacidades de la mayoría de las personas que nunca considerarían hacer algo así en su vida, ni pensarían que podría haber sido tan simple como ingresar la dirección de destino en un automóvil sin conductor.

La programación es la actividad de hacer software. Es equivalente a fabricar un automóvil y, dependiendo de la complejidad, fabricar los componentes del automóvil, o incluso las fábricas que fabrican los componentes.

Cuantas más cosas personalizadas desee, más puntos de decisión tendrá, más abstracciones tendrá que romper y más difícil y complejo será el esfuerzo.

Incluso si decide contratar ingenieros y mecánicos de automóviles para crear su automóvil personalizado para usted, aún tendrá que tomar esas decisiones, comprender si sus decisiones funcionan pueden funcionar con las limitaciones físicas y cumplir con sus requisitos. Aún tendrá que decirle a su equipo lo que necesitan hacer, trabajar con ellos para crear los diseños que lo satisfagan.

Incluso si hay computadoras que pueden hacer lo anterior en lugar de los humanos, no se aliviará el esfuerzo de tomar decisiones. Porque necesita proporcionarles, ya sea humanos o computadoras, la información.

Lo mismo sucede al construir software. Las computadoras son solo herramientas que requieren entradas humanas para hacer lo que los humanos necesitan. No importa cuán inteligentes puedan parecer ser, debajo de todas las fachadas de abstracciones creadas por programadores inteligentes son solo máquinas que procesan 1’s y 0’s.

Para hacer el procesamiento correcto, debe alimentarlos con los 1 y 0 correctos, y para lograrlo, debe decidir qué se debe construir y luego especificarlo en un formato de especificación que se pueda traducir a los 1 y 0 correctos . [1]

Y si su objetivo requiere que trabaje en un nivel inferior de abstracción, como cuando no hay un componente estándar, tendrá que romper la abstracción y lidiar con la complejidad adicional en ese nivel inferior, potencialmente todo el camino hacia el metal desnudo.

Este proceso de determinar qué se necesita construir en el nivel correcto de abstracción, no se puede reducir y es la esencia de la programación.

–

1) Este formato de especificación también se conoce como lenguaje de programación. It doesn’t matter what we humans call them, a specification unambiguous enough for compilers to translate and execute is a programming language, and the person writing them is the programmer.

Computers cannot create logic. Programming is all about logic. However, a computer can infer logic which are predefined, but it cannot create a new one.
You can relate this problem to P vs NP problem. For example, verifying a function f(x,y) over a set of values of {{x},{y}} is easy rather than finding solution for f(x,y).

I would suggest the problem isn’t deducing the function of the code (although that is probably impossible to with code of any complexity), but it’s explaining to computer what we want as output.

Let’s say you want the computer to produce a competitor to PhotoShop, how do you explain that to the computer? Or say a spreadsheet to rival Excel? How do you say to the computer that you want a spreadsheet? A computer doesn’t know what a spreadsheet is, just has no concept of it.

Computers can program themselves in some small ways, ways in which are easier to explain to a computer. But I think until we can find a way to get a computer to understand what things are and how they work, then I don’t see it getting to the point that a computer can program itself in the same way a human can, or anywhere close to it.

I have written programs to write programs using a technique call Genetic Programming. John Koza, who has written three tomes on the subject, has used the technique to have his system create several results that infringe on patents. It generally involves viewing the program as a tree and creating an initial population of individuals and testing them against a “fitness function” that determines roughly how close the program has come to the result you want. Then a new generation is produced by cutting and splicing some of the code much as what happens in mating. Then there are mutations based on a probability which is specified. This only a rough sketch but then this repeats until an individual in a generation meets the requirements. Google genetic programming which is different than genetic algorithms.

This question is like: Why children can’t teach themselves.

The answer is they need someone to supervise and show them how and what to do.

Computers are more stupid than humans, so they cannot be responsible they cannot take the blame if something goes wrong.

Computers are not inventive and just know what they’re told.

Computers cannot think like humans or even like animals, their main power over living being is to remember details reliably for a long time and their speed.

Even if computers will program themselves it will not be, at least, in this decade.

Where is your time best spent: Developing a computer that works better than humans (which is extremely complex and not without its great caveats, as discussed below) or mentoring (developing) humans?
As a developer, I want smarter computers (every day), but I’m going to suggest that developing smarter computers may not be the best use of our time.

Because they can’t.

Anything that come out of computer that do not programmed by human will be just meaningless output.

Although it is amazing how fast they can execute the program, they have no idea what are they doing. The program and the data itself is meaningless to them. The input and output that come in and out of computer ONLY meaningful for us human.

There will be no pattern found if you do not understand what the pattern is in the first place.

Because humans are still here. I’m serious.
If a computer had the flexibility to program and improve itself to anything like the extend we humans are capable of imaging we would be long obsolete. Once you start a computer now the road of being able to build better computer there is no going back. This is called the friendly AI problem and there are serious academic research being done to embed the al with similar value system that are friendly to humans. The problem I see is that a truly self improving computer would be able to remove that program by virtue of being capable of self modifying. I have nightmares about this. You should too.

They can.

But only we know what we want them to do.

A computer that programs itself will do what it wants. We’re only interested in computers that do what we want. So we have to tell them.