[ATARI] Re: Atari digest, Vol 1 #189 - 2 msgs

[Luis Manuel Asensio Royo]

Atari Emulación España (Gabriel Huertas) wrote:

> De acuerdísimo contigo. ¿Tan dificil es entender ésto?. En ciencia siempre
> hemos considerado como premisa que la solución a un problema correcta de
> entre las varias posibles es siempre la más sencilla. Esto es válido desde

Esto se debería enseñar desde el parvulario hasta el final del curso
educativo, porque es básico. Hasta en la naturaleza se emplea la leya de
la 'mínima energía' para conseguir sus fines.

> aspectos de esta posibilidad se muestran palpables: el "integrismo
> informático", "fanatismo teoSOgico" e incluso profecias "de lo que está por
> venir" y Mesias incluido no faltan.

Si, tenemos unos cuantos, empezando por Billy Puertas...
 
> Pero en fin, estamos en unos tiempos en los que se dice incluso que los
> lenguajes de programación "de verdad" son los interpretados, y no los

Depende del caso. Si el lenguaje interpretado no ha sido precompilado
previamente, entonces el intérprete tiene que traducir cada vez todas
las intrsucciones, lo cual es muy ineficiente en tiepo de ejecución,
pero por otro lado son más fáciles de programar, porque si no funciona
correctamente, lo modificas y lo vuelves ha lanzar, pero hast en ésto
hay un problema, porque la ejecución se para al primer error que
encuentra, a diferencia de la compilación que te da una lista de errores
antes de pararse. Si se quiere velocidad de ejecución no queda más
remedio que compilar el programa, es la única forma. Si se va ha
ejecutar un programa donde no es relevante la velocidad y su uso es poco
frecuente, un interpretado ya te vale. Todo depende de lo que se quiera
hacer.

> compilados, donde los procesadores virtuales son más rápidos que los de

Salvo que alguien me de pruebas de lo contrario, ésto no es cierto...

> verdad, donde los PentiunIV a 1.4 Ghz alcanzan la velocidad de los
> PentiumIII a 750Mhz, dónde un músico profesional se tiene que gastar 300.000

Y con un coste igual o superior...

> pts en un secuenciador exclusivo, basado sobre un procesador en muchos caso
> de 8 bits, para poder trabajar consecuentemente, porqyue con su ordenador de
> 32 no se puede, etc

Aquí el problema es cómo se ha implementado el sistema operativo, que es
lo que debería tener y que es lo superfluo. Igual me equivoco, pero me
da la impresión que el 50% del Windowze es superfluo, empezando por la
estúpida idea de integrar un navegador web en el sistema para también
navegar por el sistema de ficheros, engordando el sistema y
raletizándolo. Lamentablemente semejante idea ha cuajado en el KDE y
elGnome, con el Konqueror y el Nautilus respectivamente.
 
> El uso de librerias te lleva a la ineficacia en la programación, como todos
> sabemos. mientras más librerias prefabricadas, menos control sobre el

Deberían existir aquellas librerías dinámicas que aportan algo que no
tiene el sistema y que puede ser muy importante, pero para nada más.
Crear librerías dinamicas para abrir JPEGs y MP3 me parece un poco
absurdo, para éso prefiero pequeños programas especializados al estilo
Unix que te permite usarlo en cualquier momento y con cualquier
programa.

> pograma, más desperdicio de recursos , etc. Decimos que C es un magnífico
> lenguaje, o incluso más, decimos que C es "el lenguaje", y que inventos como

Es un buen lenguaje para desarrollo. Quizás para un novato la aritmética
de punteros puede ser dificil de entender, pero te acerca mucho al
sistema. El problema a menudo no es el lenguaje, sino saber programar.
Yo he visto hace muchos años viguerías de programas en el ZX-81 que
aprovechaban al máximo el escaso 1KB que tenía incorporado, desde
pequeñas utilidades hasta juegos. Programar mal es muy fácil, lo
realmente dificil es programar bien, que tu programa use los recursos
estrictamente necesarios, que o solicite cuando sea necesario, y cuando
termine que los libere inmediatamente, además deque se ciña
estrictamente a lo que has diseñado y olvidarse de florituras que no
solo consumen recursos, sino que enletecen el programa y a menudo son
más un estorbo que una utilidad.

> BASIC son depravantes porque te alejan todavía más del hardware, y te quitan
> control con sus funciones prefabricadas, y sin embargo, utilizar librerias

El Basic, al igual que el Pascal, Modula-2, LISP, PROLOG, etc, son
lenguajes de alto nivel. No tienen por qué saber qué tienen debajo para
su funcionamiento. El C es un lenguaje de medio nivel, entre el
ensamblador y los demás lenguajes. Te permite hacer buenos programas sin
tener que recurrir al ensamblador salvo para lo estrictamente necesario,
y sin embargo ésto no impide definir y diseñar funciones y tipos de
datos como los lenguajes de alto nivel. Cada lenguaje tiene un campo en
el que encaja como un guante, sólo hay que programarlo eficientemente.

> en C:
> fprint("hello world");

Y mira que el compilador te incluye la librería completa de la función
printf, que soporta muchos tipos de salida de datos. 

> En Basic:
> print "hello world"
> y aquí no tengo opción de manejar de ninguna forma las librerias (ni para
> bién ni para mal), es el sistema el que me las impone.

No, desde luego que no hay control sobre qué incorpora el compilador.
Dependiendo que cómo esté hecho se puede mirar en las opciones del
mismo, pero aun así no sabes que incluye al compilarlo. Y peor viene
cuando lo quieres 'empaquetar' para que se pueda ejecutar en cualquier
otra máquina...
-- 
 |||   Saludos | Salutations | Greetings | Grüße
_/|\_  Luis Manuel Asensio Royo

"La violencia es el último recurso del incompetente". Isaac Asimov