Discussion :

[Hibou57]

Bonsoir,

Heuuuuu.... je reste dubitatif à la lecture de cette annonce : Le langage D rénove la programmation systemes.

Pourquoi créer un langage « D », alors qu'il existe déjà Ada ? Est-ce par allergie à Ada qu'on a voulu réinventé la roue ?

Et comme chacun sait, vouloir rassembler en créant un n-ième parti, est parfaitement illusoire. Cela ne produira qu'encore plus de dispersion et de division, et on a vraiment pas besoin de ça.

On cré un langage sur la base de langages qui ont avant fait la preuve de leur défaut et de leur dangerosité, pour créer un langage censé corrigé tout leur défaut, et dans le même temps on ignore un expérience de 30 ans qui a fait ces preuves et qui se montre capable de résoudre tous ces problèmes depuis le début ?

C'est à y perdre son latin.... et c'est à se demander si ce n'est pas le but recherché. A moins que ce ne soit un n-ième coup de marketing, comme on en a connu avec Java et C# ? (c'est vrai que le marketing préfère le neuf, fut-il mauvais, à l'ancien, fût-il très bon).

Nouveau n'est pas nécéssairement synonime de qualité.

Au passage, c'est à croir qu'on est devenu incapable d'imaginer un langage de programmation comme acceptable s'il n'est pas, même sous le seul pretexte de la syntax, associé au C. Et si vraiment ce qui fait obstacle, est une simple question de syntax, alors je ne donne pas chèr des capacités d'investigations de ceux/celles pour qui cela représente l'obstacle principale.

[InOCamlWeTrust]

La réponse est évidente : laisser plus de choix au gens au moment de choisir le langage de programmation. Le D possède un garbage collector si je me souviens bien, ce qui peut être attrayant pour quelqu'un venant du monde C et voulant se débarasser de la gestion de la mémoire.

La multiplicité des langages n'est pas un inconvénient, mais une richesse : ce qui est un problème, c'est par contre vouloir plaquer un mode de pensée provenant d'un certain langage sur un autre... ce qui conduit souvent à des abhérrations, ou encore utiliser des langages à des fgins pour lesquelles ils ne sont pas du tout conçus pour (comme utiliser Lisp pour faire du calcul numérique ou matriciel, etc...).

[Hibou57]

Bonjour, et merci pour ta réponse interessante

Le D possède un garbage collector si je me souviens bien, ce qui peut être attrayant pour quelqu'un venant du monde C et voulant se débarasser de la gestion de la mémoire.

On peut en installer un dans tous les langages, ce n'est qu'une question de librairie. Et puis... avis perso.... la gestion de la mémoire doit être effectuée par la logique de l'application. Parce que de toute manière, la gestion des resources, ce n'est que la gestion de la mémoire, et une application utilise bien d'autre resource, comme socket, fichiers, sémaphore, hook, ... pour ne citer que celles-ci.

La ramasse miette est une bonne chose pour des langage comme Prolog par exemple. Mais pour les autres applications, je pense que c'est le plus souvent comme sortir le marteau pilon pour moudre un grain de café.

Le ramasse miette est bon quand il est employé comme solution, et non pas pour se débarasser et refuser de voir un problème à résoudre.

La multiplicité des langages n'est pas un inconvénient, mais une richesse

Attention quand même à la fragmentation... et à la diversité des langage ne répond pas toujours la diversité des compilateurs. Sur la plupart des système, il n'y a que quelque langage disponnible, et on a pas toujours les droits suffisant pour installer autre chose. D'où l'importance des langages majoritaire et de bien les choisir.

ce qui est un problème, c'est par contre vouloir plaquer un mode de pensée provenant d'un certain langage sur un autre...

Beh, c'est justement l'impression que j'avais là... que pour la nième fois encore, on colle quelque chose sur le C, pour faire programmer des adepte du C, avec des concept qui sont différent de ce qu'il connaisse, en leur faisant croire que c'est du C.... je n'aime pas ces embrouille, et je n'aime pas qu'on mette le C à toutes les sauces.

