¿Qué hace que C sea tan popular en la era de la POO? [cerrado]

Codifico mucho en C y C ++, pero no esperaba que C fuera el segundo lenguaje más popular, ligeramente por detrás de Java.

Índice de la comunidad de programación de TIOBE

Tengo curiosidad por saber por qué, en esta era de POO, ¿C sigue siendo tan popular? Tenga en cuenta que 4 de los 5 lenguajes de programación más populares son lenguajes capaces "modernos" orientados a objetos.

Ahora, estoy de acuerdo en que puedes usar OOP en C hasta cierto punto, pero es algo doloroso y poco elegante (bueno, al menos en comparación con C ++, supongo). Entonces, ¿qué hace que C sea tan popular? ¿Es eficiencia? siendo de bajo nivel; La gran mayoría de las bibliotecas que ya existen o algo más?

Algunos factores que contribuyen:

• C es ubicuo. Cualquiera sea la plataforma, C probablemente esté disponible.
• C es portátil. Escriba una pieza de C limpia y se compila con modificaciones mínimas en otras plataformas, a veces incluso funciona de manera inmediata.
• C ha existido por un tiempo. En los días en que UNIX conquistó el mundo, C (el lenguaje de programación elegido por UNIX) compartió su dominio mundial y se convirtió en la lengua franca del mundo de la programación. Se puede esperar que cualquier programador serio tenga al menos algún sentido de una porción de C; No se puede decir lo mismo de la mayoría de los otros idiomas.
• C sigue siendo el lenguaje predeterminado para los sistemas con sabor UNIX y UNIX. Si desea que una biblioteca tenga éxito en tierra de código abierto, necesita razones bastante buenas para no usar C. Esto se debe en parte a la tradición, pero más porque C es el único lenguaje que puede asumir con seguridad en cualquier tipo de UNIX sistema. Escribir su biblioteca en C significa que puede minimizar las dependencias.
• C es simple. Carece de la expresividad de OOP sofisticados o lenguajes funcionales, pero su simplicidad significa que se puede aprender rápidamente.
• C es versátil. Es adecuado para sistemas integrados, controladores de dispositivos, núcleos del sistema operativo, pequeñas utilidades de línea de comandos, grandes aplicaciones de escritorio, DBMS, implementación de otros lenguajes de programación y prácticamente cualquier otra cosa que se te ocurra.
• C es rápido. La mayoría de las implementaciones de C compilan directamente al código de la máquina, y el programador tiene pleno poder sobre lo que sucede a nivel de la máquina. No hay intérprete, no hay compilador JIT, no hay VM o tiempo de ejecución, solo el código, un compilador, un vinculador y el bare metal.
• C es 'libre' (tanto en el sentido de la cerveza como del habla). No hay una sola compañía que posea y controle el estándar, hay varias implementaciones para elegir, no hay problemas de derechos de autor, patentes o marcas registradas para usar C, y algunas de las mejores implementaciones son de código abierto.
• C tiene mucho impulso. El lenguaje ha sido popular durante décadas, por lo que hay una enorme cantidad de aplicaciones, bibliotecas, herramientas y, sobre todo, comunidades, para admitir el idioma.
• C es maduro. El último estándar que introdujo grandes cambios es el C99, y es en su mayoría compatible con versiones anteriores. A diferencia de los lenguajes más nuevos (por ejemplo, Python), no tiene que preocuparse por romper los cambios en el corto plazo.
• C es compatible. La mayoría de los idiomas tienen enlaces para hablar con C. Esto significa que uno puede desarrollar una biblioteca en C usando convenciones de llamadas estándar, y sentirse seguro de que casi cualquier otro idioma puede vincularse contra esa biblioteca. Para nombrar algunos lenguajes populares de uso generalizado: C #, Java, Perl, Python, PHP pueden vincularse contra bibliotecas de C sin muchos problemas.
• C es poderoso: si el lenguaje no puede hacer algo, todos los compiladores populares permiten incrustar código ensamblador que puede hacer cualquier cosa que el hardware pueda hacer. Combinado transitivamente con el punto anterior sobre compatibilidad, esto significa que C puede actuar como enlace entre lenguajes de nivel superior y el "metal desnudo" del ensamblaje.

Siempre tendí a culpar a la popularidad de C por la necesidad de un lenguaje ensamblador universal. Su combinación de especificidad a nivel de máquina, estandarización y portabilidad extrema permiten que C funcione como ese lenguaje ensamblador universal de facto , y por esa razón sospecho que su papel allí continuará indefinidamente.

