29.04.2005 :: Jaime Irurzun
Al aprender Object Pascal en la universidad, una de las cosas que más me ha llamado la atención es lo estricto que te obliga a ser a la hora de manejar tipos de datos. Hasta empezar este primer curso, toda mi experiencia en programación se reducía a xbase y algún pinito en PHP, curiosamente dos lenguajes de lo más flexibles en este aspecto. Me explico: en Object Pascal, al escribir una función que recibe parámetros tienes que indicar el tipo de dato del que va a ser cada parámetro recibido. Ejemplo:
function Potencia( nBase:real; nExp:integer ):real;Como véis, la cabecera especifica que la base será un número real, que el exponente será un entero, y que el valor devuelto por la función también será real. En xbase no ocurre lo mismo:
···var
······i: integer;
···begin
······Result := 1;
······for i := 1 to nExp do begin
·········Result := Result * nBase;
······end;
end;
function Potencia( nBase, nExp )Por una parte pienso que la legibilidad del programa aumenta muchísimo al verte obligado a especificar los tipos de datos de todas las variables (además de que el ahorro de memoria también se ve incrementado, puesto que se sabe con antelación qué cantidad exacta de ésta hará falta), pero por otra pienso que en ciertas ocasiones puede volverse una incomodidad importante. ¿Qué ocurre si en un principio pensamos que una variable basta con que sea real en simple precisión pero más adelante vemos que necesitamos doble precisión? En ese caso habrá que cambiar todos los real que encontremos por double. Aún peor, puede que esto no ocurra en una sola declaración: si esa variable se pasa por parámetro durante varias funciones, el recorrido de cambios puede ser muy extenso.
···local i := 0
···local nRes := 1
···for i := 1 to nExp
······nRes *= nBase
···next
return nRes
Más allá de mi opinión, ver que los lenguajes más extendidos (C, C++, C#, Java... etc) optan por la opción restrictiva me hace pensar que tal vez el aumento de legibilidad sea un factor con suficiente peso como para querer ahorrarnos unos minutos de trabajo cambiando tipos...
comentarios (13) |
Te aseguro que no es ningún inconveniente y si una gran ventaja que ayuda a depurar, además xBase y php lo pueden hacer porque son interpretados cuando el Object Pascal es compilado, aún así, existe en las últimas versiones un tipo llamado "Variant" que si que puede hacer esas cosas, a cambio de más procesamiento y más consumo de memoria.
No es buena práctica reutilizar variables y mucho menos reutilizarlas cambiandoles el tipo de dato. Claro que para esto, como para casi todo, hay excepciones :)
Un saludo.
Si, yo tambien estoy pasando de PHP/ColdFusion a Java y eso es bastante molesto. No el definirla sino el tener que pensar antes a que datos voy a limitar el contenedor de la variable...
Una opción que yo usaba era aceptar los punteros, pero entonces el paso de variables era siempre por referencia.
--
SegFault
Es por eso que en la universidad siempre eligen un lenguaje fuertemente tipado para enseñar a programar. Porque hay que pensar antes de programar.
De ahí la popularidad de PHP y compañía, que es más fácil programar.
Para los casos que comentas esta el typedef en c++ por ejemplo:
typedef ENTERO unsigned short int;
Nota: no se si es exactamente asi pues lo di en la universidad hace dos años y mi memoria puede fallar.
entonces en vez de usar el tipo que quieras usar puedes usar el tipo definido anteriormente y si durante el programa necesitas cambiar la precision solo tienes que modificar esa linea de codigo.
Un saludo.
En los lenguajes fuertemente tipados el compilador ha de saber el tamaño de una variable de antemano y lo que es un engorro es no definir los tipos de las variables porque ese código ni es mantenible ni es legible.
¿Qué ocurre si en un principio pensamos que una variable basta con que sea real en simple precisión pero más adelante vemos que necesitamos doble precisión?
Lo que ocurre es muy simple, que has pensado mal, porque si necesitas doble precisión has de declarar la variable desde el principio como double y no como real.
Salu2
Te puedo asegurar que te ahorraras muchos errores lógicos al limitar el tipo de datos. Por experiencia.
Totalmente de acuerdo con los comentarios, estoy en primero de carrera, pero ya nos lo dijo el profesor, el ser rígido en este sentido te ahorra después muchos problemas.
Pues sí, pensándolo después de leer todos vuestros comentarios creo que es mejor que los lenguajes sean fuertemente tipados. Ahora lo que me fastidia es que xbase no lo sea... con lo que me gusta.
Los lenguajes sin tipo (como PHP, Clipper, etc.) están muy bien para hacer cosas rápido, sin pensártelo mucho y sin tener que saber nada de lo que está ocurriendo por debajo. Sin embargo, un informático tiene que saber lo que realmente significa declarar una variable, asignar un valor, llamar a una función, etc. y eso sólo lo aprenderás con lenguajes clásicos como Pascal, C, etc.
No sé si es máso menos eficiente declarar los tipos, lo que sí que sé es que es más didáctico y más racional, y mientras aprendas, esa debe ser la prioridad.
Yo que tú aprendería de los clásicos, y después aplicaría los aprendido a cualquier otro campo que quieras utilizar.
Recuerda el artículo "De vuelta a las bases" de Joel donde describe perfectamente porqué se usan esos lenguajes en la universidad y no otros más evolucionados como Java, C#, etc.
Saludos
JM
La programación es la lucha constante contra los errores. Todos aquellos errores que se puedan detectar al compilar son los más fáciles de corregir.
El tipado de datos, al igual que otras características que aportan los lenguajes, son un mecanismo para que los errores aparezcan al compilar y, no al ejecutar.
Como decía un amigo mío... hay tres tipos de errores:
a) en tiempo de compilación
b) en tiempo de ejecución
c) y en tiempo de examen
>además xBase y php lo pueden hacer porque son >interpretados
Esta expresion es falsa.
Clipper y por extension Harbour, es lo mismito que
java, osease, P-CODE.
Un lenguaje interpretado es , por ejemplo, Gw-Basic.
Jaime, creo recordad que puedes OBLIGAR en xHarbour el uso de AS tipo_de_dato, asi como en las clases puedes determinar el ambito de acceso de esa variable DATA lSalta AS BOOLEAN, solamente
te va a permitir asignar un valor boleano, otro tpo de asignacion te dará un error en ejecucion.
A nivel de compilador, la declaracion de :
Local nNumero AS NUMERIC, tiene en cuenta que
una asignacion del tipo:
nNUmero := "MI CASA", te dara un aviso el compilador
Saludos.
JM,
> Sin embargo, un informático tiene que saber lo que > realmente significa declarar una variable, asignar > un valor, llamar a una función, etc. y eso sólo lo > aprenderás con lenguajes clásicos como Pascal, C, > etc.
No sé si estoy muy de acuerdo con eso. Vale que C es un lenguaje de más bajo nivel que xbase, pero ¿significa eso que quien usa xbase no sabe lo que hace realmente cuando declara una variable o llama a una función? Es un lenguaje amigable, pero tampoco un juego de niños...
Sobre el artículo de Joel, muy bueno, gracias por la recomendación. Leerlo me ha recordado lo mucho que me gustó cuando me tragué los 4 primeros capítulos de su libro de golpe :)
José Luis,
> El tipado de datos, al igual que otras
> características que aportan los lenguajes, son
> un mecanismo para que los errores aparezcan al
> compilar y, no al ejecutar.
Me ha gustado esta idea, eso sí que creo que es un argumento de peso... limitar los errores de sintaxis únicamente al tiempo de compilación es sin duda una ventaja muy grande.
Rafa,
Sobre el "AS TipoDeDato": precisamente ayer estuve leyendo un rato el manual que escribiste explicando Objects. Vale que lo del AS está bien, y realmente obliga a manipular datos del tipo que especifiques durante la vida de esa variable, pero tampoco llega a ser un lenguaje estricto en cuanto a los tipos. Al declarar funciones, ni siquiera tienes que (ni puedes, creo) especificar el tipo de dato de los parámetros, y al declarar variables locales, más de lo mismo. Hasta donde sé, lo habitual es hacer:
local cVar := ""
local nVar := 0
local dVar := cTOd("")
No sé... ahora que me he acostumbrado en la uni con Object Pascal y vistas las ventajas que supone, es algo que echo de menos en xbase.