SoloCodigo

Es una farsa y cada dia me sorprende mas que la gente se lo crea ...

¿Tambien crees en Papa Noel y los Reyes Magos?  

Miren este de linux- perdon.. uni*

http://www.elsop.com/wrc/humor/unixhoax.htm

No hay nada que creer o dejar de creer, es una farsa tal como la de UNIX que acaban de enlazar. Busquenlo y listo ...

jajaja
bueno eso depende de como compil¿e cada compilador y de que opciones tenga habilitadas por defecto.

A lo que más me refería es que es muy cierto que antes los programadores era considerados genios... hoy en día las secretarias hacen una macro en excel y ya son programadoras para muchas empresas  

Antes un porgramador podia cobrar miles de dolares por hacer un programa, hoy en día el software se regala e incluso 'es libre', asiq ue que no suena descabellada la idea de haber hecho con C++ lo que dice el articulo ya que en teoria  eso iria en favor de los porgramadores, por supuesto creo que eso nunca sucedio asi pero definitivamente hubiese podido ser...  

Respecto al performnce y al tamaño de los programas , todo es cuestion de reusabilidad y de seguridad, es decir de proteger el acceso a los datos y de demorar menos en el desarrollo,  por ello tenemos un hola mundo en asm mucho mas complejo y grande que en cualquier otro lenguaje pero mucho mas rapido y con un ejecutable mucho mas pequeño, mientras que en java ese mismo hola mundo  solo son tres lineas de codigo pero genera un ejecutable bastante grande y no es para nada rápido en comparación con el de asm...

diferencias:

*aprendes a hacer un hola mundo en java en menos de dos minutos, mientras que en asm a algunos les podria tomar una tarde o más

*entender el codigo java es igualmente facil casi que no se necesita de interpretacion, mientras que para entender elm codigo asm ... necesitaras saber un poco más y dedicarle más tiempo.

*no te debes preocupar por un buffer overflow en java porque los tipos son seguros, pero en asm debes hacer lo tu y vaya si se peude convertir en nu problema

*si quires ejecutar tu porgrama de asm en otroa maquina y ojala con un OS diferente , casi seguro que tendras que rehacerlo por completo, en java en cambio nisiquira tendras que tocarlo

y más


asi que la justificacion del tamaño, el consumo de memoria y otros que pueden tener los programas generados con lenguajes actuales esta más que dada, asique el texto es realmente un fraude pero, insisto, si tiene mucho de cierto y nos pone apensar acera de nuestro futuro y del curso que ha tomado la tecnología.

Tengo un libro que habla de la programacion de videojuegos en c, open gl, etc (si queres te busco el nombre y todo eso), resulta que empieza diciendo trucos para que los programas anden mas rapido, aqui van.

utiliza enteros ya que el procesador trabaja mas rapido con ellos, es decir no definas variables char o short que puedas declara int.
Ademas si son todas las variables enteras quedan alineadas y el procesador es mas veloz leyendo posiciones de memoria alineada (recuerdo ahora la orden pack del c)

otro consejo: Si utilizas mucho una funcion, por ejemplo setpixel o algo asi NO LE PASES PARAMETROS sino que define variables globales como parametros..

Esto es muy gracioso... resulta que el compiladores de C habilitan mecanismos que luego conviene saltear para mejorar nuestro codigo....un  chiste malo...

C++ es peor, cualquier metodo virtual es un puntero a una funcion que se resuleve en tiempo de ejecucion...una perdida de tiempo..

Java es peor, construye una maquina virtual para luego interpretar sobre esta maquina, lo que podria haber hecho directamente.

Es mas facil programar en java ? mmmm
que version ? utilizas AWT o java beans ? deves cambiar de version ? el metodo esta "deprecated" ?

todas las preguntas anteriores son mas dificiles de explicar a un neofito que eseñarle un hola mundo en assembler..¨

a proposito aqui esta hola mundo en fasm

bueno esto no es asm es Win32Asm Ethernal me corregira si me equivoco.

Ahora indepenmdiente de si usas AWT, SWING, o java beans o lo que sea...
trata de hacer lo mismo en asm a ver como te va, por supuesto que es diez mil veces más rapido hacerlo en java C++ o C# no?

