Desde los albores de la informática, ha sido necesario algún nexo de comunicación entre las máquinas y los humanos. En un principio se codificaban instrucciones lógicas, matemáticas, asignación, flujo... asociadas a códigos binarios. Para hacerlo un poco más legible, aparecieron los mnemotécnicos del ensamblador o código máquina. Más tarde, la productividad exigía lenguajes más sencillos para ganar rapidez, eficacia y reducir la cantidad de errores. Aparecieron el Fortran, el Cobol, el RPG, el ADA, el LISP, el Basic, el Logo, el Pascal, el C, el C++, el Java, el .NET, el Python, el Ruby, etc.
Hoy día tenemos una riqueza enorme de lenguajes de programación (ver lista de lenguajes de programación en http://people.ku.edu/~nkinners/LangList/Extras/langlist.htm). Algunos lenguajes se han inventado para tratar algunas tareas específicas. Otros lenguajes, sin embargo, son utilizados para propósitos generales. Algunos lenguajes son de muy bajo nivel, con lo que su rendimiento es altísimo. Otros lenguajes son de muy alto nivel, ganando así en productividad y en reducción de errores. Algunos lenguajes son muy sencillos de aprender y de utilizar, mientras que otros son místicos o esotéricos, reservados sólo para los elegidos que se adentran en sus arcanos conocimientos (consultar http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_esot%C3%A9rico. Hay lenguajes compilados, semicompilados, interpretados o de script. Hay lenguajes textuales y lenguajes gráficos. Hay lenguajes que comprenden uno o varios paradigmas, como el imperativo, el declarativo, el estructurado, el orientado a objetos, el funcional, el lógico, etc.
A lo largo de la historia de la programación ha habido una evolución constante, tanto de los lenguajes como del entorno del negocio de la programación. En su día, un programador era una eminencia por la que se pagaba un sueldo envidiable. Hoy día, la programación está al alcance de cualquiera, y los sueldos han bajado hasta igualarse a los de otros oficios. Hoy se valora más la gestión de equipos de programadores y la optimización de la productividad, que los conocimientos individuales de un programador.
Antiguamente se elaboraban más algoritmos, por lo que era habitual repetir el código de ciertas funcionalidades (ordenación, índices, accesos a discos, etc.), especialmente porque el código no se compartía y había mucha patente. Hoy en día hay librerías para todo, y frameworks avanzados que facilitan mucho la labor de la programación, haciéndola más productiva y estandarizada.
Un paso importante fue incluir rutinas de bajo nivel en un chip, como la ROM, la cual era (y sigue siendo) accesible por cualquier programa (especialmente por uno que acceda a bajo nivel, como C/C++). A esto le siguió incluir también rutinas estándar en el sistema operativo (nuestro adorado DOS ya las incluía). Hoy día, casi cualquier dispositivo tiene una librería de bajo nivel con los servicios estándar para su gestión. Desde hace algún tiempo también se está experimentando incluir un sistema operativo en un chip (éste era uno de los proyectos de Linus Torvalds), o incluso complejos programas completos. Tener software implementado a nivel de chip incrementaría enormemente la velocidad, aunque los chips deberían ser de acceso aleatorio y sobreescribibles, con el fin de poder actualizar bugs, firmwares, funcionalidades, etc. Asimismo, los chips deberían ser también estándares, con el fin de poder integrarlos en otros dispositivos o máquinas con sólo conectarlos.
El contenido y el contenedor de los programas también ha cambiado, aunque la esencia es la misma. Antiguamente se codificaba el código (en lenguaje máquina) en tarjetas perforadas, las cuales eran leídas y pasadas a la memoria del ordenador, que procesaba el programa. Más adelante, los lenguajes de programación se compilaban (traducían y guardaban) a código (de la propia máquina o de la propia plataforma), y las tarjetas perforadas se sustituyeron por soportes de almacenamiento magnético (y/u óptico). Los lenguajes actuales permiten crear programas independientes de la plataforma, gracias a que están en crudo y son interpretados por un intérprete (como JavaScript), o bien están semicompilados a nivel de bytecode (como Java o .NET). En ambos casos no es la máquina o el sistema operativo el que ejecuta el programa, si no otro programa (intérprete o máquina virtual). Otro punto en que se ha evolucionado el contenido y el contenedor, es que los programas solían estar en la misma máquina, y ahora ese no es un requisito indispensable, pues se pueden ejecutar servicios de programas en remoto. Con la programación en nube, los programas se sirven como un servicio, y no es necesario hacer instalaciones ni tener sistemas de almacenamiento, si no tan sólo una conexión a internet y un navegador.
Otro punto especialmente relevante ha sido la filosofía del software libre (y por ende, todo lo relacionado, como el código abierto y todo tipo de licencias no propietarias), que ha supuesto la liberación de la programación como un fenómeno profesional, cultural y social. Esto permite ya no sólo tener las libertades, si no también la igualdad para todos de poder crear productos y tener las mismas oportunidades para compartirlo, promocionarlo y explotarlo.
¿Y cuál será el futuro de los lenguajes de programación? ¿Qué más pueden evolucionar? ¿Qué más pueden aportar a nuestra sociedad de la información?
La tecnología sigue avanzando y evolucionando. Esto genera nuevas necesidades y problemas que marcarán el qué y el cómo, así como también las tendencias en los lenguajes de programación, los cuales seguirán estando con nosotros, ya que necesitamos máquinas, y las máquinas nos necesitan a nosotros, y para que ambos nos entendamos es necesario un lenguaje.
Recuerdo cuando programaba en Clipper que mi jefe me decía que los programadores iban a desaparecer, ya que apareció la primera versión de Visual Basic, y todo se hacía automáticamente con tan sólo el ratón. Pero nada más lejos de la verdad, pues ello generó muchas más necesidades, problemas y soluciones de lo que antes habíamos imaginado. Y bajo ese prisma, creo que todo avance ampliará mucho más los horizontes que ya tenemos.
Lo mismo que ocurre con los idiomas humanos, los lenguajes de programación minoritarios se extinguirán poco a poco incrementando el uso de los más consagrados, debido a la carencia de su necesidad en la industria (otra cosa que sean objeto de estudio, como el latín o el griego). Los lenguajes de alto nivel ganarán cada vez más cotas de uso, y seguirán necesitando de lenguajes de bajo nivel para equilibrar sencillez frente rendimiento y velocidad. Se abstraerá aún más la semántica del lenguaje a fin de realizar muchas más cosas con menos, con la posibilidad de entrar en detalles. Habrá lenguajes de programación en nube, como servicio, así como también infraestructuras de desarrollo y despliegue en nube. Si bien las aplicaciones Web y en nube van a ver aumentada su cuota, las aplicaciones de escritorio seguirán presentes para ciertas necesidades, y especialmente por privacidad, por gustos, para problemas específicos (especialmente ligados al hardware donde corren), etc. Las RIA's serán un referente muy importante, pues los usuarios agradecerán aplicaciones intuitivas y productivas, capaces de hacer mucho con pocas acciones, fáciles de utilizar, potentes en el tratamiento de los datos y su presentación, y en la productividad que generan, además del tiempo que se gana. No olvidemos también la capacidad multiplataforma: se hará indispensable que el código de un lenguaje de programación se pueda ejecutar en cualquier sistema operativo. El escritorio y el navegador terminarán fusionándose e integrándose como uno sólo, y sus aplicaciones tendrán lo mejor de los dos mundos.
Otra baza decisiva para el éxito de un lenguaje de programación es su apertura y la libertad de uso, sin limitaciones. Poder desarrollar aplicaciones con total libertad, sin limitaciones por licencia o imposiciones, será (y es) un factor decisivo, por costes, por libertades, por promoción de herramientas y aplicaciones igualmente libres, por cultura, por igualdad y por derecho. Una empresa con intereses comerciales y monopolistas, detrás de un lenguaje de programación (o cualquier producto software), aún a pesar de sus largos tentáculos y negocios, verá cómo los programadores que no estén bajo su nómina le darán la espalda, y cómo los clientes adoptarán cada vez más soluciones libres.
La computación en nube tendrá éxito, aunque no creo que tan rápido ni en toda su extensión. Habrá ciertos servicios o aplicaciones en los que el cliente manda por encima de toda la potencia tecnológica, todas las funcionalidades y las capacidades que pueda ofrecer la nube. La privacidad será decisiva, así como tener el control de los datos y de los dispositivos de almacenamiento, amén del coste del servicio versus software tradicional.
Habrá frameworks más sofisticados capaces de desarrollar y desplegar aplicaciones con unos pocos parámetros. Actualmente podemos verlo en Ruby on Rails o en Django, pero esto sólo es el principio. Habrá interfaces (de código y de usuario) que ayuden a los frameworks en estas tareas, y después para ajustes toquemos el mínimo código que sea necesario. Y no sólo para la Web. También veremos frameworks en nube, capaces de integrarse con nuestras aplicaciones locales, remotas o en nube.
También aparecerán entornos de desarrollo (IDE) online o en nube. Serán capaces de generar aplicaciones multipropósito: escritorio, web, nube, para dispositivos móviles, para ordenadores, etc. También permitirán agregar componentes online o en nube. ¿Imagináis crear un programa sin instalar nada en el ordenador, y que las aplicaciones desarrolladas sean accesibles desde cualquier ordenador o dispositivo sin necesidad de compilarlas, ni instalarlas, ni parametrizarlas... todo de forma transparente y natural? ¿Imagináis realizar aplicaciones sin centrase tanto en lo interno, si no más bien en lo externo, como obtener información de un servicio web o de otro programa en nube (en lugar de currarte tú mismo tu sistema de base de datos y mantenerlo)?
Quizá aparezca un nuevo paradigma de programación, basado precisamente en los recursos y servicios en red, o quizá en requisitos y resultados. Quizá aparezcan también lenguajes capaces de autoaprender según la experiencia de los programadores, o analizando los problemas de los aplicativos. O entornos de desarrollo que automáticamente ponderen la forma más eficiente de desarrollar una aplicación, eliminando u optimizando el código, y corrigiendo automáticamente todo tipo de errores. Quizá los lenguajes de programación atiendan las funcionalidades como parámetros de entrada y desarrollen automáticamente el diseño y el código libre de errores más cercano posible (paradigma basado en requisitos y resultados). Quizá los lenguajes de programación aseguren la calidad de las aplicaciones en un porcentaje cercano al 100%, minimizando el tiempo de pruebas y ahorrando tiempos de desarrollo. Quizá la semántica de las aplicaciones y de la Web condicionen también que los lenguajes de programación sean más semánticos o contemplen la semántica.
La evolución de los lenguajes de programación conllevará también una evolución en las metodologías de trabajo, en marcos o en sistemas de trabajo. El dinamismo de la tecnología y de los productos reclaman agilidad, aunque los clientes demandan metodologías predictivas para un mayor control y como arma legal. Las metodologías predictivas y la agilidad son filosofías antónimas, aunque también poseen puntos en los que se puede extraer lo más importante y positivo de cada una, ver dónde se aplican, integran y formen sinergias fortalecidas. Los clientes, las empresas de servicios, consultoras, etc., deben tener la misma visión y entenderla para no cometer los mismos errores una y otra vez. Esta dependencia condicionará también la evolución de la tecnología, de los lenguajes de programación y de los productos y servicios. Posiblemente dejemos de ver los proyectos como lo vemos actualmente, con un tiempo, un coste, una tecnología y un sistema predeterminado desde el principio. Quizá veamos los proyectos como servicios de desarrollo incrementales y dinámicos, con contratos por objetivos, sin dependencias ni fricciones entre cliente y proveedor.
A lo largo de estas reflexiones he ido anotando puntos que ya he empezado a ver, y algunas ideas que se me han ocurrido. No pretendo afirmar nada, pues el futuro llega antes de lo que uno se piensa, y de distinta manera a como uno lo ha imaginado. Ideas se tienen, y no todos por igual. Hay ideas que prosperan y otras que fenecen, al igual que las semillas. Todo depende del escenario y de las circunstancias.
Mostrando entradas con la etiqueta Reflexión. Mostrar todas las entradas
Mostrando entradas con la etiqueta Reflexión. Mostrar todas las entradas
lunes, 11 de octubre de 2010
martes, 28 de septiembre de 2010
Agnitio3: Paradigma del conocimiento basado en cubos
Introducción
El presente documento es un ensayo sobre un paradigma de conocimiento, una reflexión sobre cómo organizar la información de una forma eficiente, y sobre la cual se pueden generar consultas complejas y obtener la información en diferentes vistas.
La base es un cubo de conocimiento, el cual eleva las posibilidades que actualmente tenemos limitadas con el paradigma del 2D, en base a tablas, o matrices de columnas y filas, paradigma que se puede complementar con este paradigma 3D.
Esta paradigma organiza eficientemente la información sobre un esquema muy organizado y dimensional, aunque complejo a medida que se añaden nuevos conceptos (ver Concepto avanzados), y que pueden tratarse mediante un software especializado.
Agnitio3 es el nombre con el que he bautizado este paradigma, el cual, de base, no es nuevo, pero al que he añadido conceptos nuevos y avanzados. Agnitio es la traducción al latín de Conocimiento. El número 3 representa el cubo en matemáticas. Agnitio3 = Conocimiento al cubo.
El presente documento no está cerrado, y puede sufrir modificaciones constantes, a fin de corregir erratas o añadir nuevos conceptos e ideas.
Versiones
28/09/2010. Por Rafael Hernampérez Martín. Primera versión.
Conceptos básicos
3DtiCube es un sistema de organización de la información basada en cubos de conocimiento, con gran capacidad de configuración, personalización, versatilidad, potencia de consulta y generación de informes y gráficas.
Un cubo de conocimiento tiene tres ejes o dimensiones, cada uno de los cuales está fragmentado en coordenadas o elementos. Cada elemento se relaciona con otros elementos de otras dimensiones, y la confluencia de tres elementos diferentes de cada una de las dimensiones, dará como resultado un punto común, al que llamaremos nexo o conocimiento, pues contiene un valor compartido y común a los tres elementos.
Imaginemos un cuadro de mando básico que mide el nivel de cada servicio de una compañía, comparando cada servicio en cada producto. Este cuadro de mando se realiza cada semana, y sobre el mismo se realiza un seguimiento puntual. Aquí se identifican las 3 dimensiones necesarias para un cubo de conocimiento:
Servicio:
Servicio 1
…
Servicio n
Producto:
Producto 1
…
Producto n
Período:
Semana 1
…
Semana n
El conocimiento se obtendría de la confluencia de tres elementos, cada uno de los cuales en cada una de las dimensiones. Por ejemplo, el nivel del servicio de atención al cliente, del producto “Ordenador portátil XYZ”, en la semana 5.
Organizar la información en tres dimensiones nos permite girar el cubo y extraer la información en varias vistas 2D a partir de un determinado elemento de una de las dimensiones:
Vista 1
Servicio “XXX” (Se extrae sobre un único Servicio)
Semana 1 | ... | Semana n | |
Producto 1 | 99.99 | 99.99 | 99.99 |
... | 99.99 | 99.99 | 99.99 |
Producto n | 99.99 | 99.99 | 99.99 |
Vista 2
Servicio “XXX” (Se extrae sobre un único Servicio)
Producto 1 | ... | Producto n | |
Semana 1 | 99.99 | 99.99 | 99.99 |
... | 99.99 | 99.99 | 99.99 |
Semana n | 99.99 | 99.99 | 99.99 |
Vista 3
Producto “XXX” (Se extrae sobre un único producto)
Servicio 1 | ... | Servicio n | |
Semana 1 | 99.99 | 99.99 | 99.99 |
... | 99.99 | 99.99 | 99.99 |
Semana n | 99.99 | 99.99 | 99.99 |
Vista 4
Producto “XXX” (Se extrae sobre un único producto)
Semana 1 | ... | Semana n | |
Servicio 1 | 99.99 | 99.99 | 99.99 |
... | 99.99 | 99.99 | 99.99 |
Servicio n | 99.99 | 99.99 | 99.99 |
Vista 5
Semana n (Se extrae sobre una única semana)
Servicio 1 | ... | Servicio n | |
Producto 1 | 99.99 | 99.99 | 99.99 |
... | 99.99 | 99.99 | 99.99 |
Producto n | 99.99 | 99.99 | 99.99 |
Vista 6
Semana n (Se extrae sobre una única semana)
Producto 1 | ... | Producto n | |
Servicio 1 | 99.99 | 99.99 | 99.99 |
... | 99.99 | 99.99 | 99.99 |
Servicio n | 99.99 | 99.99 | 99.99 |
Estos conceptos básicos abarcan conocimientos singulares, es decir, un valor único en cada nexo.
Conceptos avanzados
Sobre este paradigma de organización informativa, se pueden agregar algunos conceptos avanzados para aumentar sus prestaciones y funcionalidades.
Conocimiento plural
El nexo o conocimiento puede ser plural. Es decir, puede contener tantos valores como se desee y del tipo que se desee, y no solamente uno. Este concepto nos aporta más riqueza de conocimiento (una dimensión para conocimiento), y puede servir para agregar un pequeño repositorio o base de datos en nuestro cubo. En el ejemplo anterior, nuestro cubo únicamente contemplaba niveles de servicio (generalmente expresado en % de eficiencia). Si se desea, por ejemplo, representar beneficios, pérdidas, % de penalización por incidencias, etc.), con el paradigma del cubo básico sería necesario un cubo por cada tipo de dato, aunque utilicen las mismas dimensiones. Sin embargo, con el conocimiento en plural, utilizaríamos un único cubo para almacenar en el mismo nexo todos estos valores, y extraer diferentes vistas, o extraer los diferentes valores en la misma consulta.
Los valores se podrían almacenar en formato documento, libre de esquema, con claves y valores, pudiendo almacenar también arrays de valores y documentos anidados:
{
“clave1”: valor1,
“clave2”: “valor2,
“clave3”: datetime(2010,09,28,13,03),
“clave4”: [valor1, valor2, valor3],
“clave5”: { ... }
}
Una aplicación práctica sería, por ejemplo, crear un cubo cuyas dimensiones fueran las áreas de la empresa (sistemas, seguridad, CPD, Desarrollo, calidad, etc.), un tipo de conocimiento (Java, .NET, Linux, etc.) y un nivel o uso del conocimiento (principiante, experto, usuario, etc.). El nexo podría contener manuales, tutoriales, documentos, enlaces a foros, enlaces a herramientas productivas (gestores de proyectos, agendas, incidencias...), etc.
Agrupación de elementos
Un cubo puede crecer y hacerse complejo, por lo que es preferible clasificar los elementos de una dimensión en categorías. Por ejemplo, el catálogo de productos puede llegar a ser muy extenso, así como también la dimensión de las semanas. Clasificar los productos por gama (ordenadores de sobremesa, ordenadores portátiles, accesorios informáticos, etc.), y las semanas por trimestres aporta claridad y gana en eficiencia y en productividad. Esta clasificación permitiría la agrupación de la información, permitiendo contraer o expandir los elementos agrupados, así como también realizar cálculos (en caso de valores numéricos) de dicha agrupación: sumatorio, media aritmética, valor mínimo, valor máximo, conteo, etc.
Sería muy interesante que el cubo calculase automáticamente el total de ventas de un determinado producto durante el primer trimestre de 2010. O bien que calculase la media del nivel de servicio de soporte de toda la gama de ordenadores de sobremesa durante la semana 5. Se podrían combinar agrupaciones en todas las dimensiones del cubo.
Referenciación de cubos
Funcionalmente podrían definirse infinitos niveles o jerarquías de agrupación, pero sería mucho más claro no excederse de dos o tres niveles. Si se requiriese de más detalle, podría ser más conveniente replicar un cubo categorizado en un nuevo cubo, dejando en una dimensión sencilla la agrupación de alto nivel, y empezar a categorizar en bajo nivel. Esta réplica sería una referencia al cubo original. Los cambios que surgieran en el cubo original, se trasladarían automáticamente al cubo que toma la referencia.
Podemos crear un nuevo cubo referenciado del cubo anterior agrupado. Sobre este cubo, podríamos ahora categorizar las gamas de productos por líneas de productos (por ejemplo: ordenadores agruparía ordenadores de sobremesa, portátiles, Tablets, Netbooks, etc...), y los períodos podrían ahora categorizarse por años.
Referencias entre elementos de distintos cubos
Pueden definirse elementos referenciando a otros elementos en otras dimensiones y en otros cubos, e incluso referenciar a un elemento agrupado. Pueden crearse cubos mixtos, con dimensiones que contengan elementos propios y elementos referenciados a otros elementos de diferentes cubos. Las referencias son efectivas en cubos cuyos elementos y dimensiones coinciden, pues los conocimientos tienen esta dependencia (recordemos que un conocimiento o nexo es la confluencia de tres elementos, uno por cada dimensión).
Conocimiento elevado al cubo de...
En entidades demasiado complejas, en lugar de conocimientos singulares o plurales, puede ser interesante utilizar como conocimiento un cubo de conocimiento, creando un anidamiento y exponenciando las posibilidades de información. El primer cubo sería un cubo genérico, y sus nexos contendrían los cubos del conocimiento, que pueden ser distintos entre los diferentes nexos del cubo genérico o principal.
El nivel de anidamiento podría ser infinito, aunque lo recomendable sería simplificar.
Conocimiento mixto
El conocimiento podría tratar un cubo de conocimiento como un tipo de dato más. De esta manera, un conocimiento podría contener un documento clave-valor, con diferentes valores estándar, y también podría incluir uno o varios cubos de conocimiento.
jueves, 22 de abril de 2010
¿Van mal los derechos de autor?
Interesante vídeo que hace una reflexión a los derechos de autor y a la caza de brujas orientada a los consumidores de cultura. En EEUU tienen el mismo problema, y el enfoque sobre el mismo es muy esclarecedor. Los derechos de autor, tal y como están concebidos, son obsoletos y se resisten perecer ante la evolución y la tecnología. Éstos y las acciones contra los ciudadanos no son éticas, ni legales ni democráticas.
Suscribirse a:
Entradas (Atom)