¿Crees que, algún día, crear programas será arrastrar y soltar? ¿Esto reducirá las necesidades de los ingenieros de software, ya que todos podrán programar?

Investigué sobre el tema cuáles son los problemas cuando los usuarios emplean abstracciones para resolver problemas complejos, como crear un informe a partir de múltiples fuentes de datos.

Hay muchos lenguajes gráficos que pueden emplearse, así como lenguajes de programación textuales de propósito general o lenguajes específicos de dominio.

Lo interesante es que el problema subyacente no se vuelve más simple. Incluso con la abstracción, todavía hay una tarea de programación en la parte inferior. Los resultados de mi experimento mostraron que, si bien los no programadores encontrarán una solución, no son más rápidos que usar un lenguaje de programación, y la solución no es mejor (en términos de olvido de casos extremos, controles de cordura, calidad de resultados, etc.). Especialmente cuando el problema se vuelve complejo, los lenguajes visuales en realidad son peores que los gráficos debido al espacio que necesitan y al diseño complejo que tendrá el programa.

Sin embargo, una cosa que los lenguajes gráficos y las herramientas pueden hacer es ayudar a las personas que tienen ” miedo al código ” o que comprenden mejor los problemas con una representación visual. Un buen ejemplo es el lenguaje de programación Lego Mindstorms NXT:

Otras respuestas dicen que no. Algunos de ellos proporcionan evidencia en forma de IDE de arrastrar y soltar que no lograron eliminar la programación convencional, atribuyendo esto a la dificultad de expresar ciertas abstracciones como gestos de arrastrar y soltar.

Estoy de acuerdo en lo que respecta a ellos, pero creo que el verdadero asesino es la falta total de disciplina intelectual que afecta a la mayoría de los simios que hablan.

Y hablar de simios es lo que son, son bastante buenos para expresar amenazas y deseos básicos sin mencionar mentiras, pero la mayoría de ellos no saben la diferencia entre AND y OR, incluso después de que se les explica por noventa y siete veces. .

Digo “ellos” porque algunos de nosotros entendimos de inmediato y nos convertimos en programadores.

La programación es una colección de modos de pensamiento aprendidos. Si no tiene una aptitud para esto, ninguna cantidad de recubrimiento de azúcar puede disimular su incapacidad para aprender nuevos modos de pensamiento y mantener la disciplina mental.

Los programadores, por otro lado, no son tan buenos con las amenazas o las mentiras, y no sucede mucho en el camino del deseo básico porque el departamento de ventas ya se ha llevado todas las bellezas.

En el pasado, SQL iba a hacer autoservicio MIS porque los gerentes iban a expresar sus consultas en inglés simple. Esto no fue una gran exageración, eran expertos en dominios autoproclamados en el mundo de los negocios en general y sus negocios en particular.

No sucedió con SQL, no sucederá con GUI. El problema no son las herramientas, es la falta de inclinación de la mayoría de la población a pensar en cosas que les duelen la cabeza cuando podrían robarse, beber cerveza o echarse un polvo.

Es posible que tenga la relación causal invertida aquí. Tal vez aquellos sin aptitud para los diversos libertinajes no tengan distracciones y llenen el vacío adquiriendo habilidades que nos permiten encontrar otra satisfacción. Pero prefiero la interpretación que me permite sentirme superior, porque yo también soy un mono.

Probablemente sea muy posible tener herramientas visuales, de arrastrar y soltar que permitirían resolver una clase de problemas muy similares, como puede tener un generador de informes visuales para crear informes personalizados.

Cuanto más complejo sea el problema, más difícil será usar dicha herramienta. Imagine que tiene 500 tipos de bloques y 300 tipos de flechas para conectarlos. ¿Arrastrar y soltar realmente lo ayudará?

La parte difícil de la programación de computadoras no está relacionada con escribir texto y recordar palabras clave. Lo que hacen los programadores es resolver un problema y solo expresar la solución de una manera que la computadora pueda entender. Cuando el ingeniero comienza a escribir, la solución ya está aquí, en su mente. Crear esta solución es una parte difícil de la programación de computadoras, ya que en muchos casos encontrar la solución requerirá mucho conocimiento y comprensión previamente adquiridos sobre cómo funciona realmente la computadora.

