Le topic de la programmation, string, chaînes, cuir et compagnie

[ook4mi]

Ouais, je crois que c'était ça, un truc du MIT. Merci mec !
(Ouais je vais me mettre à la programmation)

Amuse toi bien ! Tu veux t'y mettre pour faire quoi comme projet ?

[Tramb]

Nan mais c'était une blague, c'est pour un enfant tiers :-)

[ook4mi]

Nan mais c'était une blague, c'est pour un enfant tiers :-)

Tu as raison, laisse ça au petit et s'il te plait lache cette souris et éloigne toi doucement de l'écran :D

[Tomaka17]

Désolé pour cette remarque totalement primaire et débile, mais je trouve que les juges de l'IOCCC ont vraiment des têtes de juge de l'IOCCC

[deathdigger]

Bon, on m'a collé sur un projet de fou furieux au taff.
Une appli web qui est en évolution depuis 10 ans, en VB .Net, et qui utilise tous les outils MS que je ne connais pas : Reporting Service, SSIS et autres joyeusetés, versionné par Team Foundation et plein d'autres trucs.
La solution comporte plus de 70 projets, et y'a 30 bases de données
Et pour faire simple, il n'y a aucune requête dans le code, tout est en procédures stockées. Même des listes de fichiers qui remplissent des listes déroulantes (genre le truc où il te suffit de lister le répertoire), ben c'est stocké en bdd, et pour la sortir, faut passer par une procédure stockée.

Je sens que je vais m'amuser

[Nattefrost]

Bonne lecture du source, donc

[Teocali]

Bonne lecture du source, donc

Putain, j'ai l'impression de lire la description de mon nouveau projet : 20 d'age , une pelletachiee de logique métier en procédure stockée, et un client lourd en eclipse RCP qui reçoit toute sa logique de fonctionnement (j'ai bien dit tout. Depuis le contenu des menus contextuels jusqu'au comportement a avoir sur les différents évènements) depuis une application serveur (sur un tomcat 4) via un protocol XML custom...

[Tomaka17]

Tiens y a un p'tit projet intéressant pour le dependency management en C++ : http://www.biicode.com/
Si j'ai bien tout compris, leur programme analyse les "#include" de ton source code et télécharge automatiquement ce qu'il manque depuis un dépôt central.

