Discussion :

[gorgonite]

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).

ici, je crois que c'est plus un problème avec les exceptions en soi, qu'avec leur utilisation dans un langage fonctionnel à type statique par inférence... parce que certains ardents défenseurs de C-ANSI te diront qu'avoir des exceptions n'apportent rien de plus qu'une bonne gestion des code de retour d'erreur.
ce qui d'un point de vue théorique n'est pas forcement faux, à l'exception des 4/5 lignes de code à ajouter systématiquement pour les gérer à chaque appel de fonction, là où le mécanisme des exceptions permettrait de considérer toute la partie où l'exception n'a pas été gérée comme une "transaction échouée"

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...

là tu demandes une gestion des exceptions "à la Java" au niveau du compilateur... là où beaucoup de Caméliens te diront de regarder les variants polymorphes
http://till-varoquaux.blogspot.com/2...g-nothing.html

[pseudocode]

parce que certains ardents défenseurs de C-ANSI te diront qu'avoir des exceptions n'apportent rien de plus qu'une bonne gestion des code de retour d'erreur.

heu... C'est quoi "une bonne gestion des code de retour d'erreur" par exemple pour une fonction "division", ou alors "lecture d'un octet dans un flux" ?

[gorgonite]

heu... C'est quoi "une bonne gestion des code de retour d'erreur" par exemple pour une fonction "division", ou alors "lecture d'un octet dans un flux" ?

Tu leur demanderas

[pcaboche]

ici, je crois que c'est plus un problème avec les exceptions en soi, qu'avec leur utilisation dans un langage fonctionnel à type statique par inférence...

Ce que je veux dire, c'est que ce n'est pas forcément bon de mélanger les paradigmes. Difficile de trouver un exemple éloquent...

là tu demandes une gestion des exceptions "à la Java" au niveau du compilateur... là où beaucoup de Caméliens te diront de regarder les variants polymorphes
http://till-varoquaux.blogspot.com/2...g-nothing.html

Très intéressant ce lien !

[lollancf37]

Il existe déjà vraiment beaucoup de langages de programmations différents. Et là, encore un de plus qu'il faudra donc "apprendre" avant de pouvoir utiliser ces outils.
Pour moi, c'est un langage de trop, on a déjà développé un peu tout ce qui est actuellement possible de faire dans les langages de programmations existants, développer un framework sur un langage existant serai peut être plus facile à prendre en main pour les développeurs intéressés par le dév Web (qui ont déjà leurs petites habitudes avec php par exemple).

La phase d'apprentissage d'un language n'est pas quelque chose de si terrible que ça, dans le sens où plus on en apprend dans le génie logiciel et plus on s'attache au concept plutôt qu'à la syntaxe ensuite c'est vraiment une question de pratique.

J'essaierai sûrement Go lorsque j'aurais le temps

[Camille_B]

Au sujet de Javascript :

Quelqu'un disait que Javascript était un langage "limité" et qu'il évoluait lentement à cause de l'ECMA. C'est assez faux. Javascript n'est limité dans son implémentation navigateur web que pour l'accès au FS pour les raisons de sécurité que l'on connaît, ce qui n'empêche pas la création d'une implémentation qui le permet (tel que seed ou gjs par exemple). En tant que langage il est plutôt bien conçu !

Allez trop vite ne sert de toute manière à rien puisqu'il reste toujours le problème de la compatibilité entre les navigateurs.

Réponse à Pcaboche : Non, tous les "nouveaux" langages ne sont pas des impératifs à qui on enlève le point-virgule (qui à dit Python) Il y a, par exemple, Clojure, qui est une sacrée tuerie (basée sur du très vieux) !

Et puis, en concurrent de Go, il y a Lisaac qui est autrement plus excitant.

[comode]

Bon bha je prend la conversation en cours et je viens mettre mes gros pied dans le plats, mais vu qu'a la base :

1 - la question était de savoir si GoLang est un langage de trop ou un truc interessant