Sin embargo, las herramientas visuales son una buena adición para ayudar a los ingenieros con algunas partes del trabajo:

1. Modelando la interfaz de usuario, vinculándola a partes de la lógica
2. Describir los flujos de trabajo y los procesos empresariales.
3. Modelado de estructuras de datos: relacionales, objetos, etc.
4. Estructura de definición de informes, páginas web, etc.

Espero que no, y no lo creo.

Digamos que se hizo solo con arrastrar y soltar, eso no significa que nadie podrá programar más de lo que significa que puedo ser un artista gráfico porque PhotoShop e InDesign son aplicaciones DnD.

Cuando tengo un problema que trato de resolver en programación, ni una sola vez, en más de 20 años, he pensado: “¡Esta maldita escritura! ¡Si pudiera arrastrar algo a algún lado, me habría lamido!”.

¿Realmente crees que serías capaz de hacer tu propio núcleo del sistema operativo, si tan solo pudieras arrastrar cosas?

Finalmente, para un usuario experimentado de la computadora, DnD es menos eficiente e incluso menos * fácil * que simplemente escribir cosas en un editor o una consola.

Un ejemplo de esto sería la aplicación Automator de Apple, es una manera simple de automatizar muchas tareas en una Mac. Es bastante bueno para los principiantes, pero caótico y un verdadero dolor real en el culo en comparación con escribir un pequeño Python, suponiendo que sepas cómo.

P: ¿No crees que, algún día, crear programas será arrastrar y soltar?

R: No, no sucederá ‘algún día’. Ya está sucediendo y lo ha estado haciendo durante mucho tiempo.

P: ¿Esto reducirá las necesidades de los ingenieros de software, ya que todos podrán programar?

R: Sí, esto reducirá las necesidades de los ingenieros de software. De hecho, lo ha estado haciendo durante décadas (desde que Mac se hizo popular en la década de 1980) y continuará haciéndolo en el futuro previsible.

Sin embargo, todos NO podrán programar TODOS los tipos de programas sin capacitación especializada en algunas áreas. Cálculos automatizados de software de hoja de cálculo que anteriormente requerían un programador de computadora. Lo mismo ocurre con el software de dibujo y pintura, el software de diseño de página, la creación de páginas web de arrastrar y soltar, et al.

Es probable que otros avances en áreas como hápticos, reconocimiento de voz, inteligencia artificial y redes neuronales, visualización en 3D y biosensores tengan un impacto igual o mayor en la automatización del desarrollo de software que la herramienta de arrastrar y soltar.

Otras actividades que a menudo requieren habilidades especializadas están siendo suplantadas por la automatización, por lo que no veo por qué la necesidad de ingenieros de software no se reducirá (aunque no se elimine por completo). Hay pilotos automáticos para aviones, automóviles, camiones y embarcaciones, que a menudo operan de manera superior a los humanos. Inicialmente, los pilotos automáticos no están reemplazando completamente a los pilotos y conductores, pero no hace falta un clarividente para ver hacia dónde nos dirigimos. Tampoco hace falta un clarividente para ver que los ingenieros de software continuarán avanzando en la automatización de sus propios trabajos, además de otros tipos de trabajos.

Uno de los problemas que tomo con la mayoría de las respuestas a esta pregunta es el conocimiento limitado que la mayoría tiene sobre las herramientas de software disponibles que sirven para automatizar el desarrollo de software y cómo se ha desarrollado el campo a lo largo de las décadas. Hay tantos ejemplos que podrían citarse. Por ejemplo, el software de desarrollo multiplataforma permite a un programador escribir software que de otro modo requeriría varios programadores. Un programador puede escribir una aplicación en un sistema como LiveCode y compilarla en código nativo para Windows, Mac, iOS, Android y Linux. No es simplemente un problema de arrastrar y soltar, es una amplia gama de técnicas de software en evolución que están reemplazando lentamente la necesidad de programadores.

Me pregunto por qué la mayoría de las respuestas no hablan de este punto tan importante.

