¿Puede un sistema ser 100% basado en datos?

Mi nuevo jefe ha estado trabajando en este proyecto durante muchos años. Solo llevo aquí unas pocas semanas, pero no estoy seguro de que sea posible. Le gustaría diseñar un sistema que esté "100% basado en datos".

Entonces, si ponemos suficientes datos, podemos definir y generar cualquier aplicación. Al menos he logrado que reconozca algunas cosas, como los usuarios, o las aplicaciones deben tener valores predefinidos, pero a él le gusta el concepto de la estructura del sistema, la interfaz de usuario y la lógica que se almacenan como datos.

Hay algunas demostraciones de cosas simples y básicamente ha redescubierto algunas ideas simples de programación orientada a objetos y sus sistemas básicos de plantillas, pero creo que, en general, este objetivo podría ser realmente imposible.

No sé cómo puede definir la lógica utilizando datos sin que el sistema se vuelva tan complejo que de todos modos esté haciendo una programación real.

Creo que, en teoría, no es porque lo que interpreta los datos termina necesitando ser completamente completo para describir la aplicación, por lo que acaba de cambiar el problema un nivel más alto o ningún beneficio neto.

¿Es posible una aplicación basada en datos al 100%?

Su jefe debería leer esta pieza: Bad Carma: el proyecto "Visión", una historia de advertencia sobre el efecto de plataforma interna o el efecto del segundo sistema.

Resumen

Aquellos de nosotros que trabajamos en Tecnología de la Información (TI) hemos estado en un proyecto donde algo importante simplemente no está bien. Lo sabemos, la mayoría lo sabe, pero nadie es capaz de señalar el problema de manera convincente.

Esta historia es sobre un proyecto de TI, el fracaso más espectacular que he experimentado. Resultó en el despido completo de un departamento de TI de tamaño mediano, y finalmente condujo a la destrucción de una empresa en crecimiento en una industria en crecimiento. La compañía, que llamaremos "Upstart", era un negocio de televisión de suscripción exitoso y rentable.

El proyecto se produjo a principios de la década de 1990, y era una aplicación personalizada de entrada de pedidos y servicio al cliente, que se parecía mucho a lo que ahora se conoce como Gestión de Relaciones con el Cliente o CRM. La funcionalidad principal del sistema incluye:

• Entrada de pedidos e inventario
• Servicio al cliente, mesa de ayuda
• Libro mayor, cuentas por cobrar, facturación y cuentas por pagar

La aplicación se llamaba "Visión" y el nombre era tanto su promesa oficialmente declarada para Upstart como un guiño de autograndecimiento a su arquitecto. La aplicación fue innovadora, ya que fue construida para ser lo suficientemente flexible como para acomodar cualquier cambio futuro en el negocio. No solo cualquier cambio futuro previsible en el negocio, sino absolutamente cualquier cambio en el negocio, en cualquier forma. Fue un reclamo bastante notable, pero Vision estaba destinado a ser la última aplicación que se haya creado. Logró esta absoluta flexibilidad al estar completamente basado en datos, proporcionando abstracción ilimitada y utilizando técnicas de programación orientadas a objetos que eran de vanguardia en ese momento.

Al igual que muchos de esos proyectos que se propusieron crear una aplicación de misión crítica, el esfuerzo de desarrollo abarcó dos años, aproximadamente un año más de lo previsto originalmente. Pero eso era aceptable, porque esta era la aplicación que duraría para siempre, adaptándose a cualquier requisito futuro, proporcionando un retorno de la inversión (ROI) ilimitado. Cuando la aplicación finalmente se puso en funcionamiento, casi todos en la compañía habían invertido tanto en ella que, literalmente, el destino de la compañía dependía de su éxito.

Sin embargo, en el caso de un mal funcionamiento total del proyecto, las aplicaciones de misión crítica que ejecutan el negocio principal de las corporaciones multinacionales no pueden permitirse el lujo del tipo de apagón rápido demostrado por miles de empresas "punto-com" en la era de la burbuja de Internet. Un mes después de que Vision se pusiera "en vivo", fue evidente para todos, excepto para aquellos que estaban más interesados ​​en su construcción, que fue un fracaso.

Ver también

http://en.wikipedia.org/wiki/Inner-platform_effect

La respuesta es sí, es posible crear un sistema totalmente basado en datos y sí, generalmente es una muy mala idea.

Un programa totalmente basado en datos es aquel en el que toda la lógica y la configuración se manejan mediante valores almacenados de tal manera que en otro contexto se considerarían como datos. Hubo muchos productos 4GL producidos en la década de 1980 que proporcionaron la capacidad de generar informes, formularios, tablas y lógica utilizando elementos de datos ingresados ​​en una multiplicidad de formularios, almacenados en tablas y accesibles a través de informes. Solía ​​referirme a tales sistemas como "pintar por números", pero veo que ahora se conoce como el efecto del "sistema interno". Buen nombre.

