retraso - ¿Por qué no está mejorando el lenguaje de programación D?

ejercicios de terapia de lenguaje para niños de dos años (24)

¿Alguien usa el lenguaje de programación D ?

¿Por qué no es más popular?

Antes que nada: la mayoría de los desarrolladores de software con los que hablo al menos han oído hablar de D y lo han conectado mentalmente básicamente a esas propiedades que mencionaste en tu pregunta (generalmente es rápido + la forma en que debería haberse implementado C ++ en primer lugar). Esto por sí solo es un nivel de éxito que el 99 por ciento de todos los lenguajes de programación creados nunca alcanzará.

Sin embargo, hay algunas razones por las que no está en la misma liga con Java / Python / C # / Ruby / etc.

El lenguaje en sí es un sucesor de C ++ muy bien hecho y cuerdo. Pero no es lo suficientemente diferente de otros lenguajes de tipo estático para llamar la atención. Es suficiente para un amigo "ah, eso es realmente agradable", pero no para "¡Caramba! Tengo que usar esto".
No hay una aplicación arriesgada que requiera que aprendas D. Algo con lo que un programador Joe promedio quiere trabajar tan mal que pasa por la molestia de elegir un nuevo idioma.
Los lenguajes de programación dinámicos, como JavaScript, Ruby y Python, se han apoderado de algunos segmentos importantes del mercado del lenguaje, lo que hace que sea más difícil encontrar audiencias para los lenguajes de comprobación del tipo de tiempo en tiempo de compilación.
El mundo corporativo es en gran medida JVM-world. Puede que Java sea reemplazado como un lenguaje de desarrollo de aplicaciones en cualquier momento, pero su sucesor probablemente se ejecutará en la JVM, porque es una pieza de software bastante madura y estable con una gran comunidad y enormes recursos de biblioteca. La mayoría de los nuevos lenguajes JVM como Scala son compatibles con el código Java ya escrito.

Y un último pero muy subjetivo punto: tengo la impresión de que los lenguajes clásicos de C / C ++ / Java han pasado de moda en la parte de la comunidad de desarrolladores a la que le gusta consultar nuevos idiomas.

Pero dicho todo esto, D se ve muy bien y parece resolver los problemas que promete resolver de una manera sólida y rápida. No hay razón por la cual no debería encontrar su nicho.

Creo que es una cuestión de tiempo. Este es el día de los idiomas interpretados y con código de bytes para quienes recogen nuevos idiomas. Python, JavaScript, Ruby, C #, Java, Scala, Groovy, PHP, ActionScript: mucho que aprender sin caer en un nuevo competidor de C ++.

Cualquiera que use C o C ++ probablemente esté muy contento con C o C ++. ¿Cuál es el argumento convincente para alejarlos de sus entornos familiares y productivos y hacer que aprendan un lenguaje que suena como un bache para C?

Creo que hay algunos problemas:

Tango / Phobos split: los escritores del compilador usan Phobos, pero a casi todo el mundo le gusta más Tango y termina usándolo.
La falta de un gran compilador: DMD es bastante defectuoso, y todos los demás compiladores usan la misma interfaz. Es bastante fácil de bloquear. Realmente me gustaría ver que el dil (D compilador escrito en D) funciona, pero tienen mucho trabajo por hacer antes de que se convierta en un buen competidor.
Competencia: Java y C # son bastante similares y tienen mucho más soporte, por lo que todos los usan.

Cuando haya establecido idiomas como C ++ y Java, ¿por qué uno se molestaría en cambiar a un nuevo idioma? Además, C ++ y Java han evolucionado a lo largo de los años, con innumerables bibliotecas que los acompañan. No muchos estarían dispuestos a invertir tiempo para volver a crear esas bibliotecas para un nuevo idioma, ya que sería una especie de duplicación de esfuerzos.

Descargo de responsabilidad: Mi experiencia con D se limita a ver algunos de los ejemplos, leer la página de wikipedia y una conversación en el pasillo.

Como dije en un comentario anterior, D parece arañar un picor que nadie tiene. But beyond that, crap like this:

Note: all D users agree that by downloading and using D, or reading the D specs, they will explicitly identify any claims to intellectual property rights with a copyright or patent notice in any posted or emailed feedback sent to Digital Mars.

Guarantees that I won''t read the spec, or do anything to promote its use. Nice to start with the legalese right away, eh?

Estoy en el proceso de investigarlo en este momento, y el mayor impedimento para mi evaluación es la falta de una guía clara del idioma.