1) La programación no se trata básicamente de escribir códigos. Hay más para pensar que para escribir.
Suponga que se le permite usar ese tipo de lenguaje de arrastrar y soltar en IOI, codeforces o un concurso popular como ese. Si no tiene idea de algoritmos, estructuras de datos y conceptos importantes como la complejidad de tiempo / espacio, casi obtendrá una puntuación muy cercana a cero. Lo mismo con la programación de la vida real. Entonces, incluso si se implementó un lenguaje de arrastrar y soltar con todas las características en Java / C ++, no significa que todos puedan programar.

2) eficiencia
Por supuesto, si se trata de una aplicación realmente simple que implica un simple ” si esto es así, entonces haga esto” como pasos que todos podrán crear un programa que funcionará como se espera. Pero aun así, si no tiene idea de la complejidad del tiempo y la eficiencia de un programa, el programa sería muy ineficiente y la aplicación tardará mucho tiempo en ejecutar una tarea que de otro modo sería posible hacer mucho más rápido.

3) Diferentes programas que usan el mismo idioma de arrastrar y soltar
Por ejemplo, si le pidió a un ingeniero de software y a un ingeniero que no es de software que cree una solución para el problema de la mochila usando el mismo idioma de arrastrar y soltar.
El ingeniero de software idearía una solución DP que se ejecutaría en O (n ^ 2) utilizando el lenguaje dragndrop, mientras que el ingeniero que no es de software simplemente crearía una solución muy ineficiente que se ejecuta en O (2 ^ n).
Entonces, aunque ambos usaron el mismo lenguaje dragndrop, la solución del no programador no es prácticamente utilizable. Entonces, no es el código o en nuestro caso los rectángulos gráficos lo que importa, es lo que haces con ellos.

Claramente, no todos serán capaces de ser un buen programador sin ningún tipo de estudio (formal / autoestima) simplemente porque existe un lenguaje en el que es fácil escribir los pasos.

4) ¿La programación será arrastrar y soltar algún día?
Seguramente no.
No porque sea difícil crear ese lenguaje de arrastrar y soltar con todas las funciones.
Pero porque es mucho más fácil escribir un código que arrastrar y soltar.
Piensa en la siguiente línea,
si (x == 4) c = 201;
Me llevó menos de 5 segundos escribir esto,
Ahora creo que tuve que escribirlo usando un lenguaje de arrastrar y soltar.
¡Primero tendré que arrastrar la condición IF al programa desde una caja de herramientas con el mouse!
Y lo mismo con el comparador (==) y los operadores de asignación (=) pueden ser.
¿Realmente crees que es más fácil que escribir este código? Seguramente no has codificado.

Entonces, en última instancia, como en la pregunta,
¿No crees que, algún día, crear programas será arrastrar y soltar? ¿Esto reducirá las necesidades de los ingenieros de software, ya que todos podrán programar?

a) ¿No crees que, algún día, crear programas será arrastrar y soltar?

Parece que la pregunta asume que todavía no estamos tan avanzados en tecnología para desarrollar un buen lenguaje de arrastrar y soltar con todas las características en java / c ++ y es por eso que la gente todavía usa lenguajes de codificación como lenguajes de programación. Esto no es verdad. No somos técnicamente inviables para crear dicho lenguaje. Pero es realmente difícil programar usando un lenguaje que un lenguaje de codificación ordinario para un programador.

b) ¿Esto reducirá las necesidades de los ingenieros de software, ya que todos podrán programar?
No, todavía necesitaremos programadores (programación de arrastrar y soltar) incluso si (lo que no sucederá) la mayoría del software que se desarrolla en el mundo se realizó utilizando lenguajes de arrastrar y soltar.

Cuanto más fácil se vuelve la programación, más difíciles se vuelven los problemas que se le pide resolver. Una programación más fácil no significa menos programadores, significa problemas más difíciles. Y como hay problemas más difíciles que problemas fáciles, terminas empleando más programadores.

Tuve un excelente ejemplo de esto al principio de mi carrera en 1981. Éramos distribuidores de una computadora de mano que solo podía programarse en Assembler. Desarrollamos un cumplimiento cruzado de Pascal, que hizo que los programadores (literalmente) fueran aproximadamente 50 veces más productivos. Llevamos el sistema al fabricante y se lo ofrecimos por casi nada. No lo aceptarían. Le pregunté al jefe de ingeniería de software por qué no, y en un momento de franqueza admitió el problema: como un programador de Pascal podría hacer el trabajo de 50 programadores de ensambladores, se quedaría sin programadores.

