¿Por qué C ++ sigue siendo "híbrido"?

16

En una pregunta relacionada , se ha aclarado por qué C ++ no es compatible con C en muchos aspectos. Sin embargo, C ++ sigue siendo un lenguaje "híbrido" *. Y desafortunadamente, muchos programadores todavía consideran C ++ como una "C con secuencias y cadenas incorporadas". Eso da como resultado un código escrito realmente malo, que no es ni C ++ ni C. En mi humilde opinión, sería mejor si el lenguaje / compilador obligara en cierta medida a los programadores a escribir código más elegante. Entonces, ¿hay una razón para mantener híbrido C ++ moderno (por ejemplo, C ++ 0x y versiones futuras)?

* Por híbrido quiero decir que depende del programador decidir si usará: cadenas y secuencias estándar, clases, espacios de nombres distintos al predeterminado, etc.

sakisk
fuente
¿Existe alguna configuración de compilador / IDE existente que pueda hacer cumplir esto?
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner No conozco ninguna herramienta que haga eso. Pero tendría más sentido escribir dicha herramienta (compilador, IDE, etc.) si esas características fueran parte de C ++ estándar.
sakisk
2
La razón de ser de C ++ es la compatibilidad con versiones anteriores y la posibilidad de usar todos los trucos sucios que fueron posibles en C. Elimínalo, y es solo otro clon de C #, D o Java. Si querías eso, ¿por qué no solo usar C #, D o Java?
nikie
55
@nikie: Jajajaja. Debido a que las plantillas, los tipos de valor, las referencias fuertes, la destrucción determinista, la herencia múltiple, la velocidad de ejecución, el uso de memoria bajo, esas cosas no existen en absoluto.
DeadMG
2
@nikie: Excepto que D también tiene abominaciones como Objectvalores de copia binarios y matrices asociativas divinas (por qué ...) junto con otras decisiones de diseño cuestionables propias. Además, también tiene el mismo paradigma de GC que los demás, por lo que cuestionaría su bajo uso de memoria.
DeadMG

Respuestas:

26

Sí, hay una fuerte razón: el código C ++ casi siempre tiene que llamar al código C existente. Lo mejor que podemos hacer es facilitar la escritura de un buen código. No hay nada que un diseñador de idiomas pueda hacer para que sea imposible escribir código incorrecto.

Kevin Cline
fuente
1
Claro, pero dado que esto es solo para código heredado, ¿por qué las versiones más nuevas de C ++ deben seguir siendo compatibles? El código heredado aún puede usar una versión anterior de C ++.
sakisk
15
@faif, en mi trabajo escribo nuevo código C ++ todo el tiempo que necesita para interactuar con el nuevo código C. No es solo un problema heredado.
Karl Bielefeldt
55
@faif: las versiones más nuevas de C ++ tienen que ser compatibles con versiones anteriores, no solo para admitir el código C más antiguo, sino también varios cientos de millones de líneas de código C ++ existente. Si desea algo que no sea compatible con versiones anteriores, pero que esté mejor diseñado, puede cambiar a un idioma como D. Por cierto, aquí hay un artículo realmente bueno sobre la necesidad de compatibilidad con versiones anteriores de Joel Spolsky: joelonsoftware.com/items/2008 /03/17.html
Doc Brown
44
The best we can do is make it easy to write good code.- ¿Estamos hablando del mismo C ++?
BlueRaja - Danny Pflughoeft
44
@ BlueRaja-DannyPflughoeft: Me resulta mucho más fácil escribir un buen código en C ++ que en Java o C #. Con C ++, puedo leer una clase y, si todas las demás clases se comportan, sé que no se perderán recursos ni memoria. Con Java y C # no puedo hacer eso; Tengo que ir a inspeccionar las otras clases para ver si alguna de ellas requirió finalización. Las plantillas de C ++ también me permiten SECAR el código que debe repetirse en Java.
Kevin Cline
20

En mi humilde opinión, sería mejor si el lenguaje / compilador forzara en cierta medida a los programadores a escribir código más elegante.

No, no lo haría. En absoluto. Como una demostración trivial de por qué, defina elegante, y luego apuesto a que diez personas llegarán a estar en desacuerdo con usted.

Los estilos de codificación aplicados por el lenguaje son muy, muy malos. Sin mencionar todo el código heredado que se romperá.

En particular, las clases de secuencia y secuencia estándar realmente apestan . std::stringno tiene soporte Unicode y la peor interfaz hinchada que puedas imaginar. Las transmisiones tienen una sobrecarga horrenda y un diseño deficiente, incluso recurren a la herencia virtual, a los punteros de funciones const char*y a feos como ese. No penalizaría a nadie por reemplazar completamente esas dos clases / grupos de clases con otros personalizados.