Estos son dos ejemplos de un hola mundo en asm intel de 16 bit para un exe y un com respectivamente


Las facilidades de programaciíon generalmente tienen implicaciones a nivel de performance ya que en general poseen funciones 'genéricas' que permiten hacer mas cosas conmen os instrucciones, lo cual desde luego conlleva a un gasto mayor de memoria a un flujo d eprograma mucho más elaborado que si tuvieses una unica funcionalidad.

En el ejemplo anterior los programas sirven solo para colocar la palabra hola mundo en pantalla, modificandolo levemente servira para colocar alguna otra frase, sin embargo tratar de hacer algo mas generico y convertir ese programa en un printf de lenguaje C tomara muchisimo más tiempo y desde luego creara un programa mucho más grande, con mas gasto de memoria y menos eficiente pero que a la larga en un futuro nos ahorraria decenas de horas de porgramación para colocar otra frase en pantalla no o no?

Otra cosa que habia olvidado es lo de la diferencia de los ejecutables, es por ejemplo en Visual C++,
si compilas un progframa hecho en C el pro defecto asume que deseas utilizar enlaces dinámicos con las librerias del sistema operativo asi que obtendras un ejecutable bastante pequeño ( no tan como si configuras el compilador para que optimice por tamaño), pero si lo configutras para no enlazar con las librerias del sistema operativo te hara enlaces estaticos asi que tendras ejecutables bastante grandes y más un si le configuras que prime la velocidad encima del tamaño.

Para el tamaño tambien hay que tener en cuenta cuando se compila en modo depuración ya que la insercion de simbolos en el ejecutable puede aumentar el tamaño considerablemente.

¿Puedes comprobarlo? ¿Puedes? Pense que eras argentino ... De cualquier manera lo que me parece un chiste comparar GCC con RetroForth.

Dos, no es assembly puro el codigo que pusiste para sacar un MessageBox como bien dice JuanK y solo funciona para Windows en x86, ni siquiera en x64.

invoke es una directiva que pasa los parametros como debe (segun la convencion de memoria) y hace un call a la funcion.

En cuanto al tamaño me gustaria que dieras un ejemplos de C vs C++ con compiladores ACTUALES como VC++ por ejemplo, dudo que realmente encuentres diferencia sustancial, especialmente compilando como C++ codigo de C puro.

PD. El lenguaje es assembly, no assembler que es el programa que ensambla.

¿Aclarar de que estoy hablando?

Primero me parece GCC es INCONMENSURABLEMENTE mas potente y complejo que retroforth y entonces es ridiculo compararlos.

Segundo, que el ejemplo que diste de assembly dista mucho de ser codigo puro e incluso usa datos como en C. Esto estaria mas cercano a un hello world para Windows:


Tercero, evidentemente, el articulo esta hecho para engañar y por eso intenta mezclar verdades a medias con rotundas mentiras.

Estoy de acuerdo contigo

el gcc es INCONMENSURABLEMENTE mas complejo pero NO mas potente, puedo probarlo, seguramente abras leido en teoria de la computacion que los automatas de pila (el forth) es igualmente potente que la maquina de turing. (teoria de automatas y eso...)

y ahi esta el punto, para que hacer algo mas complejo si se puede hacerlo mas simple ?

puedes contestar esto ?

Habre leido mas no abre leido ...

¿Sabes la cantidad de lenguajes y arquitecturas en las que compila GCC? Reitero
que no es solo mas complejo sino MUCHO mas potente y versatil, en la respuesta a esa pregunta me tendras que dar la razon ...

¿Puedes? La verdad es que me cuesta bastante entender el "gallego". ¿Podes escribirme en "argentino"?

la variedad de lenguajes es buena si a uno le gusta la abstraccion puede usar java y sino C o assembly.

Si, y C++ obviamente, el problema es que hay saberlo usar.

lel peso del compilador gcc es porque tiene un millon de opciones y supongo que la syntaxis de C es mas compleja que la de retroForth.

Opciones, lenguajes, arquitecturas soportadas, etc.

no hya que pelearse tanto

Esto es solo un sano intercambio de opiniones