Chez toi à Bayonne il faut également faire remarquer que c'est le départ de la vélodyssée, une quasi voie verte de 1200 kilomètres. Hors quand on arrive par la gare avec les enfants, les sacoches et tout le tintouin, on se demande bien où aller (la gare est juste au dessus du rond point en question) ni vers le centre ville, ni vers la voie verte, du coup tant pis pour la visite on a repris le train pour aller à la gare juste après (Ondre je crois) pour enfin se retrouver en sécurité. Pitoyable pour une ville de cette renommée…
Je ne parle pas uniquement du passage de python 2 à 3 mais du refactoring en général, c'est la seule chose qui m'est pénible en Python, du coup en règle générale je m'abstiens, et donc même punition quand je me pose la question de migrer du code vers python 3.
C'est Guido lui-même qui m'a mis la puce à l'oreille en s'intéressant de plus en plus au typage statique. Ca m'a tellement surpris que du coup j'ai essayé en Go et sur le peu de projets que j'ai démarré c'est loin d'être illusoire, au contraire je me régale à refactoriser. Ca facilite du même coup l'optimisation en ayant beaucoup moins peur de casser quelque chose.
Je ne pense pas que Dropbox ait décidé de migrer vers Go uniquement pour des problèmes de performances, tant qu'à tout réécrire il y avait d'autres solutions plus proches de python, pypy, cython etc.
Pour en revenir au schmilblick, que penses-tu de mercurial ? L'outil qui s'enterre lui-même en refusant de suivre l'évolution de ses dépendances ?
C'est inquiétant car comme le montre très bien la discussion sur le passage vers git+github, le côté social est de plus en plus important, c'est également le côté social qui a modelé Go (formatage du code, outils, multiplateforme…). Paradoxalement à ce qu'on pourrait croire par rapport à ce que j'écris c'est ce qui me fera rester en Python, je ne lâcherai pas l'écosystème Python de si tôt.
Qui a abandonné l'autre en premier tu veux dire ?
Est-ce que python3 ne s'abandonne pas tout seul d'ailleurs ?
GvR bosse chez Dropbox qui produit pyston qui reste focalisé sur python2 et risque fort d'être abandonné également puisqu'ils migrent finalement leur partie critique en Go…
GvR s'intéresse de plus en plus au typage statique.
« What did you work on for your Hack Week project?
Static typing for Python. »
« Why did you choose static typing for your project?
I think that at least adding static typing as an optional part of Python is a good thing for the distant future. I also think that this particular tool may be able to help Dropbox convert our own Python 2-based codebase to Python 3. »
J'ai l'impression, et je le constate sur mes projets perso, que les migrations de versions sont vraiment LE problème des langages dynamiques.
Oui, c'est ce que je voulais dire par pointe d'accélération.
Ce serait difficile à faire admettre aujourd'hui tel quel du jour au lendemain. Mais dans une optique ou les cyclistes et les piétons se rapproprieraient la rue en conséquence ça redeviendrait tout à fait naturel.
Et surtout ça me semble être la solution la plus simple et la moins onéreuse ! On y vient petit à petit avec la généralisation du 30km/h et les "zones de rencontres".
Le cloisonnement peut être utile sur les voies rapides, autoroutes, voies vertes…
Mais en zone urbaine le vélo va en moyenne aussi vite voir plus vite que la voiture donc il est inutile de les séparer. Au contraire, le fait de les mélanger permet de ralentir la circulation jusqu'à une vitesse acceptable même pour les piétons. La vitesse moyenne vélo/voiture en ville est de 15km/h d'après l'ADEME. La distance de trajet est inférieure à 3km, donc inutile aussi d'occuper tout l'espace public par des parkings.
Il y a juste un problème de disproportion sur l'espace occupé qui permet à la voiture de faire des pointes d'accélérations inutiles, dangereuses et polluantes, dissuadant ainsi tous les modes de transports actifs et ainsi de suite.
Les automobilistes sont les plus durement touchés par les taxes / lois répressives alors que les piétons / vélos / cyclo / moto en sont épargnés.
Les piétons ont la loi la plus répressive possible puisqu'ils sont les premières victimes des accidents.
Les automobilistes payent quelques taxes de bonne conscience mais globalement l'automobile, avec toute l'infrastructure qui va avec et le coût des dégâts causés est très largement assumé et subventionné par la collectivité, piétons compris.
Dernièrement, subvention pour une voiture électrique : 10000€, 0€ pour un vélo électrique, indemnité kilométrique vélo plafonnée. Loi Laure, la seule qui aurait pu nous laisser un peu respirer est complètement bafouée. http://www.lcp.fr/emissions/l-echo-des-lois/vod/175176-pollution-de-l-air-une-loi-a-bout-de-souffle
L228-2
A l’occasion des réalisations ou des rénovations des voies urbaines, à l’exception des autoroutes et voies rapides, doivent être mis au point des itinéraires cyclables pourvus d’aménagements sous forme de pistes, marquages au sol ou couloirs indépendants,
Mais la phrase se termine par :
en fonction des besoins et contraintes de la circulation.
Et puis d'abord il faudrait un permis pour avoir le droit de marcher, les enfants, les handicapés et les vieux resteraient enfermés à l'intérieur. Du coup il ne resterait que les piétons et cyclistes agiles qui pourraient très bien se partager les trottoirs en bonne entente qu'ils devraient avoir au lieu d'empiéter sur les 90% d'espace (et d'air) public occupé par la sainte voiture (vide le plus souvent et donc totalement inoffensive). http://rue89.nouvelobs.com/2014/10/01/comment-a-interdit-enfants-marcher-255181
Je me demande ce que vont devenir les logiciels de compta (actuellement agréés !!) qui fonctionnent encore sous MSACCESS…
Qu'en est-t'il également des imports/exports ? Je fais régulièrement des spécifs dont le but est d'exporter une facturation ou un autre programme de compta vers celui du cabinet comptable.
Les entreprises ne paient pas de tva puisqu'elles la récupère. Elles font juste office d'intermédiaires entre les particuliers et l'état. Donc, tant qu'à taxer les particuliers, autant les taxer directement sur leurs revenus, en plus ce pourrait être un peu plus proportionnel !
Tu vends une voiture qui pollue et qui n'est plus réparable en tant que particulier, tu ne paie rien du tout. Tu la vends en tant qu'entreprise tu vas payer 30% de charges et x% sur les bénéfices. L'acheteur il va payer 20% de tva, qu'il soit milliardaire ou au rsa.
Tu vends un vélo qui sent bon la lavande et qui est ouvert à tout bricolage c'est kif kif.
Bref, on a un système complètement injuste et obsolète, qui coule nos pays à petit feu. Qui dit injuste dit pas étonnant que ça gruge dans tous les coins.
Après dans la plupart des langages ça fait très peu de temps qu'on a des solutions et elles sont encore loin d'être parfaites.
Là il y en a déjà plusieurs, la seule chose c'est qu'il faut que ça se stabilise, c'est en cours. Si quelqu'un pouvait faire un article sur le govendoringexperiment qui sera par défaut sur la 1.6…
Ce qui reste très intéressant c'est déjà d'avoir résolu le problème du déploiement en créant un binaire statique.
Sinon… Personnellement mes projets sont trop récents pour avoir à gérer des versions différentes de libs externes. J'ai tendance à procéder comme virtualenv en Python, un GOPATH par projet.
Il y a une entrée dans la FAQ : https://golang.org/doc/faq#get_version
La première phrase résumant tout : "Go get" does not have any explicit concept of package versions. Versioning is a source of significant complexity, especially in large code bases, and we are unaware of any approach that works well at scale in a large enough variety of situations to be appropriate to force on all Go users"
En gros comme le reste, on fait au plus simple tant qu'on n'a pas trouvé mieux. Avec un petit plus testé à partir de la v1.5 (current) et par défaut dans la 1.6, le vendoring https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJwkfpx90cqG9AFL0JAYo
Il y a des possibilités de "reflection", avec un module dédié. Le code de Rob Pike que j'ai cité au dessus en est un exemple. Et on trouve dans les librairies tout ce qu'on veut pour faire ça, mais ça ne fait pas partie du langage.
Comme Dave Cheney l'explique, on ne peut pas ajouter de la simplicité après coup, lorsqu'ils ont mis au point le langage les 3 auteurs se sont dit, si une chose n'est pas considérée essentielle par eux 3 ils ne l'ajoutent pas.
La question est de savoir si on gagne en performance sur le programme mais aussi sur le programmeur…
Un essai sur la question par un évangéliste complètement fondu de Go mais qui je pense résume bien ce que l'on adore ou déteste de ce langage : http://dave.cheney.net/2015/03/08/simplicity-and-collaboration
L'absence de generics. D'après ce que j'ai compris c'est qu'il n'y a pas plus simple et efficace que de faire chacun sa bonne boucle des familles plutôt que de torturer le langage pour quelque chose qui sera toujours moins performant.
La réponse de Rob Pike en code (à ne pas utiliser précise t-il !) : https://github.com/robpike/filter
On retrouve cette recherche de simplicité à peu près de partout, ça donne une certaine cohérence.
En pratique j'ai eu besoin d'un set, j'ai commencé par chercher de partout, perdu du temps à essayer des implémentations déjà faites, pour finir par utiliser le map de base et quelques routines maison finalement mieux adaptées à mon problème.
Je ne sais pas s'il faut évangéliser ce langage. Le livre est justement très clair là dessus (contrairement à des tutos ou blogs), on bénéficie d'un langage simple et particulièrement facile à prendre en main mais il faut aimer et arriver à en tirer partie. Il n'y a pas de miracle c'est du brut, un string reste une suite de bytes len("mémé") == 6 sauf si on lui demande explicitement de le traiter en []rune, les goroutines engendrent facilement des "data race" etc… On est vite refroidi !
Je comprend que tu ne retrouve pas le côté magique de python où on peut coder en recopiant ce que qu'on a écrit sur la feuille de brouillon. Personnellement je suis content de retrouver le plaisir du C avec un peu de sucre pythonique plutôt que l'inverse.
Pour ceux qui se posent la question, le gros avantage c'est qu'il est vraiment facile d'essayer. Au pire on ne perdra pas beaucoup de temps.
Le piège c'est qu'on a tout de suite envie d'essayer sur des programmes ardus, genre besoin de performance ou de multitache, alors que quand on découvre python on a plutôt tendance à l'essayer avec des scripts. Mais on s'en sort, la communauté Go aime bien les problèmes tordus et ne culpabilise pas de s'amuser à chercher la performance dès le départ :-)
Et voilà, à force d'utiliser un IDE Vim, j'avais oublié que c'est goimports que j'utilise aussi :-)
Apparemment c'est incroyable le gain qui a été gagné en vitesse de compilation du fait d'interdire les imports inutiles.
Je ne passe pas au Go pour les outils mais pour des besoins particuliers. Les outils sont un avantage qui pourrait prendre de plus en plus d'importance mais je ne changerai pas d'IDE pour ça justement.
Et pour répondre en même temps au côté black magic, j'ai remarqué que plus on connaît un langage (comme python), plus on le pousse dans ses retranchements pour s'apercevoir enfin que l'on a perdu en simplicité. Les IDE comme pycharm se retrouvent vite dépassés si on abuse du côté dynamique du langage. La rigidité de Go n'a pas été décidée au hasard, c'est justement pour que n'importe quel développeur (soit-même en particulier !) qui passe par là s'y retrouve, quelque soit ses outils.
Au niveau du formatage, c'est bluffant, on aime déjà le côté propre de Python qui impose l'indentation, mais à la main (l'IDE ne peut pas deviner si j'ai terminé mon bloc par erreur ou pas). La on tape un peu n'importe comment et hop un coup de gofmt à l'enregistrement et on a un code propre comme pas deux.
Je pense que ceux qui aiment PyCharm apprécieront d'autant plus ces possibilités. Le langage a été conçu pour ça.
[^] # Re: Comment l'industrie de l'automobile délibérément décidé de pourrir la vie des citadins.
Posté par wilk . En réponse au journal Mon insécurité à moi. Évalué à 2.
Chez toi à Bayonne il faut également faire remarquer que c'est le départ de la vélodyssée, une quasi voie verte de 1200 kilomètres. Hors quand on arrive par la gare avec les enfants, les sacoches et tout le tintouin, on se demande bien où aller (la gare est juste au dessus du rond point en question) ni vers le centre ville, ni vers la voie verte, du coup tant pis pour la visite on a repris le train pour aller à la gare juste après (Ondre je crois) pour enfin se retrouver en sécurité. Pitoyable pour une ville de cette renommée…
[^] # Re: Python 3?
Posté par wilk . En réponse au journal CPython abandonne Mercurial et passe à Git et Github. Évalué à 7.
Je ne parle pas uniquement du passage de python 2 à 3 mais du refactoring en général, c'est la seule chose qui m'est pénible en Python, du coup en règle générale je m'abstiens, et donc même punition quand je me pose la question de migrer du code vers python 3.
C'est Guido lui-même qui m'a mis la puce à l'oreille en s'intéressant de plus en plus au typage statique. Ca m'a tellement surpris que du coup j'ai essayé en Go et sur le peu de projets que j'ai démarré c'est loin d'être illusoire, au contraire je me régale à refactoriser. Ca facilite du même coup l'optimisation en ayant beaucoup moins peur de casser quelque chose.
Je ne pense pas que Dropbox ait décidé de migrer vers Go uniquement pour des problèmes de performances, tant qu'à tout réécrire il y avait d'autres solutions plus proches de python, pypy, cython etc.
Pour en revenir au schmilblick, que penses-tu de mercurial ? L'outil qui s'enterre lui-même en refusant de suivre l'évolution de ses dépendances ?
C'est inquiétant car comme le montre très bien la discussion sur le passage vers git+github, le côté social est de plus en plus important, c'est également le côté social qui a modelé Go (formatage du code, outils, multiplateforme…). Paradoxalement à ce qu'on pourrait croire par rapport à ce que j'écris c'est ce qui me fera rester en Python, je ne lâcherai pas l'écosystème Python de si tôt.
[^] # Re: Python 3?
Posté par wilk . En réponse au journal CPython abandonne Mercurial et passe à Git et Github. Évalué à 2.
Qui a abandonné l'autre en premier tu veux dire ?
Est-ce que python3 ne s'abandonne pas tout seul d'ailleurs ?
GvR bosse chez Dropbox qui produit pyston qui reste focalisé sur python2 et risque fort d'être abandonné également puisqu'ils migrent finalement leur partie critique en Go…
GvR s'intéresse de plus en plus au typage statique.
« What did you work on for your Hack Week project?
Static typing for Python. »
« Why did you choose static typing for your project?
I think that at least adding static typing as an optional part of Python is a good thing for the distant future. I also think that this particular tool may be able to help Dropbox convert our own Python 2-based codebase to Python 3. »
J'ai l'impression, et je le constate sur mes projets perso, que les migrations de versions sont vraiment LE problème des langages dynamiques.
[^] # Re: Comment l'industrie de l'automobile délibérément décidé de pourrir la vie des citadins.
Posté par wilk . En réponse au journal Mon insécurité à moi. Évalué à 1.
Avec du recul on voit effectivement que ça va dans le bon sens. Mais plus ça avance et plus on est impatient :-)
[^] # Re: Et si ?
Posté par wilk . En réponse au journal Mon insécurité à moi. Évalué à 3.
Oui, c'est ce que je voulais dire par pointe d'accélération.
Ce serait difficile à faire admettre aujourd'hui tel quel du jour au lendemain. Mais dans une optique ou les cyclistes et les piétons se rapproprieraient la rue en conséquence ça redeviendrait tout à fait naturel.
Et surtout ça me semble être la solution la plus simple et la moins onéreuse ! On y vient petit à petit avec la généralisation du 30km/h et les "zones de rencontres".
[^] # Re: Comment l'industrie de l'automobile délibérément décidé de pourrir la vie des citadins.
Posté par wilk . En réponse au journal Mon insécurité à moi. Évalué à 7.
Peut-être dans quelques grandes villes. Dans les plus petites (qui souffrent pourtant beaucoup moins de problème de manque de parkings) on continue encore à abattre des arbres et des espaces publics pour bétonner de nouveaux parkings. Il manque toujours une volonté nationale qui fait que l'on reste dépendant des élus locaux qui se trompent encore sur l'opinion des administrés.
http://droitauvelo.free.fr/DOC/fh_opinionselus.pdf
http://transports.blog.lemonde.fr/2015/10/01/dans-les-villes-moyennes-le-retour-de-la-voiture-nest-pas-une-fatalite/
[^] # Re: Et si ?
Posté par wilk . En réponse au journal Mon insécurité à moi. Évalué à 6.
Le cloisonnement peut être utile sur les voies rapides, autoroutes, voies vertes…
Mais en zone urbaine le vélo va en moyenne aussi vite voir plus vite que la voiture donc il est inutile de les séparer. Au contraire, le fait de les mélanger permet de ralentir la circulation jusqu'à une vitesse acceptable même pour les piétons. La vitesse moyenne vélo/voiture en ville est de 15km/h d'après l'ADEME. La distance de trajet est inférieure à 3km, donc inutile aussi d'occuper tout l'espace public par des parkings.
Il y a juste un problème de disproportion sur l'espace occupé qui permet à la voiture de faire des pointes d'accélérations inutiles, dangereuses et polluantes, dissuadant ainsi tous les modes de transports actifs et ainsi de suite.
[^] # Re: Comment l'industrie de l'automobile délibérément décidé de pourrir la vie des citadins.
Posté par wilk . En réponse au journal Mon insécurité à moi. Évalué à 10.
Les piétons ont la loi la plus répressive possible puisqu'ils sont les premières victimes des accidents.
Les automobilistes payent quelques taxes de bonne conscience mais globalement l'automobile, avec toute l'infrastructure qui va avec et le coût des dégâts causés est très largement assumé et subventionné par la collectivité, piétons compris.
Dernièrement, subvention pour une voiture électrique : 10000€, 0€ pour un vélo électrique, indemnité kilométrique vélo plafonnée. Loi Laure, la seule qui aurait pu nous laisser un peu respirer est complètement bafouée.
http://www.lcp.fr/emissions/l-echo-des-lois/vod/175176-pollution-de-l-air-une-loi-a-bout-de-souffle
L228-2
A l’occasion des réalisations ou des rénovations des voies urbaines, à l’exception des autoroutes et voies rapides, doivent être mis au point des itinéraires cyclables pourvus d’aménagements sous forme de pistes, marquages au sol ou couloirs indépendants,
Mais la phrase se termine par :
en fonction des besoins et contraintes de la circulation.
[^] # Re: Comment l'industrie de l'automobile délibérément décidé de pourrir la vie des citadins.
Posté par wilk . En réponse au journal Mon insécurité à moi. Évalué à 10.
Et puis d'abord il faudrait un permis pour avoir le droit de marcher, les enfants, les handicapés et les vieux resteraient enfermés à l'intérieur. Du coup il ne resterait que les piétons et cyclistes agiles qui pourraient très bien se partager les trottoirs en bonne entente qu'ils devraient avoir au lieu d'empiéter sur les 90% d'espace (et d'air) public occupé par la sainte voiture (vide le plus souvent et donc totalement inoffensive).

