Le langage Go (sous licence BSD) est issu d'une discussion entre Ken Thompson (un des auteurs d'Unix et d'UTF8) et Rob Pike (un des auteurs de Plan9 et d'UTF8). Nous avons donc affaire a de vrais barbus, des légendes de la communauté des codeurs ce qui explique la curiosité qui entoure ce projet de nouveau langage.
Comme Rob Pike travaille chez Google c'est donc avec le puissant soutien de son employeur que le langage Go a été développé avec les contraintes suivantes :
- Go doit pouvoir être utilisé pour de la programmation système donc c'est un langage compilé et pas interprété.
- La compilation doit être très rapide pour faciliter le développement des projets (l'analyse des dépendances permet une compilation en quelques secondes).
- La syntaxe doit être assez proche du C tout en corrigeant ses défauts les plus criants.
- La gestion de la mémoire doit être automatique (garbage collector)
- Le typage doit être statique mais il n'y a pas de hiérarchie des types pour simplifier le langage.
- La programmation concurrente (pour exploiter les multicores) doit être intégrée au coeur du langage. Cela se fait par l'intermédiaire des "goroutines" qui sont plus légères que les threads.
Go est le résultat de la très longue expérience de Thompson et Pike et la auteurs semblent assez fiers de leur rejeton :
"Go has fast builds, clean syntax, garbage collection, methods for any type, and run-time reflection. It feels like a dynamic language but has the speed and safety of a static language. It's a joy to use. "
La FAQ du projet évoque les questions générales et une FAQ spécifique est dédiée au langage lui-même. Un tutorial est aussi disponible avec, pour mettre en évidence le support d'UTF8, un assez inhabituel "Hello, world; or Καλημέρα κόσμε; or こんにちは 世界".
Pour l'instant les remarques sur le web se concentrent sur des points de détail: la syntaxe qui ne plaît pas à tous le monde, l'absence de telle ou telle fonction (comme les exceptions), etc.
Il faut attendre un peu pour que la poussière retombe et pour avoir des analyses qui se concentrent sur les apports spécifiques du langage: les goroutines, la segmentation de la pile d'exécution, la compilation rapide, etc.
Il sera également intéressant de lire des comparaisons détaillées avec les autres langages qui veulent s'attaquer au C en apportant des innovations techniques (comme par exemple le langage D).
L'annonce de Go sur LWN avec pas mal de commentaires intéressants.
Un article consacré à Go sur Astechnica.
Heise Online parle aussi de Go.
Enfin Wikipedia version anglaise et version française ont déjà des pages sur Go.
Journal Go : Un nouveau langage chez Google
11
nov.
2009
# Ah! C'est la saison de la galinette cendrée!
Posté par vladislav askiparek . Évalué à 1.
Merci pour ce journal intéressant. Je ne suis pas dev, mais ça fait plaisir de voir que ça bouge toujours de ce côté. Et ce d'autant plus si ce sont de bon vieux barbus qui se remettent au taf.
Il ne manquerait plus qu'un ado suédois nous ponde un Hurd OS avec ce nouveau langage.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Joël . Évalué à 1.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par ribwund . Évalué à 1.
Go est un langage système, pas un langage pour kernel.
Sinon j'aime bien les 4 premiers commits du repo hg:
http://code.google.com/p/go/source/list?r=1bc84c9f0f221196b4(...)
Finalement je ne sais pas si Go est un "vrai" projet Google, ou bien un projet sur les 20% de temps libre (ça permet de mesurer le soit-disant soutien de Google au projet).
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Thomas Douillard . Évalué à 5.
Sinon apparemment Go c'est un langage généraliste, qui se débarasse de ce que j'ai vu de toutes les vieilleries bas niveau obsolètes du C qui servent plus à rien du genre l'arithmétique des pointeurs.
C'est un vrai projet 100 % qui a démarré comme un projet de temps libre. Ça te rend un peu médisant sur le "soit disant" soutient, rien que le fait de financer des gens pour qu'ils fassent ce qu'ils veulent 20% du temps c'est un soutiens de google en soi ...
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par ribwund . Évalué à 4.
Pour le gc c'est surtout que les kerneleux n'aiment pas faire tourner un runtime du langage dans le kernel (surtout que un général il faut le réimplementer vu que le runtime d'espace utilisateur n'est pas utilisable directement).
Pour les vieilleries, il faudrait implementer une stack TCP/IP avec pour vraiment savoir si on en a toujours besoin ou pas :)
Finalement ils ont un compilo super rapide, mais qui n'implémente pas beaucoup d'optimisations. Quand ils disent 20% plus lent que du C, c'est a priori avec gccgo qui doit être beaucoup plus lent... du coup c'est un peu dommage d'avoir fait Yet Another Compiler plutôt que de targeter llvm (surtout que les blocs type Grand Central Dispatch doivent être un peu proche des goroutines).
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par jahrynx . Évalué à 2.
Pour le reste, je n'ai pas les compétences...
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Sylvain Sauvage . Évalué à 3.
Ici, le soutien n’a pas été mentionné avant, donc « sus- » n’est pas le bon choix.
De plus, il s’agit bien de porter un doute, une réserve, sur le soutien effectif ou officiel de Google (savoir si c’est du 20% ou un projet officiel).
Enfin, « so-called » (littéralement : ainsi-nommé) est tout aussi péjoratif que « prétendu » (ou « soi-disant »).
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par ribwund . Évalué à 1.
Pas vraiment:
http://www.merriam-webster.com/dictionary/so-called
commonly named : popularly so termed: the so-called pocket veto
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Moonz . Évalué à 3.
http://en.wiktionary.org/wiki/so-called
(idiomatic) So named; called by such a name, with a very strong connotation that the item is not worthy of that name.
(mathematics, sciences) Same as above, without the negative connotation.
http://dictionary.cambridge.org/define.asp?key=75376&dic(...) :
- used to show that you think a word that is used to describe someone or something is not suitable or not correct
It was one of his so-called friends who supplied him with the drugs that killed him.
- used to introduce a new word or phrase which is not yet known by many people
It isn't yet clear how destructive this so-called 'super virus' is.
http://www.thefreedictionary.com/so-called , synonymes :
Adj.1. so-called - doubtful or suspect; "these so-called experts are no help"
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
La pile TCP/IP, faut s'en séparer…
Elle a fait son temps et n'est plus adaptée (API de merde, limitée aux connexions fixes… La recherche a continué depuis la préhistoire !)
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Comment veux-tu passer à autre chose que IP sachant que IP V6 n'arrive même pas à s'imposer ?
"La première sécurité est la liberté"
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Et aussi "Pourquoi voulait-on des DVD alors que le LaserDisc n'arrivait même pas à s'imposer". IPV6 est une solution au NAT, mais pas la solution à tous les problèmes…
Ensuite, je parle de l'API et de TCP/IP, les deux mon général !
Pour l'API, j'ai été convaincu en essayant moi même il y a longtemps, et j'ai été conforté dans mon opinion par http://cacm.acm.org/magazines/2009/6/28495-whither-sockets/f(...) (si ton labo n'y est pas abonné, demande leur de le faire. C'est très bien comme magazine !)
Pour TCP/IP en soit, je te renvois sur Mobile IP par exemple (mais il existe d'autres solutions encore) : http://www.tcpipguide.com/free/t_MobileIPOverviewHistoryandM(...) et http://www.acm.org/crossroads/xrds7-2/mobileip.html
Tu vois, qu'un GC ralentisse mon kernel, je m'en tape complètement, comparé à toutes les pertes qu'on subit à ne pas implanter dès il y a 10 ans des technologies développées pour la mobilité et la distribution. Je pense que de simples statistiques sur le nombre de possesseurs de terminaux mobiles reliés à internet suffit à justifier le changement sans réfléchir plus que ça.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
On évite les GC dans les kernels *écrits dans des langages où on a collé un GC sans réflechir aux applications*.
Un GC, c'est pas un .so que tu lies, et hop c'est fini !
Un GC, ça s'optimise, ça se configure aux petits oignons tant en même temps qu'on crée le langage (son compilateur ou son interprète) et aussi en même temps qu'on développe son application.
Alors, certes, ça fait pas plaisir aux gens qui ne jurent que par un seul langage, mais on ne construit pas toutes les voitures avec une seule et unique clef à pipe…
On citait les machines Lisp plus bas, mais il me semble aussi que Lisaac possède un GC et qu'il a servi à prototyper un OS potable…
Ontologia, si tu nous lis, ton avis sur ce journal m'intéresse beaucoup !
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je pense simplement que Lisaac va plus loin dans certain cas (comme la gestion du parralèlisme).
Lisaac est aussi particulier parce que tout est en lib. Le GC aussi. Ce qui permet de "tuner" si besoin.
"La première sécurité est la liberté"
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Ontologia (site web personnel) . Évalué à 9.
Nicolas a en grande partie répondu à ta question.
Le GC est désactivable, et pour donner un exemple, il est désactivé dans le code du compilateur, au profit d'une gestion à la main assez rigoureuse. Comme tout est en lib, on peut tout à fait définir le delete de c++.
Benoit répète souvent "pas d'allocation à l'insu du programmeur", chose dont je comprend qu'il y a surement un intéret, mais dont je me fiche un peu et qui m'oblige à réfréner mes ardeurs à vouloir implémenter des features très haut niveau dans le langage ;-)
Donc comme disait Nicolas, tu peux faire ce que tu veux avec le GC, et je suis bien d'accord que ça dépend de la situation. Vu la cible de Lisaac (Embarqué, système), il risque de pas servir si souvent que ça....
Alors je répond à ta question, parce que c'est gentillement demandé et que ça a commencé à flipper sur la ML Lisaac.
De ce que j'ai compris de ce langage, particulièrement à lire http://golang.org/doc/go_for_cpp_programmers.html qui est vraiment instructif :
- Le système "objet" est marrant, original, mais j'imagine un peu limité.
En gros ça consiste à déclarer que des interfaces (ie des objets avec que des méthodes vides), et de dire qu'un truc est du type de cet objet si tu écrit une (ou plutot les) méthode qui appartient(nnent) à l'interface. Bon.. Je sens que ce genre d'approche c'est limité, et même limité ça peut péter au runtime.
Enfin on verra.
- Pas d'assertions ni d'exeptions. Bonjour le debug
- Compilation séparée, bonjour les perfs, surtout que là avec un embryon d'objet ça va commencer à poser quelques problèmes niveau perfs... T'as pas de VM pour rattraper le coup ici...
- Pas de redef des opérateurs. Change pas cela dit, par rapport à ce que la plupart des gens connaissent. (Nous, en Lisaac, on est assez fière de pouvoir écrire 45_020_089/8!.print )
- Langage avec pointeurs, en enlevant toutefois la possibilité de faire des conneries avec. Qui a dit bricolage ?
- Concurrence : correspond bien à l'état de l'art. Ca sera déterminant pour aider le langage à progresser.
Mais je pense que ce langage va marcher, car il rempli bien les condition définies par Richard P. Gabriel ( Models of Software Acceptance ) http://www.dreamsongs.com/Files/AcceptanceModels.pdf (relire cette présentation, c'est fabuleux !!) :
- Langage accessible sans nécessiter trop d'abstractions
- Gurus derrière
- Grosse boite derrière (pas de gambler ruin possible)
- Langage ressemblant à l'existant
- Langage au design relativement simple, cohérent et suffisant pour sa cible.
Plus généralement, c'est un langage construit à base de techno disponible dans l'industrie, donc un peu dépassée par ce qui se fait dans la recherche. C'est une approche pragmatique, mais qui a pas mal de limites.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par beagf (site web personnel) . Évalué à 7.
Ce serait pas le cas du C qui reste à ce niveau là un des meilleurs langage ? Et le cas du C++ aussi ?
De plus la compilation séparée n'est pas un élément du langage mais principalement du compilateur. C'est celui-ci qui choisit de considérer chaque module indépendament ou comme un tout.
- Pas de redef des opérateurs. Change pas cela dit, par rapport à ce que la plupart des gens connaissent. (Nous, en Lisaac, on est assez fière de pouvoir écrire 45_020_089/8!.print )
J'espère que tu blagues en disant ça ? Utilisé proprement et avec beaucoup de modération, la redéfinition des opérateur peut-être utile mais dans ton exemple, on peut se poser des question sur la signification du "!" et le ".print" à la fin est pas vraiment plus lisible et plus clair qu'une méthode classique.
En voyant ton exemple je me pause les question suivante :
- est ce que le "/" veut encore dire division ou est-ce qu'un boulet en a changer le sens ?
- est-ce que le "!" veut dire factorielle ou autre chose et si oui, qu'est-ce qui est vraiment calculer si la valeur n'est pas ntière ?
- entre le "/" le "!" et le "." qu'elle sont les règles de prioritées et donc est-ce qu'il va bien m'afficher le résultat du calcul et surtout faire le bon calcul ?
- Langage avec pointeurs, en enlevant toutefois la possibilité de faire des conneries avec. Qui a dit bricolage ?
On peut critiquer autant qu'on veut les pointeurs mais c'est comme la surcharge des opérateurs, dans les mains d'andouille qui font n'importe quoi ça pête dans tous les sens ; mais dans les mains de bon programmeur qui en usent sans en abuser et qui le font avec précautions, ça fait des choses magnifiques.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Au final, je trouve que cela fait un code bien plus simple que du code C (ou Ada) pour finalement avoir ce que l'on veut.
Sinon, pour les opérateurs, Fortran a aussi une bonne chose avec les opérateurs de la forme .machin. car cela permet d'avoir autant d'opérateur que l'on veux et pas que des signes cabalistiques dont on ne connaît plus la définition ensuite. Par exemple, il est assez facile de faire un opérateur .scalar. qui prend deux objets et retourne toujours un réel (produit scalaire) alors qu'avec l'opérateur *, on ne sais jamais de quel multiplication on parle...
Bref, les opérateurs du Fortran permettent d'écrire des formules en infixés comme souvent en math et donc que la formule dans le code soit le plus proche possible de la formule de la définition.
Cela est parfait dans le cadre du calcul numérique, ce qui n'est pas forcément le cas aujourd'hui de la majorité des codes que l'on manipule. Mais limiter les opérateurs aux seuls symboles est je trouve dommage.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Ontologia (site web personnel) . Évalué à 4.
J'espère que tu blagues en disant ça ? Utilisé proprement et avec beaucoup de modération, la redéfinition des opérateur peut-être utile mais dans ton exemple, on peut se poser des question sur la signification du "!" et le ".print" à la fin est pas vraiment plus lisible et plus clair qu'une méthode classique.
En voyant ton exemple je me pause les question suivante :
- est ce que le "/" veut encore dire division ou est-ce qu'un boulet en a changer le sens ?
- est-ce que le "!" veut dire factorielle ou autre chose et si oui, qu'est-ce qui est vraiment calculer si la valeur n'est pas ntière ?
- entre le "/" le "!" et le "." qu'elle sont les règles de prioritées et donc est-ce qu'il va bien m'afficher le résultat du calcul et surtout faire le bon calcul ?
On a les opérations infixées, préfixées, postfixées, ... Tu peux donc définir la priorité des opérateurs comme tu le souhaites. C'est fait pour pouvoir écrire tes formules au plus près de l'écriture mathématique classique.
45_020_089/8! fait environ 1116,56 donc il affichera ce résultat (print).
La division reste une division, la factoriel une factorielle.
Et on peut très bien implémenter factoriel dans la lib des réels (4 lignes de code) en prenant la valeur entière.
- Langage avec pointeurs, en enlevant toutefois la possibilité de faire des conneries avec. Qui a dit bricolage ?
On peut critiquer autant qu'on veut les pointeurs mais c'est comme la surcharge des opérateurs, dans les mains d'andouille qui font n'importe quoi ça pête dans tous les sens ; mais dans les mains de bon programmeur qui en usent sans en abuser et qui le font avec précautions, ça fait des choses magnifiques.
Des programmeurs "qui en usent sans en abuser et qui le font avec précautions" et qui sont capable de maitriser la chose, maintenant ça se compte sur les doigts de la main : va bosser dans des SSII, des boites ou on fait du logiciel de gestion, etc... Tu verras que très peu sont capable de faire du code propre sans qu'on soit constamment derrière leur dos, alors faire du code propre avec des pointeurs...
D'après toi pourquoi PHP, qui est un des langage les plus permissif et non rigoureux a eu un tel succès ?
Parce que le programmeur moyen a un niveau assez bas.
Faut faire des langages qui s'adaptent aux gens, pas l'inverse.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par beagf (site web personnel) . Évalué à 5.
L'intention est louable mais le problème c'est que ton code est illisible. Sans parenthèses je me demande toujours si je doit comprendre (45020089/8)! ou bien 45020089/(8!). Et le fait de pouvoir spécifier la priorité de ces opérateurs de manière différente suivant le type de données manipulée rend les choses encore pire.
Quand je vois les horreurs qui sont fait avec la surcharge des opérateurs en C++, je n'imagine même pas à quoi on finira pas arriver en Lisaac.
Des programmeurs "qui en usent sans en abuser et qui le font avec précautions" et qui sont capable de maitriser la chose, maintenant ça se compte sur les doigts de la main : va bosser dans des SSII, des boites ou on fait du logiciel de gestion, etc... Tu verras que très peu sont capable de faire du code propre sans qu'on soit constamment derrière leur dos, alors faire du code propre avec des pointeurs...
Pour récapituler : les pointeurs sont un outils très puissant dans les mains des bon programmeurs mais une grosse bombe à retardement dans les main des mauvais programmeurs.
Le problème est que l'on à peu près que des mauvais programmeurs. Donc on oubli les pointeurs, on va pas prendre de risque.
Pour tout dire, tu prend le paragraphe précédent et tu remplace pointeur par surcharge d'opérateurs et le texte reste parfaitement vrai.
Tu prend du C++ pondu en SSII et tu regardes à quoi sert la surcharge d'opérateur. Le plus souvent tu te retrouve avoir des objets qui s'additionne ou ce multiplie de manière complètement illogique et le code deviens incompréhensible et tout aussi dangereux qu'avec des pointeurs.
D'après toi pourquoi PHP, qui est un des langage les plus permissif et non rigoureux a eu un tel succès ?
Parce que le programmeur moyen a un niveau assez bas.
Faut faire des langages qui s'adaptent aux gens, pas l'inverse.
Le problème c'est que lorsque le niveau est si bas, il ne faut pas un langage permissif mais au contraire un langage extrêmement strict et très redondant afin que le compilateur puisse détecter le maximum d'erreurs et afficher des messages les plus clairs possible.
C'est pour cela que le PHP est une bouse infâme : il a une syntaxe qui lui permet de ne se préoccuper des erreur que le plus tard possible : en général quand il est trop tard. Ajoute à cela le fait qu'il est principalement utiliser sur des machine connectée au net et tu peut en déduire ce que je pense de ce langage.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Ontologia (site web personnel) . Évalué à 2.
L'intention est louable mais le problème c'est que ton code est illisible. Sans parenthèses je me demande toujours si je doit comprendre (45020089/8)! ou bien 45020089/(8!). Et le fait de pouvoir spécifier la priorité de ces opérateurs de manière différente suivant le type de données manipulée rend les choses encore pire.
Quand je vois les horreurs qui sont fait avec la surcharge des opérateurs en C++, je n'imagine même pas à quoi on finira pas arriver en Lisaac.
Quand tu écris la formule sur une feuille, tu écris bien
45020089
-------------
8!
Non ?
Le but est de pouvoir l'écrire au plus proche de cela.
Pour le reste, je suis d'accord avec toi ! Pas réfléchi ça peut vite devenir catastrophique, mais d'ici là qu'on ait au moins 100 personnes dans le monde qui codent régulièrement en Lisaac, on aura j'espère eu le temps d'écrire une bonne lib de maths qui fassent des opérations usuelles avec une syntaxe sympa et des priorités d'opérateurs réfléchis.
Autant les pointeurs, on peut, à mon avis, s'en passer, autant la surcharge des opérateurs est un réel plus, pour faire des libs sympa, réfléchies.
Mais bon, on verra...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Mildred (site web personnel) . Évalué à 1.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par beagf (site web personnel) . Évalué à 2.
45020089
-------------
8!
tu peut aussi écrire :
45020089
--------------- !
8
Quand tu écrit la division sous cette forme, ça revient à mettre des parenthèses. Dans ton code par contre l'ambiguïté demeure.
Et que ce soit programmé par des gens avec de bonnes intentions et le faisant de manière très logique ne change rien au problème. Avoir le même opérateur avec une priorité différente et une sémantique différentes suivant le type rend le programme beaucoup plus difficile à lire.
Si tu surcharge les opérateurs pour un type vecteurs par exemple, il devient naturel de ce demander si le '*' correspond au produit par composantes, au produit vectoriel au produit scalaire. Tu trouvera toujours des gens plein de bonnes intentions qui trouverons des raison parfaitement valable de choisir l'un plutôt que l'autre.
Le gros problème c'est que quand tu te retrouve face à leur code, tu te demandera toujours si le mec qui à codé la lib à la même logique que toi.
C'est, pour moi, un des plus gros points noir du C++. Combien de fois je me suis retrouver devant un code ou un mec à cru malin de redéfinir les opérateur pour rendre son code plus concis par la suite et en théorie plus clair... la plupart du temps tout ce que l'on obtient c'est un code extrêmement difficile à débugger car une expression qui semble évidente fait quelque chose auquel on aurait même pas penser dans nos pire cauchemars.
Donc, la surcharge d'opérateur est pour moi quelque chose d'encore plus dangereux que les pointeurs car ses effets pervers peuvent être quasiment invisibles, là ou un pointeur est bien visible. Quand je vois un pointeur, je sais que je dois faire particulièrement attention, pour les opérateur, il est dur de dire s'il y a danger ou pas.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Ensuite, une formule de Math doit avoir des paranthèses dès que l'on dépasse quelques opérations car la aussi, l'interprétation ne doit jamais être confuse. Même sur le papier, je met des parenthèses...
En calcul numérique, on a trop souvent un code qui tourne mais avec un mauvais résultat. Il faut donc que les formules soit le plus facile à contrôler pour éliminer les bogues le plus facilement possible.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Mildred (site web personnel) . Évalué à 3.
Quand je vois les horreurs qui sont fait avec la surcharge des opérateurs en C++, je n'imagine même pas à quoi on finira pas arriver en Lisaac.
On ne peux pas en Lisaac mélanger des opérateurs avec des types différents. Le compilateur ne s'en sort plus sinon.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Mildred (site web personnel) . Évalué à 2.
Le GC est désactivable, et pour donner un exemple, il est désactivé dans le code du compilateur, au profit d'une gestion à la main assez rigoureuse. Comme tout est en lib, on peut tout à fait définir le delete de c++.
Le GC ne marche plus du tout en fait.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Interrogations...
Posté par khivapia . Évalué à 8.
La gestion de la mémoire doit être automatique (garbage collector)
http://fr.wikipedia.org/wiki/Programmation_syst%C3%A8me
S'il faut un langage compilé pour obtenir de meilleures performances, pourquoi en faire un langage à gestion automatique de mémoire ? plutôt que d'utiliser de simples aides à la gestion comme les pointeurs intelligents, qui n'impactent pas les performances mais gardent la souplesse et la puissance d'une gestion manuelle ?
Linus Torvalds disait qu'il ne voulait pas de C++ dans le noyau Linux car il a tendance à cacher la gestion de la mémoire, qui est un élément trop important pour être laissé à de simples algorithmes. En programmation système c'est la même chose en général (gestion fine des ressources, la mémoire en particulier en fait partie).
En plus avec un garbage collector, le côté "temps réel" est beaucoup plus délicat à assurer (typiquement on a beaucoup de mal à régler le moment où il doit se déclencher et les mauvais cas sont fréquents).
Ça me paraît donc un peu aninomique, surtout qu'en compilant vite (ce qui est un objectif prioritaire du langage) on ne pourra pas profiter de beaucoup d'optimisations de la part du compilateur.
Ça s'apparente donc plutôt une sorte de langage de script compilé, avec une syntaxe proche du C. Mais alors les langages de scripts les plus utilisés sont vraiment si lents que ça par rapport à du code compilé en natif mais avec peu d'optimisation ? (la Faq sur le langage parle de python en disant que ce n'est pas efficace, les développeurs Python devraient apprécier ; il devrait être possible de développer un compilateur python rapide non ? ) http://golang.org/doc/go_lang_faq.html
Bref je ne comprends pas trop la position du langage par rapport à ses concurrents, au niveau des performances voulues/atteintes. En revanche les idées derrière l'implémentation de la concurrence sont intéressantes.
[^] # Re: Interrogations...
Posté par ribwund . Évalué à 3.
Parce que c'est l'enfer quand on commence à faire de la programmation parallèle.
D'autre part, programmation système != programmation kernel, ce n'est pas du tout évident que Go soit adapté pour la programmation kernel. A priori ils s'interessent aux programmes systemes (serveurs, base de données, etc.).
Ça me paraît donc un peu aninomique, surtout qu'en compilant vite (ce qui est un objectif prioritaire du langage) on ne pourra pas profiter de beaucoup d'optimisations de la part du compilateur.
La rapidité de compilation c'est surtout un side effect d'avoir écrit le compilateur from scratch. Ça risque de devenir plus lent avec les optimisations, même si le design du langage permet de conserver une certaine rapidité (surtout dans les couches hautes: la grammaire et la gestion particulière des modules doivent aider).
la Faq sur le langage parle de python en disant que ce n'est pas efficace, les développeurs Python devraient apprécier ; il devrait être possible de développer un compilateur python rapide non ?
C'est très dur (il suffit de voir depuis quand pypy existe), python est un langage trop dynamique pour le compiler/JITter efficacement. Alors que Go possède un système de type entièrement statique (que je trouve assez élégant, c'est une sorte de duck typing statique).
[^] # Re: Interrogations...
Posté par Gof (site web personnel) . Évalué à 3.
[^] # Re: Interrogations...
Posté par Vador Dark (site web personnel) . Évalué à 6.
Dans un programme en C, le développeur gère complètement les malloc/free. En C++, le simple fait de fermer une accolade peut avoir pour effet de détruire un objet, qui va en détruire d'autres par ricochets. De simples appellent d'opérateurs sur des objets peuvent provoquer des créations/destructions d'objets.
Ce n'est en principe pas un problème, mais je comprends que le noyau ne soit pas le meilleur endroit pour ce genre de choses.
[^] # Re: Interrogations...
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
C'est pour ça que je mets pas ma tasse à café près de l'ordinateur quand je fais du latex.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Interrogations...
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Quel rapport entre la vitesse et la gestion de la mémoire ?
>> En plus avec un garbage collector, le côté "temps réel" est beaucoup plus délicat à assurer (typiquement on a beaucoup de mal à régler le moment où il doit se déclencher et les mauvais cas sont fréquents).
Ben, tu prends un GC temps-réel, et hop.
Ou alors un GC-hybride…
Choisir son GC fait aussi partie du développement d'une appli ou du choix d'un langage pour un problème donné…
>> Mais alors les langages de scripts les plus utilisés sont vraiment si lents que ça par rapport à du code compilé en natif mais avec peu d'optimisation ?
Ça dépend du langage. Perl, Python et Ruby sont des gros bousins que personne de sensé ne veut compiler, car la sémantique de ces langages est une horreur pour tout écrivain de compilateurs (attention, je ne dis pas que les langages sont des horreurs, juste leur sémantique). Inversement, Scheme se compile très bien…
Après, je te rappelle que les langages de scripts peuvent aussi se compiler, non seulement vers du code machine, mais aussi pour une VM…
[^] # Re: Interrogations...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Si tu as un GC le codeur à tendance à être sale et à créer/détruire plein d'objets, ce qui est couteux. En C, tu as naturellement le réflexe de réutiliser les objets pour des raisons de facilité, or c'est le plus performant.
>> Mais alors les langages de scripts les plus utilisés sont vraiment si lents que ça par rapport à du code compilé en natif mais avec peu d'optimisation ?
Si tu regardes le langage shoutout, on peut estimer à un facteur 10 en moyenne la différence de performance entre du C et un script. Parfois, c'est bien pire.
"La première sécurité est la liberté"
[^] # Re: Interrogations...
Posté par khivapia . Évalué à 3.
D'un autre côté une fois qu'on a un interpréteur correct, c'est qu'on a réussi à appréhender la sémantique justement... Et de là à en écrire un compilateur (au moins vers une machine virtuelle), la marche est moins haute.
D'ailleurs comme tu le dis il existe des compilateurs pour langages de script vers du byte code (une référence se trouve ici, pour python 2.5.2 http://www.python.org/doc/2.5.2/lib/bytecodes.html ). Les opérations d'icelui sont naturelles pour un langage de bas niveau, et ne sont pas "beaucoup" plus haut niveau que de l'assembleur pur. Mis à part un linker il ne manque pas grand-chose au niveau analyse sémantique pour compiler finalement complètement le langage vers du code machine.
[^] # Re: Interrogations...
Posté par Thomas . Évalué à 1.
Un GC ne se contente pas de libérer la mémoire, il peut aussi éviter sa fragmentation.
typiquement on a beaucoup de mal à régler le moment où il doit se déclencher et les mauvais cas sont fréquents
Un bon GC peut être désactivé/réactivé. Tu peux forcer un GC quand ça t'arrange. Et dans le cas des GC générationnels (dont sont dotés les langages que j'utilise) tu peux même spécifier quelle génération collecter. Pour finir un bon GC est souvent configurable.
Jette un oeil du côté des SBCL ou CCL. Je n'ai jamais eu de longue pause pour le GC avec ceux-ci. J'ai plutôt l'impression que ce préjugés date un peu. Ou alors ce sont les GC de Perl/Python/Ruby (qui ne sont pas très évolués) qui ont engendré cette mauvaise image.
[^] # Re: Interrogations...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Interrogations...
Posté par reno . Évalué à 2.
IBM a un Java avec un GC temps reel.
[^] # Re: Interrogations...
Posté par Thomas . Évalué à 2.
Sinon comme dit tu peux désactiver le GC pendant les phases plus critiques de ton code. Et il existe d'autres techniques. J'ai lu que chez Orbitz ils mappaient d'énormes fichiers en C++, la partie Lisp les manipulant via des pointeurs (donc un fixnum, le GC ne voyait pas les données). Il y a un message à ce sujet sur google groups, je vais voir si je peux remettre la main dessus.
Sinon j'ai pas d'exemples de temps réel dur dans un environnement à GC.
[^] # Re: Interrogations...
Posté par Thomas . Évalué à 3.
http://www.paulgraham.com/carl.html
Sinon en tapant real time garbage collector dans google on trouve beaucoup de trucs intéressants, genre http://lambda-the-ultimate.org/node/2393 (où dans les commentaires quelqu'un évoque SuperCollider)
# Certaines choses bizarres
Posté par Sphax . Évalué à 3.
- la visibilité d'un champ/d'une méthode qui se définit par le nom (uppercase ou non)
- la définition d'une méthode qui est en fait une fonction normale avec un truc en plus
D'un autre côté, j'aime bien le fait qu'on puisse retourner plus d'une valeur dans une fonction
Par contre, est-ce qu'il y a la possibilité d'utiliser des bibliothèques existantes ? (Qt, GTK, etc) Si c'est pas le cas ça freinerait quand même pas mal l'adoption pour des applis desktop. Mais peut-être que c'est pas leur but.
[^] # Re: Certaines choses bizarres
Posté par zebra3 . Évalué à 3.
Étant donné que Go est conçu pour de la programmation système, j'imagine que les applications de type desktop ne sont pas du tout leur cible.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Certaines choses bizarres
Posté par Misc (site web personnel) . Évalué à 7.
Et puis, ç'est pas parce que c'est pas la cible que les gens vont pas l'utiliser pour ça :)
[^] # Re: Certaines choses bizarres
Posté par Grunt . Évalué à 3.
Ça ne m'étonnerait pas que des "bindings" apparaissent si Go intéresse suffisamment de développeurs.
Après tout, Python (par exemple) n'est pas né avec des bindings GTK et Qt, mais maintenant il y en a.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Certaines choses bizarres
Posté par Philippe F (site web personnel) . Évalué à 2.
Donc plutôt bof a priori pour Qt, possiblement OK pour Gtk.
[^] # Re: Certaines choses bizarres
Posté par Mildred (site web personnel) . Évalué à 2.
http://live.gnome.org/GObjectIntrospection/
[^] # Re: Certaines choses bizarres
Posté par Philippe F (site web personnel) . Évalué à 2.
Le modèle de classe / méthode me fait penser à la simplicité de lua, ce qui permet de l'optimiser à donf sans passer par des tables de fonctions virtuelles.
Globalement, ça me plait.
# Get back ?
Posté par Elfir3 . Évalué à 4.
http://code.google.com/p/go/issues/detail?id=9&colspec=I(...)
[^] # Re: Get back ?
Posté par BAud (site web personnel) . Évalué à 4.
Gogue (*) ?
:D
(*) http://fr.wiktionary.org/wiki/gogue
[^] # Re: Get back ?
Posté par Gniarf . Évalué à 5.
[^] # Re: Get back ?
Posté par zebra3 . Évalué à 8.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Get back ?
Posté par Kerro . Évalué à 4.
Mais le pire, c'est que "Go", c'est franchement nul de chez nul pour faire des recherches. Si je recherche "python array" et "go array" je ne vais clairement pas avoir la même qualité au niveau des résultats.
[^] # Re: Get back ?
Posté par Krunch (site web personnel) . Évalué à 10.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Get back ?
Posté par Dr BG (site web personnel) . Évalué à 4.
[^] # Re: Get back ?
Posté par B16F4RV4RD1N . Évalué à 2.
Je suis d'accord, le nom "go" est trop générique et court pour le rendre pertinent lors d'une recherche d'information, c'est nul comme nom. Tiens, pourquoi pas "null" comme nouveau nom ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Get back ?
Posté par Larry Cow . Évalué à 10.
Sans déconner, ça pourrait avoir un succès mondial ce truc!
(pardon, fatigue, tout ça)
# Programmation noyau et ramasse-miettes
Posté par Camille_B . Évalué à 6.
Or je ne puis m'empêcher de penser aux machines LISP. Leur OS était programmé en LISP, et LISP utilise les GC depuis un bout de temps. De plus faut-il rappeler que les LISP sont généralement dynamiquement typés ?
Questions : ces systèmes LISP furent-ils programmés sans GC et avec typage statique ? Si tel n'est pas le cas qu'est-ce qui explique qu'elles furent non seulement fonctionnelles, mais puissantes et relativement peu buggées (si j'en crois ceux qui en ont eus entre les mains) ? La structure même de la machine ?
[^] # Re: Programmation noyau et ramasse-miettes
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Alors non, ce n'était pas dépourvu de bugs (car les dialectes de LISP étaient nombreux, et pas forcément aussi agréables que l'actuel Common Lisp), tout comme le rappelle Joe Marshall dans son très bon blog où il raconte des histoires de debuggage qu'il a vécues dans les années 80 [1].
Mais bon, les GC d'alors, c'était pas la panacée, hein. Ni les interprètes et compilateurs…
Sinon, tu dis : « De plus faut-il rappeler que les LISP sont généralement dynamiquement typés ? », mais je ne vois pas le rapport avec le GC. Enfin, avec le typage dynamique, tu as un tag sur tes données, donc le GC sais différencier un entier d'une adresse, une chaîne de caractères d'un symbole… Ça se nettoie très bien tout ça.
Puis le typage dynamique n'impose pas qu'on ne type rien ! T'as pleins d'optimisations de typage local, d'évaluation partielles qu'on peut faire quand même…
[1] : http://funcall.blogspot.com/2009/03/talk-to-greenblatt.html cette série d'articles s'étale sur plusieurs mois.
[^] # Re: Programmation noyau et ramasse-miettes
Posté par Camille_B . Évalué à 1.
[^] # Re: Programmation noyau et ramasse-miettes
Posté par Gniarf . Évalué à 4.
faudrait ressortir d'autres architectures comme euh les calculateurs HP 48 et compagnie, on ne savait pas forcément où ça commençait et où ça s'arretait, quand encore c'était documenté...
(et, hop, plein d'objets de base déjà en ROM ! plus besoin de les jeter, dis-donc !)
# L'oublié
Posté par benja . Évalué à 1.
Sinon c'est chouette d'avoir un nouveau dans la classe. On verra s'il tient ses promesses. En tout cas, il a l'air déja plus sympa qu'Alef, le language concourrant de l'illustre Plan9 :-)
[^] # Re: L'oublié
Posté par patrick_g (site web personnel) . Évalué à 2.
Tu a raison j'aurai du donner aussi son nom. Mea culpa.
[^] # Re: L'oublié
Posté par Vivien MOREAU . Évalué à 1.
L'ex-langage concurrent de Plan9, d'ailleurs :-)
Ça pourrait être très sympa d'ailleurs, sous Plan9.
# Quelques petites rectifications et une question
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Maintenant, Rob Pike, le concepteur du langage du même nom, avec, apparemment, l'aide de Ken Thomson, envisage de remettre à plat le C au travers du langage Go. Espérons qu'il ait plus de succès qu'avec Plan9 qui méritait tout de même de réussir.
Toutefois, je me pose une question : est ce que de nos jours un langage de programmation système doit être impératif pour réussir ou être efficace ? Un langage fonctionnel ne pourrait il pas aussi être pertinent dans la programmation système ?
[^] # Re: Quelques petites rectifications et une question
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Quelques petites rectifications et une question
Posté par Victor . Évalué à 3.
[^] # Re: Quelques petites rectifications et une question
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Toutefois, ta réponse est pertinente au sens où un des principes des langages fonctionnels est d'être libre d'effets de bords, principe qui a dérivé d'ailleurs vers plutôt la maîtrise des effets de bords (parce qu'il est impossible d'être sans effets de bords ; notre univers n'est il pas entropique ?). Au regard de ceci, on peut douter effectivement de la pertinence de l'usage d'un langage fonctionnel dans la programmation système. A côté de ça, sa maîtrise des effets de bord fait que la programmation fonctionnelle semble, à l'heure actuelle, plus propre et efficace à répondre aux problèmes du parallélisme. (Et le langage Go semble avoir été écrit aussi pour répondre aux défis que posent maintenant les architectures multi-cœurs.)
En fait, lorsque je posais cette question, j'avais plus en tête son modèle déclaratif qui apporte une approche intéressante dans la résolution des problèmes ; j'ai l'impression de plus en plus que les solutions à nos problèmes informatiques se traduisent plus facilement dans une approche fonctionnelle qu'impérative.
[^] # Re: Quelques petites rectifications et une question
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Quelques petites rectifications et une question
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Les monads sont des structures qui enferment la notion d'effet de bord et pour lesquels un ensemble d'opérations est défini. On y trouve par exemple IO pour les entrées/sorties, X pour l'affichage graphique (dans XMonad), State pour la gestion des états, etc. Les monads obéissent en général à un certain nombre d'axiomes. Ceci permet de singulariser et d'identifier les effets de bords dans le but d'éviter de les repartir dans tout le code.
J'ai trouvé un lien que je pense intéressant pour un peu saisir le concept de monad :
http://www.haskell.org/haskellwiki/Monad
[^] # Re: Quelques petites rectifications et une question
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
http://www.reddit.com/r/programming/tb/1761q
J'ai compris qu'il teste en gros la validité d'un paramètre avant qu'il plante. Cela semble tellement sans intérêt !
http://sleepingsquirrel.org/monads/monads.html ici il essaye de le faire en perl.
En gros, il montre comment lier des opérations entre elle. Pourquoi ne pas utiliser une variable qui sert à identifier le flot au lieu d'utiliser une fonction explicite de lien est un mystère.
"La première sécurité est la liberté"
[^] # Re: Quelques petites rectifications et une question
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Pour l'implémentation en Perl, elle est longue et je ne l'ai que rapidement lu. Son objectif semble de modéliser en Perl les monads (structure qui implémente la notion de changement d'état et qui implique donc aussi une séquence nécessaire des opérations). Ici l'objectif est de prendre une valeur monadique (autrement dit une variable) et d'appliquer sur celle-ci des fonctions pour en ressortir une autre valeur monadique. (De cette valeur monadique, on peut en sortir une valeur pure qui peut donc ne plus être modifiée.) Avec bind, on peut appliquer une fonction pure sur des valeurs monadiques. En singularisant les effets de bords, on peut plus facilement les contrôler. Après, selon le langage, ça peut rendre le code lourd.
[^] # Re: Quelques petites rectifications et une question
Posté par benoar . Évalué à 2.
Parce qu'une variable, comme tu la penses, représente ton effet de bord. On est revenu au point de départ.
Dans un langage fonctionnel, tu n'as pas de variable au sens "impératif", donc tu ne peux pas utiliser ta "simplification". (OK, l'implémentation était ici faite dans des langages impératifs, c'est tentant de les utiliser ...)
Les monades (avec un "e" en français, il me semble) sont assez complexes, et on met beaucoup de temps à les comprendre (plusieurs années pour moi, sans y être à plein temps dessus quand même). Mais c'est une notion vraiment assez géniale à découvrir, même si, selon moi, sa complexité fait que ce ne sera jamais quelque chose que beaucoup de gens utiliseront.
[^] # Re: Quelques petites rectifications et une question
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Euh, une monade, en pratique (i.e. en programmation Haskell), c'est rien d'autre qu'un vulgaire design-pattern.
T'as une interface (les types des opérateurs), et les gars se masturbent pour coller tout et n'importe quoi qui colle à cette interface…
Des monades, j'en code en OCaml, en Scheme et en Common Lisp quand c'est pratique (typiquement la monade non déterministe (c-à-d la monade Liste)), sinon, je me fais pas chier…
Les monades, d'un point de vue catégorique (au sens mathématique du mot « catégorie », là, sont moins faciles à comprendre, oui), mais t'as aucunement besoin de comprendre ça pour coder en Haskell. Ça, c'est de la propagande ridicule (« wéé ! on a des monades, c'est trop top ») trop souvent clamée par des « newbies » qui n'ont rien compris mais qui se donnent l'impression d'appartenir à une classe de gens supra-intelligents. Dire « j'ai pu résoudre mon problème grace aux monades d'Haskell, » c'est comme dire « j'ai pu résoudre mon problème grace au pattern décorator de Java. » Comme si on pouvait pas faire autrement, ni avec un autre langage…
[^] # Re: Quelques petites rectifications et une question
Posté par Thomas Douillard . Évalué à 5.
Par contre, il me semble que les monades en théorie de la programmation fonctionnelle, c'est pour que le langage garde son accès "pur" en n'ayant pas d'effets de bords pour garder les bonnes propriétés de la programmation fonctionnelle, intuitivement je dirai en se démerdant pour avoir l'état du système entier en paramètre de la fonction ...
Ça peut se voir comme un design pattern, genre un couple (valeur encapsulée*état du système) plus les fonctions générique qui permettent de construire et de manipuler ce type, et les fonctions d'ordre supérieur qui encapsulent des fonction qui traitent de la valeur ...
D'un autre côté ça permet de voir l'état du système non plus comme une variable globale qu'on modifie mais comme un "paramètre" d'une fonction qui retourne un autre état du système, c'est l'artifice qui permet de garder la pureté du langage ... j'ai bon ;) ?
[^] # Re: Quelques petites rectifications et une question
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Des gens font ça tous les jours dans d'autres langages, y compris C (quand tu passes un pointeur vers une donnée à toute tes fonctions, genre ta surface en SDL, ta socket en réseau).
S'ils mettaient une macro pour ne plus avoir à taper à chaque fois le code redondant, ils utiliseraient la monade IO (ou la monade State) sans le savoir !
En revanche, l'idée d'encapsulation, elle, est meilleure.
Quand tu écris
do
x <- extraction
return (foo x)
c'est comme si tu écrivais
do
x <- extraction_hors_de_la_boite(boite)
met_dans_une_boite(foo x)
Sauf que l'extraction et la remise en boite, même si elles paient pas de mine là, sont en fait des fonctions qui peuvent être plus ou moins compliquées.
C'est bien un design pattern, comme tu le décris. Son avantage est d'être *très* généraliste.
Là où les dp usuels sont « limités » (un décorateur est un décorateur et n'est pas un visiteur), la monade est très configurable car l'interface ne dit rien d'autre que « ça doit typer, sinon ton algo est buggé ! »
Le concept mathématique est pas utile pour la programmation haskell. Ni pour la programmation. Les monades, c'est des foncteurs (ou un triplet de foncteurs ? je ne sais plus) dans des catégories, dans un modèle du lambda calcul simplement typé. Et c'est aussi utile pour programmer que de savoir comment représenter mathématiquement la tenue de l'encre sur le papier quand on veut juste savoir écrire.
Attention, je dis pas que c'est inutile ! J'ai bouffé des monades (mathématiques) en cours, des catégories, des power-domains, et j'en ai redemandé à l'époque. Mais à moins que tu ne cherches à faire de la sémantique dénotationnelle au niveau professionnel (recherche académique), pas la peine de se prendre la tête dessus.
T'as bien plus intérêt à te pencher sur les bases. Si tu ne sais pas pourquoi/comment on est arrivé aux catégories comme modèle et comment ça marche, alors il est vain de vouloir comprendre des concepts plus poussés qui reposent dessus.
Si néanmoins t'est un peu timbré, je te conseille l'excellentissime livre "The Scott Trachey Approach".
De mémoire t'as pas de monades, mais t'auras certainement du mal à le comprendre même en le lisant deux fois si t'as pas suivi de cours de maths et de sémantique avancées ^^
[^] # Re: Quelques petites rectifications et une question
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
[^] # Re: Quelques petites rectifications et une question
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Suffit de tout coder dans la monade IO. C'est comme en POO : tu peux tout faire dans une seule classe et envoyer balader ces classes, ces interfaces et tout ça. Je peux « coder en C » aussi bien en Haskell qu'en Java.
Ce qui garde les effets de bords à un strict minimum, c'est le programmeur. J'en met là où j'en veux, quelque soit le langage.
Quand à la soupe (et haskell), j'aime et je trouve ça bon. En revanche, je n'aime pas qu'on dise « c'est grâce aux monades » quand ça n'a pas grand chose à voir… Mon code est quasi identique en OCaml et en Haskell, pourtant, en ML, je peux mettre des effets de bord partout…
La « pureté » n'a raison d'être qu'au niveau des types, dans la formalisation mathématique. En pratique, ça change que dalle. Ah si, ça te prend 3 fois plus de temps quand tu veux tracer ton code (bon, t'as des moyens, mais ça vaut pas un printf placé ça et là…)
[^] # Re: Quelques petites rectifications et une question
Posté par Dr BG (site web personnel) . Évalué à 4.
En français on dit monade, c'est un concept mathématique et pas juste une particularité d'Haskell. N'hésitez donc pas à ajouter un « e ».
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.