Lo que no entendió fue que facilitar la programación significaba que podíamos buscar una gama mucho más amplia de aplicaciones y clientes de manera rentable, por lo que la naturaleza de nuestro negocio cambió. Nosotros (en Australia) éramos los mayores distribuidores de este producto en el mundo, porque podíamos abordar problemas mucho más difíciles y, por lo tanto, un mercado más grande. De hecho, empleamos más programadores Pascal que el fabricante empleó programadores ensambladores debido a esto.

Este tipo de cosas pasan constantemente. La programación OO es mucho más eficiente en tiempo que el uso de lenguajes de procedimiento antiguos, pero la adopción de OO no redujo el número de programadores en el mundo; facilitando la escritura de programas duros expandió lo que se podía hacer de manera rentable con las computadoras y condujo a un aumento en el número total de programadores.

La regla parece ser que facilitar la programación no reduce su necesidad de programadores, sino que la aumenta, ya que permite desarrollar una gama más amplia de aplicaciones de manera rentable.

Siempre hay un área grande para el uso de herramientas CASE (Ingeniería de software asistida por computadora). Hay mucho en la programación que siempre se puede automatizar. Pero al final, siempre necesitará programadores humanos profesionales.

La razón fundamental es que la persona que solicita el programa nunca comprende realmente lo que está pidiendo. Hay tres partes en esto.

Una es que podría ser que lo que se solicita es realmente una nueva heurística de lo que es un problema formal de NP. Se le pide que invente un nuevo algoritmo. No es algo que puedas sacar de una bolsa de trucos conocidos. El problema fundamental es que la persona que lo solicita no se da cuenta de que es tan difícil. Incluso si la persona que pide algo es un profesional en lo que está haciendo, no es un profesional en algoritmos y no puede saber cuándo está pidiendo algo trivial o algo imposible. Es poder comprender la dificultad algorítmica del problema que requiere un programador profesional. El software automático podría escribir programas para los problemas fáciles, pero ¿quién debe detectar cuándo es un problema difícil y quién debe resolverlo entonces?

El segundo punto es que, como en cualquier solución de ingeniería, hay que hacer un millón de compensaciones. Hay tiempo de ejecución versus estructura de datos, tiempo de entrega versus función terminada, y se presenta una solución específica muy limitada en comparación con una solución más general que es más fácil de adaptar a futuros cambios, lo que hace que sea fácil de usar en lugar de permitir muchas opciones. Una vez más, la persona que solicita el software no es consciente de todas estas compensaciones. De nuevo, se necesita un programador profesional para poder verlas.

El tercer punto es que, en la mayoría de los casos, la persona que solicita una solución ni siquiera sabe lo que realmente quiere. Todo se trata simplemente de agitar las manos y “ya sabes, haz que funcione” y “esa es la idea general, muéstrame algo y te diré si me gusta”. Por lo general, es “hacer algo así, excepto diferente”. Peor aún, el usuario puede preguntar cuáles son los requisitos contradictorios. “Hacer es hacer cualquier cosa, pero fácil de usar” es uno de los favoritos. “Haz que haga esto y esto y esto y esto, con un solo botón”. No hay nada que impida al usuario indicar el problema de esa manera. En algún momento, algún profesional debe sentarse y analizar lo que está sucediendo.

Parte de la respuesta a todos estos casos es que el programador entable un diálogo con la persona que solicita el programa. El programador dice cosas como “OK, esto es lo que realmente estás pidiendo, ¿es eso lo que realmente quieres?”, O “Acabas de pedir un proyecto multimillonario de cinco años, ¿es eso lo que realmente quieres?” o “OK, no podemos hacerlo todo en la línea de tiempo dada, priorizar una lista de las cosas que se pueden descartar”, o “OK, esa parte es trivial y te la consigo esta tarde, ¿qué más hacer? ¿usted quiere?” o “OK, este botón no puede hacer que la imagen suba y baje al mismo tiempo, ¿qué tal esto?” Esta es una parte necesaria del proceso.