En el pasado, los idiomas tenían libros que venían con ellos (en el momento en que necesitabas unos 80 disquetes para instalar un idioma), luego aparecían los idiomas interpretados, Java y C #. Todos estos tenían buenas guías basadas en la web, clara documentación de fácil acceso, o un IDE con algún tipo de intellisense. Todos estos recursos (o incluso solo 1 de ellos) podrían apuntarle en la dirección que necesita para cualquier pregunta simple que tenga (y siempre son las cosas más simples las que le hacen tropezar).

No hay una guía fácilmente referenciada al lenguaje D. Como se menciona en una de las otras publicaciones, no se puede buscar en Google fácilmente (aunque a veces funcionan la "programación D" o el "lenguaje d").

Un ejemplo que tuve fue cómo quitar la puntuación de una cadena, qué métodos están expuestos para el objeto ''cadena'' (no hay recursos como los javadocs para D, así que necesito googlearlos). Resultó que necesitaba importar y usar std.regex y era bastante simple, pero todavía no tengo ningún documento que me diga exactamente qué ''cadena'' expone (o cualquier otro objeto para el caso).

En una nota relacionada, no específicamente sobre D (por cierto, esto solo podría ser yo). Al principio, confiaba en conocer realmente la sintaxis y las bibliotecas que usaba al revés, ahora descubrí que generalmente solo conozco los resúmenes de las bibliotecas que uso y uso el intellisense o javadocs (o lo que sea para otros idiomas) para detalles. Cualquier idioma sin un sistema de documentación fácilmente referenciado estará en desventaja.

Hay dos bibliotecas estándar ^{<obsoletas a partir de D2>} y 3 o 4 compiladores distintos ^{<la calidad de las implementaciones mejoró mucho>} , pero otros ya lo han mencionado.

Una vez que haya elegido una biblioteca ^{<Phobos es la única biblioteca estándar de facto D2>} (phobos para mí), y obtuvo un compilador que funciona principalmente, descubre que D (el lenguaje) tiene muchos pequeños problemas. Por sí mismos son pequeños, pero juntos hacen que la programación D sea algo dolorosa.

Unicode se trata de una manera un tanto extraña: hay tres tipos diferentes de cadenas de caracteres unicode: char [], wchar [] y dchar [] ^{<para UTF-8, UTF-16 y UTF-32 respectivamente>} - el estándar es char [ ], en el que unicode se almacena codificado como utf-8 - y las conversiones entre utf-8 y codepoints (dchar) son necesarias en varios lugares ^<where?> (y algunas veces están implícitas) ^{<code points durante la iteración - no hay asignación de memoria implícita>} . char [i] sin embargo producirá el i-ésimo byte, no el i-ésimo punto de código ^{<hacerlo de lo contrario tendría costos de rendimiento ocultos>} ... Las cadenas también son mutables ^{<Las cadenas D2 son inmutables>} , debe implementar copy-on-write usted mismo.
Las matrices son extrañas. Algunos son estáticos, otros son dinámicos. int [] x = null; hace x una matriz vacía. Las matrices asociativas literales (que son una gran característica) con cadenas como claves deben tener todas las claves con la misma longitud o usar un truco sintáctico para solucionar un problema de deducción de tipo ^{<fijo en D2>} - funciona pero es feo.
Las matrices no son objetos regulares, y no tienen métodos de instancia como tales (sin indexOf por ejemplo), pero hay reglas raras ^{< es una característica D - métodos de extensión / UFCS > con} respecto a las funciones que están dentro del alcance y toman una matriz como su primera argumento para crear la ilusión de métodos de instancia ...
A veces puede llamar a métodos sin los parens. ^{<característica ( @property methods)>}
Las funciones que forman cierres o están unidas a objetos (es decir, métodos) no son lo mismo que las funciones normales, sino que se llaman delegados, y debe tener en cuenta las diferencias. ^{<Los punteros de función son como en C, los delegados tienen un puntero de contexto adicional>}
Las cadenas literales (char []) se pueden definir con x "40fe", para especificar los bytes en hexadecimal que componen la matriz utf-8. El sitio web de D dice que se permite especificar una secuencia ilegal de utf-8, pero mi compilador no está de acuerdo. ^{<No reproducible con DMD 2.031 o 1.046, probablemente PEBKAC>}
Los módulos de biblioteca estándar (phobos) a menudo toman argumentos semánticamente incorrectos como argumentos de función (por ejemplo, tomar char [] donde debería tomar ubyte []) ^{probable Phobos1-specific} , u obligarlo a usar convenciones extrañas ( ubyte b; inputStream.read(b); lugar de ubyte b = inputStream.readUByte(); ^{<std.stream está obsoleto, use ranges / std.stdio>}
Hay un bucle for-each, pero la sintaxis se siente mal en comparación con Python o incluso con Java: foreach(ubyte b, char c; "abcdef"){ ... } . for(ubyte b, char c in "abdef"){ ... } sería más agradable (aunque no mucho ...). Tiene una inferencia de tipo opcional para b .
No puedes hacer una clase de solo lectura por la clase const class X {} , porque "los métodos no pueden ser const ". ^{<Funciona en la última DMD2>}
La sintaxis del elenco: ubyte u = cast(ubyte) 300; es demasiado detallado. ^{<Por diseño, para ayudar a revisar el código>}
Puede convertir valores no válidos en un tipo de enumeración: enum X : ubyte {a=0, b=1}; X z = cast(X) 10; enum X : ubyte {a=0, b=1}; X z = cast(X) 10; no da error - z es ahora 10. ^{<Entonces escribirá en un puntero emitido.} ^{Por diseño, el cast reemplaza las comprobaciones del compilador>}
La sensación que tengo es que si continúo evaluando DI encontrará más pequeños problemas que realmente no importan siempre que haga X e Y, pero simplemente no quiero hacer X e Y ...
Es muy difícil buscar en Google elementos relacionados con un idioma llamado "D": http://www.google.com/search?q=d+modules ^<Solution>

La respuesta a esta pregunta siempre se reduce a dos cosas

La cadena de herramientas, la documentación, la biblioteca estándar y las bibliotecas de terceros están en construcción
Ya hay idiomas como C y C ++ que, aunque quizás sean menos convenientes y fáciles, pueden hacer el trabajo adecuadamente.

Ambos son discutiblemente verdaderos.

Vengo de Java y para mí el lenguaje D es muy atractivo. Me gusta la modernidad de D y la simplicidad relativa, y su poder.

Es comprensible que a la comunidad D le gustaría ver una adopción más amplia. Si hiciste algo hermoso y genial, querrías reconocimiento y querrías compartirlo. Me solidarizo, pero personalmente no me preocupo demasiado por cuántas personas usan D. Siempre y cuando la comunidad siga siendo lo suficientemente grande como para mantener el proyecto viable, para que las personas que aman D puedan seguir usándolo.

Por esa razón, una pequeña promoción de vez en cuando, no puede doler :)

