Todos saben que no hay nada más estúpido que discutir "qué idioma es mejor". Por ejemplo, ¿mejor para qué? Diferentes idiomas tienen éxito en diferentes nichos, y no tiene sentido sacar conclusiones definitivas sin tener en cuenta esto.
Pero, ¿qué sucede si recurre a especialistas experimentados que ellos mismos entienden todo esto y les pide que arreglen el holivar C ++ vs C #? Resulta que puedes encontrar muchos detalles interesantes. La palabra "multiplataforma" se puede aplicar de ambas maneras a ambos idiomas, pero ¿qué significa esto en la práctica? ¿C ++ se está desarrollando activamente ahora? ¿C # ha roto alguna vez la compatibilidad con versiones anteriores? Las respuestas pueden ser obvias para aquellos que ya están profundamente inmersos en ambos idiomas a la vez, pero hay pocas de esas personas, y todos los demás aprenderán algo nuevo.
De C ++,
Sergey sermp Platonov , Presidente del Comité del Programa de la Conferencia
C ++ Rusia , participó. El lado C # estuvo representado por
Anatoly Kulakov : está incluido en la PC de la conferencia
DotNext y entre los líderes de
DotNetRu . Y el líder de la discusión, en la vida en la que coexisten ambos mundos, fue
Dmitry mezastel Nesteruk .
Dmitry: Buenas tardes, colegas. Bienvenido a reuniones informales sobre el tema de los lenguajes de programación. En Internet se nos recuerda constantemente que los idiomas no se pueden comparar. Y hoy haremos exactamente lo que no puede hacer: comparar C ++ con C # y .NET, sus ventajas y desventajas. Preséntate por favor.
Anatoly: Mi nombre es Anatoly, y hoy me ahogaré por C #, porque he estado estudiando este lenguaje desde sus primeras versiones y, al parecer, sé todo sobre él.
Sergey: Hola, mi nombre es Sergey, hoy me ahogo por C ++. Dima dijo correctamente que compararemos los pros y los contras. Todos lo llaman "Pros", se sabe que, resulta que C # en esta discusión será un signo negativo. ¿Es eso cierto, Anatoly?
Anatoly: ¡ C # tiene dos ventajas más! Por lo tanto, creo que este es un desarrollo evolutivo de las ventajas que ya son obsoletas y que no pueden competir en casi ningún lugar.
Educacion
Dmitry: Tengo el primer tema para nuestra discusión. Imagine que los nuevos estudiantes vienen a la universidad, necesitan el primer idioma. ¿Cuál crees que debería ser el primer idioma que las personas obtienen en su primer año: C ++, C # o ensamblador en general?
Sergey: Enseñé durante algún tiempo, así que tengo una opinión establecida. Entiendo que aquí vamos a discutir qué lenguaje es mejor, y defiendo C ++ ... Pero para aprender C ++, necesitas entender la arquitectura de la computadora. Y con esto, el gran problema de enseñar a los estudiantes (al menos en la universidad donde enseñé). Y para enseñar algoritmos y otras cosas, probablemente necesite algo que no se centre en la infraestructura, en el lenguaje mismo. Aquí Eiffel intentó hacer esto, pero también hay mucha magia. Por lo tanto, diría que ninguno de nuestros dos idiomas es adecuado.
La programación es diferente, y no es la "programación" la que enseña, sino los algoritmos, las estructuras de datos, etc. Es posible que tenga sentido elegir su propio instrumento en cada tema. Comprender algún tipo de estructuras de datos de Lisp. Y C ++, en consecuencia, debe administrarse después de que los estudiantes entiendan algo sobre arquitectura. Y entonces será posible entender por qué todo este dolor y sufrimiento. Ni siquiera argumentaré que las ventajas son sobre el dolor.
Anatoly: Sí, estoy completamente de acuerdo en que necesitas separar los objetos, no ponerlos en "programación" y martillar todo en un idioma. Pero si llega al punto en el que aprendió los conceptos básicos, los fundamentos, los algoritmos y comienza a elegir algún tipo de lenguaje industrial, entonces, por supuesto, C # será mucho mejor. Porque no te obliga a aprender todo esto a nivel de arquitecturas, bytes de memoria y otras "puestas de sol a mano". Ofrece un lenguaje inmediatamente comprensible, una sintaxis simple, y en este idioma desde el primer o segundo año puede ganar dinero bastante tangible.
Dmitry: Hay un argumento de que no darles a los estudiantes principiantes algunas cosas como punteros es una especie de sacrilegio. Tendrán un gran agujero si una persona no comprende que, por ejemplo, un enlace es en realidad solo la dirección de una variable en la memoria. ¿Qué opinas sobre esto?
Anatoly: hace 20 años, esto era cierto cuando las computadoras no tenían suficiente memoria, ni suficientes discos y otras cosas. Ahora mire estos javascripts, arrastran 500 megabytes de bibliotecas a cada "hola mundo". ¿Cuánto llevan en la memoria? ¿Cuál es su desempeño? ¿Cuáles son los enlaces allí? Sí, a nadie le importa. Lo principal es rodar rápidamente y lanzar algo en producción. No pretendo que esta sea una buena o correcta manera, sostengo que es necesario cambiar junto con las realidades. Tal vez ahora no sea tan importante cuánto tarda tu enlace.
Sergey: Probablemente dependiendo de dónde. Dmitry, por lo que yo entiendo, estaba interesado en el comercio algorítmico: puedo imaginar vívidamente cómo saca las bibliotecas de JS para enviar una orden al intercambio.
Dmitry: Bueno, sí, por supuesto, en la práctica nadie usa idiomas de este tipo allí. Aunque en teoría esto puede ser posible: no olvidemos que no se arroja dinero débil a la infraestructura de JS. Motores que hacen que la compilación JS se convierta en cualquier cosa. Muchos consideran este lenguaje como el lenguaje de primera clase para todo en general.
Naturalmente, algo de comercio es ahora una disciplina remota de dicha disciplina, pero algo de comercio y matemáticas financieras en general es un área específica. Simplemente predomina C ++. Y predomina en parte debido a la inercia, simplemente por razones históricas: al principio todos estaban en C ++, y esta área es conservadora.
Sergey: no estoy de acuerdo. Ahora trabajo en fintech, y mis colegas que han estado aquí desde el comienzo del comercio algorítmico hablan de grandes empresas que escribieron por primera vez en Java. Al principio, Java se enfrentó al comercio algorítmico, pero cuando el mercado comenzó a crecer y aparecieron los competidores con C ++, en algún momento simplemente no pudieron hacerlo, no lograron hacer todo de manera eficiente ... Así que no todos en el comercio algorítmico comenzaron con C ++. Solo aquellos que no escribieron sobre él murieron. Una selección tan natural.
Dmitry: En realidad, puedes tomarlo más ancho. Hay muchos ejemplos en los que incluso los grandes bancos mantienen sus algoritmos en un documento de Excel. Luego usan Excel también como servidor para calcular todo esto. Hay frenos infernales, pero todo depende de si está haciendo operaciones de alta frecuencia (o generalmente algo de alta frecuencia). Si usted es un creador de mercado, es natural que necesite un alto rendimiento, y allí el negocio ni siquiera se limita a C ++, allí vamos a los lenguajes de hardware y HDL.
Pero nuestra discusión no es solo sobre el comercio algorítmico, sino también sobre cosas simples. Aquí les doy un ejemplo. En relación con la construcción, necesitaba escribir varias aplicaciones pequeñas que calcularan cosas diferentes: por ejemplo, cómo colocar ladrillos alrededor del contorno de una casa. Y apenas puedo imaginar cómo hacer tales cosas en C ++, porque todo lo relacionado con la interfaz de usuario es más débil allí. Solo hay un marco, Qt, e incluso escribir sobre él es muy difícil. Y si me siento para C #, para WinForms, entonces instantáneamente hago la aplicación.
Anatoly: Bueno, la parte visual siempre ha sido una fortaleza de C #. Microsoft invirtió mucho en moldes, e incluso en moldes multiplataforma, y en general en visualización. Por lo tanto, si estamos hablando de aplicaciones de escritorio visual, entonces me parece que las ventajas generalmente están muy, muy por detrás.
Sergey: Bueno, depende, como siempre. Realmente no me gusta la interfaz de usuario, pero en las ventajas tengo que hacerlo constantemente. Parecería traer JS e interactuar con los profesionales. Pero trabajé con incrustado, y ahí es difícil. La gente compró algún tipo de motor rápido y costoso, pero aún no podía hacer frente a la representación normal de la IU escrita en JS. Y después de reescribir todo esto en Qt, resultó ser overclock. Historia ordinaria
Multiplataforma vs multiplataforma
Sergey: quería aclarar aquí. No sé mucho acerca de C #, lo toqué yo mismo hace mucho tiempo, en las primeras versiones (en ese entonces estaba roto la compatibilidad con versiones anteriores). Entonces la pregunta es: ¿todavía está siendo desarrollado solo por Microsoft?
Anatoly: No, ahora es multiplataforma, abierto y verificado bajo ISO (ECMA-334 e ISO / IEC 23270). Por cierto, hasta donde yo sé, C ++ todavía no tiene una especificación ISO abierta, solo paga. Y C #, por el contrario, está completamente abierto. Desarrollado por muchas compañías (incluidas Google, Amazon y Samsung), tenemos la
Fundación .NET . Ni siquiera conozco un lenguaje más abierto ahora que C # y su plataforma .NET.
Sergey: Bueno, Haskell.
Anatoly: Por cierto, el autor de Haskell trabaja en Microsoft Research e hizo muchos esfuerzos para hacer que todo tipo de cosas geniales aparezcan en C #, por ejemplo, una comprobación estática, algún tipo de reflexión, con la que probablemente ni siquiera puedas soñar.
Sergey: Pueden soñar, e incluso el trabajo continúa en esta dirección. Pero está claro que todo tiene su propio precio. En C ++, simplemente se niegan a pagar este precio.
Anatoly: ¿Cuál? Se compilan durante dos horas, ¿cuál más podría ser el precio?
Sergey: En C ++, el principio de abstracción de costo cero. Bueno, es decir, una máquina virtual no es una abstracción de costo cero, ¿verdad? Tenemos que aguantar esto.
Dmitry: Bueno, pero una máquina virtual puede, por ejemplo, ocultar código para una arquitectura en particular. Mientras que en C ++, si uso la instrucción AVX en una computadora sin AVX, mi proceso simplemente se cierra. Diría que este argumento no es del todo correcto, porque teóricamente, enfatizo, teóricamente, JIT puede hacer lo que C ++ no está disponible. A saber, optimización en el momento del lanzamiento.
Sergey: Pero en C ++, durante la compilación, puedes controlar completamente las instrucciones que necesitas. En este caso, no lo controla con las manos, pero abandona el instrumento (compilador). Mire, qué instrucciones hay en esta arquitectura, qué conjunto de instrucciones ...
Dmitry: Esto es comprensible. Pero puede formularlo de esta manera: dado que hay un millón de plataformas, nunca obtendremos ningún tipo de ideal, porque no podemos lanzar un millón de versiones con diferentes indicadores de compilación. Derecho? Generalmente lanzamos x86 y x64, pero no lo desglosamos en algunos subgrupos.
Sergey: ¿Por qué no podemos? Siglo XXI. Mantenga Docker con diferentes parámetros, eso es todo.
Dmitry: cuando tenemos un cliente final que descarga nuestra aplicación, quiere descargar un binario específico. Y en este binario, lo mejor que podemos hacer es pegarnos en todas partes si. Como "si cpuid es regular y el soporte avx es regular, entonces usamos el algoritmo versión 25". Como resultado, necesitamos 25 versiones diferentes del mismo algoritmo, porque la aceleración depende de las plataformas, depende de la plataforma.
Sergey: Probablemente estoy de acuerdo. Es solo que, para ser honesto, nunca he creado un producto no interno. Estoy principalmente en empresas que utilizan su producto.
Dmitry: Bueno, por supuesto, la mejor opción es cuando conoces de manera predecible la arquitectura. En este caso, estrictamente hablando, nadie te obliga a usar las instrucciones x86. Puede tomar una tarjeta específica (por ejemplo, Nvidia Tesla) y hacer lo que quiera. Este es mi enfoque también, yo controlo mi arquitectura. Pero cuando toma decisiones de mercado masivo para el usuario ... Si toma un ReSharper condicional, él no puede simplemente tomar y usar la aceleración de GPU para cualquier índice arbitrario. Porque la aceleración de GPU no es algo portátil.
Sergey: En realidad, hay enfoques (ahora probablemente no necesites entrar en detalles), hay tipos interesantes (el autor del enfoque, al parecer, ahora también se mudó a Microsoft). Aquí, en nuestra conferencia el año anterior, hubo un
informe sobre cómo escribir un programa de este tipo, que comprenderá en qué consiste (relativamente fácil, de nuevo, abstracciones de costo cero). Para que pueda elegir sobre la marcha y, en todo caso, reconstruir correctamente el código en un estilo CUDA ...
Dmitry: En realidad, CUDA está tratando de resolver este problema, porque en CUDA hay una cierta capa intermedia de
PTX que se ocupa de esto. Pero esto sigue siendo muy difícil, porque el hierro está cambiando radicalmente evolutivamente, y es muy difícil mantenerse al día. Y si observamos el uso de la aceleración de GPU, por ejemplo, en productos de Adobe, entonces utilizan una sección muy limitada de tecnologías disponibles. Si su tarjeta es correcta, entonces sí, todo lo será. Pero si es un poco exótico, nada está garantizado a este respecto.
Anatoly: En esta discusión, tocamos un tema bastante importante, un mito: C ++ fue declarado hace muchos años como un lenguaje multiplataforma, pero en este momento multiplataforma está mucho más en C #. Uno y solo binario funciona en todas partes donde se admite .NET, y esto es casi en todas partes.
Sergey: Bueno, esto también es bastante infundado. Como una persona que pasó la mayor parte de mi vida en incrustaciones, rara vez vi que .NET fuera compatible con la cadena de herramientas del fabricante del hardware. Las empresas que producen hierro toman el mismo G ++ o Clang o hacen que comience a generar código para su plataforma.
Dmitry: Sí, pero el problema es que cada vez que hacen esto, pierden algo de C ++. Por ejemplo, Nokia usó una variación de C ++, pero su C ++ tenía giros extraños y API locos que enfurecían a todos. Es decir, no es solo C ++, sino C ++ para una u otra plataforma. Y entonces comienzan los problemas. Por ejemplo, tome el mismo CUDA. Es como si simplemente dejara pasar a los profesionales por sí mismo; no es un compilador en absoluto, sino solo un controlador. Pero a pesar de esto, tiene dudas sobre el hecho de que todavía usa algún tipo de marco para dividir archivos CUDA en partes de GPU y CPU. Y a veces ella no tiene éxito.
Sergey: No quise decir eso un poco. Es solo que cuando escucho ".NET se ejecuta en todas partes", la mayoría de mi biografía de trabajo retrocede. Cuando compra una pieza de hardware con un procesador personalizado, solo viene incluido con la entrega de G ++. Y hay C ++ ordinario, que G ++ puede convertir de la cadena de herramientas en código de máquina compatible con este procesador en particular.
Dmitry: Pero de nuevo, esto debe ser reensamblado ...
Sergey: por supuesto.
Dmitry: Y la idea de que tomemos un código plus existente y lo arrastremos a una pieza de hierro; esta idea tampoco funciona, porque de repente arrastraste tu x86 normal a alguna parte, donde tienes 8 gigabytes de memoria para todo sobre todo, y no es expandir: por ejemplo, no hay intercambio en disco, porque no hay disco y acceso a él. Esto es si estamos hablando de portabilidad. Depende de los objetivos, naturalmente.
Anatoly: los profesionales trabajan en más dispositivos y, por supuesto, incrustar es una de las partes más fuertes. Pero generalmente tiene que adaptar de alguna manera su código a la plataforma. Esto es malo Puedo cubrir una gran cantidad de plataformas, arquitecturas, modelos con un solo código. En las ventajas, tuve que pensar en cada plataforma individual: dónde comenzará allí y en qué condiciones. Y es muy malo, está muy frenando.
Estabilidad, compatibilidad, desarrollo del lenguaje.
Dmitry: También se mencionaron abstracciones de costo cero, pero el problema es que esto tiene un precio enorme. Por ejemplo, en .NET existe un concepto de tipo enumerado y una interfaz IEnumerable. Y para cada tipo, por ejemplo, una matriz, puede tomar y pasar por un iterador. Pero en C ++ no existe tal idea. Debido a la abstracción de costo cero, para moverse por la colección, hay un par de begin () y end (), hay reglas para su trabajo y todo esto es mucho más complicado (especialmente para aquellos que comienzan a programar). Este es un problema directo: cómo moverse por una matriz de la A a la Z.
Sergey: Si entiendo correctamente de lo que estás hablando ... Si solo necesitas recorrer un contenedor de principio a fin, ahora solo escribes, como en Python.
Dmitry: Todo esto es maravilloso. Pero usted, por ejemplo, no usa polimorfismo para esto. No puede decir que aquí tengo una función que recibe un cierto valor, que se enumera a priori. No puede decir que tengo un valor que implementa la interfaz, y esta interfaz tiene un iterador, por ejemplo.
Sergey: ¿ Estamos hablando de qué C ++? Sobre C ++ en general, C ++ del futuro, C ++, que ahora se aceptan como estándar.
Dmitry: Bueno, si en los pros del futuro será ...
Sergey: En C ++ 20, esto ya está ahí. Ya puedes decir, incluso puedes declararte. Estas no son interfaces, pero, cómo decirlo correctamente ... En general, puede declarar que su tipo debe cumplir tales condiciones. Por ejemplo, tiene inicio y fin, que devuelven un iterador. Y un iterador es un concepto tan preparado en la biblioteca estándar. Él dice lo que es, describe. Los iteradores también son diferentes. En general, lo intentamos, lo hacemos más conveniente para las personas.
Dmitry: Me parece que esto surgió del hecho de que la gente se dio cuenta de que es difícil vivir sin los conceptos de iterable de un objeto. Porque no está claro cómo escribir cosas generalizadas. Sí, la abstracción de costo cero significa que no tenemos el costo de caminar por la mesa virtual cuando buscamos ... En .NET solo hay un método específico, por ejemplo. Y nosotros, para encontrarlo, naturalmente, tenemos que gastar esfuerzos, lo que las ventajas rechazan. Pero desde el punto de vista de la usabilidad, diría que el resultado final no es tan bueno.
Sergey: Naturalmente, debe haber un equilibrio. No puedes tener todo de una vez.
Anatoly: Te hace preguntarte cuántos años han pasado. Los lenguajes alternativos evolucionan, y en ellos aparecen cosas tan básicas desde el principio. Ahora se están poniendo al día con algo más sustancial e interesante. Y las ventajas se sientan durante diez años con la misma sintaxis incomprensible, abstracciones oscuras, muletas incomprensibles y subdesarrolladas. Puedes poner esto como uno de los inconvenientes.
Sergey: Bueno, vamos! ¿Qué significa "pobremente desarrollado"?
Usted mencionó un comité: C ++ también tiene un comité ISO que lo desarrolla. Hay representantes allí, incluido Microsoft, que se ahogó por el hecho de que "no puede hacer esto, porque tenemos mucho legado que debemos apoyar". Solo C ++ es el lenguaje que ya se tiene. Y, por supuesto, camina con mucho cuidado. Una de las tareas principales (que Straustrup ya declaró al crear) es la compatibilidad con C. Pero ahora C incluso ha evolucionado bastante, debe designar con qué C es compatible.
Y en mi opinión, ahora C ++ se está desarrollando a un ritmo tremendo. Con respecto a los conceptos, etc., de hecho, todo crece, por supuesto, no a partir de la iterabilidad. De hecho, el desarrollo sigue lo que Alexander Stepanov también describió: uno de los autores de lo que ahora llamamos "programación generalizada", la persona que realmente arrastró plantillas, genéricos, etc. a C ++. Para ser honesto, no sé cuánto se inspira el comité en estas ideas, pero me parece que definitivamente hay alguna intersección con ellas.
Anatoly: Parece que todas estas metaclases, iteradores son realmente inspiración, lo que ya fue hace muchas décadas. Incluso si toma metaprogramación, plantillas, macros, todas estas personas tienen una larga experiencia, se mueven y hay conceptos mucho más simples, obvios y comprensibles. En otros idiomas, todo esto se hace un millón de veces mejor y más rápido, con seguridad de tipo, verificación de tiempo de compilación, etc.
Sergey: Espera, ya estás hablando de algo por lo que no todos están dispuestos a pagar. No quiero que mi programa verifique algo en tiempo de compilación sin mi conocimiento. ¿Entiendes?
Anatoly: Creo que todo esto con banderas se puede configurar. Establece el nivel de optimización, y lo comprueba o no. Esto no es un problema
Sergey: A menudo necesitas controlar todo con tus manos. Sepa exactamente lo que está pasando. Porque las herramientas ... bueno, eso.
Dmitry: Ni siquiera se trata de herramientas. Aquí el hecho de que lenguajes como D y Rust, digan, digan: bueno, sí, existe tal cosa que cuando accedes a un elemento de matriz, puedes verificarlo, pero no puedes verificarlo. Y simplemente se lo dan al usuario, es decir, puede decir "pero apaguemos las verificaciones de la matriz", "pero enciéndalo". Es decir, algún tipo de control a este respecto.
Sergey: No está claro cuando tienes inseguro y seguro, como en Rust, no veo la diferencia con C, por ejemplo, en este caso.
Anatoly: La diferencia es que puedes escribir de manera segura y puedes escribir rápido. Y en C tienes que escribir peligrosamente. Bueno, sí, quizás rápido. La estabilidad es a veces más importante que la velocidad.
Dmitry: En realidad, si comenzamos a cavar este tema con nuevos lenguajes, en C ++ hay cosas que generalmente son muy difíciles de transmitir a las personas. Una pregunta simple: ¿de qué tamaño es int? En la mayoría de los idiomas, sabes la respuesta a esta pregunta. Usted dice: int es de 32 bits. Pero no sabes los pros. Conoces el tamaño de tu computadora en particular porque lo recuerdas, pero, estrictamente hablando, ni siquiera quieres usar los tipos básicos porque no son deterministas. Y esas cosas me enfurecen cuando hay un conjunto de enfoques heredados como el int será diferente en diferentes plataformas. Y ahora ya entendemos que esto no se puede hacer. ¿Por qué no ir más allá y resolver de alguna manera este problema?
Sergey: Bueno, eso está decidido. Hay
ETS , los tipos necesarios con una longitud fija. Ahora el representante de Rusia en el comité está
arrastrando un int de longitud variable (bueno, de nuevo, con abstracción de costo cero).
Anatoly: ¿Recuerdo correctamente que incluso hay un tamaño no determinista de un puntero a un método? Es decir, bajo diferentes compiladores y diferentes plataformas, ¿los punteros son diferentes?
Sergey: Naturalmente, esto es arquitectura. Cuando está cerca del hardware, ¿cómo puede garantizar el tamaño del puntero, si tiene 8 bits y luego 64 bits?
Anatoly: ¿Y cómo se puede hacer aritmética en punteros después de eso? Esto es una locura
Sergey: quiero decir? Pues con cuidado.
Anatoly: Ya veo. El enfoque es claro en todas partes, controlando cuidadosamente todo con asas.
Sergey: Bueno, si. Una vez más, en los estándares modernos de C ++, se desarrollan enfoques ... Si hablamos de la elección, entonces, en las ventajas modernas, de hecho, existe la opción de usar el recolector de basura. Es solo que GC está construido allí en contadores de referencia.
En general, en sus palabras, colegas, lo siento, siento que no ha actualizado su conocimiento sobre las ventajas modernas durante mucho tiempo.
Ahora, personas como Straustrup, que son parte del panteón de los dioses más, vienen con muchas llamadas para descubrir cómo enseñar C ++ moderno. El problema es lo que la gente piensa en las categorías C ++ de 2003, y enseña en las mismas categorías. Y en relación con esto, hay nuevos proyectos y enfoques interesantes, hay cursos modernos, digamos que los chicos de Yandex han hecho un
curso maravilloso. Y ahora en ventajas se considera de mala educación, por ejemplo, usar puro nuevo y eliminar.
Dmitry: En cuanto a su comentario sobre la actualización del conocimiento ... El matiz es que mi enfoque, por ejemplo, es utilizar el pequeño delta de C ++, que está garantizado que funcione para mí y con el que soy "amigo". Usted ve, C ++ es extenso. Hay metaprogramación de plantillas, y todo estaría bien, hay mucha magia, pero, desafortunadamente, esta magia es ilegible. Este es un código en el que un no autor no puede resolverlo sin ningún conocimiento especial, en cierto sentido, una caja negra. Y hay muchas cajas negras en los profesionales, áreas de oscuridad que no pueden ser digeridas ... Me gustaría, no sé, su opción para que se calcule de manera predecible, bien y sin ningún truco.
El ejemplo más simple es hablar de rangos (
rango-v3 y todo este tema). Por un lado, todo esto es genial: hay cosas que han estado en C # durante varios años, lo que permite, por ejemplo, construir un calendario mediante cualquier transformación de la colección estándar. Por otro lado, la forma en que se implementa en C ++ es simplemente desagradable en comparación con C #: es pesado, no legible.
Sergey: Esto es saborizante. A mí, por el contrario, me gusta. Según tengo entendido, estás en el
informe Nibler y su presentación ...
Dmitry: Verás, cuando el operador "o" se usa para filtrar una colección, inmediatamente tengo preguntas sobre esto. Tanto C # como Java hicieron todo a través del punto, a través de los métodos habituales.
Sergey: Y me parece que esto está inspirado en Bash. Es decir, es solo una tubería.
Dmitry: Bueno, sí, probablemente esto explica algo en este enfoque.
Sergey: ¡ Explica mucho! Hablemos de PowerShell, ya que estamos hablando de Bash. ¿Quién vio PowerShell?
Anatoly: Escribo en PowerShell, un gran lenguaje. Pero nuevamente, la tubería debe insertarse donde está en su lugar, donde toda la arquitectura está impregnada por ella. No es donde necesita hacer una sola acción, y es aquí una sintaxis idiomáticamente mala.
Sergey: En la tubería de rango, es muy ...
Dmitry: En mi opinión, en el rango se usan por la siguiente razón ... Diré esto: si en C ++ hubiera métodos de extensión o funciones de extensión, las usaría, por supuesto. Porque lo más natural si necesita ordenar una colección es escribir "collection. Filter ()". Y no "colección | view :: filter () ".
Anatoly: También tuve la impresión de que te dispararon en las piernas durante 20 años, te golpearon en la cara, te golpearon la cabeza contra la pared y finalmente dijiste: "Bueno, ahora hemos hecho todo muy bien en el vigésimo estándar, ahora enseñemos los profesionales tienen razón ". ¡Sí, nadie quiere enseñarles correctamente! Es decir, es un dolor a largo plazo.
Sergey: Por favor no enseñes. Cual es el problema Escribir en C #: comerciar con él, escribir incrustado. No me importa
Anatoly: Bueno, hay nichos estrechos donde los profesionales siguen ahí.
Sergey: Incrustado es un "nicho estrecho" ... En este momento, mirando alrededor de mi cocina, veo un montón de computadoras.
Dmitry: Cada vez que vuelo en avión, pienso: "Maldita sea, espero que estas ventajas hayan escrito todo bien allí".
Sergey: Bueno, por cierto, hay principalmente Ada, por lo que recuerdo.
Dmitry: Ada domina allí, sí.
Anatoly: Por cierto, recientemente me encontré con
un excelente artículo donde el autor en diferentes idiomas (alrededor de 10) escribió un controlador de bajo nivel: controlador de red para una tarjeta Intel de 10 gigabits. De C a Swift, JS, Python y, naturalmente, C #. Si miramos estos gráficos, que obtuvo, entonces C # en grandes lotes (cuando los costos de lanzamiento están nivelados) va a la par con C y Rust.
Es decir, si hablamos de rendimiento, puede ser un error pensar que C # es muy inferior en alguna parte. También hay un informe funky de Federico Luis
Scratched Metal , donde mostró cómo optimizó el código C # para los perfiladores de procesadores.
Sergey: Bueno, comienza de nuevo. La cuestión es que cuando comienzas a optimizar esa Java, ese C #, no queda claro por qué no escribir en pluses. Porque necesitas un conocimiento específico. Y, como me parece, la ventaja de lenguajes como C # y Java está nivelada, no es un umbral de entrada muy alto. Hasta donde yo entiendo, de lo que Dmitry estaba hablando: legibilidad de código, aprender mucho, difícil de explicar algunos conceptos, etc.
Anatoly: Trabajo el 99% de mi tiempo escribiendo en C # "normal" - seguro, estable y trabajando todo el tiempo. Y el 1% de las veces quiero escribir algún tipo de código rápido de bajo nivel. Y este C # me permite también. Pero mi herramienta principal sigue siendo estable, legible, sin errores ...
Dmitry: Tolya, déjame darte un ejemplo simple: vectorización. Con la vectorización en .NET, todo es muy malo, a pesar del hecho de que System.Numerics.Vectors se está cortando lentamente. ¿Y a qué conduce, por mi parte, por ejemplo? Al hecho de que si estás hurgando en el mercado y comprando una biblioteca matemática para .NET, está escrito en los pros (con un contenedor completo). Debido a que en .NET prácticamente no hay acceso a la aceleración de hardware (AVX, etc.), ahora se encuentra en una etapa embrionaria.
Anatoly: Intrinsics se lanzan en
.NET Core 3 donde puede acceder directamente a AVX. Realmente están allí en su infancia, pero hay cosas básicas, y el resto es bastante conmovedor.
Dmitry: Entiendes, tenemos 2019 en el patio. Como usuario de todo este bien matemático acelerado, no esperé esto. Y como resultado, para mí, si quiero considerar rápidamente algo, C # ya no es un candidato. Porque las bibliotecas C ++ ya existen. Tal vez ya se ha perdido tiempo para esto.
Anatoly: Me parece que C # se está moviendo en la dirección de las ventajas, está tratando de ganar su mercado. Pero las ventajas ya no se mueven a ningún lado.
Sergey: ¿De dónde viene esto? ¿Qué significa "las ventajas no van a ninguna parte"?
Anatoly: Cuando me dicen en 2019 que habrá iteradores en el estándar, habrá algún progreso sobre las lambdas, me parece que ...
Sergey: No sé por qué estás hablando de iteradores y lambdas, no entiendo en qué dirección estaba la piedra ...
Anatoly: No se trata de iteradores, lo puse mal, me refería a los contenedores enumerables que discutimos antes. Y mientras tanto, tenemos coincidencia de patrones.
Sergey: Todo depende de si es necesario o no. Estamos discutiendo la coincidencia de patrones. Pero hasta ahora no hay argumentos sobre si es necesario en los profesionales.
Dmitry: escucho muchos comentarios similares de las ventajas, que dicen que "aunque ya existe una presencia obvia de este o aquel enfoque en otros idiomas, ya se ha resuelto, a la gente le encanta y desarrolla soluciones, todavía no queremos esto en ventajas, porque no se trata de ventajas idiomáticas ". Y me parece que Java cayó en el mismo agujero. Java dijo "no chicos, no tendremos delegados". Y en Java todavía no existe el concepto de delegados, pero en .NET todo funciona bien.
Sergey: Mira, los profesionales son muy simples. De nuevo, de vuelta al comité. Hay un consejo: estas son personas que están desarrollando compiladores. Y para ellos, las palabras "abstracción de costo cero" son exactamente lo que deben guiarse. Y la palabra "legado", por desgracia.
Dmitry: Bueno, la abstracción de costo cero es un ensamblador. Si queremos abstracción de costo cero en general, necesitamos escribir todo en ensamblador.
Sergey: No hay abstracción.
Dmitry: Assembler es una abstracción sobre código binario. Es solo la segunda generación, no la tercera.
Sergey: Entonces, sobre todo tipo de "cosas convenientes", resulta que no está claro cómo hacer que funcionen rápidamente.
Dmitry: Déjalos trabajar más despacio. La idea con iteradores asíncronos, corutinas, todo esto: en .NET con C #, la palabra clave de rendimiento ya no sabe cuántas versiones funcionan muy bien. Sí, se están construyendo enormes máquinas de estado detrás de escena, solo magia. Pero async / await también construye magia, y en iteradores. Pero todos lo usan, y es realmente conveniente.
Sergey: Las rutinas se suman a las ventajas, hola.
Dmitry: Bueno, sí, se están haciendo progresos. Pero las corutinas aparecen ahora, no hace 10 años.
Sergey: una vez más. Las ventajas son más antiguas y, en mi opinión, la velocidad de desarrollo disminuye con la acumulación de la base de código. Claramente, todo depende de si existe el deseo de mantener el soporte de Legacy. Para los profesionales, esta es una posición de principios. Es decir, el código que escribió en los años 80 ahora está compilado por un compilador moderno.
Dmitry: Sí, pero compila el código que escribió en C # 1.0 con un compilador moderno.
Sergey: Esto no es cierto. Al comienzo de la discusión, dije que llegó una actualización en mis primeras versiones de .NET, y de repente todos los programas dejaron de funcionar.
Dmitry: Tal vez las API que usaste simplemente cambiaron. Aquí debe separar la biblioteca y el lenguaje de programación.
Sergey: No tenía nada, solo C #. Yo era joven, estos fueron los primeros años.
Dmitry: Recuerdo solo un cambio importante, en C # 4: un pequeño cambio en el comportamiento de foreach. Por supuesto, en las versiones 1.x todo podría ser más turbulento, pero ahora definitivamente no estamos en la fase en la que alguien de repente rompe algo.
Anatoly: Bueno, oficialmente Microsoft se adhiere a la posición que monitorea estrictamente la compatibilidad con versiones anteriores, prueba nuevas versiones en una gran cantidad de máquinas y bases de código. Quizás tuviste un error o algo así.
Dmitry: en general, .NET también monitorea la compatibilidad con versiones anteriores, pero la velocidad del progreso ha aumentado tanto C ++ como Java.
Sergey: Me parece que jugó un papel importante, que al principio todo esto fue impulsado por una empresa. Debido a que C ++ estaba originalmente en el comité, y esto es política, todos están tratando de impulsar su decisión, y esto es como una reunión del Senado en Star Wars.
Dmitry: ¿Entonces su argumento es que todos somos rehenes de los comités que no son impulsados por la innovación?
Sergey: El problema es que no eliges una solución que satisfaga a todos. La herramienta está tan ampliamente distribuida que muchas empresas la utilizan. Ustedes las mismas corutinas recordaron: ¿por qué las recibieron tarde? Porque Microsoft, al parecer, no podría estar de acuerdo con Google. Hubo dos implementaciones: no recuerdo quién estaba detrás de stackful y quién estaba detrás de stackless, pero no podía estar de acuerdo. Debido a que ambas compañías son grandes, tienen enormes bases de código que ya contienen una solución, y se niegan a reescribirla.
Dmitry: Desde el punto de vista del lector, uno tendrá la sensación de que lo escupieron desde un alto campanario, porque hay intereses corporativos, están involucrados en entrelazados, y todo esto no parece preocuparle: vaya, lacayos,
"déjenlos comer pastel" .
Sergey: Todo lo contrario. El comité está tratando de elegir para que una persona común no tenga que sufrir. Y a menudo es difícil.
Dmitry: Bueno, puedo decir por mí mismo que no sufriré si el costo cero va directo a algún lado, pero habrá algún tipo de oportunidad flexible para caminar a lo largo del árbol binario e iterar de diferentes maneras sin variables de tiempo. yield, - - — , , , , - .
: , , , , - .
: ,
Boost .
: , . Boost , , , … - . std::string, , . size(), length(), : , - ? - , , . , . , , , . , , , - .
: , , , . ?
: , , «», .
: .
: embedded-, include, ?
: . embedded -.
, , - ? , , . ?
: . 150 . - , . .
: , !
: , Steam, , , 64 . , 150 ?
: , , .
: , -. ? , , , — , zero cost abstractions . -?
: , , , , ?
: , . , , .
: , , , . — , . , . , , . , . -. C.
: . «». : , . , , , . . , .
: , . . , . proposal. .
: , proposal. , « »: , STL , . , - , .
: STL . STL . , , STL — , , .
: , — , ? , greenfield. brownfield development, . — , . — . ?
: , . , , . , . , , . G++ , Clang . .
: , , , . « , A, B». , .NET, . , , , , , ?
: , , . , C++ 2.0. ++C++. , C.
: , . , , . , , , , #include #import - — . , . , , , , .
. , . , , , C# C++, .
: , , 10 . , , , , , , . « », . , .
C# , C++. , C# . , , . , , , , JIT' — , , - ( int). , , , , .
: , , , C# — . , , C++ . , . ( , ) — cutting edge. , UI- C++, , . C# — . C++ , .
, . , , , C++ , , , . , .
, C# Microsoft. , .NET Foundation, , , Microsoft. , .
C++ Russia DotNext . : ?