Primeros pasos (5). Últimas consideraciones.

Primeros Pasos (5). Últimas consideraciones generales:

Hasta ahora hemos visto de forma general, por que V7 es así de inicio (Primeros pasos 1). Además dadas las características de V7 nos hemos detenido también en como plantear un modelo de solución (Primeros pasos 2) que nos sirva de momento a los iniciados para reutilizar el desarrollo y compartir los proyectos haciendo nuestra solución escalable. Y como no podía ser de otra manera para cerrar las primeras consideraciones, seguimos con los modelos de proyecto de datos (Primeros pasos 3) y proyecto de aplicación (Primeros pasos 4) sobrevolando los objetos que podremos utilizar en cada tipo de proyecto así como su finalidad, dando a priori por concluida una primera etapa y abriendo el camino pues al comienzo de nuestro primer desarrollo.

En teoría hemos prestado atención a todas las cuestiones básicas para dar comienzo al nuestro primer desarrollo, pero para los que no hemos crecido en la cultura Velneo, todavía existe un matiz básico que nos descoloca, “el código”.

Velneo por definición es un producto “abstracto” y esto implica que las estructuras que presenta y los objetos que maneja, realizan por si solos muchas de las necesidades básicas que tenemos a la hora de desarrollar. Cuando un desarrollador quiere profundizar por ejemplo en C++ es necesario que profundice en el conocimiento de la clases, estructuras abstractas que realizan tareas de nivel superior evitando la necesidad de programar el código mediante estructuras de control básicas. Todo parece pues, estar perfectamente alineado en la filosofía Velneo.

Pero la principal diferencia cualitativa con Velneo, es que C++ es un lenguaje multiparadigma, es decir además de las facilidades de la programación genérica, contiene las propiedades de la programación estructurada y la programación orientada a objetos (para mas información ver enlaces).

V7 parece un lenguaje orientado a objetos (hasta ahora no hemos hecho otra cosa que ver objetos), además parece un lenguaje de programación estructurada, pero lo que no es sin duda, lenguaje de programación genérica. No existen formalmente las definiciones de algoritmos de la programación genérica ni sus partículas y estructuras de control básicas (auténticos átomos con los que se construye el universo), no existe “el código” (las moléculas con las que se construye la vida) que es el último enlace entre el hombre y la máquina antes de que se produzca la magia en tiempo de ejecución (las leyes de la física).

En su lugar solo tenemos objetos que emulan la programación genérica, estos objetos no son otros que Proceso, Función, y Evento,  contenedores de comandos de instrucción (que llaman a las clases nativas de las librerías QT y C++) y que sustituyen la necesidad básica de todo desarrollador de controlar y decidir todo lo que acontece a nivel primario, y es aquí donde está la emulación “del código” en v7, lo más parecido a una hoja en blanco, que es donde mayor capacidad de imaginar tenemos.

Y haciendo un paréntesis antes he dicho que, V7 parece un lenguaje orientado a objetos, V7 parece un lenguaje de programación estructurada, y digo parece por que hasta la fecha yo no he visto en la Web oficinal de Velneo ninguna definición seria, ni formal, ni rigurosa de V7, y podéis consultar los enlaces http://velneo.es/info/, http://velneo.es/info/velneo-v7/informacion-comercial/ ¿algo escuetos en la definición, no os parece? No estaría de más que oficialmente se pronunciaran diciendo si es un lenguaje de programación, si no lo es, si es un lenguaje orientado a objetos, si es un lenguaje de programación estructurada o afirmando que no es un lenguaje de programación genérica. Cuando lo calificas de “plataforma”, o “herramienta” es porque todavía no sabes lo que es, solo sabes lo que hace y para que sirve, que es nuestro caso. Así yo tampoco me atrevería por el momento a presentarlo en Wikipedia, pero en fin este es otro tema.

Volviendo al hilo del post, los que venimos utilizando lenguajes de programación genérica debemos asumir que V7 no lo es, y debemos asumir que nuestra costumbre de escribir código en una hoja en blanco no existe en V7, cosa que tiene ventajas e inconvenientes. Para paliar esas necesidades deberemos utilizar los objetos contenedores de comandos de instrucción (Evento, Proceso, y Función) donde solo utilizaremos comandos de instrucción no un lenguaje de programación nativo, así pues mejor asumirlo y a otra cosa mariposa.

Otro tema es el tratamiento y la visión que V7 da a los objetos Evento, Proceso, y Función. Si los definiéramos semánticamente los términos:

Evento:

Cualquier acontecimiento, circunstancia, suceso o caso posible, que sucede en un lugar y tiempo particular.

En Informática: un evento es un suceso de software que indica que algo ha ocurrido, como un tecleo o un click de un mouse.

Proceso:

Un proceso es un conjunto de actividades o eventos que se realizan o suceden con un fin determinado.

En Informática: Un proceso es un es un conjunto de instrucciones que una vez ejecutadas realizarán una o varias tareas en una computadora.

Función:

En matemáticas: Dados dos conjuntos A y B, llamamos función a la correspondencia de A en B en la cual todos los elementos de A tienen a lo sumo una imagen en B, aunque esta sea el conjunto vacío.