Me gusta D porque es un lenguaje de nivel inferior (nivel C / C ++) que tiene muchas de las convenciones y características que me gustan en C #. Es una buena mezcla. Sin embargo, tiene muchos inconvenientes en este momento:

1) División de Biblioteca Estándar - Phobos vs Tangos divide todo el código hecho en D. Esto podría arreglarse en D 2.0 con las mejoras de Phobos, pero veo que esto continúa hasta que Marte Digital adopte el Tango ejecutado por la comunidad como estándar oficial.

2) Version Split - D 1.0 es una plataforma bastante estable y sólida para escribir código, pero D 2.0 promete muchas características nuevas, algunas de ellas rotas. También es explícitamente una plataforma inestable para construir. Hasta que D 2.0 se estabilice y se libere, el lenguaje no irá a ningún lado.

3) No hay IDE bueno - Simplemente no hay nada grandioso por ahí. Existen plugins de Eclipse y algunos editores a medio hacer, pero no hay un verdadero entorno de codificación. Creo que esto es solo cuestión de tiempo, ya que hay muchos buenos comienzos disponibles, en los que se trabaja.

4) Falta de bibliotecas / aplicaciones asesinas: esto es algo de una situación de huevo / pollo. Hay algunas bibliotecas geniales para D, particularmente porque puedes envolver cualquier biblioteca escrita en C muy fácilmente. En realidad, hay muchas buenas bibliotecas para D, y también algunas buenas aplicaciones. Creo que cuando se resuelvan los problemas anteriores, más programadores acudirán a D y luego tendrán las aplicaciones geniales que necesita para atraer una base más amplia.

Mi gran conjetura es el dinero corporativo.

Los creadores de D, DigitalMars, no son realmente grandes jugadores en el mundo corporativo en este día y edad.

Su público objetivo era originalmente programadores Java o C ++.

Pero, por un lado, el problema es que la mayoría de los 8 a 5 programadores Java no invertirán en algo como D a menos que haya un orden desde arriba, y la gente que está arriba, no sepa acerca de D, porque no se menciona en círculos corporativos. En cambio, Microsoft ha estado presionando C #, que apunta a la misma audiencia, pero tiene un gran nombre corporativo.

