Discussion :

[pseudocode]

Personnellement, je n'ai pas trop entendu parlé de ce langage récemment.

Bien que je ne doute pas de l'engouement de la "communauté" pour les nouveaux langages, je n'ai pas vu de buzz fracassant sur le sujet. Peut-être l'annonce de la simplification de la programmation multi-core va changer la donne ?

a voir...

[pcaboche]

Ca commence à bien faire ces soi-disant "nouveaux" langages !

À chaque fois qu'un "nouveau" langage sort, c'est toujours pareil: toujours le même style de programmation (impérative), à quelques différences de syntaxe près ("Regardez ! Dans notre super langage révolutionnaire on n'a pas besoin de mettre un point-virgule à la fin de chaque ligne, w00t !" )

Finallement, tout ce qui change, ce sont les bibliothèques disponibles ("Regardez ! Dans notre super langage révolutionnaire on a un truc pour faire du multithread, w00t !" )

Donc à chaque fois que sort un "nouveau" langage:
- soit c'est un langage impératif (~90% des cas) qui n'apporte strictement rien de révolutionnaire
- soit ça utilise un paradigme de programmation totalement différent (déclaratif : fonctionnel, logique, etc) et là tout le monde le décrie parce que c'est "compliqué" (comprenez: "ça ne ressemble pas assez à du C ou du Java donc personne ne fait l'effort de comprendre") ou lent (mais on pourrait aussi dire: "C, c'est nul: programmez en assembleur !")


Bref, lorsqu'il s'agit de programmation impérative, on parle souvent de "nouveau" langage, alors que le terme "clone plus ou moins abouti de C, C++, Java et compagnie" serait plus approprié...

si j'en crois cet article, il y a une syntaxe pour faire de la programmation fonctionnelle
http://www.doc.ic.ac.uk/~klc/gowp.html

Ha, peut-être que finallement ce langage apporte quelque chose de nouveau...

Je crois qu'on ne parle pas du même go, voir : http://code.google.com/p/go/issues/detail?id=9

forcemment, si en plus ils prennent un nom déjà utilisé

Fausse alerte: ça n'apporte rien de nouveau. Même le nom a été repompé !

[Jérémie A.]

Eh bien perso j'apprécie l'info, donc merci aux chroniqueurs.
La puissance "com'" de Google derrière un langage, je trouve cela intéressant.

[elmcherqui]

Pensez-vous que Go va remplacer Python et C++ ? Et Java ?

tous au long de ce sujet on parle de concurence pour C++ et Java , et on oublie completement C# , quelqu'un peux m'expliquer pourquoi ?
parceque ce qui concurence Java concurence C# par la meme occasion a mon avis , je me trompe ?

[pcaboche]

tous au long de ce sujet on parle de concurence pour C++ et Java , et on oublie completement C# , quelqu'un peux m'expliquer pourquoi ?

Peut-être parce que:

Code :

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

C# = Java.Clone();

[tomlev]

Peut-être parce que:

Code :

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

C# = Java.Clone();

mmm.... de très loin peut-être, mais ça n'a quand même pas grand chose à voir

[pseudocode]

Cela se ressemble tout de même beaucoup : Programmation imperative, syntaxe type C, Orienté Objet, Garbage Collection, Machine virtuelle, ... ça implique que, pour un problème donné, concevoir une solution C# n'est pas différent de concevoir une solution Java.

[tomlev]

Bah, ca se ressemble tout de meme beaucoup : Programmation imperative, syntaxe type C, Orienté Objet, Garbage Collection, Machine virtuelle, ... Ca implique que, pour un problème donné, concevoir une solution C# n'est pas différent de concevoir une solution Java.

Certes, ça ressemble... je voulais juste dire qu'il y a en C# beaucoup de choses qui n'existent pas en Java : "vrais" génériques, itérateurs, delegates, évènements, propriétés, et surtout toutes les nouveautés de C# 3.0 : Linq, expressions lambda, méthodes d'extension, types anonymes...