Debo mencionar que siempre estoy un poco sorprendido cuando OOP se presenta en los cursos de programación como una especie de "modelo final" que es el único punto final posible para una buena programación. Al igual que muchos otros aspectos de la programación, el valor de OOP es un compromiso entre muchos factores competitivos, incluyendo cómo los cerebros humanos organizaron la información, cómo los grupos sociales apoyan el software a largo plazo y, en el caso de la programación orientada a objetos, algunos aspectos bastante profundos de cómo funciona el universo mismo.

Y ese último punto vale un poco más. Lea más si está interesado en una exploración a nivel físico de por qué existen ciertos estilos de programación, cómo funcionan juntos y hacia dónde se dirige el mundo en el futuro a medida que nos expandimos más en tales conceptos ...

Un objeto en física es cualquier cosa que mantenga una coherencia reconocible a lo largo del tiempo. Eso a su vez permite que criaturas simples como nosotros se salgan con la suya representando el objeto usando solo una pequeña cantidad de bits, sin poner en peligro nuestra supervivencia. Pero en términos de física en general, la cantidad de cosas que debe acertar exactamente para hacer que este tipo de simplificación sea fácil y común es notablemente grande. Como humanos, no pensamos mucho en eso porque, francamente, no estaríamos aquí si no fuera cierto.

¿Suena demasiado abstracto? Realmente no lo es. Imagine, por ejemplo, tratar de navegar por el camino a la casa de su amigo si, en lugar de automóviles, se encuentra con campos de plasma que oscilan rápidamente y condensaciones momentáneas de materia que se mueven con un enorme rango de velocidades. Tal escenario podría cortar bastante profundamente en las oportunidades de socialización, ¿sí? Necesitamos objetos, que son objetos, y la existencia de los objetos que nos provee de un nivel enorme y críticamente importante de la simplificación del entorno que nos rodea.

Entonces, regresemos todo eso al software. ¿Qué tienen que decir los objetos en el mundo real sobre los objetos en términos de programación?

Bueno, por un lado, significa que lo que define un objeto "bueno" en el software realmente debería ser si el tipo de datos que maneja respalda o no la idea de persistencia reconocible en el tiempo .

Con la definición, las formas más fáciles de OOP son fáciles de reconocer. Ellos son los que copian un poco al usar solo datos que ya están "adjuntos" o definidos por algún objeto realmente físico del mundo real, como una persona, una casa o un automóvil. Incluso hoy, esta es con demasiada frecuencia la única definición de objetos que las personas obtienen en los cursos de software. Eso es una lástima, porque incluso los programas triviales orientados a objetos necesitan una definición más amplia que esa.

La segunda y mucho más interesante categoría de objetos consiste en lo que llamaré eventos inmortalizados del mundo real . Por "inmortalizado" me refiero a cosas que existen al menos brevemente como una entidad o colecciones bien definidas en el mundo real, pero que luego se dispersan y dejan de existir como colecciones físicamente significativas. Un simposio es un gran ejemplo: el simposio existe por un corto tiempo como una colección decentemente bien definida de lugares y personas. Pero, por desgracia, incluso las mejores conferencias deben terminar, y las partes individuales que las componen pasan a otras actividades.

Pero al usar computadoras y redes, podemos hacer que un simposio transitorio parezca un objeto a largo plazo al capturar y mantener una memoria de él como un objeto de software. Muchas de las cosas que hacemos con las computadoras y las bases de datos equivalen a este tipo de inmortalización de eventos transitorios, en el que, en efecto, tratamos de enriquecer nuestro universo real al capturarlo y extenderlo de formas que no pueden existir físicamente. Por ejemplo, ¿has visto una Pandora real últimamente? Tales capturas y extensiones de piezas del mundo real ayudan a enriquecer y extender nuestras propias vidas, economías y opciones de manera notable. Para mí, este es el corazón de la programación orientada a objetos, el lugar donde ha tenido y continúa teniendo los impactos más notables.

Una categoría final de OOP consiste en objetos que no tienen una conexión cercana a eventos externos, sino que son la infraestructuranecesitábamos apoyar nuestra extensión continua de la realidad usando objetos inmortalizados del mundo real. Aquí es donde puedes descender hasta el (semi) metal de la computadora, creando piezas de realidad persistente que, al igual que los elementos químicos del mundo real, se pueden combinar rápidamente y de manera interesante para construir nuevos mundos internos. La informática móvil ha ayudado a promover el crecimiento de este tipo de enfoque altamente recombinante, uno que de nuevo imita de muchas maneras las características recombinantes del mundo físico. También es difícil: lo que puede parecer una buena opción puede probar con el tiempo haber sido una inesperadamente mala, generalmente porque termina bloqueando la diversidad y la expansión en lugar de apoyarla.