No usar clases y espacios de nombres está bien para el código de estilo de pizarra, y hay muchas, muchas bibliotecas que proporcionan funciones que no están en una clase. La clase forzada es una muy mala idea.

DeadMG
fuente
+1 para el enfoque algo más realista (cuándo se detendrá la conversación del "código elegante": /
Rook
2
"Los estilos de codificación aplicados por el lenguaje son muy, muy malos". ¿Puedes dar algunos ejemplos? Creo que incluso cosas simples como la sangría de código forzada de Python mejora la legibilidad del código.
sakisk
3
No estoy seguro si estoy de acuerdo con esto. La razón principal para usar CoffeeScript sobre JavaScript es porque CoffeeScript está diseñado para imponer la escritura de código más elegante.
user16764
3
No puedo estar de acuerdo con esto. Algunos diseños de lenguaje están destinados a fomentar las buenas prácticas, y la naturaleza en expansión y atornillada de gran parte de C ++ generalmente lo impide. De hecho, sacrificar el lenguaje, mantener las partes buenas y mejorar el resto es la principal motivación detrás de la existencia de C ++ 11 .
Robert Harvey
1
@Pubby: "Escribir un programa feo que funcione es mejor que escribir un programa hermoso que no haga nada". Claro, estoy de acuerdo con eso. Pero este artículo va mucho más allá y parece argumentar que la fealdad es en realidad una virtud. Y eso es simplemente ridículo.
Mason Wheeler
8

C ++ es un híbrido no porque le permite a uno escribir código de estilo C, sino porque admite varios paradigmas de programación, como procedimientos, orientados a objetos y genéricos. C ++ no te obliga a una sola forma de hacer las cosas, y esa es su fortaleza, porque diferentes problemas pueden resolverse más fácilmente usando diferentes paradigmas.

En mi humilde opinión, sería mejor si el lenguaje / compilador forzara en cierta medida a los programadores a escribir código más elegante.

Entonces primero tienes que definir qué significa elegante . Entonces tendría que ver si su definición de elegante es apropiada para todos los dominios y plataformas problemáticos para los que se utiliza C ++. Un estilo de codificación que sea elegante para escribir un procesador de textos para Windows podría ser completamente inadecuado para escribir un sistema embebido.

Considere escribir código C ++ para ejecutar en un DSP. Primero, el compilador de C ++ para ese DSP puede simplemente no admitir ciertas características de C ++, como las transmisiones. En segundo lugar, la velocidad de la CPU, y posiblemente la memoria, lo limitan severamente, por lo que algunas características de C ++ pueden simplemente afectar su rendimiento. Por ejemplo, es posible que deba evitar las funciones virtuales en aras de la velocidad. Tales consideraciones cambiarían radicalmente su estilo de programación, en comparación con lo que usaría en una PC, y C ++ lo permite.

Para resumir, C ++ es un lenguaje enorme y complicado con muchas características. Hay muchas razones por las cuales cualquier subconjunto de esas características puede no ser aplicable a un proyecto en particular: velocidad, portabilidad, soporte del compilador o incluso experiencia y familiaridad del programador. Por esa razón, el lenguaje para obligar al desarrollador a usar ciertas funciones en lugar de otras para cualquier tarea dada es una mala idea. Piense en Java, donde el lenguaje exige que cada función sea un método de una clase. Hay muchos casos en los que crear una clase solo para ajustar un método es incómodo e innecesario, y sin embargo tienes que hacerlo porque el lenguaje te obliga a hacerlo.

Dima
fuente
1
No podría estar más de acuerdo. Pensaría que cuando alguien dice "C ++ es flexible", lo creo porque admite muchos más paradigmas que C.
Prelic
5

En mi humilde opinión, sería mejor si el lenguaje / compilador forzara en cierta medida a los programadores a escribir código más elegante.

Nadie está obligando a nadie a usar C ++ en primer lugar. Si el idioma no le conviene, utilice uno diferente: hay muchos idiomas facturados como "C ++ sin C".

La filosofía de diseño de C ++ es dejar que el programador decida. Si quieren pegarse un tiro en el pie, entonces déjenlos. Esto permite hacer muchas cosas malas, pero también permite una gran flexibilidad. Por ejemplo, es poco probable que Boost pueda escribirse en un lenguaje como Java, ya que aprovecha las características y prácticas del lenguaje que generalmente se evitan. También es poco probable que C ++ crezca tanto como lo ha hecho hoy en día: tener acceso a la gran biblioteca de C es una gran ventaja, tómalo o déjalo.

La compatibilidad de C ++ con C es definitivamente uno de sus puntos más débiles, pero también tenga en cuenta que es uno de los mejores.


Voy a agregar una cita maravillosa de Jon Purdy que creo que es extremadamente relevante:

Todo se reduce a pragmatismo versus elegancia, y para mí, a pesar de mi obsesión por el código preciso y hermoso, escribir un programa feo que funcione es mejor que escribir un programa hermoso que no hace nada.

Quitar el híbrido puede mejorar la elegancia, pero dificulta la capacidad.

Pubby
fuente
¿Crees que el pragmatismo y la elegancia son contradictorios? Creo que Python, Ruby y Scala son buenos ejemplos de lenguajes que son pragmáticos y elegantes.
sakisk
1
@faif: No, pero la compatibilidad y elegancia anteriores son contradictorias. Esto también se aplica a Python (2.x vs. 3.x).
dan04
4

Si el comité intentara obligar a la gente a usar (la noción de alguien) de un lenguaje más elegante, probablemente sería ignorado. Las personas continuarían haciendo lo que quisieran, y los vendedores de compiladores seguirían el mercado (pero los vendedores de compiladores tienen suficiente representación en el comité para evitar esto).

Gran parte de lo que defiende es realmente una cuestión de juicio, basada en el dominio del problema de todos modos. Hay muchos programas pequeños que simplemente no necesitan espacios de nombres (por ejemplo). Intentar obligarme a usar un espacio de nombres cuando estoy escribiendo un filtro de texto de 30 líneas sería una tontería y arrogancia. Incluso si decidió que solo se aplicaría cuando más de X líneas de código, o funciones Y, o lo que sea que esté involucrado, en general, sería contraproducente. Los espacios de nombres fueron diseñados por una razón, para prevenir / curar problemas específicos. Intentar forzar su uso en ausencia de esos problemas no logra nada útil para nadie.

Al mismo tiempo, creo que vale la pena señalar que algunas personas realmente pasan mucho tiempo y esfuerzo tratando no solo de permitir la elegancia en C ++, sino también de enseñar y guiar a las personas a usar esas capacidades para escribir un mejor código (por ejemplo, muchos contribuyentes de Boost). Como tal, las personas que continúan insistiendo en escribir su código como "C con clases" están ignorando lo que está ahí fuera de todos modos. Creo que se sentirían tan cómodos ignorando nuevos compiladores como ignorando todo lo que se ha aprendido sobre cómo usar C ++ en la última década o más (por ejemplo, Modern C ++ Design se publicó hace 11 años, pero la mayoría de la gente aparentemente estás hablando de que aún no has oído hablar de él, mucho menos leído o entendido, incluso sus partes más simples).

Jerry Coffin
fuente
2

Su idea constituye gran parte de la lógica del diseño detrás de Java. Java te obliga a usar clases, organizar la jerarquía de archivos de acuerdo con la jerarquía de paquetes, capturar excepciones, etc. La gente todavía logra escribir código similar a C en él.

Como programadores, a veces olvidamos que la mejor solución puede no ser técnica. Las revisiones por pares son la solución más conocida en este caso.

Karl Bielefeldt
fuente
0

C ++ no tiene "un camino verdadero"; Cada enfoque tiene fortalezas y debilidades. La solución se puede escribir de cien maneras diferentes.

Usted, como desarrollador de software, debe decidir qué enfoque es mejor para la tarea en cuestión.

Descifrador
fuente
0

Creo que el hecho de que todas esas cosas que enumera sean opcionales crea un potencial para más elegancia, no menos. Una característica utilizada innecesariamente es poco elegante a mis ojos.

Los problemas que necesitamos resolver usando la programación son muy diferentes.
Algunos se resuelven bien utilizando los principios OO (por ejemplo, GUI), otros se prestan mejor a un tratamiento puramente funcional (por ejemplo, material numérico), mientras que otros se expresan mejor en un lenguaje de bajo nivel "cercano al silicio".

Un montón de software necesita resolver subproblemas que se resuelven mejor en cualquiera de esas formas. Forzar la solución a una forma específica solo conducirá a un código que se ajuste menos a su propósito (incluso podría decir "menos elegante").

Es por eso que la hibridación de C ++ es algo bueno : nos permite resolver una gran variedad de problemas de una manera que se adapte al problema , no al dogma actual.
Por supuesto, se puede usar mal, siempre que tenga algo flexible, existe el riesgo de doblarlo mal, pero la elegancia proviene del pensamiento y la experiencia cuidadosos, no de la adhesión a lo que sea que sea la moda del día.

molbdnilo
fuente