Las personas que crean estos sistemas están intentando (lo sepan o no) crear un nuevo lenguaje de programación. Como no tienen las habilidades, lo hacen mal. Desde el punto de vista de JVM / CLR, un programa compilado Java / C # es simplemente datos. En este caso se ha hecho bien. En cualquier caso, se necesitan programadores para usar el lenguaje, sea lo que sea.

Hay una manera específica de hacer que esto funcione, que yo sepa. Construye el esqueleto de cada uno de los componentes que necesita: formulario, informe, tabla, etc. Proporciona un mecanismo para configurar varias partes de estos componentes mediante la configuración de elementos de datos. Para un conjunto elegido de funciones, usted toma las decisiones y las congela en el sistema, y ​​específicamente niega la capacidad de configurar esas funciones.

También implementa un lenguaje que tiene la capacidad de codificar operaciones lógicas. Mi recomendación es usar un lenguaje existente como lua o quizás Python. Incruste partes de este código donde sea que se necesiten operaciones lógicas.

Al hacer esto, reduce sustancialmente la cantidad de escritura requerida para implementar cada formulario, informe, tabla, etc. El sistema parece estar basado en datos, pero solo hasta cierto punto.

En este punto, acaba de implementar un nuevo 4GL. Si sucede, haga esto con éxito, hágamelo saber. La mayoría de la gente falla tristemente. Seré el primero en felicitarte por tu logro.

Creo que básicamente tienes razón. Un lenguaje en tiempo de ejecución ya es un sistema totalmente flexible basado en datos. Toma una pieza de datos (el programa) y la usa para determinar cómo debe actuar sobre otros datos. Incluso podría tener un esquema multiusuario para almacenar código para que otros programas lo reutilicen (desde una ruta de inclusión hasta una administración de instalación adecuada).

Un "lenguaje de secuencias de comandos", en términos generales, es un tiempo de ejecución del lenguaje en el que esta entrada de código es legible para los humanos. Un compilador coloca un paso adicional entre el usuario y el tiempo de ejecución. No es necesario que los lenguajes de "broma" como Malbolge y APL sean legibles por humanos de ninguna forma. Pero todo es lo mismo en un nivel, y de todos modos legible por humanos no significa que todos los usuarios potenciales tengan las habilidades para leerlo o escribirlo, o se puede esperar que lo desarrollen.

Existen buenas razones por las que normalmente no expone un tiempo de ejecución de idioma directamente a los usuarios finales. La principal es que eliminar la flexibilidad aumenta la comodidad.

Si quiero escribir una publicación SO, solo quiero escribirla. Soy perfectamente capaz de escribir un programa C ++ para generarlo, pero no usaría un navegador web que expusiera un editor de programas C ++ en lugar de un cuadro de texto normal. Las personas que no conocen C ++ no solo no usarían el navegador, sino que no podrían.

Si quiero configurar ciertos parámetros comerciales, no necesariamente quiero hacerlo usando un lenguaje de especificación completo de Turing, e incluso si lo hiciera, probablemente no sea distinguible de "codificar" esos mismos parámetros comerciales en ninguna otra programación idioma. Aún debe considerar si lo que está escribiendo significa lo que quiere que signifique. Aún necesita probar que los cambios son correctos. Es decir, que aún necesita conocimientos de programación para la realización de tareas que no son triviales y no previsto por alguien que no tiene conocimientos de programación que han preparado un subsistema especializado ( "aplicación") que se le configure ( "uso").

Entonces, si está a punto de embarcarse en un sistema 100% basado en datos, que puede hacer cualquier cosa con los datos correctos, tiene dos preguntas que hacerse:

1. ¿Estamos en el negocio de inventar lenguajes de programación, o deberíamos estarlo?
2. ¿Será nuestro nuevo lenguaje de programación mejor (para nuestros propósitos) que los que ya tenemos y lo apoyaremos y lo desarrollaremos según sea necesario?

A veces las respuestas son afirmativas y usted escribe un lenguaje específico de dominio de algún tipo. O incluso un lenguaje de programación real de uso general si eres Sun / Microsoft / Stroustrup / van Rossum / muchos otros. A veces las respuestas son no y tienes el efecto de "plataforma interna": después de mucho esfuerzo y prueba y error, terminas con algo. Si tienes suerte, es solo ligeramente inferior al lenguaje de programación en el que lo escribiste, y no es más fácil de usar.

Algunos lenguajes son más difíciles o más fáciles de usar que otros, en particular si están especializados para un propósito como R, entonces algunos usuarios los encontrarán mucho más fáciles. Lo que probablemente no hará es hacer que la programación de aplicaciones generales sea fundamentalmente más fácil. En cualquier momento, probablemente haya varias personas / organizaciones en el mundo con el potencial para hacerlo, pero su jefe / compañía tiene que considerar honestamente si eso lo incluye a usted o no.

