Buenas gente.
Creo que los comentarios sobre el lenguaje C o cualquier otro no pueden ser Off-Topic, en todo caso deberían postearse en "General".
A mí me parece que está bueno que hablemos sobre programación en general y sobre otros lenguajes porque es una forma de enriquecernos, no creo que haya una desviación importante o nociva respecto del tema original.
Shell, yo también en su momento aprendí a programar con Pascal en la universidad y es un lenguaje que siempre me provocó sentimiento nostálgico. Pero no por ello, ni por su característica de ser un lenguaje de tipos fuertes, con verificación estática de tipos y sin conversiones de tipos automáticas, sea un buen lenguaje para enseñar/aprender programación.
Esto tiene que ver con lo que comentaba en un mensaje anterior y, como dijo Julio, lo que se intenta en
gambas con esta nueva característica es brindar una facilidad al estilo, no digo de Python, sino de cualquier lenguaje con un sistema de tipos dinámicos (me alegra que alguien se haya dado cuenta de ello y no me sorprende que sea Julio).
En cuanto al sistema de tipos
gambas tiene una aproximación práctica (algo que se acentúa más en
gambas que en otros BASIC) e híbrida.
Se supone que un sistema de tipos dinámico permite que se asigne a una variable un valor de cualquier tipo, lo que supone que el tipo de las variables no se declara (no necesariamente que la variable no se declara) y la verificación de tipos se realiza en tiempo de ejecución (si no hay verificación entonces se trata de un lenguaje "untyped"). De estas cosas
gambas sólo cumple la última.
Que un lenguaje tenga un sistema de tipos fuertes significa que el lenguaje permite asignar a una variable sólo valores del tipo declarado (o inferido) para esa variable. La mayoría de los lenguajes fuermente tipificados realizan la verificación de tipos en tiempo de compilación. Sin embargo,
gambas es un lenguaje de tipos fuertes que realiza la verificación en tiempo de ejecución.
En un mensaje anterior dije que
gambas al requerir la declaración del tipo de datos de las variables y realizar la verificación en tiempo de ejecución, reúne lo peor de ambos mundos. Pero la obligatoriedad en la declaración de tipos de datos permite que el compilador genere bytecode más eficiente (quienes siguen de cerca el desarrollo de
gambas saben que Benoit es un tipo muy obsesivo en cuanto a que
gambas tenga un muy buen rendimiento).
La aproximación de
gambas es práctica en el sentido de que se trata de decisiones de diseño (del lenguaje) que le permiten a Benoit lograr ciertos objetivos con una implementación relativamente sencilla, pero para eso se realizan algunas concesiones con respecto a la sencillez o practicidad del lenguaje desde el punto de vista del programador usuario de
gambas.
Para un lenguaje de tipos fuertes lo mejor es un sistema de inferencia de tipos porque permite que la declaración del tipo de datos de las variables sea opcional (sólo con fines de documentación del código) de modo que se parece a un sistema de tipos dinámico en que no requiere la declaración, pero no permite asignar un valor de tipo de datos diferente a aquel con el que la variable fue inicializada y obtiene (por inferencia) la información de tipos que necesita para realizar optimizaciones en el código máquina o bytecode resultante.
Un sistema de inferencia de tipos (Haskell, Erlang) como parte de un sistema de tipos bien diseñado y altamente coherente, le brinda al programador mayores comodidades al no requerir la declaración del tipo de datos y por proveerle de todos los beneficios comúnmente asociados a la tipificación estática.
Sin embargo, escribir un sistema de inferencia de tipos y un sistema de tipos de datos que sea robusto es algo bastante complicado de realizar incluso para programadores/diseñadores de lenguajes.
La verificación estática de tipos tiene como una de sus ventajas que se obtiene información de realimentación de forma inmediata después de compilar. La verificación en tiempo de ejecución es uno de los puntos que frecuentemente se critican en lenguajes cuyo sistema de tipos es dinámico y el otro es que al no requerirse la declaración del tipo de datos de las variables se puede generar el tipo de error que podría provocar esta nueva característica de
gambas (que compilador interprete un error tipográfico como la intención del programador de crear una nueva variable).
Pero los lenguajes cuyo sistema de tipos es dinámico generalmente proporcionan herramientas que facilitan la escritura de pruebas unitarias. Un aprendiz tiene la "desventaja" de tener que escribir pruebas unitarias para comprobar que la lógica de su programa es correcta y como parte de esas pruebas tiene que escribir tests que realizan lo que el compilador hace "gratis" en un lenguaje con verificación de tipos estática.
En realidad, lo anterior no es una desventaja porque el aprendiz se enfrenta desde el principio a la necesidad de aprender a escribir pruebas unitarias. Cuando el aprendiz deja de serlo, generalmente ya no necesitará escribir pruebas unitarias para realizar la clase de comprobación elemental que realiza el compilador en un lenguaje con un sistema de tipos con verificación estática.
La mayoría de los lenguajes actuales con sistemas de tipos fuertes y verificación estática también suelen proveer herramientas que facilitan la escritura de pruebas unitarias (por ejemplo, Java).
Me consta que un lenguaje que no provee herramientas de prueba (como
gambas) desalienta al programador a escribirlas. Al no contar con las herramientas acostumbradas, la tendencia a no escribir tests unitarios es muy fuerte.
Entonces, cabe preguntarse qué clase de "malas costumbres" son más malas, si no declarar las variables o no escribir pruebas unitarias. Para mí, acostumbrarse a no escribir pruebas unitarias es para un programador lo que sería para un maratonista correr con una sola pierna.
En un lenguaje de objetos puro, que no exista el requerimiento de declarar el tipo de las variables no es un problema porque "el código" o más propiamente los métodos suelen ser muy breves (en Smalltalk es muy común que la mayoría de los métodos tengan entre 1 y 10 líneas) y porque siempre se puede utilizar alguna convención de nombres que indique el tipo de datos esperado, por ejemplo:
name: aStringName
name := aStringName
Lo anterior es un setter y aStringName es un parámetro formal, el primer "name" es el nombre del método y el segundo "name" es una variable de instancia de una clase. Esto equivale a:
En Smalltalk las variables deben declararse (no su tipo), pero aún en lenguajes que no requieren la declaración de variables, esto no debe suponer un mayor problema si toda rutina de código se escribe tan breve como sea posible y si se escriben pruebas unitarias.
Si nos ponemos a pensar un poco caeremos en la cuenta de que una variable al ser básicamente un apuntador (una referencia) a un objeto alojado en memoria, no tiene por qué tener asociado un tipo de datos (como sí se sugiere al declarar el tipo de datos de las variables), sino que lo que "debería" tener un tipo es el objeto mismo.
Mucho de la complejidad de los lenguajes de programación deriva de sistemas de tipos de datos pobremente diseñados que imponen restricciones al programador para luego incorporar al lenguaje mecanismos para evadir esas restricciones.
Por ejemplo,
gambas (al igual que otros BASIC) incorpora el tipo de datos Variant: si un programador usa extensivamente este tipo de datos, básicamente estaría evadiendo casi todo tipo de restricción y comprobación de tipos, lo que sería muy parecido a usar un lenguaje de tipos de datos dinámico (el programa resultante utilizaría más memoria y tendría un rendimiento inferior).
Algo similar ocurre si se usa extensivamente el tipo Object.
Pero esto permite utilizar polimorfismo entre objetos que no pertenecen a una misma jerarquía de clases, algo a priori impensado para un lenguaje con un fuerte sistema de tipos.
En conclusión, para mí esta nueva característica debe ser opcional (y así lo hizo finalmente Benoit según leí en la lista de correo en inglés) porque el usuario promedio de
gambas no es un programador profesional y principalmente porque
gambas no provee de las herramientas que faciliten la escritura y ejecución de pruebas unitarias.
Saludos.
Al otro lado de la pantalla
Montevideo
Me gustaría dar mi humilde opinión con respecto al tema original. No me parece una buena mejora, es más, prefiero que me siga diciendo "identificador desconocido" al tratar de ejecutar el programa, cuando me olvido de declarar la variable.