En Programación: es un subprograma o subrutina que realiza una tarea específica a la que introducimos unos parámetros de entrada y devuelve unos parámetros de salida, los parámetros pueden ser variables, objetos, clases, etc …

Los tres son conceptos anidados y escalables, y su máxima expresión es la función que engloba todas las propiedades de sus hijos proceso y evento.

 

Ahora deberíamos preguntarnos, ¿es este el significado que V7 da a los términos Evento, Proceso, y Función? Pues inexplicablemente NO. Veamos que nos dice Velneo a cerca de ellos:

 

Evento	Proceso	Función
Subobjeto	Objeto	Objeto
Contenedor decomandos de instrucción	Contenedor decomandos de instrucción	Contenedor decomandos de instrucción
Entrada: Ninguna	Entrada: Fichas o Listas	Entrada: Parámetros*
Salida: Ninguna	Salida: Fichas o Listas	Salida: solo 1 parámetro.
Ámbito: Local al objeto que lo contiene.	Ámbito: General a los objetos con el mismo origen (entrada).	Ámbito: General
Ejecución: 1º Plano	Ejecución: 1º,2º,3º,y 4º Plano	Ejecución: 1º Plano

Para Velneo un evento es un contenedor de comandos de instrucción sin entrada ni salida, es decir, un proceso o procedimiento en programación genérica, definición que no tiene mucho sentido y lo que es peor Velneo llama conexión de evento a lo que formalmente es un evento, un suceso, algo que ocurre en un lugar y un tiempo determinado. Esto no favorece en nada la claridad y estructura de la “herramienta” y dista mucho de convertirse en un lenguaje ya que la semántica empieza a fallar gravemente.

Para Velneo proceso es un contenedor de comandos de instrucción, cosa que en principio si esta en línea con la semántica de la programación genérica, pero sin embargo el Proceso_Velneo admite como entrada y salida las estructuras estrella de Velneo las fichas y listas de tabla de datos, convirtiéndolo de facto formalmente en una clásica función de la programación genérica. Es el Proceso_Velneo el objeto editor de código más complejo y potente de la plataforma, orientado a la gestión de rutinas con las colecciones de datos, buque insignia de v7.

Por último, para Velneo función es un contenedor de comandos de instrucción, “sin origen” según su propia definición (que no quiere decir que no tenga origen, si no que este no es ni una ficha ni una lista de tabla de datos), pero que admite parámetros de entrada (solo valores de variables) y retorna un simple valor, reduciendo a la más mínima expresión la potentísima definición de función en la programación genérica o la programación multiparadigma.

¿Por qué una función solo debe admitir un valor de retorno? ¿Por que no utilizar el paso de parámetros por referencia y permitir el retorno de n parámetros? ¿Acaso no permitiría este retorno múltiple de datos el traspaso de información entre diferentes ámbitos y objetos? ¿Por que no admitir un objeto como parámetro? ¿Por que no devolver un objeto como retorno? Todas estas cuestiones están resueltas en la programación multiparadigma, pero pendientes en Velneo.

En fin otro mestizaje sin concierto, pendiente de resolver y estructurar adecuadamente por Velneo y que supone un duro choque a la hora de resolver planteamientos para el desarrollador, que debe sortear con ingenio los errores de definición y las limitaciones de ámbito y respuesta de estos objetos.

Ya se que parece una critica muy dura, y alguien podrá decir que Velneo tiene como principal objetivo en este área manejar las colecciones de datos, cosa que hace sobradamente y con nota con el objeto proceso y tiene toda la razón, mi única intención es poner de manifiesto que a veces define con desorden la herramienta y dificulta la comprensión de la misma.

Sin querer redundar en este tema, en la última versión 7.5 se presentó el objeto alternador de lista, este objeto tiene como función presentar los registros de la lista seleccionada en diferentes contenedores según seleccionemos, rejillas, casilleros, informe, etc …, ya se que es una tontería pero la definición de alternador de lista es otro error arrastrado de la definición de multivista.

Me explico, un objeto que es capaz de presentar diferentes vistas, semánticamente es un multivista, es decir lo que Velneo llama alternador de lista. Por otra parte un objeto que es capaz de sincronizar registros de diferentes listas, semánticamente es un sincronizador de listas no un multivista como lo llama Velneo.

Ya se que me vais a crucificar, pero desde mi punto de vista Velneo reincide en la definición errónea de sus objetos, estructuras y propósitos y al final va a crear un “engendro” que solo entenderán los adeptos, los evangelizados, los creyentes y debe evitar en la medida de lo posible esto, debe estructurar adecuadamente sus propósitos y objetos, y corregir sus errores de definición.

En fin para todos los que ya me habéis crucificado no os lo toméis a mal, solo es una opinión y seguro que de poca trascendencia en la comunidad Velneo, para los que no, a partir de ahora cuando nos enfrentemos a una solución Velneo seguro que nos ayuda haber pensado con lo que nos enfrentamos y de esta manera intentaremos evitar errores básicos en los planteamientos de los desarrollos, no pidiéndole peras al olmo.

Ámbito: General a los objetos con el mismo origen (entrada).