[pcaboche]

Bah, ca se ressemble tout de meme beaucoup : Programmation imperative, syntaxe type C, Orienté Objet, Garbage Collection, Machine virtuelle, ... Ca implique que, pour un problème donné, concevoir une solution C# n'est pas différent de concevoir une solution Java.

C'est exactement ce à quoi je faisais allusion, mais pour aller plus loin, et pour faire écho à ce que dit tomlev :

Dans sa version 1.0, C#, sans en être une copie conforme, s’est quand même “très largement inspiré” de Java qui lui-même s’est “très largement inspiré” de C++ (syntaxe) et même de SmallTalk (qui a par ailleurs inspiré pas mal de langages, y compris Java, Objective-C et Ruby).

Puis Java et C# ont vécu chacun de leur côté, mais toujours en s’inspirant de ce qui a été fait ailleurs (ex: les templates du C++ qui sont devenus des Generics dans les 2 langages).

Dans sa version 3.0, C# a reçu l’ajout de LINQ qui, pour certains concepts (inférence de types, fonctions anonymes…), s’est “très largement inspiré” des langages fonctionnels. D’ailleurs F#, le langage fonctionnel de Microsoft, s’est lui-même “très largement inspiré” d’OCaml, qui est un langage fonctionnel mais qui, dans le but d’attirer un large public conditionné par la programmation impérative, a décidé d’implémenter certaines fonctionnalités propres à ces langages (boucles, objets, mutables, exceptions…).

Tout ça pour étayer ce que je disais : difficile de parler véritablement de “nouveaux” langages tant ceux-ci se copient les uns les autres…

[pseudocode]

Tout ça pour étayer ce que je disais : difficile de parler véritablement de “nouveaux” langages tant ceux-ci se copient les uns les autres…

C'est sur qu'on ne crée pas des nouveaux paradigmes tous les 4 matins.
Impératif, fonctionnel, déclaratif, procédural, objet, évènementiel, ... On tourne souvent autour des mêmes idées.