Pero incluso después de eso, todavía hay muchas decisiones fundamentales en términos de lidiar con la complejidad del problema, las compensaciones del problema y la definición real del problema, que el programador tiene que tomar solo para obtener Lo hecho. Todas estas decisiones que se toman, entre el usuario y el programador, y por el propio programador, requieren una gran madurez profesional para tener éxito. Y puede tener problemas muy grandes cuando se toman malas decisiones. Claro que puede automatizar todas esas decisiones en función de un conjunto predeterminado de prioridades. Pero, ¿quién debe saber cuándo esas prioridades cambian o no se aplican?

La persona que solicita el programa nunca tendrá la experiencia y la competencia para identificar y tomar todas estas decisiones por su cuenta, y luego presentarlas a las personas de programación perfectamente factibles, factibles y definidas, y todo concluido con un arco Con suerte, es porque la persona que lo solicita es un profesional en otra cosa. Sin embargo, también hay momentos en que, como programador, ni siquiera lo entiendes.

Si todo su mundo consiste en tratar solo con problemas que ya están 100% definidos y solucionables, entonces puede hacerlo todo escogiendo y eligiendo de una bolsa de trucos. Mucha vida es así. Crear un conjunto de datos y una serie de cálculos en Excel es así. Esas herramientas son muy importantes y muy útiles, y cubren mucha vida. Una vez más, siempre existe la necesidad de más y mejores herramientas CASE en la programación misma.

Pero para algo nuevo y significativo, el problema, como se dijo originalmente, siempre será una combinación de poco o mal o francamente mal definido. La dificultad es que la solución, el programa real, estará 100% claramente definido. Está reduciendo esa brecha entre la definición general del problema y la solución real que necesita programadores humanos en la vida real.

Se supone que los generales siempre están “peleando la última guerra”. Eso es porque eso es lo único que saben hacer. Puede obtener software automatizado para escribir “el último programa”. A veces eso es muy útil, y a veces los generales tienen razón. Es resolver nuevos problemas lo que lleva a un humano profesional a cerrar la brecha entre saber qué se puede hacer y qué se está pidiendo realmente. Para un nuevo problema, en algún lugar entre definir cuál es realmente el problema y encontrar una solución, se produce un acto de creatividad e invención. Se necesita creatividad para ver que tal vez se puede hacer algo nuevo, o que lo que se solicita es realmente diferente de lo que se dijo. Algunos de los inventos más importantes no fueron el resultado de encontrar una nueva solución a un problema dado, sino el resultado de volver a plantear el problema dado como algo más.

Por lo general, la persona que lo solicita en primer lugar no tiene la capacitación y el talento para hacer ese paso creativo, para salvar la mano y el resultado final. Para eso está un programador humano profesional. El único momento en que sucede es cuando un programador profesional declara y resuelve su propio problema. Pero encontrar el dinero para eso es un poco complicado.

Se necesitan buenos ingenieros (al menos buenos) debido a estas herramientas. 🙂 Lo llevan a un punto en el que necesita comprender no solo cómo usar la herramienta de codificación DnD, sino también cómo funciona debajo para que pueda codificar a su alrededor y a pesar de ello.

Soy fanático de las herramientas visuales: trabajé en wavemaker.com, un IDE basado en navegador DnD, en Sun on Netbeans (JATO / Marco de aplicaciones web / Herramientas, Refactorización y módulos UML) y NetDynamics App Server e IDE antes de eso) , pero no es fácil hacerlo bien para la mayoría de las cosas. Por lo general, puede acertar de algunas cosas a cierto nivel de profundidad antes de que alguien que pueda escribir código, que escale, necesite hacerse cargo.

Hasta que un ingeniero de software brillante invente la IA para escribir código por sí solo, los programadores de todos los niveles tendrán trabajos. Una vez que la IA es una realidad, bueno, esa es otra pregunta que estoy seguro que me han hecho aquí. 😉

La pregunta realmente no es si los programas se realizarán mediante arrastrar y soltar, sino que la disciplina de recopilación de requisitos y la creación de consenso se puede hacer más arrastrar y soltar. La mayoría de los problemas importantes que he observado se produjeron debido a la recopilación y / o articulación inadecuada / imprecisa / incompleta de requisitos.

Las personas comunican conceptos complejos utilizando abstracciones situacionales y experimentales: pedir una silla puede estar solicitando una silla de puf, un banco, una roca, una silla plegable, etc. El verdadero desafío es reducir el contexto de la solicitud para determinar el tipo de silla, su uso anticipado, métodos / materiales de construcción esperados, restricciones de costos y duración del uso.

