¿ Por qué Delphi y Visual C++ ya no son como antes ?

[Casimiro Notevi]

Empezado por mamcx

Incluso puedes usar haskell ... javascript ... y asi por el estilo.

Ya, ya, y por ejemplo ¿con qué está hecho haskell? Solamente tienes que mirar la cabecera de uno de sus ficheros fuentes;

{-# LANGUAGE CPP #-}
{-# LANGUAGE DeriveDataTypeable #-}

[mamcx]

Empezado por Casimiro Notevi

Ya, ya, y por ejemplo ¿con qué está hecho haskell? Solamente tienes que mirar la cabecera de uno de sus ficheros fuentes;

{-# LANGUAGE CPP #-}
{-# LANGUAGE DeriveDataTypeable #-}

Y con que esta hecho https://www.kitlang.org/? Con haskell, que compile a C que compila por LLVM (c++) a Assembler.

Y como es posible que Delphi estuviera hecho en Delphi? Porque se puede hacer:

https://en.wikipedia.org/wiki/Bootstrapping_(compilers)

Y entonces, es posible compilar de Ruby a Rust a Scala y asi atavesar 128 lenguajes de programacion terminando en REXX y luego en Ruby de nuevo:

https://github.com/mame/quine-relay

porque un compilador es:

Input -> Compile -> Output

y por lo tanto, NO LE IMPORTA que se use en el COMPILE mientras pueda leer su INPUT y generar su OUTPUT.

Un interprete, por el contrario, si se beneficia de "bajar" de nivel, puramente porque necesita un runtime.

[Casimiro Notevi]

Creo que no me has entendido, o no me he explicado.
Lo que quiero decir es que el día que decidieron crear "el lenguaje que sea", abrieron el IDE de un compilador y empezaron a teclear, ¿qué compilador era?
Porque obviamente es imposible crear Delphi con Delphi, al principio tuvieron que usar turbo pascal, ensamblador, etc. y una vez que tienes una base mínima para trabajar, ya sí, ahí puedes abrir esa mínima base de Delphi y seguir creando/ampliando Delphi. Además que el compilador de delphi es totalmente básicamente el mismo que el de C builder, por lo que ya estaba hecho.
Y así con todos, cuando fueron a crear Haskell, por ejemplo, ¿qué compilador usaron? pues si miras el código fuente y ves cabeceras CPP, eso es lo que quiero decir.
Ahora bien, que hoy en día con tantas mezclas, derivaciones, clones, etc. sea posible crear algo de "abajo" con algo de "arriba", pues no lo dudo. Cosas más difíciles se han hecho.

[[brakaman]]

Hola amigos:

Yo por lo que he entendido cuando un lenguaje o compilador esta hecho en si mismo, normalmente se hace un pequeño kernel en lenguaje C, entonces con esta herramienta ya se puede usar el futuro compilador de una manera muy basica, entonces este software crea ya el exe del compilador en el propio lenguaje en esta caso Delphi y a partir de ahi se genera todo, esto es explicado a grandes rasgos.

Entonces creo haber leido que el kernel de delphi se hizo en Ensamplador (Todavia mejor que en C) y a partir de ahi con instrucciones Delphi se genero su propio compilador.

La mayoria de los lenguajes ya digo que usa C, un ejemplo ultimo es el lenguaje Go de google al principio se uso durante mas de un año una version hecha totamente en C aunque luego tuvieron la santa paciencia de reescribirlo en el propio Go, por eso esta hecho en Go como le pasa a Delphi, otros ejemplos , el lenguaje Rust esta hecho en Rust. No conozco mas ejemplos.

Pero el 90% estan hechos en lenguaje C, Haskell, Java, Scala, Julia, Kotlin, etc.etc. Javascript por supuesto.

[Casimiro Notevi]

Empezado por brakaman

Hola amigos:

Sí, eso quería dar a entender.

[mamcx]

Empezado por brakaman

Yo por lo que he entendido cuando un lenguaje o compilador esta hecho en si mismo, normalmente se hace un pequeño kernel en lenguaje C

Es un camino comun. Pero no es INDISPENSABLE. El que parezca serlo es ppalmente que las comunidad de hacedores de lenguaje es muy pequeña ( y esos hacedores son muy conservadores en su uso de herramientas), y solo en los ultimos años se ha extendido y se hace mas popular la idea de hacer lenguajes.

Se hace en C por inercia, y acceso a ecosistema. Pero puedes arrancar con CUALQUIER lenguaje. El punto es que la implicacion de la imagen no es correcta (aunque se puede argumentar que historicamente fue la sequencia que nos toco. Pero perfectamente pudo haber sido diferente: Lisp pudo haber sido el "c" para hacer lenguajes).

Ahora, para *interpretes* si es mas cierto. Se pueden hacer interpretes metacirculares, en su propio lenguaje, y en un lenguaje mas "arriba", pero para hacerlos eficientes, necesitas hacer un bytecode y tener un lenguaje con la maquinaria de operar eficiente en eso ( y para especificar la estructuras y manipulacion memoria). Si tiene GC, este interfiere con el tema, porque los GC estan ajustados a su lenguaje, asi que si te desvias mucho termina afecto negativamente.


Ahora, esto es puramente por eficiencia. Se puede totalmente hacer un interprete de C en Java y con bytecode, no ser tan lento en su generalidad (solo sufrir en manipulacion intensiva).

P.D: Llevo como 3 años ya leyendo del tema y prototipando lenguajes en varios entornos.

P.D: Si hablamos de que *realmente* hace un lenguaje bueno para hacer lenguajes, tenemos que estas son sus familas/versiones:

Todos los lenguajes con Homoiconicidad (https://es.wikipedia.org/wiki/Homoiconicidad):

- Derivados Lisp, por su enorme facilidad de metaprogramacion
- Forth y derivados, trivial de hacer bootstraping
- ML y derivados: Uso de tipos algebraicos hacen para lenguajes tipados lo que lisp para no tipados: Trivial de operar en AST

Y lenguajes con capacidad de operar en estructuras de "bajo" nivel. C, C+, Pascal, Delphi... pero se puede en C#, Java con extenciones y soportes como

https://github.com/dotnet/roslyn

que operan al nivel del AST y no del lenguaje de alto nivel como tal.

Osea, lo que hace a un lenguaje bueno pa hacer lenguajes? Que permita manipular AST de forma eficiente y natural.

[Casimiro Notevi]

Empezado por mamcx

... Se puede totalmente hacer un interprete de C en Java ...

Bien, pero a donde quiero llegar es a ¿qué lenguaje se usó para crear java? pues principalmente c++ además de pascal y objetive-c

[mamcx]

Empezado por Casimiro Notevi

Bien, pero a donde quiero llegar es a ¿qué lenguaje se usó para crear java? pues principalmente c++ además de pascal y objetive-c

Si lo miras historicamente, se usa el lenguaje que había en el momento. Y se crea uno adicional. Eso esta bien. Pero la grafica dice:

"La LEY es muy simple. Cada nivel SOLO puede emitir complejidad hacia ARRIBA".

Cada una de las palabras en mayusucula es una afirmacion errada. Si dijera:

"La HISTORIA es muy simple. Cada lenguaje SE USO para crear un lenguaje ADICIONAL".

Que no suena tan descrestante.

No es sorprendente, porque incluso la afirmación de que C es un "lenguaje de bajo nivel" usandola como suposición de que significa "permite programar mas cerca de la maquina" no es correcta:

http://lambda-the-ultimate.org/node/5534
https://queue.acm.org/detail.cfm?id=3212479

C Is Not a Low-level Language


In the wake of the recent Meltdown and Spectre vulnerabilities, it's worth spending some time looking at root causes. Both of these vulnerabilities involved processors speculatively executing instructions past some kind of access check and allowing the attacker to observe the results via a side channel. The features that led to these vulnerabilities, along with several others, were added to let C programmers continue to believe they were programming in a low-level language, when this hasn't been the case for decades.

Esto puede sonar imposible de creer, pero una vez estudias todo lo que tiene que hacer un compilador para hacer que ese codigo C ande, te das cuenta que tambien C es de (relativamente) alto nivel. Y no uno muy bueno.

El punto? "Alto" y "bajo" es relativo. Estamos amarrados a C no por ser de "bajo" nivel, sino porque es el estandar de la industria. Se me olvido de mencionar la razon ppal por la que se usa C/C++ para estas tareas. Por el ABI! Ya que tantos componentes y OS estan hechos en C, para hacer llamadas a esas interfaces, en C, tienes que emitir y entender C!

Y es un ASCO!

C es un pesimo lenguaje para conectar apps! Pero como es lo que hay, es lo que hay. Asi que toca aguantaselo. Asi, que si usas un lenguaje que ya tiene la maquinaria para entender C, pues te ahorras un problema menos.

------

Es posible hacer codigo en otros lenguajes que permiten emitir mucho mas eficiente assembler, simplemente porque son mas "cerca al metal" de la arquitectura moderna de los computadores:

http://www.lighterra.com/papers/modernmicroprocessors/

Y en este caso, C es una barrera para explotar esas nuevas capacidades.