Les nouveautés sont plus dans la façon d'utiliser (mélanger) les paradigmes pour répondre a des problématiques. Par exemple l'ajout des annotations en Java, c'est un ajout de "déclaratif" sur de l' "impératif". Il y aussi les nouveaux langages déclaratif pour les IHM (XAML, JavaFx) appelant du code Objet (Java, C#, C++) par un mécanisme évènementiel (C#, Qt).

Bref, les nouveaux langages ne sont pas forcément des nouveaux paradigmes, mais plutot une nouvelle façon d'utiliser les paradigmes existant de manière cohérente pour résoudre un problème.

[syruslevirus]

Bonjour,
A la vue de leur annonce(google) on remarque tout de suite qu'il n'y as pas d'avantages à utiliser ce langage, juste un intérêt très geek.
Pour moi personnellement je pense que le c++ est indétrônable:
1°) Gestion de la mémoire et nettoyage manuel(on est jamais aussi bien servi que par soi même !!)
2°) Heu, un paquet, et vraiment gros paquet, un paquet gigantesque de code réutilisable.(Personnellement je n'aime pas open office car si on veut une version plus performante il faudrait le réécrire entièrement: le java est lent et bouffe votre mémoire). Un code en c++ à une durée de vie bien plus importante, certain code existe depuis un paquet d'année et peuvent être repris!
Pour écrire rapidement du code j'utiliserai le python qui ce veut vraiment de haut niveau par rapport à la compilation, mais qui donne la possibilité de "binding" votre code avec du c++ pour des fonctions consommatrice de mémoire.
Go! ou si on à du temps à perde pour une société commercial comme google qui ne vous payeras pas

[pcaboche]

Bref, les nouveaux langages ne sont pas forcément des nouveaux paradigmes, mais plutot une nouvelle façon d'utiliser les paradigmes existant de manière cohérente pour résoudre un problème.

Le problème, c'est que certains langages introduisent certains paradigmes dans le seul but d'attirer plus de monde à sa cause...

Le mélange peut alors se révéler assez inefficace (ex: des exceptions du paradigme impératif qui court-circuitent complètement le mécanisme de pattern-matching et d'inférence de type du paradigme fonctionnel) et il devient alors plus difficile de saisir l'intérêt d'un paradigme donné.

Il peut alors se révéler plus judicieux de se restreindre à un type de raisonnement particulier, qui sera adapté à la résolution de certains problèmes. Mais dans ce cas:

1. cela demande un plus grand effort d'apprentissage (que l'utilisateur n'est pas forcément enclin à fournir)
2. cela risque de restreindre le champ d'applications

Je pense, par exemple, que le paradigme objet a réussi à s'imposer parce qu'il était suffisamment proche des autres paradigmes impératifs (prédominant). Il a introduit de nouveaux concepts (encapsulation, héritage...) sans que les habitués du procédural ne soient trop perdus. Sans cela, il n'aurait sans doute pas connu le même succès...

[OWickerman]

Bonjour,
Pour moi personnellement je pense que le c++ est indétrônable:

On a dit la même chose de la machine à vapeur.

[IDontLikeYou]

Bonjour,
A la vue de leur annonce(google) on remarque tout de suite qu'il n'y as pas d'avantages à utiliser ce langage, juste un intérêt très geek.
Pour moi personnellement je pense que le c++ est indétrônable:
1°) Gestion de la mémoire et nettoyage manuel(on est jamais aussi bien servi que par soi même !!)
2°) Heu, un paquet, et vraiment gros paquet, un paquet gigantesque de code réutilisable.(Personnellement je n'aime pas open office car si on veut une version plus performante il faudrait le réécrire entièrement: le java est lent et bouffe votre mémoire). Un code en c++ à une durée de vie bien plus importante, certain code existe depuis un paquet d'année et peuvent être repris!
Pour écrire rapidement du code j'utiliserai le python qui ce veut vraiment de haut niveau par rapport à la compilation, mais qui donne la possibilité de "binding" votre code avec du c++ pour des fonctions consommatrice de mémoire.
Go! ou si on à du temps à perde pour une société commercial comme google qui ne vous payeras pas

J'espère que ce fil ne deviendra pas un énième troll langage X vs reste du monde (oui c'est un message aux modos là).

[_skip]

Quasiment toutes les technologies existantes ont un gros background de librairies disponibles. Ca ne change pas qu'un nouveau venu qui est bien poussé en avant par un acteur majeur du monde informatique a bien des chances de développer une communauté et au fil du temps, de prendre de l'importance.

Si go se montre beaucoup plus productif qu'un langage comme C++ pour une perte de performance de 2-5%, il aura toutes ses chances.

[LLB]

D’ailleurs F#, le langage fonctionnel de Microsoft, s’est lui-même “très largement inspiré” d’OCaml, qui est un langage fonctionnel mais qui, dans le but d’attirer un large public conditionné par la programmation impérative, a décidé d’implémenter certaines fonctionnalités propres à ces langages (boucles, objets, mutables, exceptions…).

OCaml a ajouté ces fonctionnalités, non pas pour attirer des gens, mais pour améliorer le langage et son expressivité. OCaml n'a jamais cherché à être pur et a toujours beaucoup utilisé les exceptions, les valeurs mutables, etc.

Tout ça pour étayer ce que je disais : difficile de parler véritablement de “nouveaux” langages tant ceux-ci se copient les uns les autres…

Heureusement que les "nouveaux" langages reprennent une partie de l'existant, réutilisent les techniques qui ont fait leurs preuves et essaient de les adapter. Ils ajoutent aussi, pour certains d'entre eux, de nouvelles fonctionnalités : ce n'est pas de la simple copie et l'on peut véritablement parler de nouveauté.