La ingeniería de software debe lograr una buena y correcta ‘traducción’ de los deseos y necesidades de los usuarios a posibles soluciones aceptables, no solo una generación rápida de soluciones. Dado que los usuarios con frecuencia acuerdan una abstracción, pero no detalles específicos (por ejemplo, uso anticipado, construcción, duración, presupuesto), la generación de soluciones más rápida / fácil no eliminará la necesidad de ingenieros de software. Sin embargo, puede impulsar la evolución de una contraparte menos consensuada, más política y más política.

Si. La mayoría de los trabajos, incluida la programación tal como la conocemos, seguramente desaparecerán en un par de décadas, si no antes

El primer desarrollo de software de arrastrar y soltar que hice fue en 1991, cuando me presentaron la GUI de Visual Basic inventada por el visionario de interfaz de software y usabilidad Alan Cooper. También me gustaría señalar que todavía estoy trabajando como desarrollador de software itinerante y programador políglota y mi amigo Alan Cooper dirige una empresa de diseño y estrategia de experiencia de usuario tremendamente exitosa en San Francisco.

No estoy demasiado preocupado por el impacto de arrastrar y soltar ya que ha estado con nosotros durante más de 20 años. Lo que probablemente nos dejará a todos sin trabajo es un código inteligente generado automáticamente. Seguramente eso sucederá dentro de una década o como máximo dos. Uno de los grandes avances recientes que vuela principalmente por debajo del radar son productos revolucionarios en la nube como CodeShip que permiten a los desarrolladores sin experiencia activar un entorno de desarrollo de CI / CD completamente funcional en 5 minutos (esto solía llevar semanas de tiempo de desarrollo alfa).

Soy una de las pocas barbas grises que todavía está programando. Espero poder seguir siendo empleada durante otros 15 años antes de caer muerto (ya que pocos de nosotros tendremos los medios para retirarme). Si eres joven, sigo afirmando que la programación es una buena apuesta en comparación con otras carreras que desaparecen. Me estremezco al pensar qué harán los vehículos sin conductor a cientos de miles de conductores profesionales.

Para crear un entorno de desarrollo de software de arrastrar y soltar, se requieren muchos ingenieros de software muy buenos. Viva y prospere Ingenieros de software.

Sin embargo, creo que los ingenieros de software no deberían perder el tiempo reescribiendo código una y otra vez, cada vez que escriben una nueva solución de software. En la mayoría de las soluciones de software, hay una gran cantidad de funcionalidades que se usan comúnmente en muchos programas y terminamos codificando esto una y otra vez cada vez que creamos una nueva solución. Entonces, hace unos tres años, decidimos que era hora de hacer algo al respecto, no con la intención de eliminar el desarrollo de software, sino concentrarlo donde realmente se necesita. Comenzamos a repensar cómo se desarrollan las soluciones, desde el momento en que se conceptualizan, generalmente no por un ingeniero de software, sino por una necesidad comercial o social, descrita en lenguaje “humano”, hasta el momento en que se implementan y codifican. Así que nos embarcamos en esta misión “interminable”. Nosotros (Gumbuya | Platform for Building Modern Business Applications) creamos una plataforma para crear aplicaciones en un gráfico semántico, desde los datos en sí hasta los componentes que componen la aplicación. Incluso nuestras herramientas para construir la arquitectura de la información y las aplicaciones están en el gráfico. Como una impresora 3D que “imprime” otras impresoras 3D. La programación se convierte más en una tarea de ensamblaje, arrastrando y soltando “Componentes” que realizan operaciones en el gráfico. Estos componentes, pueden recibir información del gráfico (nodos), realizar una interacción con el usuario, realizar algunas operaciones en el gráfico y pueden llamar a otras aplicaciones para que pasen información del gráfico (nodos) hacia adelante. Estos componentes están escritos por ingenieros de software (usted), pero toda la “fontanería”, acceso a datos, infraestructura, etc. es manejada por la plataforma. La plataforma proporciona un conjunto de componentes que uno puede usar (arrastrar y soltar) o puede escribir sus propios componentes personalizados y arrastrarlos y soltarlos en la aplicación. Ahora estamos llevando esto gradualmente al mercado mientras desarrollamos nuevas capacidades cada semana. Hay mucho que hacer, pero tiempos muy emocionantes.