http://rue89.nouvelobs.com/2014/10/01/comment-a-interdit-enfants-marcher-255181
[^] # Re: J'ai voté autre donc je justifie
Posté par wilk . En réponse au sondage C'est l'heure des bonnes résolutions. Pour moi, 2016 sera l'année où. Évalué à 3.
Et inversement
[^] # Re: Perl6, le Hurd des langages ....
Posté par wilk . En réponse au journal Merry 6.c! Mon expérience avec Perl 6. Évalué à 6.
Tu peux pas relire et corriger Perl6 pendant que t'y es ? ;-)
[^] # Re: Réel problème pour tous les ERP
Posté par wilk . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 1.
Faudra commencer par faire certifier le logiciel de gestion de pétition ;-)
[^] # Re: Quid des base de données
Posté par wilk . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 2.
Je me demande ce que vont devenir les logiciels de compta (actuellement agréés !!) qui fonctionnent encore sous MSACCESS…
Qu'en est-t'il également des imports/exports ? Je fais régulièrement des spécifs dont le but est d'exporter une facturation ou un autre programme de compta vers celui du cabinet comptable.
[^] # Re: Les solutions modernes ?
Posté par wilk . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 2.
Les entreprises ne paient pas de tva puisqu'elles la récupère. Elles font juste office d'intermédiaires entre les particuliers et l'état. Donc, tant qu'à taxer les particuliers, autant les taxer directement sur leurs revenus, en plus ce pourrait être un peu plus proportionnel !
Tu vends une voiture
qui pollue et qui n'est plus réparableen tant que particulier, tu ne paie rien du tout. Tu la vends en tant qu'entreprise tu vas payer 30% de charges et x% sur les bénéfices. L'acheteur il va payer 20% de tva, qu'il soit milliardaire ou au rsa.Tu vends un vélo
qui sent bon la lavande et qui est ouvert à tout bricolagec'est kif kif.Bref, on a un système complètement injuste et obsolète, qui coule nos pays à petit feu. Qui dit injuste dit pas étonnant que ça gruge dans tous les coins.
# Go
Posté par wilk . En réponse à la dépêche Nanocloud Community, solution de transformation des applications traditionnelles en solution Cloud.. Évalué à 2.
Un petit retour d'expérience sur le choix et le résultat de l'utilisation du langage ?
Merci
[^] # Re: got get et version
Posté par wilk . En réponse à la dépêche The Go Programming Language. Évalué à 1.
J'ai un peu exagéré, ça ne résout pas LE problème mais un des problèmes (ce qui est déjà pas mal)…
[^] # Re: got get et version
Posté par wilk . En réponse à la dépêche The Go Programming Language. Évalué à 1.
Après dans la plupart des langages ça fait très peu de temps qu'on a des solutions et elles sont encore loin d'être parfaites.
Là il y en a déjà plusieurs, la seule chose c'est qu'il faut que ça se stabilise, c'est en cours. Si quelqu'un pouvait faire un article sur le govendoringexperiment qui sera par défaut sur la 1.6…
Ce qui reste très intéressant c'est déjà d'avoir résolu le problème du déploiement en créant un binaire statique.
[^] # Re: got get et version
Posté par wilk . En réponse à la dépêche The Go Programming Language. Évalué à 2.
Merci pour cette question.
Une autre ?
Sinon… Personnellement mes projets sont trop récents pour avoir à gérer des versions différentes de libs externes. J'ai tendance à procéder comme virtualenv en Python, un GOPATH par projet.
Il y a une entrée dans la FAQ :
https://golang.org/doc/faq#get_version
La première phrase résumant tout : "Go get" does not have any explicit concept of package versions. Versioning is a source of significant complexity, especially in large code bases, and we are unaware of any approach that works well at scale in a large enough variety of situations to be appropriate to force on all Go users"
En gros comme le reste, on fait au plus simple tant qu'on n'a pas trouvé mieux. Avec un petit plus testé à partir de la v1.5 (current) et par défaut dans la 1.6, le vendoring https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJwkfpx90cqG9AFL0JAYo
[^] # Re: map/fold/filter
Posté par wilk . En réponse à la dépêche The Go Programming Language. Évalué à 1.
Il y a des possibilités de "reflection", avec un module dédié. Le code de Rob Pike que j'ai cité au dessus en est un exemple. Et on trouve dans les librairies tout ce qu'on veut pour faire ça, mais ça ne fait pas partie du langage.
Comme Dave Cheney l'explique, on ne peut pas ajouter de la simplicité après coup, lorsqu'ils ont mis au point le langage les 3 auteurs se sont dit, si une chose n'est pas considérée essentielle par eux 3 ils ne l'ajoutent pas.
[^] # Re: map/fold/filter
Posté par wilk . En réponse à la dépêche The Go Programming Language. Évalué à 6.
La question est de savoir si on gagne en performance sur le programme mais aussi sur le programmeur…
Un essai sur la question par un évangéliste complètement fondu de Go mais qui je pense résume bien ce que l'on adore ou déteste de ce langage :
http://dave.cheney.net/2015/03/08/simplicity-and-collaboration
[^] # Re: map/fold/filter
Posté par wilk . En réponse à la dépêche The Go Programming Language. Évalué à 3.
L'absence de generics. D'après ce que j'ai compris c'est qu'il n'y a pas plus simple et efficace que de faire chacun sa bonne boucle des familles plutôt que de torturer le langage pour quelque chose qui sera toujours moins performant.
La réponse de Rob Pike en code (à ne pas utiliser précise t-il !) : https://github.com/robpike/filter
On retrouve cette recherche de simplicité à peu près de partout, ça donne une certaine cohérence.
En pratique j'ai eu besoin d'un set, j'ai commencé par chercher de partout, perdu du temps à essayer des implémentations déjà faites, pour finir par utiliser le map de base et quelques routines maison finalement mieux adaptées à mon problème.
A voir à l'usage si c'est réellement pénalisant…
[^] # Re: Juste de la sorcellerie
Posté par wilk . En réponse au journal The Go Programming Language. Évalué à 1.
Tu peux donner un exemple, je suis pas sûr de comprendre ce que tu veux dire…
[^] # Re: GO GO GO GO
Posté par wilk . En réponse au journal The Go Programming Language. Évalué à 7.
Je ne sais pas s'il faut évangéliser ce langage. Le livre est justement très clair là dessus (contrairement à des tutos ou blogs), on bénéficie d'un langage simple et particulièrement facile à prendre en main mais il faut aimer et arriver à en tirer partie. Il n'y a pas de miracle c'est du brut, un string reste une suite de bytes
len("mémé") == 6
sauf si on lui demande explicitement de le traiter en[]rune
, les goroutines engendrent facilement des "data race" etc… On est vite refroidi !Je comprend que tu ne retrouve pas le côté magique de python où on peut coder en recopiant ce que qu'on a écrit sur la feuille de brouillon. Personnellement je suis content de retrouver le plaisir du C avec un peu de sucre pythonique plutôt que l'inverse.
Pour ceux qui se posent la question, le gros avantage c'est qu'il est vraiment facile d'essayer. Au pire on ne perdra pas beaucoup de temps.
Le piège c'est qu'on a tout de suite envie d'essayer sur des programmes ardus, genre besoin de performance ou de multitache, alors que quand on découvre python on a plutôt tendance à l'essayer avec des scripts. Mais on s'en sort, la communauté Go aime bien les problèmes tordus et ne culpabilise pas de s'amuser à chercher la performance dès le départ :-)
[^] # Re: Outils
Posté par wilk . En réponse au journal The Go Programming Language. Évalué à 2.
Et voilà, à force d'utiliser
un IDEVim, j'avais oublié que c'est goimports que j'utilise aussi :-)Apparemment c'est incroyable le gain qui a été gagné en vitesse de compilation du fait d'interdire les imports inutiles.
[^] # Re: Outils
Posté par wilk . En réponse au journal The Go Programming Language. Évalué à 3.
Je ne passe pas au Go pour les outils mais pour des besoins particuliers. Les outils sont un avantage qui pourrait prendre de plus en plus d'importance mais je ne changerai pas d'IDE pour ça justement.
Et pour répondre en même temps au côté black magic, j'ai remarqué que plus on connaît un langage (comme python), plus on le pousse dans ses retranchements pour s'apercevoir enfin que l'on a perdu en simplicité. Les IDE comme pycharm se retrouvent vite dépassés si on abuse du côté dynamique du langage. La rigidité de Go n'a pas été décidée au hasard, c'est justement pour que n'importe quel développeur (soit-même en particulier !) qui passe par là s'y retrouve, quelque soit ses outils.
Au niveau du formatage, c'est bluffant, on aime déjà le côté propre de Python qui impose l'indentation, mais à la main (l'IDE ne peut pas deviner si j'ai terminé mon bloc par erreur ou pas). La on tape un peu n'importe comment et hop un coup de gofmt à l'enregistrement et on a un code propre comme pas deux.
Je pense que ceux qui aiment PyCharm apprécieront d'autant plus ces possibilités. Le langage a été conçu pour ça.