Esta última categoría también señala los riesgos de usar un solo modelo para la programación, ya que al igual que el mundo real, los mundos programados también necesitan procesos que nocorresponden bien a objetos relativamente inmutables. La Tierra está llena de objetos, pero el sol está lleno de flujos de energía altamente dinámicos que, en última instancia, son necesarios para "conducir" los objetos y actividades en la Tierra de baja energía. Del mismo modo, al crear mundos informáticos, hay casos en los que debe lidiar con flujos y transformaciones y contextos que cambian rápidamente que, aunque no son muy parecidos a los objetos en sí mismos, son absolutamente críticos para permitir que los objetos más simples y amigables para los humanos se utilicen en niveles superiores . No es casualidad que gran parte de la programación realizada a nivel del núcleo no sea visiblemente similar a un objeto, o que tienda a depender en gran medida de lenguajes como C que estén más orientados al procesamiento. Estos son los dominios más profundos que complementan la fascinante diversidad que vemos más arriba en los mundos generados por computadora.

La otra área donde OOP puede salir mal es enfocarse demasiado en los viejos conceptos de objetos.

Los objetos en el mundo real, y especialmente los objetos vivos , tienen un nivel de habilidad absolutamente sorprendente para interactuar con sus entornos de formas complejas y sutiles. Los widgets componibles que se miran entre sí, hacen algunas comprobaciones de compatibilidad y cordura, y tal vez incluso descubren algunas formas nuevas de interactuar que se acercan mucho más al concepto biológico real de los objetos que los marcos simples y los esquemas de herencia simples que tendemos para centrarse (¡generalmente por necesidad!) en el nivel de código. Esta es una de las áreas de crecimiento para los objetos en el mundo cibernético, los enfoques más "como agentes" donde la reactividad al medio ambiente es la norma, incluso dentro de la programación misma.

¡Y mucho por mi "crítica" de OOP! Sin embargo, espero haber señalado por qué crear un mundo cibernético más rico significa abarcar la diversidad de estilos de programación, en lugar de asumir que "solo uno" es todo lo que se necesita. ¡Mi sensación es que las cosas realmente interesantes están por venir, no importa cuán mundano sea mucho de lo que hacemos ahora!

En primer lugar, no necesita OOP para todo, a pesar de los dogmas con respecto a esto que se han popularizado. A diferencia de Java, C permite punteros de función e incluso cierres, lo que abre la puerta a la programación funcional y resuelve una gran parte del espacio problemático que maneja OOP, porque proporciona los medios de inyección de dependencia. También el uso prudente de las macros puede crear algunas cosas muy bonitas, como lo demuestra sglib .

De una manera extraña, uno podría ver a C como un buen compromiso entre Java y C ++. Tenga en cuenta que no estoy diciendo que C sea de ninguna manera una mezcla de ambos. Pero en contraste con Java, es un lenguaje bastante poderoso, mientras que en contraste con C ++ tiene una complejidad manejable.

Es un lenguaje antiguo, que se ha vuelto confiable y consistente, mientras que en realidad no se está volviendo más complicado. Y aparte de eso, tiene un ecosistema gigante y simplemente funciona en todas partes.

C tiene una ABI (interfaz binaria de aplicación) C ++ no. Esto hace que C sea más útil que C ++ en ciertos casos. Si voy a escribir una biblioteca y poder enviar binarios para el uso de otras personas, C ++ es la herramienta incorrecta para el trabajo. Si voy a escribir bibliotecas que serán utilizadas por algún otro idioma nuevamente, C es la herramienta adecuada para el trabajo. Nunca he oído hablar de un lenguaje que no sea compatible con FFI (interfaz de función externa) para C, por otro lado, C ++ no funcionará con bibliotecas escritas en C ++ si se utilizan compiladores diferentes.

Básicamente se reduce a C, cumpliendo un rol para el que C ++ no es adecuado.

Una ventaja de usar C sobre lenguajes como C ++ o Java es que no hay mucha magia bajo el capó. No se ejecutan constructores cuando se asignan elementos, y no se ejecutan destructores cuando los objetos salen del alcance. No hay cambio de nombre ni vtables. El rendimiento es más fácil de predecir; no tiene que preocuparse de que un recolector de basura interrumpa una rutina y pierda su tiempo.