Por otro lado los programadores de C ++ son hardcore, incluido yo mismo, y aunque reconocemos que D reduciría el masoquismo de nuestras vidas, estamos enganchados en el dolor :) Aunque para ser honesto, sigo esperando a D, simplemente no he tenido una oportunidad de usarlo.

Miré en D y me gustó lo que vi, especialmente el lanzamiento 2. Lamentablemente, hasta ahora, parece que solo hay compatibilidad razonable con Linux y Windows, pero no para Mac OS X. En Mac OS X, está lejos de ser listo para la producción, que es el asesino para mí. Es una lástima, porque realmente parece una alternativa razonable para el desarrollo de aplicaciones nativas e incluso la integración de las bibliotecas C fue sorprendentemente simple para lo que usé hasta ahora.

No hay bibliotecas maduras y documentación de apoyo en general (la mayoría del trabajo lo hacen voluntarios que hacen algo por un tiempo y luego se van)

Además, creo que el cisma reciente que creó Tango no ayuda a D en absoluto.

Otra razón podría ser que, a diferencia de C ++, no existe un estándar internacional para el idioma. Esto previene efectivamente que terceros implementen sistemas de lenguaje D.

Para mí, el lenguaje no es lo suficientemente reflexivo. No tiene reflejo, por lo que el programador no muestra interés. No está apoyando la reflexión, puede deberse a sus dependencias de máquina.

Si ve el último marco desarrollado utilizando C # o Java, tienden a respaldar la dinámica a través de Inversion of Control. IOC permite configurar el sistema en el formato XML / other y crear los objetos en el tiempo de ejecución. Gran parte de la innovación es posible si respalda la reflexión. Las DLL y el ejecutable deberían proporcionar metainformación sobre sí mismo.

Las clases, funciones, atributos deben estar enganchados. De lo contrario, pierdo el interés en hackear el idioma.

No sé quién comercializó Perl o Python o Ruby. Si el lenguaje atrae a los piratas informáticos, tienden a crear un marco o aplicación en el hogar, eventualmente atraerá a los otros programadores.

Para mí, es la falta de un IDE de alta calidad. Si un IDE como Visual Studio o incluso Code :: Blocks tuviera soporte completo para D, comenzaría a usarlo en un abrir y cerrar de ojos.

Para mí, la característica más emocionante de D es la capacidad de codificar en UTF-8. ¡Qué maravilloso es eso!

Puede haber otros lenguajes que permitan caracteres internacionales (¡no C ++!), Pero he estado en el mundo C y C ++ y D es el único que conozco que admite UTF-8.

Es muy agotador encontrar nombres de símbolos que no sean ambiguos cuando se quitan los acentos: döndür () y dondur () tienen significados completamente diferentes en turco: ''return'' vs. ''freeze''.

Considera sıkıcı () vs. sikici (); que significa "aburrido" vs. [una palabrota].

Creo que D puede ser muy popular si se impulsa el soporte de caracteres internacionales, lo que haré en mi sitio turco D.

Ali

Para mí, un gran impedimento para una adopción más amplia es que el lenguaje todavía está evolucionando tan rápidamente. D1 es / fue un intento relativamente conservador de crear un mejor C ++ al agregar algunas lecciones aprendidas en los últimos 20 años de lenguajes como Java y Python. Es un lenguaje agradable, pero no tiene grandes características de asesino, por lo que es comprensible que los costos de cambio sean suficientes para desalentar a las personas.

D2, por otro lado, todavía está en alfa, pero representa una innovación mucho más significativa. Intenta cerrar la brecha entre la programación funcional y la imperativa, con características tales como:

Const transitivo (todo lo que se puede alcanzar desde un objeto const / inmutable es en sí mismo const / inmutable).
Funciones puras Marca una función como pura y el compilador hace cumplir que no puede tener efectos secundarios externamente visibles. Sin embargo, puede usar estado mutable libremente siempre que no sea visible fuera de la función pura.
Compartido. Esto aún no está implementado, pero la idea es hacer que todos los datos no se compartan entre subprocesos de manera predeterminada, hacer que el compilador inserte vallas de memoria automáticamente, etc. cuando sea necesario si se comparten datos, y hacer que el sistema de tipo evite el intercambio accidental.

D2 también agrega algunas características para hacer que D sea más amigable con los escritores de la biblioteca, como retorno por referencia, alias esto (básicamente un operador implícito), argumentos de alias de plantilla (básicamente pasa cualquier símbolo de tiempo de compilación como argumento a una plantilla), plantilla restricciones (similares a los conceptos de C ++ 0x) y cierres reales.