Le mélange peut alors se révéler assez inefficace (ex: des exceptions du paradigme impératif qui court-circuitent complètement le mécanisme de pattern-matching et d'inférence de type du paradigme fonctionnel)

En quoi les exceptions se mélangeraient mal avec le pattern-matching ? C'est du délire : penses-tu aussi que les exceptions court-circuitent le switch case en C++ ? Ça n'a pas de sens. Quant à l'inférence de type, ça fait très longtemps qu'elle supporte les exceptions et qu'il n'y a aucune espèce d'incompatibilité.

Le problème, c'est que certains langages introduisent certains paradigmes dans le seul but d'attirer plus de monde à sa cause...

Par curiosité, j'aimerais bien voir des exemples pertinents pour justifier cette affirmation.

[pseudocode]

Par curiosité, j'aimerais bien voir des exemples pertinents pour justifier cette affirmation.

L'ajout du paradigme Orienté-Objet dans PHP ?

[pcaboche]

En quoi les exceptions se mélangeraient mal avec le pattern-matching ? C'est du délire : penses-tu aussi que les exceptions court-circuitent le switch case en C++ ?

En Caml, je pense qu'il est particulièrement intéressant de se passer des exceptions. Si une erreur se produit, on le spécifie dans le type de retour de la fonction:

Code :

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

1
2
3
4
5
6
7
8
9
10
type erreurFonction =
  Erreur1
| Erreur2
| Erreur3
;;
 
type resultat = 
  Erreur of erreurFonction
| Resultat of int
;;

Ici, soit le résultat est correct et exploitable, soit on a une erreur avec tous les détails spécifiés dans le type. Sur ce type, on peut faire du pattern-matching:

Code :

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

1
2
3
4
5
6
7
 
let resultat = maFonction parametre1 parametre2
in
 
match resultat with
| Resultat(v) -> traiterValeur v
| Erreur(err) -> afficherErreur err

Tu vas me dire qu'on peut faire la même chose avec une exception. Oui, mais dans ce cas il y a une énorme différence: si par inadvertance mon pattern-matching se révélait incomplet (oubli de valeurs possibles), le compilateur le signalera par un warning; en revanche avec les exceptions, si (suite à un oubli de ma part) une exception n'est pas traîtée dans la fonction, elle remontra dans la fonction appelante.

C'est ça que j'appelle "court-circuiter le pattern matching".

Si le matching des exceptions n'est pas complet, le compilateur ne le signalera pas. Or, si j'oublie de traîter une erreur, je souhaite que le compilateur le signale. Propager une erreur à la fonction appelante peut être tout à fait normal, à condition que cela soit un choix délibéré (pattern-matching), et non pas un choix par défaut (exceptions).


Maintenant, concernant l'inférence de type:

Une fonction est censée retourner un résultat d'un type particulier, et à partir du type retourné par une fonction, le compilateur en déduit le type d'une variable. Rien qu'en regardant le type retourné par une fonction on peut en déduire les valeurs possibles que peut prendre une variable (y compris énumérer de manière exhaustive les possibles cas d'erreurs). Tout cela est parfaitement lisible rien qu'en regardant le code.

Oui mais voilà: au milieux de la fonction on balance une exception qui elle, ne transparaît pas dans le prototype de la fonction. Je trouve ça problématique...


En Caml, il y a ce qu'il faut pour se passer des exceptions et faire du matching "propre". Je pense qu'il vaut donc mieux éviter d'utiliser les exceptions dans du code Caml. (mais ça, c'est juste mon point de vue)

Par curiosité, j'aimerais bien voir des exemples pertinents pour justifier cette affirmation.

Je dirais: Java, qui mange un peu à tous les rateliers, qui implémente des nouveautés (par rapport au langage) non pas parce que cela apporterait plus de cohérence au langage mais uniquement pour attirer du monde venu d'autres horizons.

Cela va même au-delà du langage lui-même puisque de nombreux projets ont pour seul but de faire tourner des langages autres que Java (Python, Ruby, PHP...) dans un environnement Java, tout ça afin d'attirer plus de monde.