Los constructores, destructores, cambio de nombres, vtables, recolectores de basura, etc., pueden aliviar parte de la complejidad del código que usted crea, pero luego esa complejidad se convierte en parte del lenguaje en sí, donde tiene poco o ningún control sobre él . Puede terminar con tiempos de compilación más largos (molestos, pero tolerables), mayor huella de memoria en tiempo de ejecución (puede o no ser tolerable) o un rendimiento más lento. Con C puede eliminar parte de esa complejidad hasta que se quede con la funcionalidad que necesita .

Por ejemplo, el stringtipo de datos C ++ es años luz más fácil de trabajar que las cadenas de estilo C, pero es un código bastante pesado y agrega algo de peso al tamaño de su imagen. Raramente he visto a alguien hacer uso completo de stringlas capacidades de cualquier programa. Las cadenas de estilo C, aunque son más difíciles de trabajar, imponen menos penalización en términos de tiempo de ejecución y tamaño de imagen, y por un problema particular puede ser más atractivo por esa razón.

Los sistemas y controladores integrados generalmente se programan en C. Además de eso, hay toneladas de sistemas C heredados que aún se mantienen y extienden.

Lo mismo que hace que un martillo manual sea popular en la era de los martillos neumáticos (martillos neumáticos): C sigue siendo la herramienta adecuada para ciertos trabajos.

Simplicidad, consistencia y precisión.

Es simple: no necesita un entorno de desarrollo complejo, bibliotecas extensas o una máquina virtual.

Es coherente: la mayoría de los C escritos hace 10 años podrían compilarse hoy.

Precisión: le permite bajar al nivel de la máquina, conociendo las ubicaciones de memoria según sea necesario. Esto es excelente para el rendimiento y el hardware integrado.

No es para todo, pero sigue siendo una herramienta útil.

Cito dos puntos de otra respuesta, porque capturan exactamente las razones por las que todavía uso C de vez en cuando (sin embargo, no es mi lenguaje principal de elección):

• C es simple. Carece de la expresividad de OOP sofisticados o lenguajes funcionales, pero su simplicidad significa que se puede aprender rápidamente.
• C es maduro. El último estándar que introdujo grandes cambios es el C99, y es en su mayoría compatible con versiones anteriores. A diferencia de los lenguajes más nuevos (por ejemplo, Python), no tiene que preocuparse por romper los cambios en el corto plazo.

Creo que esto es muy cierto. Aprendí C durante las primeras noches: era simple, pocas palabras clave y construcciones, la mayor parte del trabajo realizado por las bibliotecas. Entonces no usé C por algunos años. Alrededor de 2002 necesitaba una implementación rápida de un algoritmo, instalé un compilador de C y lo implementé. Conozco el lenguaje, sé para qué es bueno, para qué no es bueno (¡ nunca implementaría una aplicación web en C!), Y está ahí cuando lo necesito. No hay sorpresas.

Con C ++ tuve una experiencia diferente. Lo aprendí alrededor de 1995 y significó un gran cambio de paradigma de imperativo a OOP. ¡Excelente! Lo utilicé para varios proyectos hasta 1999. Durante algunos años no utilicé C ++ y cuando lo retomé nuevamente (2008) encontré muchas características nuevas ya en el lenguaje, y aún más planificadas (mientras tanto, introducido en C ++ 11) Tengo la sensación de que tengo que volver a aprender el idioma.

Como desarrollador, prefiero idiomas maduros y estables. Me gusta aprender un idioma una vez, comprender sus principios de diseño, para qué sirve y usarlo cuando creo que es la herramienta adecuada para el trabajo. También me gusta aprender diferentes idiomas y elegir el idioma que mejor se adapte a mis necesidades (C, C ++, Java, Scala, Haskell, etc.). Lo que no me gusta es tener que aprender el mismo idioma una y otra vez porque se desarrolla cada vez más y nunca alcanza la madurez.

En mi humilde opinión, un lenguaje de programación debe tener un diseño claro, coherente y estable. Me gusta el enfoque de diseñadores como Niklaus Wirth: cada vez que sintió la necesidad de un idioma diferente, diseñó uno nuevo (Pascal, Modula-2, Modula-3, Oberon). No me gustan los idiomas que experimentan cambios importantes cada 5-10 años: son como objetivos en movimiento y nunca siento que valga la pena invertir mi tiempo para aprenderlos en profundidad, porque la versión que estoy aprendiendo ahora probablemente sea obsoleta en unos pocos años de todos modos.