2 - que je suis tombé sur le sujet via Google en recherchant des infos sur le sujet

Je me range du côté des gens intéressés. Je connais pas tous les langages du monde (genre le D qui revient souvent dans la discussion), j'en suis encore à chercher des infos sur celui-la, mais on me fait miroiter un langage compilé et rapide, un système de channel fort intéressant et une gestion des accès concurrents sans sémaphores, le tout servit open source. Je ne peux donc m'empêcher d'y voir un bon langage pour la programmation d'applications serveur.

[deadalnix]

Comme le D en fait

[Idelways]

Go : une nouvelle version du langage de Google améliore le support sous Windows
Et introduit des modifications significatives de sa syntaxe


Mise à jour du 03/02/2011 par Idelways


Une nouvelle version de Go, le langage de programmation open-source de Google, vient de voir le jour.

Estampillée « release.2011-02-01 » par l'équipe du développement du langage, cette version introduit des changements significatifs à la syntaxe des opérations sur les canaux et introduit de nouvelles améliorations au support dans les environnements Windows.

Les opérations non bloquantes sur les canaux ont été supprimées. Les sources utilisant ces opérations doivent donc être modifiées en utilisant l'instruction « Select » avec une clause « Default ».

Cette clause Default sera exécutée au cas où aucune autre clause n'est prête, ce qui empêcherait le blocage de la communication.

Les canaux en Go offrent un mécanisme permettant à deux fonctions concurrentes de synchroniser leurs exécutions et de communiquer entre elles en se passant une valeur d'un type d'élément spécifique.

Le package Log a aussi été modifié. Ses fonctions Exit, Exitf et Exitln ont été respectivement renommées Fatal, Fatalf et Fatalln.

Autre modification majeure, sous Windows, il est désormais possible d'écrire la fonction WndProc directement dans le langage Go et de recevoir ainsi toutes les entrées vers la fenêtre du programme.

Enfin, le port du langage sur le système d'exploitation « Tiny » a été officiellement arrêté, un port jugé non maintenu et non testé.


Pour mettre à jour votre version de GO, il suffit de lancer les commandes suivantes

Code :

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

1
2
hg pull
hg update release

Source : Mailing List de Go

Et vous ?

Que pensez-vous de ces nouveautés ?
Utilisez-vous le langage Go ? Dans quel type de projets ?

[camus3]

Au sujet de Javascript :

Quelqu'un disait que Javascript était un langage "limité" et qu'il évoluait lentement à cause de l'ECMA. C'est assez faux. Javascript n'est limité dans son implémentation navigateur web que pour l'accès au FS pour les raisons de sécurité que l'on connaît, ce qui n'empêche pas la création d'une implémentation qui le permet (tel que seed ou gjs par exemple). En tant que langage il est plutôt bien conçu !

Allez trop vite ne sert de toute manière à rien puisqu'il reste toujours le problème de la compatibilité entre les navigateurs.

javascript n'est pas limité , il est mal concu , avec des "bad parts" et absolument pas concu pour ce qu'on lui fait faire aujourd'hui.

Et rien n'empêche ECMA de faire une nouvelle version de javascript , puisque la balise script précise le type de script ainsi que sa version. Il suffit que les anciens navigateurs n'exécutent pas la nouvelle version , tout simplement.

Et ECMA est bien responsable de la situation pour avoir laisser yahoo et microsoft torpiller la version 4 de la spec.

JAVASCRIPT a des défauts de conception , c'est pour cela que la version 5 introduit un STRICT mode , personne ne peut le nier. Cela ne veut pas dire qu'on ne peut rien faire avec , cela veut surtout dire qu'il n'est pas la meilleurs solution pour un langage client censé être facile à pratiquer et souple. Javascript n'est ni souple ni facile puisqu'il a des pièges.

Enfin il faut faire la différence entre API et le langage lui même et ses types et fonctions de base.

[wokerm]

je ne connait pas le languages en question, mais si c'est pour un languages de plus et pour un choix de plus je ne dirai qu'une chose