Hay un truco que se usa a menudo para los juegos, que es exponer los enlaces de Lua al motor del juego. Esto permite a los diseñadores programar en un lenguaje relativamente fácil, pero aun así contratar a un programador "real" cuando sea necesario para el rendimiento o para acceder a una funcionalidad particular del motor o la plataforma. Las secuencias de comandos Lua resultantes son "datos" en lo que respecta al motor. No todos necesitan incluir gran parte de lo que llamarías "lógica" en lugar de datos de configuración, y a menudo definen casi toda la trama y el entorno, pero no todo el juego. Esto no está 100% basado en datos y ciertamente no está 100% libre de errores, pero es un compromiso práctico interesante.

Trabajé en una empresa donde este era el objetivo. Los fragmentos de SQL se almacenaron en tablas de bases de datos, se leyeron en tiempo de ejecución y se ejecutaron. El rendimiento fue terrible, como puede imaginar, y los errores fueron frecuentes. También era imposible depurar, sin rastros de pila o cualquier otra cosa que facilite la vida.

La "programación basada en datos" resulta de una falta fundamental de comprensión de lo que estamos haciendo, como programadores; cualquier dato que sea capaz de hacer que un algoritmo suceda es en realidad "programación", incluso si de alguna manera has logrado mezclar (¿alterar?) las dos ideas en la interfaz de usuario. Ahora, esto no significa que no se puedan combinar las dos ideas desde la otra dirección, de modo que todo el código son datos; esa es la premisa detrás de lisp, que está habilitada por su homoiconicidad y explotada por su sistema macro. Sí, estos conceptos suenan similares, pero sus implicaciones y aplicaciones son muy diferentes en la práctica.

Además, esto puede estar editorializando, pero los lugares que he encontrado que quieren una programación "completamente basada en datos" realmente no valoran a sus programadores. Piensan en el código como un centro de costos, algo para ser subcontratado o ignorado.

Quieres decir que tu jefe quiere que escribas esto:

[
  {
    "statement": "Assignment ",
    "variable": "App",
    "value": {
      "type": "Function",
      "arguments": [],
      "function-body": [
        {}
      ]
    }
  },
  {
    "statement": "Assignment",
    "variable": "App.prototype.action",
    "value": {
      "type": "Function",
      "arguments": [
        "data"
      ],
      "function-body": [
        {
          "statement": "Call",
          "function-name": "console.log",
          "arguments": [
            "data"
          ]
        }
      ]
    }
  }
]

Para generar esto:

var App = function () {};
App.prototype.action = function ( data ) {
    console.log( data );
}

El primero es JSON y el segundo es JavaScript .

Aclaracion

Creo que, en teoría, no es porque lo que interpreta los datos termina necesitando ser completamente completo para describir la aplicación, por lo que acaba de cambiar el problema un nivel más alto o ningún beneficio neto.

¿Es posible una aplicación basada en datos al 100%?

Aquí es donde acabo de empezar. Con mi respuesta, estoy tratando de estar de acuerdo con la publicación original de que: es posible, pero tienes razón, simplemente cambiará el problema un nivel más alto sin beneficio [obvio] .

Podría argumentar convincentemente, creo, que cualquier aplicación de navegador web podría considerarse 100% basada en datos ¹ .

Por supuesto, eso no facilita o simplifica la creación de aplicaciones en la web, de hecho, las hace mucho más difíciles.

Dígale a su jefe que está reinventando el navegador web, y que eventualmente tendrá que reinventar JavaScript para construir algo razonablemente complejo.

¹ Bueno, si ignoras los complementos, JavaScript y HTML5 .

Si. Hasta donde yo sé, un sistema como Mathematica , que es un lenguaje de programación poderoso pero esencialmente es un shell, se basa en la idea similar que su jefe esperaba. Wolfram Mathematica ahora se está volviendo lo suficientemente complejo como para que muchas tareas computacionales se puedan realizar fácilmente.

Los datos impulsados ​​son un concepto. Si los programadores vamos a manipular los datos de una manera simple, necesitamos un shell que nos resulte fácil de jugar con los datos. Intente comprender que una vez que comenzamos a hablar sobre el aprendizaje de un lenguaje de programación basado en la sintaxis, en realidad estamos aprendiendo la interfaz de la aplicación o simplemente su shell. Si entendemos el shell, podemos manejar los programas.

En cuanto al 100% de datos manejados, si el compilador o el intérprete pueden entender el shell, el cómputo es manejado. Si los datos tienen la misma estructura subyacente que el shell o la interfaz que tiene, los datos también pueden ser manejados por el compilador o el intérprete. Creo que Mathematica es una buena explicación de por qué te respondo con un sí.