Du coup, je trouve que Java a tendance à partir un peu dans toutes les directions.

Heureusement que les "nouveaux" langages reprennent une partie de l'existant, réutilisent les techniques qui ont fait leurs preuves et essaient de les adapter.

Bien sûr, on ne va pas réinventer la roue tous les 4 matins...

Encore que, quand on voit ces "nouveaux" langages (comme Go) qui promettent de résoudre des problématiques vues et revues des milliers de fois, on est en droit de se demander si ce n'est exactement ce qu'ils sont en train de faire (réinventer la roue encore une fois !)

Pour l'instant, je trouve qu'on ne dispose pas d'assez d'éléments pour affrimer ou infirmer cette hypothèse (même si, pour avoir vu de nombreux langages prétendus "révolutionnaires", je suis plutôt pessimiste à l'heure actuelle). Wait and see...

[LLB]

En Caml, je pense qu'il est particulièrement intéressant de se passer des exceptions.

Tu remarqueras que la bibliothèque standard se passe très bien de ton type Erreur (ainsi que le projet assez gros sur lequel je travaille professionnellement) et se contente du type option, qui ne donne aucune info sur l'erreur.

Si l'on veut lire un fichier en entier, on lira jusqu'à ce que l'exception End_of_file se produise. Pour convertir une chaîne en entier, int_of_string lève une exception en cas de problème, là où C# propose TryParse. Ouvrir un fichier inexistant lève une exception, là où d'autres langages renvoient null. La fonction find des modules List, Map et Hashtbl ne renvoie pas d'option, mais lance plutôt une exception... En fait, OCaml est l'un des langages qui forcent le plus à utiliser des exceptions.

Note aussi que Caml est l'un des langages les efficaces pour les exceptions (plus que C++ avec les compilateurs que j'avais testés, et 100 fois plus que .NET), ce qui fait qu'on peut les utiliser comme structure de contrôle, ce qui est aberrant dans d'autres langages. Il n'est pas rare d'interrompre une boucle, un map ou un fold de cette façon. D'ailleurs, la bibliothèque standard définit l'exception Exit sans l'utiliser, elle est simplement laissée à la disposition de l'utilisateur. Pour moi, Caml incite beaucoup plus à utiliser les exceptions que C++, C# et Java (regarde comme c'est lourd d'en lancer en Java), dans lesquels on nous répète que les exceptions doivent rester execptionnelles.

Oui mais voilà: au milieux de la fonction on balance une exception qui elle, ne transparaît pas dans le prototype de la fonction. Je trouve ça problématique...

Quand on type à la main comme en C++/C#, l'exception n'apparaît pas non plus. Non, vraiment, je ne vois pas de problème lié à l'inférence. Au contraire même : si une fonction lance systématiquement une exception, cela se verra dans son type en Caml (polymorphique), alors que ce sera masqué dans d'autres langages (void).

Je dirais: Java, qui mange un peu à tous les rateliers, qui implémente des nouveautés (par rapport au langage) non pas parce que cela apporterait plus de cohérence au langage mais uniquement pour attirer du monde venu d'autres horizons.

Je trouve qu'il manquait vraiment beaucoup de choses à Java et que les nouveautés comblent un peu le retard du langage et le rendent plus utilisable.

Cela va même au-delà du langage lui-même puisque de nombreux projets ont pour seul but de faire tourner des langages autres que Java (Python, Ruby, PHP...) dans un environnement Java, tout ça afin d'attirer plus de monde.

C'est un énorme bénéfice - pour Java et pour ces langages - que d'ajouter cette compatibilité.

Encore que, quand on voit ces "nouveaux" langages (comme Go) qui promettent de résoudre des problématiques vues et revues des milliers de fois, on est en droit de se demander si ce n'est exactement ce qu'ils sont en train de faire

Je suis aussi sceptique vis-à-vis de Go, mais je suis heureux de voir Scala et F# se développer.

[pcaboche]