ce qui conduit souvent à des abhérrations, ou encore utiliser des langages à des fgins pour lesquelles ils ne sont pas du tout conçus pour (comme utiliser Lisp pour faire du calcul numérique ou matriciel, etc...).

C'est quoi « fgins » ?

[InOCamlWeTrust]

On peut en installer un dans tous les langages, ce n'est qu'une question de librairie.

Oui, à ceci près que les bons garbage collector ne sont pas légion... je veux parler de ceux qui ne pourrissent pas les performances du programme (et accessoirement aussi de ceux qui ne buguent pas).

Et puis... avis perso.... la gestion de la mémoire doit être effectuée par la logique de l'application. Parce que de toute manière, la gestion des resources, ce n'est que la gestion de la mémoire, et une application utilise bien d'autre resource, comme socket, fichiers, sémaphore, hook, ... pour ne citer que celles-ci.

Effectivement, c'est une idée intéressante... mais il est parfois difficile, lorsque les algorithmes sont complexes et le code très long de gérer tout soi-même. La possibilité d'utiliser un garbage collector te donne une souplesse de programmation autre et permet de mettre en oeuvre d'autres paradigmes de programmation.

Par exemple, il existe une grande différence entre les compilateurs écrits en C et ceux écrits en Objective Caml : les premiers jouent à fond la carte de la ré-utilisation des arbres créés au cours de l'exécution du programme, alors qu'en Objective Caml, doté d'un garbage collector, on privilégiera la construction d'arbres abstraits très spécifiques à l'étape en cours d'exécution... et ça donne deux approches, au niveau de la programmation, assez éloignées l'une de l'autre.

Là encore, je pense qu'il faut utiliser non pas SA solution, mais la bonne solution, et effectivement si la gestion des ressources à la main est envisageable, celà peut être une bonne alternative.

Le ramasse miette est bon quand il est employé comme solution, et non pas pour se débarasser et refuser de voir un problème à résoudre.

Tout dépend des impératifs... une chose est sûre, c'est que leur utilisation accélère grandement le temps de développement.

Attention quand même à la fragmentation... et à la diversité des langage ne répond pas toujours la diversité des compilateurs. Sur la plupart des système, il n'y a que quelque langage disponnible, et on a pas toujours les droits suffisant pour installer autre chose. D'où l'importance des langages majoritaire et de bien les choisir.

Moi je dirais que tout programmeur devrait connaître au moins le C-ANSI à fond (comme langage portable et généraliste) plus un autre langage, lui aussi en long en large et en travers. Pour le D, étant donné que son utilisation n'est pas très développée, la question ne se pose pas... surtout que si je me souviens bien, il n'existe qu'un seul compilateur D, celui de Digital Mars (moi je n'avais trouvé que celui-là lorsque je m'y étais intéressé), commercial.

Beh, c'est justement l'impression que j'avais là... que pour la nième fois encore, on colle quelque chose sur le C, pour faire programmer des adepte du C, avec des concept qui sont différent de ce qu'il connaisse, en leur faisant croire que c'est du C.... je n'aime pas ces embrouille, et je n'aime pas qu'on mette le C à toutes les sauces.

Que veux-tu ? Si on ne fait pas des syntaxes aujourd'hui à la C avec des accolades dans tous les sens, les gens n'en veulent pas. Les accolades, je crois que c'est ce genre de chose qui rassure, mais qui est complètement obsolète en soi. C'est l'un des arguments de Java : les gens qui faisaient du C pourront toujours programmer à la C en Java. Ca instaure un climat de confiance.

Pour ma part, je préfère les syntaxes dédiées car elles introduisent souvent des nouveautés d'un point de vue sématique... et c'est plus rigolo comme ça. Tiens, en Haskell on pourrait écrire un tri rapide comme ceci...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
quicksort [] = []
quicksort (x : xs) = quicksort [ y | y <- xs, y < x ] ++ (x : quicksort [ y | y <- xs, x <= y ])

... il faut avouer que c'est tout de même marrant pouvoir écrire des listes par compréhension, plutôt que de manière traditionnelle !

Sinon, moi aussi j'aime beaucoup le C !

C'est quoi « fgins » ?

C'était fins.