Envío erróneo o controvertido, por favor lee los comentarios.
Aria Beingessner fue en su momento integrante de los equipos responsables de implementar los lenguajes Rust y Swift, de modo que su opinión sobre el desarrollo de software no es una que podamos descartar sin más miramientos, ni siquiera cuando sostiene en su blog una teoría tan controvertida como la de que "el lenguaje C ya no es un lenguaje de programación". En primer lugar, acusa a C de fragmentación ("C está en realidad horriblemente mal definido debido a sus mil millones de implementaciones") y de tener "una jerarquía de...
|
etiquetas: lenguaje de programación , c , implementació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."
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.
C es EL lenguaje, lo otro ya...
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.
youtu.be/1S1fISh-pag
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."
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.
un chiste. De ignorantes, pero un chiste.
Core dumped
Gracias D. Ritchie, el verdadero padre de la informática moderna, gracias por C y UNIX.
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.
9000 dependencias no encontradas
Es q ni lo intentaria...
namespace parse {
empire_affiliation_enum_grammar::empire_affiliation_enum_grammar(const parse::lexer& tok) :
empire_affiliation_enum_grammar::base_type(rule, "empire_affiliation_enum_grammar")
{
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<EmpireAffiliationType> {
empire_affiliation_enum_grammar(const parse::lexer& tok);
detail::enum_rule<EmpireAffiliationType> rule;
};
¿Qué es "detail:enum_rule<xxx>"?
namespace parse::detail {
struct is_unique {
typedef bool result_type;
template <typename Map>
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() << "More than one " << boost::algorithm::to_lower_copy(type)
<< " has the same name, " << key << ".";
return will_be_unique;
}
};
template <
typename signature = boost::spirit::qi::unused_type,
typename locals = boost::spirit::qi::unused_type
>
using rule = boost::spirit::qi::rule<
parse::token_iterator,
parse::skipper_type,
signature,
locals
>;
...
Me voy pa mi casa.
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.
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?
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?
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.
P.S: Suerte con lo tuyo!
Soberana estupidez. ¿De qué longitud eran las pipelines de la ALU del PDP?
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.
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.
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!
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 =.
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.
Tambien se sigue usando Metrica3 en la AAPPP y muy util documentacion...
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.
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: docs.python.org/3/library/ctypes.html
- JNI en Java: 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.
C es la paella y C++ es arroz con cosas
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.
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.
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).
Y esperas entenderlo de primeras cuando das a entender que no sabes C++... pos lo llevas claro , pero en C++ y en cualquier lenguaje
Los hilos que comento son estos:
* Audio - twitter.com/devruso/status/1483726769282813956
* Gráfico - twitter.com/devruso/status/1457641774705434625
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
manuel.cillero.es/doc/metodologia/metrica-3/
Precisamente C se creó para que el código fuese portable. Fijate Linux lo potable que es.
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
Por otro lado, cualquier lenguaje que compile directamente a una ABI tiene la capacidad de "saltarse" C.