No estoy desmereciendo ningun lenguaje RICHI777!
Y mucho menos cuando, en su medida, de alguna forma me dieron de comer.
He programado y programo cualquier tipo de lenguaje. Assembler, Basic, QBasic, Pascal, Clipper, Clarion, Fortran, ADA, Logo, Lisp, Pyton, PHP, Visual basic, Delphi (Object Pascal), C, C++, PowerBuilder, SQL e inclusive basuras de reciente aparicion...
En infinidad de plataformas Sinclair 1000, ZX Spectrum, Commodore, PC para sus respectivos micros y Microcontroladores varios 8081, 8085, 8052 y derivados PIC, AVR y ahora estoy entroduciendome en los ARM.
Entonces, no me puedo dar el lujo arrogante en desmerecer a ninguno de ellos inclusive las "maravillosas" basuras actuales.
Lo que trato de decir, es que los resultados no son los mismo, y en tus citas, de alguna forma me decis esos, que es mas o menos lo mismo que trate de decir.
convengamos que todo compilador debe terminar en assembler. Entonces, podemos decir que puedo saber si un compilador es bueno o no segun el resultado que produzca en el assembler generado. Claro! esto solo es posible si sabemos y entedemos de assembler.
Cuando decis:
Eso no es asi.....
En parte tenes razon. ya que con solo incluir el header no basta. Obviamente necesitamos tambien, decirle al linker que incluya la libreria.
Pero cuando decis:
...el compilador basicamente consiste en dos procesos...
Esto no es asi.
El preprocessor tiene como mision analizar la semantica y resolver las macros, declaraciones etc. para que luego el compilador
se encargue de forma eficiente convertir todo a assembler para que luego y por ultimo, el Linker enlace todos los modulos compilados y traducidos al assembler de forma correcta.
Entonces, podemos decir que son tres las partes PREPROCESSOR, COMPILADOR Y LINKER.
Existen directivas para el preprocessor como tambien para el compilador y tambien hay indicadores para el linker.
las directivas las podemos inlcuir en el codigo directamente pero los indicadores para el linker no.
Si hay algo que destaca al C por sobre los demas lenguajes, es el preprocessor. Esto hace que el lunguaje se el mas eficiente en la historia y nada podra superarlo. ACLARO... NO SOY FANATICO DEL C! pero es MARAVILLOSO!!
Para la mayoria de los lenguajes de alto nivel, el compilador fue escrito en C. Esto te da una pauta de como esta hecho el C.
Cuando digo que las librerias no son nativas del lenguaje, es exactamente eso.
El lenguaje se compone de
-tipos
-operadores
-expresiones
-sentencias.
Cuando el C nacio, nacio con esto. a medida que fueron necesitando funcionalidad, fueron apareciendo las librerias.
Pero dentro de las librerias, solo hay codigo nativo del lenguaje agrupado de tal forma que le dan la funcionalidad esperada.
Un lenguaje de programacion no es considerado como tal si no posee las herramientas minimas e indispensable para la manipulacion de datos.
Yo no puedo sacar al mercado un lenguaje que solo posee operadores, expresiones, etc. porque obviamente que ningun programador va a intersarle ya que no le resuelve absolutamente nada.
Pero si le agrego librerias para manipulacion de strings, entradas y salidas, operadores matematicos algebraicos cientificos, manimpulacion de numeros enteros flotantes y demas. Entonces puede existir algun interes de adopcion por algun programador.
El exito del lenguaje estará definitivamente en el compilador. porque ahi esta el alma del mismo.
si el compilador es eficiente y genera un codigo assembler rapido y estable. entonces habra mas de un programador que lo adopte. Pero el programador tiene que tener concimientos precisos en assembler para poder evaluar el compilador.
En (casi)todos los lenguajes, pongo casi porque desconozco el "todo" como para hacer dicha afirmación, existe el concepto de función, procedimiento o rutina, después de lo que haga es tarea de la implementación, en el caso de C se llama RTL ( Real Time library ) en C++ se llama STL ( standart template library ) y asi. No conozco ningun lenguaje que tenga funciones como palabra reservada o digamos propia de la semantica del lenguaje.
Insisto, para codificar una libreria tenes que hacerlo basandote en el lenguaje utilizado sus herramientas nativas.
Por ejemplo, no podes codificar una funcion que dependa de otra funcion en otra libreria y querer que esta nueva funcion sea considerada libreria estandard. ya que que tiene una depencia inevitable.
Pero si codificas esa misma funcion solo con el lenguaje, entonces podes pretender un estandard.
Lo que trato de decir es que las librerias de funciones no son nativas del lenguaje.
y podes escribir codigo sin ni siquiera agregar un minimo #include de estas librerias.
en mi caso, por ejemplo, trato de no usar la funcion sprintf. es muy grande y lenta para lo que necesito en la mayoria de los casos.
si quiero escribir un texto en un display, lo hago manipulando los datos con las herramientas nativas del lenguaje. Arrays, punteros, while, for, switch, etc. Y logro un codigo muy reducido y rapido.
Pero si en algun momento inevitablemte la tengo que usar, bueno a partir de ahi la uso siempre porque ya se encuentra en memoria entonces es ridiculo que no la use. Se entiende?
De todos modos, en este punto, estamos muy aljados del hilo objeto de este post. habria que habrir un post sobre "ASSEMBLER O ALTO NIVEL?" y recuperar el hilo de este.
Saludos!