Pour moi la programmation fonctionnelle repose sur un principe simple: on passe des valeurs en paramètres à une fonction et elle retourne une valeur qui peut être un type de base (entier, flottant...), un type définit par l'utilisateur, un tuple, ou même rien (unit ()).

À partir de ce principe tout simple on obtient des choses intéressantes.

Imaginons que j'aie un protocole, constitué d'un ensemble des messages échangés. Je définis ces différents messages à l'aides de types. Je peux ensuites passer des valeurs de ce type à un ensemble de fonctions qui en retour me donneront une réponse d'un certain type. De là on peut spécifier dans le programme, par exemple: "en réponse à un message de tel type, j'attends un message de tel autre type". En cas d'erreur, on spécifie le type d'erreur qu'il est possible de rencontrer. De là, on va pouvoir définir un comportement en cas d'erreur, avec en réponse un type de message approprié vis-à-vis du protocole.

On définit donc une sorte de contrat entre les fonctions ("j'accepte tel ou tel type de message en entrée et je répond par tel ou tel autre type de message). L'inférence de types permet de vérifier si ce contrat est bien respecté. Le pattern-matching permet de vérifier si on a bien spécifié un comportement pour chaque type de message en entrée.


Certes, on peut se dire que les exceptions permettent d'introduire une certaine souplesse dans la programmation. À l'inverse, on peut se dire "je programme d'une manière volontairement rigide, mais si je fais une connerie, le compilateur me le signalera", qu'on peut aussi traduire par: "si ça ne marche pas, faut pas que ça compile !".

Note aussi que Caml est l'un des langages les efficaces pour les exceptions (plus que C++ avec les compilateurs que j'avais testés, et 100 fois plus que .NET), ce qui fait qu'on peut les utiliser comme structure de contrôle, ce qui est aberrant dans d'autres langages.

C'est très bien pour Caml. Pour une fois, ses détracteurs pourront arrêter de dire (souvent à tort) : "Caml c'est lent".

En revanche, il semble qu'en F# le traitement des exceptions soit beaucoup plus lent qu'en Caml :

Caution Programmers coming from an OCaml background should be careful when using exceptions in F#. Because of the architecture of the CLR, throwing an exception is pretty expensive—quite a bit more expensive than in OCaml. If you throw lots of exceptions, profile your code carefully to decide whether the performance costs are worth it. If the costs are too high, revise the code appropriately.

Source:
http://en.csharp-online.net/FSharp_F...ption_Handling

Tu remarqueras que la bibliothèque standard se passe très bien de ton type Erreur (ainsi que le projet assez gros sur lequel je travaille professionnellement) et se contente du type option, qui ne donne aucune info sur l'erreur.

Je trouve cela idiot comme remarque. Heureusement qu'en Caml on peut définir ses propres types. Et si on trouve une utilité à spécifier les cas d'erreur dans un type approprié (pour pouvoir faire du pattern-matching dessus) plutôt que de lancer une exception, et bien heureusement que c'est possible !

C'est un énorme bénéfice - pour Java et pour ces langages - que d'ajouter cette compatibilité.

Avec la multiplication des frameworks et des serveurs d'application, ça rend parfois les choses plus difficiles... Plutôt que de chercher quelqu'un qui aura appris à réfléchir sur certaines problématiques, on va rechercher quelqu'un qui aura passé X années sur le framework Machin.


Avec Go, c'est encore un langage de plus pour résoudre toujours les mêmes problématiques, sans forcément apporter de réelles innovations.

À mon avis:

• un langage vraiment innovant a peu de chances de devenir populaire car il tranche trop avec les habitudes de chacun (en particulier celles du chef de projet qui ne veut pas remettre en cause tout ce qu'il a appris pendant 20 ans)
• corolaire: un langage en passe de devenir populaire a peu de chance d'être vraiment innovant (à moins de faire d'énormes concessions, qui ne disparaîtront jamais complêtement pour des histoires de rétro-compatibilité), le reste est juste une question de marketing