Pregunta interesante, pero que puede confundir el resultado final.

El “un día” donde uno puede crear visualmente aplicaciones (reales, sofisticadas, ricas, complejas, significativas, etc.) ya está aquí. Muchos desarrolladores ya tienen éxito con este enfoque.

El ingeniero de software está muerto, ¡viva el ingeniero de software! (una referencia a El rey está muerto, ¡viva el rey!). La persona responsable de crear estas increíbles piezas de software simplemente se está transformando … como siempre. Al igual que hay muy pocas personas que todavía usan código de máquina, el rol evoluciona.

Uno todavía tiene que tener la capacidad de pensar mediante programación y descomponer un problema en sus partes. Hoy, la mayoría de estas personas también saben cómo “codificar” tradicionalmente (trabajar en un editor de texto y hacer que la verdadera magia suceda).

El andamiaje en los lenguajes tradicionales, la introducción de nuevos lenguajes o marcos en los existentes, la programación visual o lo que viene después, es solo parte de la evolución y no son mutuamente excluyentes. La programación visual significa que le permite agregar algo de Java si necesita expresividad adicional al igual que C le permite agregar algo de ensamblaje si lo necesita.

Mi descargo de responsabilidad es que actualmente trabajo para OutSystems, un proveedor que ha estado en entrega rápida de aplicaciones durante más de una década. No dejes que ese hecho manche la respuesta, trabajamos donde trabajamos porque creemos …

Siempre habrá requisitos especiales que requieren más que simplemente juntar el software con el mouse.
También hoy en día es posible juntar aplicaciones simples sin o casi sin codificación. Sin embargo, cuando se trata de aplicaciones más complejas, agregar nuevas funcionalidades o mantener proyectos heredados, debe escribir código real.
Cada vez más tareas se automatizan. Puede juntar jerarquías de UI completas sin escribir una sola línea de código. Pero a menos que solo necesite realizar operaciones básicas con sus datos, tendrá que escribir la lógica del controlador, los validadores y convertidores de datos, etc.
Y este es solo un ejemplo muy simple.

Creo que habrá situaciones en las que bastará con juntar la interfaz de usuario y la lógica. Pero con un poco más de complejidad o personalización surge la necesidad de escribir código.

O en otras palabras: teóricamente podríamos arrastrar y soltar palabras aleatorias para escribir una novela. Pero nadie hace esto, y por alguna razón. 🙂

Como han dicho otros, las herramientas existentes de este tipo son decepcionantes.

Pero, ¿y si pudieras construir sobre eso no es decepcionante?

Entonces sería tan difícil hacer un programa realmente bueno como las herramientas existentes, con quizás una interfaz un poco más fácil.

Fundamentalmente, nuestra comprensión actual de la programación implica que las personas especifiquen completamente los programas para la computadora de alguna manera. Hemos encontrado muchas maneras de hacer esto más fácil: lenguajes de alto nivel, amplias bibliotecas integradas, recolección de basura. No hay duda de que habrá mejoras similares.

Pero el paradigma de “programación visual, arrastrar y soltar” solo puede solucionar problemas muy simples: no a todos les gustan los IDE, no a todos les gusta el texto. Un entorno muy bueno de ese tipo * podría * solucionar ese problema, aunque cada intento existente falla miserablemente.

Pero luego te quedas con todos los problemas existentes. Y son bastante difíciles. Esencialmente terminas con un nuevo lenguaje de alto nivel y / o un nuevo IDE para él. Eso sería bueno, pero no cambiaría el mundo.

No. Incluso puedes aprender un lenguaje como C ++ (muchos piensan que este es uno de los lenguajes ‘difíciles’) en unas pocas semanas.
Pero aprender a resolver problemas complejos de una buena manera (rendimiento, facilidad de mantenimiento, confiabilidad, selección adecuada y uso de bibliotecas, etc.) lleva muchos años.
Aún más difíciles son los aspectos ‘no técnicos’ como comprender realmente y completamente los problemas que va a resolver con su código. A veces es difícil comprender por qué no puede resolver un problema perfectamente, aceptar este hecho y hacer el compromiso correcto. Quizás la vida es muy corta.