El mensaje para llevar a casa aquí es, dar tiempo D. D1 es un lenguaje agradable, pero relativamente conservador. La mayoría de las características asesinas realmente impresionantes están en D2, pero todavía está en alfa.

Porque los programadores de C ++ no creen que necesiten nada más. D ofrece muchas cosas interesantes, pero no cambia el hecho de que C y C ++ son suficientes para los desarrolladores. Además, creo que el hecho de que se considere un lenguaje de programación de "Sistemas" y que esté enyesado en la página de inicio de D hace que la gente se aparte antes de siquiera mirarlo.

Probablemente valga la pena mencionar que, para un lenguaje de sistemas, es notablemente difícil encontrar un compilador que le permita escribir código del sistema contra el baremo de una computadora sin darles mensajes de error extraños ya menudo crípticos.

Personalmente, estoy cruzando los dedos para que el front-end de LLVM madure y se convierta en una criatura más útil que el gdc GNU estancado y los difíciles compiladores dmd de Mars digitales.

Al leer D2, debería ser un lenguaje realmente agradable si está bien implementado y si tiene un nivel de soporte de herramientas vagamente razonable.

Puedo pensar en algunas razones:

La base de usuarios es pequeña. Es difícil para los nuevos lenguajes alcanzar el ímpetu suficiente que les permita competir con los viejos jugadores porque hay menos incentivos para que los programadores cambien a ellos.
Menor cuerpo de conocimiento (ver anterior). Es más difícil encontrar bibliotecas, ejemplos de código, desarrolladores experimentados, etc. Esto compensa las ventajas que el lenguaje en sí tiene para ofrecer en muchos casos.
Quizás el idioma no es el problema, y (aún) otro idioma no es lo que necesitamos. La mayor parte de lo que D pretende lograr a través de las características del lenguaje se puede lograr en otros idiomas en forma de biblioteca.

Siempre estoy buscando algo como D. AC que tiene algunos de los bordes ásperos sacados y modernizados. Muchas veces he instalado e intentado hacer que D funcione. D no funciona bien recién salido de la caja y es un objetivo móvil. Sin embargo, el problema real es que no es compatible con el código C heredado. Oh, ¿dices que sí? No, no. ¿Todavía dices que sí? No, no. El problema es que aunque se enlazará con archivos C .o, los archivos .H NO son compatibles. Esto significa que tengo que volver a escribir todos los encabezados para todo lo que quiero vincular, y luego al actualizar el archivo .h para siempre en el futuro, convertirlo a formato D nuevamente. Este proceso no puede ser automatizado, y apesta. Eso es lo principal que me apaga. Podría llamarlo Q o Frak o lo que sea, ya que no está tan relacionado con C como se anuncia.

Supongo que D está posicionado como un "mejor C ++", pero C ++ es lo suficientemente bueno y tiene una gran inercia, por lo que D no va a ser grande.

Para una codificación de nivel superior ya tienes muchos mejores idiomas que C ++ o D.

Uso D. Lo que me gusta es la velocidad de compilación rápida. Tenía una idea, y podría implementar realmente rápido. Imagínese cuando la velocidad de compilación es de aproximadamente 1 segundo. (Un programa similar compila en 8 segundos en C ++.) Si uno sabe qué hacer, uno puede volar. La flexibilidad del lenguaje muchas veces se cumple con los deseos. Me pasó a mí, pensé en una característica, la probé y se implementó. Construcciones de lenguaje útiles: foreach, plantillas, listas pueden especificarse / inicializarse en C ++, las estructuras pueden inicializarse en su definición, la inferencia de tipo automática, las estructuras fáciles de inicializar, la evaluación de funciones de tiempo de compilación, las matrices asociativas y las matrices dinámicas están incorporadas como así como recolección de basura que se puede apagar.

Podría agregar que hay problemas (como ya se mencionó por otros): buggy linker, missing IDE de alta calidad, no el mejor depurador (ddbg) (los depuradores de C ++ son mejores), menos librerías que para C ++, la sobrecarga del operador es más restrictiva (menos los operadores pueden estar sobrecargados), la herencia múltiple no es compatible (hay mixins). Tenga en cuenta que las bibliotecas C se pueden utilizar, C ++ también se puede usar con limitaciones (no lo he intentado).

Yo uso D para programas de consola.

I don''t see in the example the site is illustring, any real noticable difference between it and C#. I think that C# is more clear and clean.

I don''t see why I should use it instead and I don''t figure out what benefit it offers...