Portada
mis comunidades
otras secciones
#14:
Mejor irse a la fuente original y ver que, además del cabreo que ha pillado por los problemas que le está dando, lo que dice es bastante interesante y tiene buena parte de razón.
Del original:
"C is the lingua franca of programming. We must all speak C, and therefore C is not just a programming language anymore – it’s a protocol that every general-purpose programming language needs to speak."
https://gankra.github.io/blah/c-isnt-a-language/
No es cierto que diga que C no sea un lenguaje de programación, lo que dice es que la ubicuidad de C es tal que ya no es sólo un lenguaje de programación, sino que además se comporta como un protocolo de, por ejemplo, comunicación con cualquier SO, de manera que quieras o no te va a tocar meterte con C.
Además, de lo que entiendo del artículo, es que ya que no queda más remedio que pasar por el aro de C, sería bastante deseable que estuviera más estandarizada la manera de hacerlo, porque con la fragmentación de C es realmente complicado hacer que las cosas funcionen de una forma previsible a través de las interfaces.
Del original:
"C is the lingua franca of programming. We must all speak C, and therefore C is not just a programming language anymore – it’s a protocol that every general-purpose programming language needs to speak."
https://gankra.github.io/blah/c-isnt-a-language/
No es cierto que diga que C no sea un lenguaje de programación, lo que dice es que la ubicuidad de C es tal que ya no es sólo un lenguaje de programación, sino que además se comporta como un protocolo de, por ejemplo, comunicación con cualquier SO, de manera que quieras o no te va a tocar meterte con C.
Además, de lo que entiendo del artículo, es que ya que no queda más remedio que pasar por el aro de C, sería bastante deseable que estuviera más estandarizada la manera de hacerlo, porque con la fragmentación de C es realmente complicado hacer que las cosas funcionen de una forma previsible a través de las interfaces.
#59:
#14 #37 Como tú dices, lo mejor es leer el artículo original aunque no esté muy bien escrito (demasiado quejica).
Muy resumido sería esto:
- C está estandarizado a nivel de lenguaje (ISO), librerías estándar (ISO y POSIX) y llamadas al sistema operativo (POSIX).
Esto es lo que podríamos considerar el API estándar de C.
- Sin embargo no existe estándar a nivel binario: organización en memoria de las estructuras de datos, cómo se realizan las llamadas a funciones y cómo se recuperan los valores de retorno.
Sí, esto es de muy bajo nivel y además existen muchos tipos de llamadas: entre funciones del mismo código objeto, entre funciones de distintos objetos binarios (linkados estáticamente o dinámicamente) y llamadas al sistema operativo (con salto de anillo de protección incluido).
Por eso los interfaces binarios de C dependen de 3 cosas: la arquitectura del procesador, el compilador y el sistema operativo.
Y existen muchas combinaciones (~170 en clang, si no me equivoco).
A esto se le llama ABI.
Por cierto, el estilo de ABI más extendido viene de la PDP11, donde se inventó el C.
- Todo esto sería sólo relevante para los que programan en C, si no fuera porque la inmensa mayoría de librerías de bajo nivel y sobre todo interfaces de sistemas operativos están hechos en C.
Ningún sistema operativo popular ofrece API/ABI para otros lenguajes aparte del C.
Así que cuando otros lenguajes tienen que interactuar con el sistema (pintar cosas en pantalla, capturar teclado o ratón, leer o escribir en disco...), tienen que llamar a código compilado desde C, cuya ABI sigue alguna de las combinaciones arquitectura/compilador/sistema operativo.
Además, de alguna manera, tienen que traducir a APIs de su propio lenguaje (a nivel de código fuente) las cabeceras (.h/.h++) que declaran esas librerías/sistema.
Ejemplos:
- ctypes de Python: https://docs.python.org/3/library/ctypes.html
- JNI en Java: https://www.oracle.com/java/technologies/jni-j2sdk-faq.html
Este es uno de los motivos por los que el kernel de Linux lo enlaza todo desde los códigos fuente.
Por ejemplo, aunque los módulos se cargan dinámicamente, van ligados a una compilación concreta del núcleo. Si no, no funcionan.
Y los módulos que descargamos aparte, se deben compilar durante su instalación a través de DKMS (Dynamic Kernel Module System).
Aquí están los famosos problemas con el driver de NVIDIA, binario propietario, pero con un wrapper/bridge fino que es código fuente abierto y que se compila con DKMS en el momento de instalar el driver.
Muy resumido sería esto:
- C está estandarizado a nivel de lenguaje (ISO), librerías estándar (ISO y POSIX) y llamadas al sistema operativo (POSIX).
Esto es lo que podríamos considerar el API estándar de C.
- Sin embargo no existe estándar a nivel binario: organización en memoria de las estructuras de datos, cómo se realizan las llamadas a funciones y cómo se recuperan los valores de retorno.
Sí, esto es de muy bajo nivel y además existen muchos tipos de llamadas: entre funciones del mismo código objeto, entre funciones de distintos objetos binarios (linkados estáticamente o dinámicamente) y llamadas al sistema operativo (con salto de anillo de protección incluido).
Por eso los interfaces binarios de C dependen de 3 cosas: la arquitectura del procesador, el compilador y el sistema operativo.
Y existen muchas combinaciones (~170 en clang, si no me equivoco).
A esto se le llama ABI.
Por cierto, el estilo de ABI más extendido viene de la PDP11, donde se inventó el C.
- Todo esto sería sólo relevante para los que programan en C, si no fuera porque la inmensa mayoría de librerías de bajo nivel y sobre todo interfaces de sistemas operativos están hechos en C.
Ningún sistema operativo popular ofrece API/ABI para otros lenguajes aparte del C.
Así que cuando otros lenguajes tienen que interactuar con el sistema (pintar cosas en pantalla, capturar teclado o ratón, leer o escribir en disco...), tienen que llamar a código compilado desde C, cuya ABI sigue alguna de las combinaciones arquitectura/compilador/sistema operativo.
Además, de alguna manera, tienen que traducir a APIs de su propio lenguaje (a nivel de código fuente) las cabeceras (.h/.h++) que declaran esas librerías/sistema.
Ejemplos:
- ctypes de Python: https://docs.python.org/3/library/ctypes.html
- JNI en Java: https://www.oracle.com/java/technologies/jni-j2sdk-faq.html
Este es uno de los motivos por los que el kernel de Linux lo enlaza todo desde los códigos fuente.
Por ejemplo, aunque los módulos se cargan dinámicamente, van ligados a una compilación concreta del núcleo. Si no, no funcionan.
Y los módulos que descargamos aparte, se deben compilar durante su instalación a través de DKMS (Dynamic Kernel Module System).
Aquí están los famosos problemas con el driver de NVIDIA, binario propietario, pero con un wrapper/bridge fino que es código fuente abierto y que se compila con DKMS en el momento de instalar el driver.
#24:
Justo ayer tuve que retomar un proyecto en C "pelao" de hace como 10 años, que lo vamos a revivir porque nos viene perfecto para algo que estamos montando nuevo. Compiló en una máquina nueva a la primera perfecto, cero problemas.
Igualito que los ecosistemas modernos, que retomas un proyecto de 6 meses atrás y han cambiado todas las herramientas, las librerías, la versión del lenguaje y básicamente lo tienes que reescribir todo.
Igualito que los ecosistemas modernos, que retomas un proyecto de 6 meses atrás y han cambiado todas las herramientas, las librerías, la versión del lenguaje y básicamente lo tienes que reescribir todo.
#23:
Ahora la culpa es de C y no de que en cada SO se hayan definido unas reglas disintas en su API sobre qué tamaño de datos deben tener los enteros y las direcciones de memoria, que es lo que le incumbe a este señor. Nadie ha obligado (ni a prohibido) a los arquitectos de sistemas que escogiesen libremente distintos tamaños para los tipos, cada uno hace con su libertad lo quiere.
Gracias D. Ritchie, el verdadero padre de la informática moderna, gracias por C y UNIX.
Gracias D. Ritchie, el verdadero padre de la informática moderna, gracias por C y UNIX.
#5:
C es un lenguaje de programación, la aberración se llama C++.
#31:
#15 Ciertas cosas de C++ me dejan grogui. Es que me pierdo y no sé por donde seguir...
namespace parse {
rule
= tok.TheEmpire_ [ _val = EmpireAffiliationType::AFFIL_SELF ]
| tok.EnemyOf_ [ _val = EmpireAffiliationType::AFFIL_ENEMY ]
| tok.Human_ [ _val = EmpireAffiliationType::AFFIL_HUMAN ]
;
">
¿Qué es "rule"?
struct empire_affiliation_enum_grammar : public detail::enum_grammar ;
¿Qué es "detail:enum_rule"?
namespace parse::detail {
struct is_unique {
typedef bool result_type;
template
result_type operator() (const Map& map, const std::string& type, const std::string& key) const {
// Will this key be unique?
auto will_be_unique = (map.count(key) == 0);
if (!will_be_unique)
ErrorLogger()
namespace parse {
rule
= tok.TheEmpire_ [ _val = EmpireAffiliationType::AFFIL_SELF ]
| tok.EnemyOf_ [ _val = EmpireAffiliationType::AFFIL_ENEMY ]
| tok.Human_ [ _val = EmpireAffiliationType::AFFIL_HUMAN ]
;
">
¿Qué es "rule"?
struct empire_affiliation_enum_grammar : public detail::enum_grammar ;
¿Qué es "detail:enum_rule"?
namespace parse::detail {
struct is_unique {
typedef bool result_type;
template
result_type operator() (const Map& map, const std::string& type, const std::string& key) const {
// Will this key be unique?
auto will_be_unique = (map.count(key) == 0);
if (!will_be_unique)
ErrorLogger()
#25:
#18 El artículo está distorsionado en el titular. Se refiere a que C cumple las funciones de lengua franca, de intermediario entre cualquier otro lenguaje de programación y el SO u aplicaciones corriendo sobre él, porque para ello se ha de usar la API de C independientemente de qué lenguaje de programación estés usando en tu programa o en aquellos con los que te quieres comunicar. Y esto es así porque los SO están implementados con C (y ASM).
#1:
Si Rust o Swift se quejan de C, haberse inventado antes que aquél. C no se queja del ensamblador.
Comentarios
Mejor irse a la fuente original y ver que, además del cabreo que ha pillado por los problemas que le está dando, lo que dice es bastante interesante y tiene buena parte de razón.
Del original:
"C is the lingua franca of programming. We must all speak C, and therefore C is not just a programming language anymore – it’s a protocol that every general-purpose programming language needs to speak."
https://gankra.github.io/blah/c-isnt-a-language/
No es cierto que diga que C no sea un lenguaje de programación, lo que dice es que la ubicuidad de C es tal que ya no es sólo un lenguaje de programación, sino que además se comporta como un protocolo de, por ejemplo, comunicación con cualquier SO, de manera que quieras o no te va a tocar meterte con C.
Además, de lo que entiendo del artículo, es que ya que no queda más remedio que pasar por el aro de C, sería bastante deseable que estuviera más estandarizada la manera de hacerlo, porque con la fragmentación de C es realmente complicado hacer que las cosas funcionen de una forma previsible a través de las interfaces.
#14 Pero C no tiene un ISO que todos siguen?
Yo no he tocado C pero que le pasa? En teoria si escribo un programa no lo podría compilar con cualquier compilador, por ejemplo. Entonces dónde estaría la fragmentación?
#37
Pues creo que no.
C es muy dependiente de la arquitectura. Se menciona en la primera parte del articulo, donde se indica los problemas de fragmentacion. Si defines "enteros de 64bits" y la maquina donde compilas y ejectas es de 32 bits pues igual no te compila ni funciona.
#14 #37 Como tú dices, lo mejor es leer el artículo original aunque no esté muy bien escrito (demasiado quejica).
Muy resumido sería esto:
- C está estandarizado a nivel de lenguaje (ISO), librerías estándar (ISO y POSIX) y llamadas al sistema operativo (POSIX).
Esto es lo que podríamos considerar el API estándar de C.
- Sin embargo no existe estándar a nivel binario: organización en memoria de las estructuras de datos, cómo se realizan las llamadas a funciones y cómo se recuperan los valores de retorno.
Sí, esto es de muy bajo nivel y además existen muchos tipos de llamadas: entre funciones del mismo código objeto, entre funciones de distintos objetos binarios (linkados estáticamente o dinámicamente) y llamadas al sistema operativo (con salto de anillo de protección incluido).
Por eso los interfaces binarios de C dependen de 3 cosas: la arquitectura del procesador, el compilador y el sistema operativo.
Y existen muchas combinaciones (~170 en clang, si no me equivoco).
A esto se le llama ABI.
Por cierto, el estilo de ABI más extendido viene de la PDP11, donde se inventó el C.
- Todo esto sería sólo relevante para los que programan en C, si no fuera porque la inmensa mayoría de librerías de bajo nivel y sobre todo interfaces de sistemas operativos están hechos en C.
Ningún sistema operativo popular ofrece API/ABI para otros lenguajes aparte del C.
Así que cuando otros lenguajes tienen que interactuar con el sistema (pintar cosas en pantalla, capturar teclado o ratón, leer o escribir en disco...), tienen que llamar a código compilado desde C, cuya ABI sigue alguna de las combinaciones arquitectura/compilador/sistema operativo.
Además, de alguna manera, tienen que traducir a APIs de su propio lenguaje (a nivel de código fuente) las cabeceras (.h/.h++) que declaran esas librerías/sistema.
Ejemplos:
- ctypes de Python: https://docs.python.org/3/library/ctypes.html
- JNI en Java: https://www.oracle.com/java/technologies/jni-j2sdk-faq.html
Este es uno de los motivos por los que el kernel de Linux lo enlaza todo desde los códigos fuente.
Por ejemplo, aunque los módulos se cargan dinámicamente, van ligados a una compilación concreta del núcleo. Si no, no funcionan.
Y los módulos que descargamos aparte, se deben compilar durante su instalación a través de DKMS (Dynamic Kernel Module System).
Aquí están los famosos problemas con el driver de NVIDIA, binario propietario, pero con un wrapper/bridge fino que es código fuente abierto y que se compila con DKMS en el momento de instalar el driver.
#59 Gracias por la aclaración. Por esto entro en meneame.
#14 Gracias por la aclaración. Por esto entro en meneame.
#14 Pues no estoy del todo de acuerdo. Para mi, la lingua franca es la ABI de cada arquitectura. Claro, esto, así dicho es un oxímoron, pero si RISC-V llega al rescate y se convierte algún día en la arquitectura omnipresente, pues ya estaría!.
Por otro lado, cualquier lenguaje que compile directamente a una ABI tiene la capacidad de "saltarse" C.
C es un lenguaje de programación, la aberración se llama C++.
#5 que bueno, la primera vez que oigo este chiste
#5 Me has tentado en meterte un negativo. Me lo tomaré como
un chiste. De ignorantes, pero un chiste.
#15 Ciertas cosas de C++ me dejan grogui. Es que me pierdo y no sé por donde seguir...
namespace parse {
rule
= tok.TheEmpire_ [ _val = EmpireAffiliationType::AFFIL_SELF ]
| tok.EnemyOf_ [ _val = EmpireAffiliationType::AFFIL_ENEMY ]
| tok.Human_ [ _val = EmpireAffiliationType::AFFIL_HUMAN ]
;
">
¿Qué es "rule"?
struct empire_affiliation_enum_grammar : public detail::enum_grammar ;
¿Qué es "detail:enum_rule"?
namespace parse::detail {
struct is_unique {
typedef bool result_type;
template
result_type operator() (const Map& map, const std::string& type, const std::string& key) const {
// Will this key be unique?
auto will_be_unique = (map.count(key) == 0);
if (!will_be_unique)
ErrorLogger()
#31 Defender el lenguaje != defender el código de alguna peña
P.S: Suerte con lo tuyo!
#31 Joder, te coges de lo mas complicado que puede haber en cualquier lenguaje que es un generador de parsers (boost::spirit) y dentro de eso uno especialmente complicado porque se empeña en hacerlo todo mediante metaprogramacion (que tiene sus ventajas, ojo)
Y esperas entenderlo de primeras cuando das a entender que no sabes C++... pos lo llevas claro , pero en C++ y en cualquier lenguaje
#69 Tal cuál. No tengo problemas con C (con lo que aprendí y trabajé mis primeros años), ni con Python y R que uso para análisis de datos y ploteado de mapas, pero cualquier cosa "moderna" de C++ me deja loco.
#70 Claro, pues eso digo, con ese background te coges lex y yacc (que son bastante mas sencillos ,ojo) y lo intentas entender asi de primeras , sin anestesia.... pues te cuesta
Y lex y yaxx tienen un proposito fijo, lo que se ha usado para spirit son facilidades genericas de metaprogramacion , algo asi como si intentas pillar las macros de lisp sin leer antes sobre higiene , gensym , etc... pues te quedas loco.
Pero vamos que llevo toda la vida con C++ y spirit es de las cosas que ni de coña intento aprender
#5 media humanidad funciona con C++
#5 y Objective-C ya dónde lo dejamos?
#21 Objetivamente hay que dejarlo en el Contenedor de basura mas cercano
#5 esa aberración se sigue preguntando en oposiciones.
#32 Y?
Tambien se sigue usando Metrica3 en la AAPPP y muy util documentacion...
#55 métrica que?
#76
https://manuel.cillero.es/doc/metodologia/metrica-3/
Si Rust o Swift se quejan de C, haberse inventado antes que aquél. C no se queja del ensamblador.
#1 De hecho C y los que usamos C amamos C y el ensamblador, e interactuamos con el de manera suave y placentera.
C es EL lenguaje, lo otro ya...
Yo aprendí con C, y es un lenguaje que le tengo un cariño especial.
Para mí, como dice #3, C es EL lenguaje. He probado otros (la familia .NET, Java, Python, COBOL...) Pero me quedo con C como lenguaje favorito.
#10 mi lenguaje favorito depende del proyecto que necesito implementar
#16 Exacto, cada trabajo requiere su herramienta. Por ejemplo C es ideal para entornos que no requieran portabilidad y si mucha rapidez de ejecución. Cuando diseñando una arquitectura de microservicios dije que para uno en concreto, encargado de comunicaciones con sensores, PLCs, etc. sin base de datos necesaria (era suficiente con datos cargados en memoria y valía un fichero, no precisaba ni siquiera de base de datos en memoria) y con muchas peticiones esperadas al API, propuse C la gente me miraba como a un loco. Al final se hizo en C y a las mil maravillas.
#43 "para entornos que no requieran portabilidad"
Precisamente C se creó para que el código fuese portable. Fijate Linux lo potable que es.
#80 El concepto de portabilidad creo que ha cambiado mucho con los años. De Linux sigues teniendo distribuciones según familias de microprocesador. El código puede ser portable pero has de compilar para tu entorno. El concepto de portabilidad ahora es que incluso me abstraigo no ya solo del hardware sino incluso del SS.OO, me estoy refiriendo, obviamente a máquinas virtuales, lenguajes semicompilados, etc. Desarrollo en windows 64 bits con un x86 y me lo llevo a linux ARM, por ejemplo. Al concepto actual me refiero yo. Está claro que en su día, comparado con ensamblador, era mucho mas portables, eso si.
#83 estoy hablando de portabilidad del código, lo escribes una vez y funciona en múltiples ISAs y sistemas operativos. Este concepto no es nuevo y es la razón por la que existen lenguajes como C que precisamente se creó para que el mismo código fuente se pudiese ejecutar en un PDP-7 y un PDP-11 en los 70, hace más de 50 años.
#16 Mi equipo favorito es el que gane
#10 En realidad alguno de ellos, como Python (al menos en su implantación oficial y mas extendida) corren por debajo C.
#3 Doy por hecho que hablamos de C++, yo aprendí con C pero hace mil años que no lo toco, eso sí C++ a diario.
#48
No, C es una cosa y C++ es otra muy distinta.
Lo que acabas de decir, en algunos ambitos, se consideraria blasfemia y podrian quemarte por hereje. Quemarte con un soldador de estaño hasta morir.
#54 Totalmente de acuerdo, lo del soldador de estaño me parece incluso una muerte demasiado rápida.
C es la paella y C++ es arroz con cosas
#48 C++ es, a dia de hoy, una aberracion, parche sobre parche y un monstruo gigantesco ya. Tengo algo de respeto por Objective C, por ejemplo, por haber hecho las cosas MUCHO MEJOR que C++ en conseguir una POO sin cagarse en C y sin ser un amasijo de parches y locuras que tapan otras locuras.
#48 sólo te queda decir que JavaScript es Java.
#1 Deberían haber dicho "el C no es un lenguaje de programación MODERNO"
#18 El artículo está distorsionado en el titular. Se refiere a que C cumple las funciones de lengua franca, de intermediario entre cualquier otro lenguaje de programación y el SO u aplicaciones corriendo sobre él, porque para ello se ha de usar la API de C independientemente de qué lenguaje de programación estés usando en tu programa o en aquellos con los que te quieres comunicar. Y esto es así porque los SO están implementados con C (y ASM).
#25 Para mí la clave está en la reflexion final del artículo. Si te paras a analizar la pila tecnológica en detalle ves una gran cantidad de elementos que se mantienen por retrocompatibilidad. Me gustan mucho los tweets de devruso sobre el motor gráfico y la gestión de audio en Linux porque ejemplifican lo que pasa cuando se intenta innovar y al mismo tiempo respetar lo existente.
El software libre tiene una fragmentación enorme y sin C el ecosistema no se habría desarrollado. No creo que sea posible inventar un lenguaje desde 0 que sustituya lo que hay, o al menos no es viable sin que haya un equipo muy representativo del sector impulsándolo.
¿Cuánto costaría en tiempo y esfuerzo hacer un nuevo lenguaje y adaptarlo al hardware tan heterogeneo que Linux soporta hoy en día? Y si ese no es el propósito, ¿por qué no lo escriben para la tecnología que ellos quieren impulsar?
Un ejemplo de cambio sin compatibilidad: Google ha hecho esto con ChromeOS. Imaginad el esfuerzo económico para lograrlo. Cada vez que trabajo con un chromebook pienso que Linux debe olvidarse de popularizarse en escritorios del hogar: es rápido, sencillo, fiable, económico... a la larga, ChromeOS ocupará un espacio importante dentro de la cuota de Linux y Windows. (Nota para puristas: sí, hay iniciativas para ejecutar ChromeOS en equipos no chromebook, pero ninguna destaca y varias han muerto en el camino).
Pero algo así, reescribir un SO con un lenguaje nuevo y tal, o eres talibán y te centras en un nicho con una inversión fuerte o es inviable. Así que me parece que las reflexiones pueden ser interesantes para un debate y poco más.
#34 ¿pero chrome os no está basado en linux? pensaba que si la verdad.
#39 Sí, lo está. Lo que quiero decir es que linux no es per sé compatible universalmente, te tienes que currar los drivers.
Lo que Google ha hecho ha sido cerrar especificaciones hardware no sólo para optimizar el rendimiento sino asegurar el mantenimiento de la plataforma de manera universal y evitar/paliar la fragmentación de ChromeOS
#75 los drivers te los tienes que currar con cualquier sistema operativo
#34 ¿Quién es el dev ruso? Me come sanamente la curiosidad.
#72 Este es su perfil:
.Los hilos que comento son estos:
* Audio -
* Gráfico -
#74 Ahhhh jajajajaj creia que era un dev ruso por ahí que se llama Dimitri.
#1 C es ensamblador maquillado. Jajaja
Justo ayer tuve que retomar un proyecto en C "pelao" de hace como 10 años, que lo vamos a revivir porque nos viene perfecto para algo que estamos montando nuevo. Compiló en una máquina nueva a la primera perfecto, cero problemas.
Igualito que los ecosistemas modernos, que retomas un proyecto de 6 meses atrás y han cambiado todas las herramientas, las librerías, la versión del lenguaje y básicamente lo tienes que reescribir todo.
#24 no quiero saber q pasaroa con un proyecto moderno de JS q hubiera q levantarlo 10 años despues
9000 dependencias no encontradas
Es q ni lo intentaria...
#28 solo 9000? Que es un hola mundo?
Ahora la culpa es de C y no de que en cada SO se hayan definido unas reglas disintas en su API sobre qué tamaño de datos deben tener los enteros y las direcciones de memoria, que es lo que le incumbe a este señor. Nadie ha obligado (ni a prohibido) a los arquitectos de sistemas que escogiesen libremente distintos tamaños para los tipos, cada uno hace con su libertad lo quiere.
Gracias D. Ritchie, el verdadero padre de la informática moderna, gracias por C y UNIX.
#23 Yo amo y odio a partes iguales al bueno de Ritchie.
Como jefe de desarrollo de Lucent Technologies produjeron auténticas mierdas que a día de hoy sigue habiendo que mantener y que desgraciadamente nos van a sobrevivir a todos.
#40 que bueno el be a pointer my friend
C es el único y verdadero lenguaje. Todos los demás son superfluos (excepto Javascript, que es útil como ejemplo de cómo no hacer un lenguaje de programación)
#7 Yo lo único que hice fue fue aprobar un examen hace 26 años o así en el cual definí todo de pm, sus procedimientos y funciones y casi al final me di cuenta de q no había definido el programa principal . Esos cinco minutos me dieron el 5 final. Con su dispose y todo Yeah!
#8 cierto, en Pascal las funciones que no devuelven nada se llaman procedure.
#9 Es muy habitual en ciertos lenguajes distinguir de funciones y procedimientos. Lo hacen que yo sepa Pascal, Ada y Basic.
#36 nunca programé en Ada, y en Basic hace 30 años.
En los lenguajes más comunes a día de hoy no he visto esa distinción en ninguno, ni siquiera en los antiguos como C. Pensaba que era una peculiaridad de Pascal.
#47 Ya, pero es que hoy en día la mayoría de lenguajes se basan en C. Su sintaxis es tipo C. Por lo tanto copian las peculiaridades de C y que todo sean funciones, devuelvan o no un valor.
Piensa que en C y derivados, realmente siempre se devuelve un valor None/null/void.
En Pascal/C/Basic los procedimientos no devuelven nada, ni un None/null/void. Es decir, no puedes hacer esto con un procedimiento:
Procedure PrintScreen(text) do
begin
print(text);
end;
res = PrintScreen("Some text")
Esta asignación haría que el sistema petara.
En C, aunque no te devuelva nada, la puedes hacer porque todo son funciones.
La sintaxis es posible que sea errónea, hace 20 años que no he tocado Pascal o Ada.
En VB/VBA tienes el sub/function. Si declaras un sub, no puede devolver valores.
#49 tienes razón en que mayoritariamente se basan en C, pero no todos. Por ejemplo Python tampoco distingue esas cosas. Go tampoco, y no sé si este último se puede considerar basado en C (el criterio es algo subjetivo).
Efectivamente, la sintaxis está mal porque has puesto la asignación en C. Te faltan los dos puntos. ¡Aún me acuerdo y hace mil años que no programo en Pascal!
#51 Python tiene inspiración de C, es una de sus influencias.
Y cierto, la asignación es :=. Se me olvidó. Es que actualmente mis lenguajes más habituales son Python, a veces VBA de manera forzada y Javascript, y todos asignan con solo =.
#53 bueno, puede que influencias tenga; pero no diría que está basado en C. No encuentro que tenga apenas ningún parecido, personalmente.
#63 Está influenciado pero no está basado en C. Basado es más Algol y cosas así. Su sintaxis es muy propia.
Simplemente, ha cogido alguna idea de C, y otros lenguajes. Pero como bien dices no está basado en ese lenguaje. Y lo de que todo sea funciones podría ser una influencia de C (que realmente son todo objetos, una función es un objeto).
#63 Según lo mires es muy absurdo decir que está basado en C, por una parte tiene sentido, pero otra tampoco es cierto. Las ideas en las que se basan los lenguajes de programación han ido evolucionando y refinándose, igual que los seres vivos en la evolución, algunos de ellos son referentes importantes pero esas ideas tampoco son exclusivas.
Linus torvals opina lo mismo... Los amantes de la eficiencia también.
C no es un lenguaje de programación, es un tipo de vitamina
Pues yo creo que el titular y la entradilla están mal.
Core dumped
Why do Python developers wear glasses? Because they don't C.
Y turbopascal?
#2 Ese si es un lenguaje, con tanto "do begin"
#4 Hay que liberar memoria a manopla, es casi lo único de lo q me acuerdo. Y definir todas las variables... npi
#6 dispose, que es como free en C.
#4 Peor es ADA. Como odiaba Ada en fundamentos de programación.
Alguien de Baleares de promociones de finales de la década de los 2000 o principios del 2010 me podría decir que lenguaje de programación se da ahora en Fundamentos?
Anda, no es un lenguaje de programación, como el HTML 😂
Segun lo entiendo, no veo que sea tanto una limitación del lenguaje en si, como que sobre él toda la industria ha cargado las excepciones necesarias para que no se rompa la interacción entre las distintas capas de software por encima de cada ISA que existe.
"La causa originaria de las vulnerabilidades Spectre y Meltdown radica en que los arquitectos de procesadores no estaban tratando de construir procesadores rápidos, sino procesadores rápidos que exponen la misma máquina abstracta que un PDP-11"
Soberana estupidez. ¿De qué longitud eran las pipelines de la ALU del PDP?
Y ¿Cual es el problema?
Leyendo los comentarios cualquiera pensaria que meneame es un laboratorio de computacion del MIT.
Este señor se dedica a crear lenguajes de programacion. Por lo que haciendo una analogia el seria un programador y nosotros seriamos usuarios.
Yo no entiendo mucho de hacer lenguajes, compiladores y como los programas interactuan a bajo nivel con el SO. Se lo basico que se da en la universidad y por eso digo que que no se casi nada.
El titular y parte del articulo esta claro que va por el clickbait y para generar polemica.
Por un lado habla de la fragmentacion del lenguaje. Lo que dice me parece correcto. La creacionde C parate de otras premisas que los lenguajes de alto nivel.
Despues aborda el hecho de ser o no ser un lenguaje de bajo nivel. El no dice que no lo sea. Lo que dice es que es algo mas. Si no he entendido mal habla que C seria como el ingles o el dolar del mundo actul. Por que? Porque los SO estan implementados en C y al estar implementados en C quieras o no quieras cuando haces un lenguaje o compilar al final lo tienes que traducir a C para que tu programa y el SO se entiendan. Quizas este equivocado pero eso no me parece descabellado.
El tema de lo de la maquina PDP11 si que me ha dejado fuera de juego. No tengo ni idea y me gustaria saber si hay alguien experto que nos aporte luz a este asunto.
C es un gran lenguage para susurrarle cosas dulces al oido al hardware.
Lo llama lengua franca estandar y al mismo tiempo dice que esta terriblemente fragmentado. Menuda contradiccion
#26 pues como el inglés, y aún con problemas puntuales pero nos seguimos entendiendo
#_9 Porque no son funciones al uso son procedimientos.
Pues mira que me gustaba C, pero es un lenguaje ya desfasado. Y eso se nota en muchas cosas.
Ahora me entero de que c se ha considerado de bajo nivel de toda la vida. Lo que no dicen es de la vida de quien...
C es dios coño! jejejeje, los problemas que comentan algunos de que si en un sistema hace una cosa y en otro sistema hace otra no es problema de C, sino de los compiladores que no hagan bien del todo su trabajo, o del sistema operativo que cambie cosas que no debe.
Éste artículo es el motivo por el que evito en Menéame todo aquel contenido que leo previamente en Hacker News: Artículo clickbait de regular traducción obtenido del blog personal de un desarrollador con el que ganar un puñado de visitas. Qué panorama.
#58
Ahi amigo que suerte la tuya que sabes el idioma del conocimiento universal.
Con mi cerebro y mi edad ya me cuenta hasta leer el español.