En este sentido, C es un ganador de la OMI: es bueno para ciertas aplicaciones y menos apropiado para otras, pero tiene la ventaja de que es simple y relativamente estable.

Me sorprende que nadie haya mencionado Peor es mejor todavía. Tiene más de 20 años en este momento, pero aún vale la pena leerlo. Aunque a veces es un poco irónico, hace un muy buen trabajo al describir cómo y por qué el expediente a menudo gana al ideal, usando C (enfrentado a LISP) como uno de sus ejemplos centrales.

Probablemente quiera preguntar por qué las personas usan C en lugar de C ++ a pesar del hecho de que cuando tiene un compilador de C, generalmente también tiene un compilador de C ++.

• El lenguaje C es mucho más simple que C ++. No conozco ninguna compañía que use el estándar C ++ completo en su convención de codificación. Eche un vistazo al estilo de código C ++ de Google como ejemplo: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
• C es mucho más rápido de compilar. Gracias a la falta de construcciones difíciles de compilar.

Nada. TIOBE es un índice sin valor. Si realmente observas su medida, es una suposición absoluta, en el mejor de los casos.

Mucho software heredado

Muchas compañías no pueden cambiar, instantáneamente todo su código a C ++ o similar.

Muchas compañías no pueden darse el lujo de cambiar su código.

Muchas compañías pueden darse el lujo de cambiar su código, pero no les importa, o son "baratas".

Muchas empresas están en proceso de migración, pero aún no han terminado.

Orientación de objetos ocultos

(No orientado a objetos) Código fuente C diseñado como código fuente C orientado a objetos, aplicaciones que están modeladas con Orientación a objetos y codificadas con "C puro", o herramientas que se traducen desde "C ++" u otro programa OO. lang en C.

Escuché que algunos videojuegos se hacen de esa manera. Algunas herramientas multiplataforma también, y la biblioteca de interfaz visual GTK (GObject, GLibrary) para las distribuciones GNome Linux OS.

Veo que algunos de los que responden dan por qué C es el más popular, existe desde hace mucho tiempo, está disponible en la mayoría de las plataformas, es gratuito, etc.

Pero lo mismo puede decirse de otros idiomas, por ejemplo, Pascal gratuito: es gratuito y compatible con casi todas las plataformas.

Pascal se inventó alrededor de 1970, C se inventó alrededor de 1972, así que creo que Pascal ha existido tanto tiempo como C.

Personalmente, creo que C es el lenguaje más popular porque solo hay más código de código abierto disponible para ser reutilizado por cualquier persona. Y sí, tiene un nivel más bajo que Pascal, por lo que se está acercando al ensamblaje, pero es mucho más legible que el ensamblaje.

Creo que hay demasiados lenguajes de programación por ahí. Como programadores tenemos que conocer la mayoría de los importantes, pero al final no debería haber necesidad de eso. Se puede implementar un lenguaje de programación para hacerlo todo, desde la creación de sitios web hasta juegos de computadora iOS.

C parece ser ese lenguaje global, pero desearía que fuera algo así como Object Pascal. Por qué Object Pascal, es un lenguaje de programación más legible, el código OOP tiende a ser más reutilizable y menos propenso a errores (en mi opinión) que C.

Las aplicaciones muy grandes son más fáciles de administrar con Object Pascal que C / C ++.

En cuanto a tener un lenguaje de programación que ha sido algunos desde los '70, y no gustarle los idiomas que cambian cada 5 o 10 años. A medida que pasa el tiempo, la tecnología avanza y los métodos de programación mejoran. Si un idioma cambia drásticamente cada pocos años, probablemente su diseñador no lo pensó bien. Pero 1970 a 2012 es casi medio siglo, está bien hacer cambios a un idioma en ese momento para incorporar los avances utilizados en el desarrollo de software.

C se ha revisado varias veces. Entonces, no es mejor que otros idiomas desde ese punto de vista.

Porque C tiene una gran base de usuarios. Sí, es un poco atrapado, pero cuando hago una pregunta sobre C en StackOverflow, obtengo la respuesta casi al instante. La misma pregunta sobre Python podría tardar horas en ser respondida.

Con respecto a C ++, es IMO más complicado de aprender. Además, después de haber probado OOP durante 10 años, creo que no siempre es útil, y muchas veces es más fácil usar la programación de procedimientos.