C'est bien pour ça que j'insiste sur un des avantages des micros frameworks qui est de pouvoir être changés facilement au cas où ça tournerait mal (ou que l'app évolue dans un sens différent), ce qui est loin d'être évident avec un plus gros et qui entraîne d'énormes problèmes pour faire évoluer le framework lui-même. Alors oui, le gros framework ne casse pas la compatibilité, mais pour cause, il n'évolue plus et au bout d'un moment on change tout, le langage avec l'eau du bain !
On retrouve cette philosophie en Go, de ne pas s'encombrer de ce qui pourrait devenir un boulet par la suite.
Utiliser un langage en cours de mise au point est au contraire tellement plein d'enseignements ! Même si on doit en utiliser un autre pour l'alimentaire il y a toujours moyen de progresser et d'améliorer sa pratique dans son langage actuel.
Je remercie donc particulièrement les auteurs de journaux ou dépêches qui partagent leurs découvertes et nous permettre d'en débattre.
Personne n'a prétendu que les frameworks étaient nuls. Au contraire, ce sont souvent des monuments d'ingénierie. Mais ça ne signifie pas pour autant qu'ils soient adaptées à tous les cas de figure, surtout sur le long terme.
On n'utilise sûrement pas le même java. Celui que j'utilisais était en version 1.x, j'adhérai d'autant plus au framework que c'était le mien !
Ce que je veux dire par là c'est qu'un framework, même si on le connaît très bien, comporte trop d'effets de bords et de couches à maintenir pour évoluer sans peine sur des projets divers et variés.
Donc par la suite, en python, j'ai préféré opter pour un framework minimaliste (perso car à l'époque ça n'existait pas) et travailler sur la composition.
Par exemple je peux utiliser le même framework pour faire du "traversal" http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/traversal.html
Mais il est difficile de savoir si on parle de la même chose en terme de framework… Autrement dit, je préfère la méthode "Unix" où chaque chose fait une seule chose mais bien et communique avec les autres.
Je suis également surpris par le ton que tu emplois contrairement à tes habitudes…
Chicha a juste dit qu'il en avait raz le bol lui-même pour ses propres besoins persos ! je ne vois pas où il y a une généralité là dedans ? Mais pas de quoi en faire un fromage, ça reste marrant à lire.
Par rapport à ton affirmation que beaucoup de gens disent du mal des frameworks parce qu'ils ne les maîtrisent pas, et bien là encore je constate exactement l'inverse, ce que j'ai écris sur les gros frameworks je ne l'applique pas uniquement aux frameworks que je ne connais pas bien mais également aux miens ! Quand j'utilisais Java, fier de la philosophie du langage qui incitait à faire les choses bien comme il faut je me suis écris à l'époque quelques bon gros framework qui me permettait d'aller hyper vite sur certains projets. En revanche comme je l'expliquait, sur le long terme j'ai du tout réécrire pour faire évoluer les applications dans des sens trop différents les unes des autres, ça m'a servi de leçon !
Ne m'incendie pas, c'est pas une généralité c'est mon expérience perso (petits projets qui évoluent sur du long terme) ;-)
Tout dépend de ce qu'on appelle un framework ?
Je constate plutôt l'inverse de ce que tu décrits, un gros framework (genre RoR ou Django) rend de plus en plus difficile toute évolution car il y a trop d'effet de bords et de surcouches à maintenir. En revanche un framework minimaliste comme Pyramid permet de faire évoluer un code dans n'importe quelle direction beaucoup plus facilement et surtout sans avoir à tout réécrire. Combien de projets on voit partis de RoR ou Django être réécrits entièrement car arrivés à une impasse ? On accuse bien trop souvent le langage alors que le problème vient du framework à mon avis.
Un critère que je trouve pertinent est de pouvoir conserver un même code d'un framework à l'autre. C'est ce que j'ai pu faire sur des applis qui datent de plus de dix ans et que je fais évoluer au fil de l'eau justement par ce que je n'ai jamais utilisé de gros framework. C'est aussi ce qui me permet de réécrire une partie en Go sans avoir à toucher à l'architecture ni à abandonner et réécrire ce qui peut très bien rester en Python.
J'aime bien Go pour ce même aspect minimaliste qu'on retrouvait au début en Python et qui a hélas été un peu perdu. Cet aspect me semble justement primordial pour la maintenance sur le long terme.
C'est marrant j'ai aussi fait un jeu de scrabble pour ma mômant ! http://seps.flibuste.net
Un jour j'ai eu un mail de Hasbro, je leur ai demandé sur quelle loi française ils s'appuyaient et depuis pas de réponse… J'attends qu'ils me fassent un effet Streisand avec mes mamies !!!
On trouve des tout petits scripts (moins de 200 lignes) qui montrent à quel point ça peut être simple et facile à intégrer : https://github.com/diafygi/acme-tiny/
Super ta présentation aux BlendWebMix, tu fais bien ressortir le côté simple et ludique de Go.
Je vais aller voir ton framework, si tu pouvais en faire un journal ou une dépêche pour nous expliquer comment il fonctionne, pourquoi tu en a créé un nouveau etc ce serait génial.
On trouve aussi l'inverse où on triche avec un langage à typage statique… Y a pas de miracle ! C'est pour ça que je trouve intéressant ce consensus où on essaye maintenant d'apporter plus de souplesse dans les langages statiques et plus de "sécurité" dans les langages dynamiques.
L'approche événementielle est complètement différente… Question de goût ou de besoin ?
Ce qui est marrant c'est qu'on reste en famille, Robert Griesemer a travaillé sur V8 (et java hotspot) avant de participer à la conception Go.
J'ai la chance de pouvoir choisir un langage parce qu'il me plait plus que par besoin donc je ne pourrai pas t'aider.
Merci du merci, quand on a le nez dans une dépêche c'est difficile de se rendre compte de ce que ça va donner.
Je ne pense pas non plus que ce soit une révolution, c'est juste une réponse bien pratique à des problèmes actuels, sans justement se casser la tête à tout réinventer.
Pour rester dans le sujet et répondre à ta question, une conf intéressante sur le dev de http://ngrok.com
à la fin il explique pourquoi Go et comment il a essayé de ne pas se perdre dans les dédales de l'orchestration.
Déploiement d'un binaire sans dépendance sur différents plateformes
Le tout en une journée ;-)
Bon, maintenant que j'ai réussi il ne me reste plus qu'à trouver les clients pour faire les requêtes. La il donne une réponse aussi : vendez ce qui se vend déjà, vous êtes au moins sur que c'est vendable ! Mince c'est toujours pas la révolution non plus…
Ca montre le problème qu'il y a à utiliser les deux systèmes. Ca n'est pas tant qu'il y en ait un mieux que l'autre mais on essaye de retrouver des équivalences de commandes là où il y a une différence de conception…
J'utilise hg incoming pour le côté centralisé, pour voir si mon collègue à fait quelque chose ou pas. Si j'ai besoin de savoir exactement ce qu'il a fait je fais hg incoming -patch, ça me permet de voir exactement ce qu'il a fait, visuellement, sans rien récupérer. Je m'en sert également pour voir si mes librairies (en subrepos) sont à jour ou pas.
Inversement j'utilise push pour mettre à jour des applis en ligne. Avec outgo je peux savoir où j'en suis.
Depuis que j'utilise un algo en tête maison plus de soucis. C'est à dire un petit algo perso qui transforme le nom du service en un mot de passe, par exemple la première lettre + 1, la deuxième + 2, le nombre de lettre x l'année de naissance de ma fille etc…
Pour les cas un peu particulier où ça ne marche pas directement (pas assez de lettre ou autre) je l'écris sur un fichier qui lui n'a aucun besoin d'être crypté.
Pour les mots de passes ou codes que je ne peux pas modifier moi-même, je les écris avec une erreur. Par exemple si c'est un numéro j'inverse systématiquement le premier et le dernier caractère ou je lui ajoute mon année de naissance etc… Donc là aussi ça permet de l'écrire n'importe où.
N'importe où c'est généralement un fichier qui n'a l'air de rien genre test.py dans un répertoire build par ex.
Je ne comprend pas non plus, tant qu'à faire des sacrifices pour le côté social de github, autant en tirer les avantages jusqu'au bout, quitte à changer par la suite. Les alternatives à la github sont en cours non ? https://gogs.io/
J'aime bien le texte de Dave Chenney : http://dave.cheney.net/2015/03/08/simplicity-and-collaboration où il explique que la simplicité on ne peut pas l'ajouter, on ne peut l'acquérir qu'en enlevant des choses. Hors plus un langage évolue et mieux on le connaît plus on est tenté de le pousser dans ses recoins jusqu'à s'inventer son propre langage. Du coup j'essaye de plus en plus comme toi à avoir plus de rigueur sur les côtés dynamiques.
Par contre je changerai de langage plutôt que de changer d'éditeur (c'est entre autre ce qui m'avait amené à passer de java à python !).
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".
[^] # Re: Go
Posté par wilk . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 4.
C'est bien pour ça que j'insiste sur un des avantages des micros frameworks qui est de pouvoir être changés facilement au cas où ça tournerait mal (ou que l'app évolue dans un sens différent), ce qui est loin d'être évident avec un plus gros et qui entraîne d'énormes problèmes pour faire évoluer le framework lui-même. Alors oui, le gros framework ne casse pas la compatibilité, mais pour cause, il n'évolue plus et au bout d'un moment on change tout, le langage avec l'eau du bain !
On retrouve cette philosophie en Go, de ne pas s'encombrer de ce qui pourrait devenir un boulet par la suite.
[^] # Re: Version 0.x.x
Posté par wilk . En réponse à la dépêche Et si JavaScript allait droit dans le mur ?. Évalué à 7.
Utiliser un langage en cours de mise au point est au contraire tellement plein d'enseignements ! Même si on doit en utiliser un autre pour l'alimentaire il y a toujours moyen de progresser et d'améliorer sa pratique dans son langage actuel.
Je remercie donc particulièrement les auteurs de journaux ou dépêches qui partagent leurs découvertes et nous permettre d'en débattre.
[^] # Re: Go
Posté par wilk . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 2.
edit: sur les frameworks que tu m'indiques, à vu de nez ça ne me déplaît pas, ça n'est pas ce que je critique, au contraire.
[^] # Re: Go
Posté par wilk . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 4.
Personne n'a prétendu que les frameworks étaient nuls. Au contraire, ce sont souvent des monuments d'ingénierie. Mais ça ne signifie pas pour autant qu'ils soient adaptées à tous les cas de figure, surtout sur le long terme.
[^] # Re: Go
Posté par wilk . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 2.
On n'utilise sûrement pas le même java. Celui que j'utilisais était en version 1.x, j'adhérai d'autant plus au framework que c'était le mien !
Ce que je veux dire par là c'est qu'un framework, même si on le connaît très bien, comporte trop d'effets de bords et de couches à maintenir pour évoluer sans peine sur des projets divers et variés.
Donc par la suite, en python, j'ai préféré opter pour un framework minimaliste (perso car à l'époque ça n'existait pas) et travailler sur la composition.
Par exemple je peux utiliser le même framework pour faire du "traversal" http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/traversal.html
Mais il est difficile de savoir si on parle de la même chose en terme de framework… Autrement dit, je préfère la méthode "Unix" où chaque chose fait une seule chose mais bien et communique avec les autres.
[^] # Re: Go
Posté par wilk . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 6.
Je suis également surpris par le ton que tu emplois contrairement à tes habitudes…
Chicha a juste dit qu'il en avait raz le bol lui-même pour ses propres besoins persos ! je ne vois pas où il y a une généralité là dedans ? Mais pas de quoi en faire un fromage, ça reste marrant à lire.
Par rapport à ton affirmation que beaucoup de gens disent du mal des frameworks parce qu'ils ne les maîtrisent pas, et bien là encore je constate exactement l'inverse, ce que j'ai écris sur les gros frameworks je ne l'applique pas uniquement aux frameworks que je ne connais pas bien mais également aux miens ! Quand j'utilisais Java, fier de la philosophie du langage qui incitait à faire les choses bien comme il faut je me suis écris à l'époque quelques bon gros framework qui me permettait d'aller hyper vite sur certains projets. En revanche comme je l'expliquait, sur le long terme j'ai du tout réécrire pour faire évoluer les applications dans des sens trop différents les unes des autres, ça m'a servi de leçon !
Ne m'incendie pas, c'est pas une généralité c'est mon expérience perso (petits projets qui évoluent sur du long terme) ;-)
[^] # Re: Go
Posté par wilk . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 9.
Tout dépend de ce qu'on appelle un framework ?
Je constate plutôt l'inverse de ce que tu décrits, un gros framework (genre RoR ou Django) rend de plus en plus difficile toute évolution car il y a trop d'effet de bords et de surcouches à maintenir. En revanche un framework minimaliste comme Pyramid permet de faire évoluer un code dans n'importe quelle direction beaucoup plus facilement et surtout sans avoir à tout réécrire. Combien de projets on voit partis de RoR ou Django être réécrits entièrement car arrivés à une impasse ? On accuse bien trop souvent le langage alors que le problème vient du framework à mon avis.
Un critère que je trouve pertinent est de pouvoir conserver un même code d'un framework à l'autre. C'est ce que j'ai pu faire sur des applis qui datent de plus de dix ans et que je fais évoluer au fil de l'eau justement par ce que je n'ai jamais utilisé de gros framework. C'est aussi ce qui me permet de réécrire une partie en Go sans avoir à toucher à l'architecture ni à abandonner et réécrire ce qui peut très bien rester en Python.
J'aime bien Go pour ce même aspect minimaliste qu'on retrouvait au début en Python et qui a hélas été un peu perdu. Cet aspect me semble justement primordial pour la maintenance sur le long terme.
# SEPS n'est pas scrabble
Posté par wilk . En réponse au journal Trivabble : jouez au Scrabble ® en ligne. Évalué à 5.
C'est marrant j'ai aussi fait un jeu de scrabble pour ma mômant ! http://seps.flibuste.net
Un jour j'ai eu un mail de Hasbro, je leur ai demandé sur quelle loi française ils s'appuyaient et depuis pas de réponse… J'attends qu'ils me fassent un effet Streisand avec mes mamies !!!
[^] # Re: un peu quand même
Posté par wilk . En réponse à l’entrée du suivi Changer le tag Golang en Go. Évalué à 1 (+0/-0).
Sans ambiguïté dans le sens ou Go est le seul nom officiel du langage.
[^] # Re: Gros script qui fait trop de chose
Posté par wilk . En réponse au journal Reparlons de Let’s Encrypt. Évalué à 4.
On trouve des tout petits scripts (moins de 200 lignes) qui montrent à quel point ça peut être simple et facile à intégrer :
https://github.com/diafygi/acme-tiny/
[^] # Re: C'est intégré dans Python 3.5
Posté par wilk . En réponse au journal MyPy 0.3 sort bien accompagné. Évalué à 2.
Je pense au Go par exemple, les interfaces, l'inférence de type, la compilation quasi instantanée…
[^] # Re: merci
Posté par wilk . En réponse à la dépêche Sortie du langage Go en version 1.6. Évalué à 4.
Super ta présentation aux BlendWebMix, tu fais bien ressortir le côté simple et ludique de Go.
Je vais aller voir ton framework, si tu pouvais en faire un journal ou une dépêche pour nous expliquer comment il fonctionne, pourquoi tu en a créé un nouveau etc ce serait génial.
[^] # Re: C'est intégré dans Python 3.5
Posté par wilk . En réponse au journal MyPy 0.3 sort bien accompagné. Évalué à 3.
On trouve aussi l'inverse où on triche avec un langage à typage statique… Y a pas de miracle ! C'est pour ça que je trouve intéressant ce consensus où on essaye maintenant d'apporter plus de souplesse dans les langages statiques et plus de "sécurité" dans les langages dynamiques.
[^] # Re: merci
Posté par wilk . En réponse à la dépêche Sortie du langage Go en version 1.6. Évalué à 3.
L'approche événementielle est complètement différente… Question de goût ou de besoin ?
Ce qui est marrant c'est qu'on reste en famille, Robert Griesemer a travaillé sur V8 (et java hotspot) avant de participer à la conception Go.
J'ai la chance de pouvoir choisir un langage parce qu'il me plait plus que par besoin donc je ne pourrai pas t'aider.
[^] # Re: merci
Posté par wilk . En réponse à la dépêche Sortie du langage Go en version 1.6. Évalué à 5.
Merci du merci, quand on a le nez dans une dépêche c'est difficile de se rendre compte de ce que ça va donner.
Je ne pense pas non plus que ce soit une révolution, c'est juste une réponse bien pratique à des problèmes actuels, sans justement se casser la tête à tout réinventer.
Pour rester dans le sujet et répondre à ta question, une conf intéressante sur le dev de http://ngrok.com
à la fin il explique pourquoi Go et comment il a essayé de ne pas se perdre dans les dédales de l'orchestration.
https://www.twilio.com/blog/2016/02/how-alan-shreve-built-ngrok-with-go.html
24:50 exercice :
Le tout en une journée ;-)
Bon, maintenant que j'ai réussi il ne me reste plus qu'à trouver les clients pour faire les requêtes. La il donne une réponse aussi : vendez ce qui se vend déjà, vous êtes au moins sur que c'est vendable ! Mince c'est toujours pas la révolution non plus…
[^] # Re: Popularité
Posté par wilk . En réponse au journal Matt Mackall, l'auteur de Mercurial, passe la main. Évalué à 2.
Ca montre le problème qu'il y a à utiliser les deux systèmes. Ca n'est pas tant qu'il y en ait un mieux que l'autre mais on essaye de retrouver des équivalences de commandes là où il y a une différence de conception…
J'utilise hg incoming pour le côté centralisé, pour voir si mon collègue à fait quelque chose ou pas. Si j'ai besoin de savoir exactement ce qu'il a fait je fais hg incoming -patch, ça me permet de voir exactement ce qu'il a fait, visuellement, sans rien récupérer. Je m'en sert également pour voir si mes librairies (en subrepos) sont à jour ou pas.
Inversement j'utilise push pour mettre à jour des applis en ligne. Avec outgo je peux savoir où j'en suis.
# Algo en tête maison
Posté par wilk . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 2.
Depuis que j'utilise un algo en tête maison plus de soucis. C'est à dire un petit algo perso qui transforme le nom du service en un mot de passe, par exemple la première lettre + 1, la deuxième + 2, le nombre de lettre x l'année de naissance de ma fille etc…
Pour les cas un peu particulier où ça ne marche pas directement (pas assez de lettre ou autre) je l'écris sur un fichier qui lui n'a aucun besoin d'être crypté.
Pour les mots de passes ou codes que je ne peux pas modifier moi-même, je les écris avec une erreur. Par exemple si c'est un numéro j'inverse systématiquement le premier et le dernier caractère ou je lui ajoute mon année de naissance etc… Donc là aussi ça permet de l'écrire n'importe où.
N'importe où c'est généralement un fichier qui n'a l'air de rien genre test.py dans un répertoire build par ex.
[^] # Re: Un peu choqué de ton style
Posté par wilk . En réponse au journal Mon insécurité à moi. Évalué à 2.
Change rien ! On aime ou on aime pas mais c'était vraiment bien calé.
[^] # Re: Verrouillage?
Posté par wilk . En réponse au journal CPython abandonne Mercurial et passe à Git et Github. Évalué à 2.
Je ne comprend pas non plus, tant qu'à faire des sacrifices pour le côté social de github, autant en tirer les avantages jusqu'au bout, quitte à changer par la suite. Les alternatives à la github sont en cours non ? https://gogs.io/
[^] # Re: Python 3?
Posté par wilk . En réponse au journal CPython abandonne Mercurial et passe à Git et Github. Évalué à 2.
J'aime bien le texte de Dave Chenney :
http://dave.cheney.net/2015/03/08/simplicity-and-collaboration où il explique que la simplicité on ne peut pas l'ajouter, on ne peut l'acquérir qu'en enlevant des choses. Hors plus un langage évolue et mieux on le connaît plus on est tenté de le pousser dans ses recoins jusqu'à s'inventer son propre langage. Du coup j'essaye de plus en plus comme toi à avoir plus de rigueur sur les côtés dynamiques.
Par contre je changerai de langage plutôt que de changer d'éditeur (c'est entre autre ce qui m'avait amené à passer de java à python !).
[^] # 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".