(dommage que dans mon coeur j'ai abandonné le C++ pour le rust)

[moimadmax]

J'ai un petit problème en python, j'avais fais un script en python 3.4 pour parser une position GPS d'une page web. Il fonctionne bien. Par contre en passant le script en 2.7 ça marche pas. Le problème vient du caractère '°' dans l'expression régulière. Qui passait bien en 3.4 et là visiblement il bloque, car re.search me revoit none dès que je le met dans l'expression régulière. J'ai tenté de l'échapper \° sans résultat.

J'ai vérifié qu'il n'y avait pas de problème d'encodage sur l'entrée. Du moins Pas dans le string en mode inspection dans PyCharm.
HELP please.

[deathdigger]

Tu peux pas passer par le code du caractère ? ° ou ° ?

[moimadmax]

On peut mettre ça dans une expression régulière ?

[Møgluglu]

Il ne considère pas ° codé en UTF-8 comme 2 caractères, par hasard ?

[moimadmax]

J'en sais rien du tout. Je sais que quand j'ai essayé de retirer le .decode("latin_1") il affichait des petits carré au lieu des °.
J'ai reussi en mettant .? à la place du °. Mais c'est moins propre et moins claire à la lecture.

[Teocali]

Essae d'ajouter u devant la chaine décrivant ton pattern, du genre u"\d\d°". Je pense que le souci viennent que par défaut une chaine de charactères est considéré comme unicode en Pthon 3, mais en Python 2. Et si ça suffit pas, colle ton script ici, qu'on puisse critiquercorriger

[moimadmax]

On peut pas cumuler le u avec le r ?
regex = ru"\d\d°"
Du coup je dois passer par re.compile(u"\d\d°") ?

[deathdigger]

Et après on dit que le Python est plus simple que le C#

[Nattefrost]

Ben si c'est un problème d'unicode c'est pareil qu'en C#, ici c'est simplement la compatibilité entre les deux branches qui fout la merde (on dirait).
Quelqu'un qui s'y met aujourd'hui n'apprendra certainement pas python2, et puis arrivé en entreprise il tombera sur des kilotonnes de legacy code en python2

[moimadmax]

C'est un peu ce qui m'arrive, j'ai appris direct en v3, mais comme pygame n'est pas integré dans portable python 3 et que ça me lourde de faire une vrai install. Je me suis dit qu'il n'y aurai pas trop de différence entre la 2.7 et la 3.4. Finalement pour mon truc j'étais pas trop loin de la vérité. A cette broutille près.

[Teocali]

On peut pas cumuler le u avec le r ?
regex = ru"\d\d°"
Du coup je dois passer par re.compile(u"\d\d°") ?

J'aurais tendance a dire oui. Mais colle ton script, qu'on regarde. Ça fait longtemps que j'ai pas fait mumuse en python

[Nattefrost]

C'est un peu ce qui m'arrive, j'ai appris direct en v3, mais comme pygame n'est pas integré dans portable python 3 et que ça me lourde de faire une vrai install. Je me suis dit qu'il n'y aurai pas trop de différence entre la 2.7 et la 3.4. Finalement pour mon truc j'étais pas trop loin de la vérité. A cette broutille près.

Le mec a la flemme de faire une install de python ! Encore de visualstudio ou un gros fatras je comprend mais python, 13 Mo.

edit : d'ailleurs je connaissai pas portablepython, 64Mo le machin, bon avec 3 IDEs dans le package. A ce propos je suis récemment passé sur ninja-ide parce que j'en avai marre de switcher entre vim sous linux et geany sous windows (non parce que vim sous windows c'est nul à chier).
Je préfère vim avec les plugins qui vont bien mais bon, ninja-ide me semble bien, pour ce que je fais avec du moins (principalement des petits programmes avec tkinter).

[Sekigo Le Magnifique]

J'ai un petit problème en python, j'avais fais un script en python 3.4 pour parser une position GPS d'une page web. Il fonctionne bien. Par contre en passant le script en 2.7 ça marche pas. Le problème vient du caractère '°' dans l'expression régulière. Qui passait bien en 3.4 et là visiblement il bloque, car re.search me revoit none dès que je le met dans l'expression régulière. J'ai tenté de l'échapper \° sans résultat.

J'ai vérifié qu'il n'y avait pas de problème d'encodage sur l'entrée. Du moins Pas dans le string en mode inspection dans PyCharm.
HELP please.

Tu as effectivement un problème d'encodage. Python3 a facilité beaucoup de choses de ce coté là.
Si tu veux pas t'emmerder, TOUT tes fichiers .py doivent être sous la forme (pour l'en-tête):

#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""
TODO: écrire la documentation de ce module
"""
from __future__ import unicode_literals, print_function, division

Il faut aussi que tu t'assures que tes codes sources sont encodés en utf-8.
Ainsi, toutes tes chaines de caractères "en dur" dans le code seront en unicode (un peu comme si il y avait la lettre u devant chaque string). Dont la regexp.
Bien entendu, il faut AUSSI que tu t'assures que la chaine que tu envoies à matcher dans la regexp soit aussi en unicode. Unicode everywhere.

En python2, c'est vicieux parce qu'il y a deux types de bases pour les chaines de caractères: les str et les unicode. Respectivement renommées en byte et str en python3. Les str en python2, c'est une suite d'octets, où un glyphe visuel est égal en réalité à un ou plusieurs caractères en mémoire suivant l'encodage. Les unicodes, c'est une "vraie" chaine de caractère, où chaque glyphe visuel est égal à un caractère en mémoire (je schématise).
Si tu ne comprends pas, fais joujou avec l'interpréteur, il est là pour ça:

In [6]: import re

In [7]: re.search('°', '::°::')  # Deux str avec le même encodage, ça match
Out[7]: <_sre.SRE_Match at 0xb60a69c0>

In [8]: re.search('°', u'::°::')  # Un str et un unicode, ça match pas

In [10]: re.search(u'°', u'::°::')   # Deux unicode, ça match
Out[10]: <_sre.SRE_Match at 0xb60a6b10>

In [11]: re.search(u'°', u'::°::'.encode('latin-1'))  # un unicode et un str, ça match pas
Out[11]: <_sre.SRE_Match at 0xb60dd678>                                                                                                                                             

In [12]: re.search(u'°'.encode('utf-8'), u'::°::'.encode('latin-1'))  # deux str avec un encodage différent, ça match pas

In [16]: u'°'  # Le signe unicode
Out[16]: u'\xb0'

In [17]: u'°'.encode('utf-8')  # On transforme en str utf-8. On voit qu'il y deux octets
Out[17]: '\xc2\xb0'

In [18]: u'°'.encode('latin-1')  # On transforme en str latin-1. Et on voit qu'il y a un octet
Out[18]: '\xb0'

Je pense que ça ne peut pas matcher parce que par défaut, python2 interprète ton code comme encodée en latin-1 (si y a rien dans l'en-tête). Et la chaine que tu envoies, c'est certainement soit de l'unicode, soit de l'utf-8. Et dans tous les cas != latin-1.

Ou autre hypothèse (la plus probable), comme python2 interprète ton code en latin-1 si tu ne lui as rien précisé, mais que ton fichier source est en utf-8, ça va probablement foutre la merde, parce que `°` est sur deux octets en utf-8, et un seul en latin-1. Et il te lèvera pas d'erreurs d'encodage parce que les deux octets en utf-8 (correspondant à un glyphe visuel) sont correct en latin-1 (correspondant à deux glyphes visuels qui n'auront probablement aucun sens). Python ne va pas chercher à savoir si tes strings ont un sens, il va juste regarder si les trucs que t'as mis dedans sont valide d'un point de vue encodage. Ce qui est le cas.
\o/ Bienvenue dans l'enfer de l'encodage et l'unicode. Prochaine étape, découvrir les cotés cool d'unicode

En python3, le code est interprété par défaut en utf-8 et toutes les chaines de caractères sont de l'unicode.


Les chaines raw (celle préfixé par un r), elles ne sont d'aucune utilité dans ce problème là. Elles servent à ne pas échapper le caractère antislash, et par habitude, on les utilises pour les regexps (et les chemins sous windows), vu qu'elles se servent des antislashs de manière récurrente.
Et on peut très bien les coupler avec le signe `u` unicode. Ce qui donne ur"mon string".

C'est un peu compliqué et indigeste, je le conçois. Faut vraiment faire joujou avec la console pour comprendre, et tester plein de trucs idiots.
Tous les langages qui manipulent de l'unicode ET des bytes sont impactés par ce "problème" (qui n'en ai pas un en réalité).

[Teocali]

De toute façon, pour l'encoding et Python, un seul article : http://sametmax.com/lencoding-en-pyt...is-pour-toute/. J'ai deja du le balancer une ou deux fois, en plus. Encore un ou deux fois, et ça pourra terminer dans l'OP

[moimadmax]

J'aurais tendance a dire oui. Mais colle ton script, qu'on regarde. Ça fait longtemps que j'ai pas fait mumuse en python

J'ai honte c'est trop sâle. C'est en gros chantier et je suis débutant python (http://pastebin.com/bt8BAaYb)

Le mec a la flemme de faire une install de python ! Encore de visualstudio ou un gros fatras je comprend mais python, 13 Mo.

J'ai pas la fleme, c'est pour pas pourrir le PC du taf avec ce projet qui tournera sur un raspberry après. Du coup la version portable me parait correct.

Tu as effectivement un problème d'encodage. Python3 a facilité beaucoup de choses de ce coté là.
Si tu veux pas t'emmerder, TOUT tes fichiers .py doivent être sous la forme (pour l'en-tête):

#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""
TODO: écrire la documentation de ce module
"""
from __future__ import unicode_literals, print_function, division

Il faut aussi que tu t'assures que tes codes sources sont encodés en utf-8.
Ainsi, toutes tes chaines de caractères "en dur" dans le code seront en unicode (un peu comme si il y avait la lettre u devant chaque string). Dont la regexp.
Bien entendu, il faut AUSSI que tu t'assures que la chaine que tu envoies à matcher dans la regexp soit aussi en unicode. Unicode everywhere.

En python2, c'est vicieux parce qu'il y a deux types de bases pour les chaines de caractères: les str et les unicode. Respectivement renommées en byte et str en python3. Les str en python2, c'est une suite d'octets, où un glyphe visuel est égal en réalité à un ou plusieurs caractères en mémoire suivant l'encodage. Les unicodes, c'est une "vraie" chaine de caractère, où chaque glyphe visuel est égal à un caractère en mémoire (je schématise).
Si tu ne comprends pas, fais joujou avec l'interpréteur, il est là pour ça:

In [6]: import re

In [7]: re.search('°', '::°::')  # Deux str avec le même encodage, ça match
Out[7]: <_sre.SRE_Match at 0xb60a69c0>

In [8]: re.search('°', u'::°::')  # Un str et un unicode, ça match pas

In [10]: re.search(u'°', u'::°::')   # Deux unicode, ça match
Out[10]: <_sre.SRE_Match at 0xb60a6b10>

In [11]: re.search(u'°', u'::°::'.encode('latin-1'))  # un unicode et un str, ça match pas
Out[11]: <_sre.SRE_Match at 0xb60dd678>                                                                                                                                             

In [12]: re.search(u'°'.encode('utf-8'), u'::°::'.encode('latin-1'))  # deux str avec un encodage différent, ça match pas

In [16]: u'°'  # Le signe unicode
Out[16]: u'\xb0'

In [17]: u'°'.encode('utf-8')  # On transforme en str utf-8. On voit qu'il y deux octets
Out[17]: '\xc2\xb0'

In [18]: u'°'.encode('latin-1')  # On transforme en str latin-1. Et on voit qu'il y a un octet
Out[18]: '\xb0'

Je pense que ça ne peut pas matcher parce que par défaut, python2 interprète ton code comme encodée en latin-1 (si y a rien dans l'en-tête). Et la chaine que tu envoies, c'est certainement soit de l'unicode, soit de l'utf-8. Et dans tous les cas != latin-1.

Ou autre hypothèse (la plus probable), comme python2 interprète ton code en latin-1 si tu ne lui as rien précisé, mais que ton fichier source est en utf-8, ça va probablement foutre la merde, parce que `°` est sur deux octets en utf-8, et un seul en latin-1. Et il te lèvera pas d'erreurs d'encodage parce que les deux octets en utf-8 (correspondant à un glyphe visuel) sont correct en latin-1 (correspondant à deux glyphes visuels qui n'auront probablement aucun sens). Python ne va pas chercher à savoir si tes strings ont un sens, il va juste regarder si les trucs que t'as mis dedans sont valide d'un point de vue encodage. Ce qui est le cas.
\o/ Bienvenue dans l'enfer de l'encodage et l'unicode. Prochaine étape, découvrir les cotés cool d'unicode

En python3, le code est interprété par défaut en utf-8 et toutes les chaines de caractères sont de l'unicode.


Les chaines raw (celle préfixé par un r), elles ne sont d'aucune utilité dans ce problème là. Elles servent à ne pas échapper le caractère antislash, et par habitude, on les utilises pour les regexps (et les chemins sous windows), vu qu'elles se servent des antislashs de manière récurrente.
Et on peut très bien les coupler avec le signe `u` unicode. Ce qui donne ur"mon string".

C'est un peu compliqué et indigeste, je le conçois. Faut vraiment faire joujou avec la console pour comprendre, et tester plein de trucs idiots.
Tous les langages qui manipulent de l'unicode ET des bytes sont impactés par ce "problème" (qui n'en ai pas un en réalité).

Merci pour ton explication, c'est plus claire et en effet le ur"Regex" fonctionne parfaitement.

De toute façon, pour l'encoding et Python, un seul article : http://sametmax.com/lencoding-en-pyt...is-pour-toute/. J'ai deja du le balancer une ou deux fois, en plus. Encore un ou deux fois, et ça pourra terminer dans l'OP

Le pire c'est que je l'ai déjà lu et j'ai même pas pensé a y faire un tour quand je suis passé sur la V2.7

[Teocali]

Le pire c'est que je l'ai déjà lu et j'ai même pas pensé a y faire un tour quand je suis passé sur la V2.7

:gifd'unlapinquicolleunefessée:

EDIT:
dans l'instruction de retour de ta methode getpage(url), essaye return data.decode("latin_1").encode(utf-8)

[Møgluglu]

from __future__ import unicode_literals, print_function, division

Python...



Désolé mais ça faisait longtemps...

[Sekigo Le Magnifique]

Je viens de lire deux pages sur le site de rust (parce que Tomaka17 nous bassine avec, et parce que je vois plein de développeurs python le présenter):
* http://doc.rust-lang.org/0.12.0/guide.html
* http://doc.rust-lang.org/guide-strings.html

Ok. Je suis (presque) conquis.
La gestion des strings et du formatage de celle-ci est complètement foiré dans les langages web (javascript coté navigateur et php). C'est complètement con parce que c'est probablement le type de données qu'on manipule le plus.
Là, rust propose un formatage des strings python-like. C'est génial.
Et la gestion de l'encodage et de la dualité byte/string me semble bonne (un point très important pour moi, je bosse dans l'édition numérique et je manipule des flux de données texte dans toutes les langues et dans toute sorte d'encodage).

Et en lisant la doc en diagonale, j'ai presque tout pigé. Y a que les chapitres sur les références qui me semble encore un peu obscur, maitrisant surtout des langages haut niveau qui ne s’embarrassent pas trop sur la question. Les itérateurs, les boucles, les types de données composites, les modules, tout ça ressemble fortement à ce que j'utilise en python, et ce pourquoi j'adore ce langage. Et on sent aussi un bon héritage d'Haskell (je ne code pas avec, mais je lis pas mal de trucs en rapport, parce que c'est un langage qui m'intéresse pas mal. Je n'ai pas encore pris le temps de trouver un projet pour le tester en réel).
De première lecture, le système de type me semble bien plus intelligent que celui de Python (heureusement pour un langage à fort typage statique !), qui est à chier par rapport à d'autres langages. D'où l'utilisation de duck-typing massif en python.
Et y a pas l'héritage lourdingue de la POO en Java \o/ (coucou php).

Par contre, je ne vois pas trop comment marche la gestion des erreurs. La doc copie-colle les messages d'erreurs, mais c'est pas assez. Après, je pense que ça doit être à des années lumières de ce que je connais, parce que c'est un langage compilé et que pas mal d'erreurs doivent être gérer à la compilation. C'est un monde que je connais peu.

J'attends quand même la version stable pour commencer à voir si je l'utilise, au moins en expérimental chez moi pour des projets perso.
Je vais regarder la gestion du xml en Rust. Un autre point important pour moi. Et qui est souvent foiré aussi dans les langages web.

[Tomaka17]

Héhé

En ce qui concerne les erreurs, le Rust a des exceptions similaires à celles du python avec la macro "panic!". Cela dit, contrairement à d'autres langages, les exceptions ne devraient être utilisées que s'il n'est pas possible de gérer l'erreur ou qu'il s'agit d'une erreur de programmation (par exemple un manque de mémoire, t'as reçu comme paramètre une valeur négative alors qu'elle doit obligatoirement être positive, une classe est dans un état invalide, etc.). C'est plus une sorte de "plantage soft". D'ailleurs il n'est pas possible de les "catch" en Rust, mis à part si tu isoles totalement le code qui génère potentiellement une exception.

Le mécanisme qui est privilégié pour les erreurs, c'est de renvoyer un objet de type "Result". Par exemple ouvrir un fichier renvoie un "Result<File, IoError>". Si ça a marché, l'objet contient un "File", s'il y a eu un problème il contient un "IoError" qui décrit le problème.
En plus de ça t'as une macro "try!(operation)" qui te permet de dire "si l'opération renvoie une erreur, on return cette même erreur hors de la fonction, sinon on continue d'exécuter la suite du code avec la valeur du succès". Je trouve que c'est un très juste milieu entre la transparence (parce que gérer les erreurs c'est chiant) et la nécessité de s'occuper de ça quand même (gérer les erreurs, c'est important).
Et encore en plus de ça ils sont en train d'améliorer ce système pour que ce soit encore plus simple à utiliser.

Je ne suis pas trop l'évolution des guides, mais ils ont engagé un mec il y a quelques mois qui bosse à plein temps sur les guides. Il n'a probablement pas encore fait celui des erreurs.


Par contre si tu cherches un langage web, c'est pas encore ça pour le Rust. Il existe déjà des libs permettant de créer des sites web, mais elles sont plus ou moins copié-collées sur ce qui existe dans les langages webs classiques, et du coup ça ne profite pas vraiment des qualités du langage. Par exemple ils utilisent tous un vilain objet "AnyMap" qui te permet de stocker n'importe quel type, un peu comme si tu avais du typage dynamique.

[Sekigo Le Magnifique]

Ok, merci des infos. Le mieux serait d'avoir les mains dans le cambouis pour voir ce que ça donne.

En fait, je ne recherche rien. Je suis curieux par nature, et je n'hésite pas à voir comment ça se passe dans d'autres langages. Mais dans mon besoin concret de tous les jours, python me convient amplement. Il y a des choses qui me posent problème de temps à autre, mais 95% du temps, ça répond vite (dans le sens temps de développement alloué) et bien (dans le sens maintenabilité du programme) à mes problèmes et à mes besoins.

Le fait que la stack web ne soit pas encore au point en Rust n'est pas vraiment un problème pour moi. En réalité, je travaille beaucoup à destination du web, mais très peu *sur* le web (et ça tombe bien, parce que je HAIS travailler sur le web).
La plupart du temps, j'ai un moteur qui à partir d'un truc fabrique un autre truc (par exemple, à partir d'articles en docbook, je fais un ebook/pdf. Ou je vais moissonner des données sur plusieurs serveurs à l'étranger et convertir tout ça en données xml "standardisé"). Et pour utiliser ce moteur, je monte une interface web autour, qui est le moyen pour moi le plus rapide et le plus maintenable pour le déploiement (mais pas que. Parfois, je rajoute aussi une interface cli, parfois une interface en api pour python, etc.).
De temps en temps, je fais aussi des api REST pour la visualisation de données, et c'est principalement un client en JS/HTML qui va s'occuper de rendre tout ça humainement lisible (d'où ma déception vis à vis de angularjs qui n'est pas stable et qui continue à péter, qui m'aurait facilité grandement la tâche. Je ne veux *surtout* pas gérer ça coté serveur).
Donc, le seul truc dont j'ai réellement besoin, c'est d'avoir un serveur http solide et plein de bibliothèque pour me faciliter la vie dans les waoutmille formats qui pullulent en informatique. Tout les trucs genre framework web, je n'en ai pas besoin, je ne fais pas de site web en tant que tel. Au contraire, j'ai besoin d'un truc le plus éclaté possible, parce que les données en html d'aujourd'hui seront peut-être en yaml demain. Et les bases de données sql seront peut-être intégralement en redis après demain. Donc, pour maintenir les programmes, j'ai besoin d'avoir plein de modules que j'imbrique comme des legos et que je peux supprimer ou remplacer sans que ça impacte trop le code dans sa globalité.
Rust me tape dans l'oeil pour la sécurité des données traités, et les performances (c'est très très rare que j'ai des bottlenecks sur le cpu, la gestion des threads s'est bien amélioré ces derniers temps en python et c'est devenu moins critique de ce coté là). Et pour le fun, surtout pour le fun. Je ne connais pas trop les langages compilés, et j'aime bien sortir de ma zone de confort pour apprendre de nouvelles manière de faire et les intégrer à ma dite zone de confort. Et Rust m'a l'air de ne pas être trop éloigné de ce que je connais, tout en étant assez différent pour m'apprendre des tas de nouveaux trucs. J'aime bien faire des sauts de puces quotidien plutôt que tout bazarder tout les X ans.
Haskell me plait dans la théorie, mais c'est trop éloignée de ce que je fais habituellement et c'est trop extraterrestre par rapport au milieu informatique dans lequel j'évolue (où php est roi, qui est une relative bonne chose pour l'affichage des données, mais qui l'est beaucoup beaucoup moins pour le traitement des données).

Je ne souhaite absolument pas bazarder python pour un autre truc. En fait, j'ai plein de modules différents et y en a certains que je voudrais "figer" dans un langage statiquement typé et plus safe niveau code que python. Je pensais le faire en C, mais c'est trop relou à écrire, je n'y prend aucun plaisir.

[Awake]

On dirai qu'il y a une tendance à laisser tomber l'OOP, par exemple Rust et go ne le proposent pas. Javascript non plus, on pourrait penser à cause de l'age mais vu le carton que fait node ce n'est pas le cas.

Vous avez une idée du pourquoi ?

J'ai toujours trouvé l'OOP élégant, au même titre que la programmation événementielle, l'abandonner semble un retour en arrière.

[Tomaka17]

Les types et les interfaces ne sont pas près de disparaître dans les langages à typage fort.
Le seul truc qui disparaît c'est l'héritage de classes non-abstraites. On a enfin remarqué que surcharger une classe n'avait aucun intérêt et était même néfaste dans la mesure où tu es quasi tout le temps obligé de faire des changements dans la classe parente afin de l'adapter à l'enfant.
Plutôt que d'avoir B et C qui héritent de A, il est quasi-toujours mieux de cacher A dans l'implémentation de B et C.

L'OOP en soi n'est pas forcément néfaste, par contre le "style OOP" l'est. Je veux parler du fait d'avoir des objets avec une longue durée de vie, de vouloir tout rendre générique en utilisant des interfaces partout, de créer des Builder et des BuilderBuilder, utiliser des singletons, etc. Ça rend le code plus complexe, plus spaghetti, donc plus buggé, et en plus tu es lent (heap + vtable partout, ouch les perfs) et incompatible avec le parallélisme. Quand je vois quelqu'un parler du "gang of four" en général je m'enfuis en courant.

---------- Post added at 14h36 ---------- Previous post was at 14h20 ----------

D'ailleurs en Rust il y a des débats houleux sur "faut-il ou non ajouter de l'héritage".

Apparemment l'équipe qui s'occupe de Servo (un navigateur, le second plus gros projet Rust existant derrière le compilo) en aurait besoin pour faire un truc précis.
Le Rust possède des traits et des templates, qui sont un mécanisme d'abstraction bien plus puissant que l'héritage de classes abstraites. Du coup beaucoup de gens ne veulent pas voir arriver des programmeurs qui ignoreraient ces mécanismes et coderaient en Rust en Java-style.