Para resumir, un lenguaje de programación “apunte y haga clic” le ahorrará las primeras semanas de su carrera como programador. Alguien que no sea programador podrá resolver problemas “simples” rápidamente. Pero alguien que quiera resolver problemas complejos necesitará todo el aprendizaje de todos modos. Tal vez él o ella cambie a un idioma “tradicional” algún día, solo porque, después de practicar, escribir es más rápido que hacer clic.

cristiano

En los años 90, Visual Basic era popular por su capacidad de permitir que los no programadores “escriban programas”. En lugar de escribir 80 líneas de código C para obtener una aplicación básica de Windows en la pantalla, podría iniciar VB, presionar F5 y obtener lo mismo. Entonces, en cierto sentido, pude “escribir” una aplicación básica de Windows usando solo un dedo (o incluso algún otro apéndice menos ágil si me inclinaba a presumir).

Todo en VB era arrastrar y soltar; Puede extraer un control de la paleta a una ventana, arrastrarlo para ajustarlo al tamaño que desee, establecer algunas propiedades en el control, presionar F5 y ejecutar un programa con funcionalidad de hoja de cálculo.

El problema con esta demostración (ciertamente impresionante) de lo fácil que es construir un programa en ejecución sin esfuerzo ni habilidad, es básicamente donde termina. Todavía hay cierta habilidad involucrada en la escritura de software que hace algo más allá de lo básico, y lo hace de manera confiable. Incluso en un entorno como este, debe comprender los tiempos de vida de los componentes, el uso de la memoria, por qué ciertas cosas funcionan mejor que otras, etc. Un no programador puede aprender estas cosas con el tiempo, pero cuando lo hacen, son efectivamente programadores de algún tipo.

Antes de ese momento (y desde entonces), escuché que algún día, la programación será un asunto de arrastrar y soltar, y ya nadie necesitará desarrolladores de software. Ya nadie está haciendo C, nadie está haciendo Java, se trata de arrastrar y soltar y de los empresarios. En verdad, ahora estoy haciendo más C / C ++ que hace 10 años, y las IU que construyo no están hechas con un entorno de arrastrar y soltar.

En realidad, hay muchas herramientas útiles que permiten a los desarrolladores diseñar gráficamente procesos.

Hasta cierto punto, eso está bien, excepto que desea hacer algo bastante complejo en dicho entorno.

O terminas con algo que es bastante incapaz de manejar o cambiar más tarde, o la herramienta viene con una característica de refactorización agradable y útil que te ayuda a despejar el desorden.

Usualmente, este es el punto donde la programación debería haber entrado, ya que la sobrecarga gráfica y general para implementar algo que es relativamente fácil de hacer, que el conjunto de herramientas / lenguaje adecuado, podría funcionar en un entorno gráfico puro que generalmente genera código, pero es simplemente “incorrecto” desde el punto de vista de la eficiencia.

Lo bueno, siempre y cuando no salgas del área sana, es que literalmente puedes ver lo que está sucediendo.

No creo que esto permita a todos, ni siquiera a casi todos, programar de esta manera, ya que aún necesita una mente analítica y debe transportar el problema por abstracción al conjunto de herramientas. Cuando puede hacer esto, generalmente es un programador o un mejor ingeniero de software.

Me gustan los beneficios de las interfaces gráficas mejoradas como, por ejemplo, en los diferentes conjuntos de talentos, pero hasta ese cierto punto en el que debería usar mejor los módulos programados en un lenguaje apropiado y organizarlos mediante una herramienta gráfica.

Sin embargo, las herramientas de programación de clic-clic podrían facilitar la entrada en el área de programación a personas que se habrían irritado por estas líneas de código sin sentido en primer lugar.

¿No es eso para lo que sirve el desbordamiento de pila?

En serio, arrastrar y soltar es solo una interfaz: hará que las cosas sean más accesibles pero no menos desafiantes. ¿Es la capacidad de hacer que la próxima Mona Lisa sea más fácil gracias al photoshop? Sigo pensando que necesitas un conocimiento profundo de la historia del arte y muchos otros requisitos que el hecho de poseer Photoshop no alivia.