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

[Naity]

Sinon oui, la classe Hello world en Java, c'est genre pénible. Mais pas autant que les programmeurs Java qui te ramènent ces "bonnes pratiques" en C. A la base, je pense qu'il doit y avoir une sémantique derrière la définition d'une classe, mais je sais que je suis vieux jeu

C'est quoi ce que tu appelles la sémantique derrière la définition d'une classe?

[Lazyjoe]

Des design patterns.

[vectra]

Ca doit représenter une entité tangible dont le nom laisse deviner la fonction et le contour précis des missions qui lui sont dévolues. Rien qu'au nom, s'il le faut complété d'un commentaire de deux lignes, on doit deviner l'essentiel des données membres et des méthodes.

Mais une classe random pour rien, je ne vois pas. Autant mettre le bordel fourre-tout dans vectra_misc.c
Après, c'est ma version à moi de comment qu'on doit faire.

[BentheXIII]

Coin,
j'ai écrit un script python qui génère une bmatrix ou tabular Latex à partir d'un Numpy array, avec possibilité de passer des en-têtes de colonnes/lignes. J'en avais marre de copier/coller depuis le terminal . Si jamais y'a des intéressés, ça se passe par là

[war-p]

Ouah putain, j'aurais jamais dû parler de lombok, si j'avais su que ça vous mettrais dans cet état
Sinon, lombok, c'est pas que pour les getter/setter, c'est bien plus puissant que ça, ça permet de générer tout les bouts de code qu'on réécrit à peu près 1 millions de fois lorsque l'on crée des beans en java, ça inclue les builder pattern et pleins d'autres joyeusetés.

[rOut]

Ouah putain, j'aurais jamais dû parler de lombok, si j'avais su que ça vous mettrais dans cet état
Sinon, lombok, c'est pas que pour les getter/setter, c'est bien plus puissant que ça, ça permet de générer tout les bouts de code qu'on réécrit à peu près 1 millions de fois lorsque l'on crée des beans en java, ça inclue les builder pattern et pleins d'autres joyeusetés.

Ouais mais je prenais cet exemple parce que c'est assez obvious (j'aurais pu prendre la génération des constructeurs via la liste des membres, ou des fonctions equals ou hashCode. C'est bien Lombok que j'avais justement utilisé et c'était quand même bien sympa.

Sinon, pour en revenir au C++: http://www.meetup.com/User-Group-Cpp...ents/229508095

[vectra]

Non mais déjà qu'on peut plus faire de hardware-porn sur le topic, si en plus on ne peut pas basher java et python, je me fais rembourser mon invitation

[Tomaka17]

Non mais déjà qu'on peut plus faire de hardware-porn sur le topic, si en plus on ne peut pas basher java et python, je me fais rembourser mon invitation

Au pire on se rabat sur le Javascript et le PHP.

[war-p]

PHP, trop facile

[Sodium]

C'est très bien PHP.
Par contre sur JavaScript vous pouvez y aller, c'est open bar, même s'il y en aura toujours pour dire qu'avec le bon bouquin de 1200 pages, 7 frameworks, un moteur côté serveur et 3 langages intermédiaires qui compilent ensuite le code c'est the best thing ever.

[Charmide]

C'est un peu comme si on s'en moquait du langage, et ce qui importait c'est ce qu'on fait avec

[Orhin]

C'est très bien PHP.
Par contre sur JavaScript vous pouvez y aller, c'est open bar, même s'il y en aura toujours pour dire qu'avec le bon bouquin de 1200 pages, 7 frameworks, un moteur côté serveur et 3 langages intermédiaires qui compilent ensuite le code c'est the best thing ever.

On pourrait dire exactement l'inverse sans que ça choque hein.

En vrai ce sont 2 langages qui ont énormément évolué (encore plus pour le JS) ces dernières années, que ce soit au niveau des framework ou des perfs brutes.

[Sodium]

C'est un peu comme si on s'en moquait du langage, et ce qui importait c'est ce qu'on fait avec

Pas tout à fait d'accord. On peut faire de très belles choses très bien organisées avec la plupart des langages, effectivement. Sauf qu'avec JavaScript, c'est chiant.
Quand je fais de l'orienté objet en JS et que c'est une gymnastique permanente que de garder la trace de l'instance courante dans laquelle une méthode s'exécute, je trouve ça chiant, par exemple.

En vrai ce sont 2 langages qui ont énormément évolué (encore plus pour le JS) ces dernières années, que ce soit au niveau des framework ou des perfs brutes.

En théorie c'est vrai (même si JS en lui-même n'a pas tant évolué que ça, le passage à ES6 est encore en cours il me semble), en pratique on est toujours avec JavaScript obligé de prendre en charge le navigateur de l'utilisateur qui peut avoir jusqu'à 10 ans de retard.

Dans tous les cas, ce n'est pas la teuf. Sans framework ou langage intermédiaire, faire du full objet avec JavaScript reste une plaie. Le Canvas HTML5 permet de faire des choses super mais l'API qui va avec ne propose que des manipulations de bas niveau et est pratiquement innexploitable sans l'une des nombreuses librairies encore en version Alpha qui se tirent la couverture.

Il y a autant de façon de travailler avec JavaScript qu'il y a de développeurs, et personnellement je ne pense pas qu'il s'agisse d'une force.

[rOut]

Pas tout à fait d'accord. On peut faire de très belles choses très bien organisées avec la plupart des langages, effectivement. Sauf qu'avec JavaScript, c'est chiant.
Quand je fais de l'orienté objet en JS et que c'est une gymnastique permanente que de garder la trace de l'instance courante dans laquelle une méthode s'exécute, je trouve ça chiant, par exemple.



En théorie c'est vrai (même si JS en lui-même n'a pas tant évolué que ça, le passage à ES6 est encore en cours il me semble), en pratique on est toujours avec JavaScript obligé de prendre en charge le navigateur de l'utilisateur qui peut avoir jusqu'à 10 ans de retard.

Dans tous les cas, ce n'est pas la teuf. Sans framework ou langage intermédiaire, faire du full objet avec JavaScript reste une plaie. Le Canvas HTML5 permet de faire des choses super mais l'API qui va avec ne propose que des manipulations de bas niveau et est pratiquement innexploitable sans l'une des nombreuses librairies encore en version Alpha qui se tirent la couverture.

Il y a autant de façon de travailler avec JavaScript qu'il y a de développeurs, et personnellement je ne pense pas qu'il s'agisse d'une force.

Franchement, quand j'ai tripoté atom en coffeescript j'ai trouvé ça plutôt plaisant. Et plus que du python

[Longwelwind]

Bah justement, le créateur de Javascript a dit que le développement de WebAssembly (un nouveau langage "natif" web crée en concertation avec plusieurs géants des navigateurs) était "excitant".
On va peut-être enfin avoir un environnement web sympa !

[Tomaka17]

WebAssembly ne va probablement rien changer pour le développeur front-end lambda.

Si tu veux faire une app client-side avec WebAsm, soit tu dessines toute ton app à base de canvas ou WebGL, ce qui est très mauvais pour une UI puisque tu perds la moitié de ce qu'offre le browser, soit tu dessines tout avec du DOM et du CSS, et là tu perds tout l'intérêt d'utiliser WebAsm.

Webasm va probablement surtout servir pour les jeux, et pour coder des fonctions utilitaires (qui ne manipulent pas le DOM) pour les apps complexes comme celles de Google.

[Charmide]

Pas tout à fait d'accord. On peut faire de très belles choses très bien organisées avec la plupart des langages, effectivement. Sauf qu'avec JavaScript, c'est chiant.
Quand je fais de l'orienté objet en JS et que c'est une gymnastique permanente que de garder la trace de l'instance courante dans laquelle une méthode s'exécute, je trouve ça chiant, par exemple.

Typiquement, faire de l'orienté objet dans un langage sans concept objet, c'est sûr que ça va être un peu râpé. Mais c'est pas non plus l'unique paradigme.

Au sujet de l'ES6 (et plus), en pratique, bien beaucoup de monde en écrit puis utilise des transpillers dont l'output est compatible avec IE 8 (tu peux toujours voir ça comme un "langage intermédiaire", personnellement je vois assez peu d'intérêt à faire la distinction, surtout quand c'est que du "js du futur"). La compatibilité navigateur, concrètement, après des décennies de souffrance, c'est sur le précipice de devenir un non-problème pour une grande majorité de cas.

Sur "Il y a autant de façon de travailler avec JavaScript qu'il y a de développeurs, et personnellement je ne pense pas qu'il s'agisse d'une force", ça se défend. Je pense pas que ce soit un atout non plus si tu le prends à cet échelle.
Le truc, c'est un peu comme PHP. Sauf que pour PHP si ça te donnait des boutons tu pouvais toujours choisir autre chose. Sauf que là t'es bloqué. Du coup la distinction se fait sur la couche d'au-dessus.
Au final, ça veut dire que "travailler avec JavaScript", ça va dans ton sens, veut plus dire grand chose. On est plus dans du "Je travaille avec React + Babel", "Je travaille avec Angular 1.X", "Je travaille avec jquery + rxjs", "Je travaille avec document.write", et trucmuche. Ca fait davantage de sens de raisonner à cette échelle à propos du javascript ces temps-ci. Typiquement, pour reprendre ton point de vue, chacun de ses groupes auront des façons de travailler consistantes, et des bonnes pratiques relativement stables.
Et c'est presque normal qu'on en soit là vu la quantité de javascript pondue, et la diversité des développements web (sans même prendre en compte node & co... Cf la comparaison avec PHP ).

[Sodium]

Typiquement, faire de l'orienté objet dans un langage sans concept objet, c'est sûr que ça va être un peu râpé. Mais c'est pas non plus l'unique paradigme.

Je t'arrête tout de suite, JavaScript est totalement orienté objet, bien plus que du PHP.
Il n'implémente pas le modèle de classe commun à la plupart des langages hérités du C++, ce qui est différent.

Le truc, c'est un peu comme PHP. Sauf que pour PHP si ça te donnait des boutons tu pouvais toujours choisir autre chose. Sauf que là t'es bloqué. Du coup la distinction se fait sur la couche d'au-dessus.

PHP a rattrapé une bonne partie de son retard dans sa version 5.2 qui est maintenant plus que largement implantée et est encore passé à la vitesse supérieure dans sa version 7 qui est maintenant officiellement sortie.

En PHP comme en JavaScript et comme pour n'importe quel langage, il y a effectivement des librairies, des frameworks, etc. Sauf que dans le cas de PHP, ces outils servent à ce à quoi ils doivent servir, c'est à dire faciliter le travail du développeur et le travail en équipe en permettant de faire plus de choses avec moins de code tout en apportant un cadre comme dans la manière de travailler. En JavaScript par contre, une grosse majorité des outils disponibles (jQuery, Angular, TypeScript...) servent à standardiser la manière dont le code est interprété par les navigateurs et émuler des fonctionnalités manquantes. PHP est resté au fil des ans PHP. JavaScript par contre, il ne se passe pas trois mois sans qu'un langage ou pseudo-langage vienne se présenter comme son successeur ou une nouvelle révolution.

[Charmide]

WebAssembly ne va probablement rien changer pour le développeur front-end lambda.

Si tu veux faire une app client-side avec WebAsm, soit tu dessines toute ton app à base de canvas ou WebGL, ce qui est très mauvais pour une UI puisque tu perds la moitié de ce qu'offre le browser, soit tu dessines tout avec du DOM et du CSS, et là tu perds tout l'intérêt d'utiliser WebAsm.

Webasm va probablement surtout servir pour les jeux, et pour coder des fonctions utilitaires (qui ne manipulent pas le DOM) pour les apps complexes comme celles de Google.

Je suis d'accord avec ton analyse.
Après, il y a cet espèce de sentiment qui flotte dans l'air que finalement le DOM est plus une contrainte qu'un atout.
Je vois bien à long terme des surcouches sur du Canvas ou du WebGL qui te permettent de t'occuper de ta présentation sans avoir à descendre trop bas.

Me semble que je l'avais déjà évoqué, mais j'me répète, React par exemple est assez marrant pour ça. Ils ont sorti React Native pour faire des apps mobiles avec un coeur javascript + un layer de présentation natif (contrairement à phonegap/cordova & co où la présentation est du DOM dans un pseudo-browser).
Pour transformer ton app React web en app React Native, t'as littéralement juste à transformer un return <h1>Title</h1>; dans ton code en return <TextboxAndroidNative> Title </TextboxAndroidNative>;. Avec, bien sûr, pas mal de magie derrière, mais qui s'abstrait pour ton dev web lambda.
Un peu plus loin je vois bien un <MonComposantQuiSurcoucheCanvas> Title </MonComposantQuiSurcoucheCanvas>.

Comme tu le dis, court-circuiter le DOM ça ne semble avoir d'intérêt que pour des apps complexes. Je doute pas qu'il restera des devs wordpress dans 15 ans qui font juste de l'intégration et 2 ou 3 manip' en Jquery.
C'est aussi le sens du vent, du site statique au framework JS. La valeur ajoutée des gros projets web se crystalise de plus en plus sur des problématiques d'UX. Donc tu veux la main complète sur ta couche de présentation. C'est une des raisons pour lesquelles on a commencé à s'amuser à manipuler le DOM via du javascript.
Au final, ça pourrait toucher une bonne grosse partie du web.
Des interfaces web aussi flexibles que des interfaces de JV, je demande à voir.

- - - Mise à jour - - -

Je t'arrête tout de suite, JavaScript est totalement orienté objet, bien plus que du PHP.
Il n'implémente pas le modèle de classe commun à la plupart des langages hérités du C++, ce qui est différent.

C'est gentil de m'arrêter tout de suite, j'espère que tu as lu le reste quand même.
J'étais pas très habile dans les termes, mais sans contexte, "orienté objet" ne m'inspire pas grand chose. Vu celui que tu as fourni, j'ai conclu que t'essayais de faire autre chose que du prototype. Parce que sinon je vois pas très bien le problème.

[Orhin]

En théorie c'est vrai (même si JS en lui-même n'a pas tant évolué que ça, le passage à ES6 est encore en cours il me semble), en pratique on est toujours avec JavaScript obligé de prendre en charge le navigateur de l'utilisateur qui peut avoir jusqu'à 10 ans de retard.

Bof, on peut facilement se permettre d'envoyer chier les dinosaures non compatibles maintenant.
Au pire, transpiler.

Sans framework ou langage intermédiaire

Oui mais elle est là l'évolution, personne d'un peu sérieux n'utilise un langage (quel qu'il soit) sans la stack qui lui est adaptée.

Sauf que dans le cas de PHP, ces outils servent à ce à quoi ils doivent servir, c'est à dire faciliter le travail du développeur et le travail en équipe en permettant de faire plus de choses avec moins de code tout en apportant un cadre comme dans la manière de travailler.

C'est exactement le cas de toute la stack Angular hein.

[Naity]

Faites gaffe. Ca derive presque comme sur (feu) le toppic de l'actu. Avec vos querelles politiques le banhammer vous attend au tournant

[Charmide]

En PHP comme en JavaScript et comme pour n'importe quel langage, il y a effectivement des librairies, des frameworks, etc. Sauf que dans le cas de PHP, ces outils servent à ce à quoi ils doivent servir, c'est à dire faciliter le travail du développeur et le travail en équipe en permettant de faire plus de choses avec moins de code tout en apportant un cadre comme dans la manière de travailler. En JavaScript par contre, une grosse majorité des outils disponibles (jQuery, Angular, TypeScript...) servent à standardiser la manière dont le code est interprété par les navigateurs et émuler des fonctionnalités manquantes.

J'ai un peu du mal à te suivre.
TypeScript a vocation à être un langage différent, ça n'est ni une librairie ni un framework. C'est une alternative qui a ses mérites et effectivement ça sert à palier des défauts du langage en lui-même (en l’occurrence l'absence de typing), qui sont indéniables mais encore une fois, à mon sens, pas incroyablement importantes.
JQuery est une librairie qui apporte des fonctionnalités. Elle est typée usine à gaz, donc c'est dur de la résumer, mais manipuler le DOM, qui reste son boulot principale et ce qui a fait sa $('.popularité'), c'est tout à fait possible avec du JS vanilla, ie. son boulot principal c'est littéralement "faire plus de choses avec moins de code".
Angular, c'est un framework, "un cadre comme dans la manière de travailler" c'est littéralement comme ça que je le décris. Ca vient avec ses designs patterns (le double-binding, l'injection de dépendance), son architecture (MVC, templating providers/controllers/directives). D'aucune façon ça ne sert à "standardiser la manière dont le code est interprété par les navigateurs et émuler des fonctionnalités manquante". Je suis sûr que si tu fouilles tu trouveras des fonctions utilitaires planquées quelque part pour être sûr que ça tourne sur IE8, mais en aucun cas c'est son objet.

Aucun d'entre eux ne s'inscrit dans une course à la destruction du Javascript ou à une révolution qui rend tout le reste obsolète.

PHP est resté au fil des ans PHP. JavaScript par contre, il ne se passe pas trois mois sans qu'un langage ou pseudo-langage vienne se présenter comme son successeur ou une nouvelle révolution.

C'est une preuve de dynamisme. Objectivement, tu peux pas préférer que ton écosystème ait moins d'innovation. C'est pas une qualité que rien ne bouge pendant des années, hein, c'est pas le signe qu'il ne reste plus rien à inventer et qu'on pourra jamais faire mieux
Suffit de pas se faire prendre par la hype et d'avoir une approche rationnelle pour que ce soit une qualité. J'en connais des gars qui si on les laissait faire referaient tout tous les trimestres sans autre motivation que l'amour de la nouveauté, mais ça, c'est pas exactement un défaut de l’écosystème.
A l'inverse, de la façon dont tu le décris, j'ai un peu l'impression d'entendre ce qu'on faisait dans le web il y a très longtemps. Ou alors, tel que quelqu'un qui en fait à la va-vite de temps en temps le verrait.
Et ça me fait mal

- - - Mise à jour - - -

Faites gaffe. Ca derive presque comme sur (feu) le toppic de l'actu. Avec vos querelles politiques le banhammer vous attend au tournant

Sévère comme comparaison

Mais je défendrais la veuve et l'orphelin jusqu'à la fin des temps.

[Nattefrost]

Oui mais elle est là l'évolution, personne d'un peu sérieux n'utilise un langage (quel qu'il soit) sans la stack qui lui est adaptée.

C'est quoi la stack adaptée à un langage ? Y a des outils autour du langage (ou d'une implémentation d'un langage) qui sont adaptés à un usage mais le langage lui-même n'est pas de facto lié à une stack, c'est une spec et c'est tout non ?
A part peut-être des langages dont l'usage (peut etre R ou certains langages fonctionnels ? je connais mal je dois le confesser) est de fait extremement spécifique car leur implémentation et la stdlib qui a été designée l'a été pour un usage bien particulier ?

En fait je comprend pas bien ce qu'on appelle stack, j'ai un peu l'impression d'un mot fourre-tout. Pour moi la stack on se la fait en fonction des outils (librairies, frameworks) existants autour du langage qu'on veut ou doit utiliser et du projet qu'on doit réaliser.

Dans le cas de JS, je trouve que le fait qu'utiliser du JS vanilla soit plus ou moins vu comme une "mauvaise pratique" en dit long.

[Sodium]

Dans le cas de JS, je trouve que le fait qu'utiliser du JS vanilla soit plus ou moins vu comme une "mauvaise pratique" en dit long.

C'est également mon avis, d'autant qu'à être automatiquement orientés vers des librairies comme jQuery, les développeurs ne maîtrisent pas les bases du langage en lui-même.

[vectra]

Yop les gens,

De bons bouquins pour la programmation en assembleur, en intrinsics?

[Monsieur Odd]

Typiquement, faire de l'orienté objet dans un langage sans concept objet, c'est sûr que ça va être un peu râpé. Mais c'est pas non plus l'unique paradigme.

La POP c'est de la POO.

Et, un peu de sucre avec l'ES6 :

https://developer.mozilla.org/fr/doc...erence/Classes

[Møgluglu]

Yop les gens,

De bons bouquins pour la programmation en assembleur, en intrinsics?

Ce recentrage de débat.

J'ai pas de bouquin de référence qui me vienne à l'esprit. Ça évolue vite et ça intéresse peu de monde. J'aurais bien conseillé l'Abrash, mais ça a légèrement vieilli.
Sinon les chapitre 2 et 3 d'Agner, ou les whitepapers d'Intel. Mais sorti des listes d'instructions sèches, l'info sur comment les utiliser est globalement éparpillée et rarement à jour.

[Tomaka17]

La POP c'est de la POO.

Faut arrêter de mettre tout dans le sac "POO".
Si tu définis "langage orienté objet" comme "langage ayant un concept d'objet", il n'y a pas un seul langage qui ne soit pas orienté objet. Même le C a un concept d'objet, car officiellement `malloc()` renvoie un objet. Le Haskell par exemple, que personne n'oserait qualifier d'orienté objet, a pourtant lui aussi des classes et de l'héritage.
Avant ES6 le Javascript était plus éloigné du Java/C# que ne le sont le C ou le Haskell.

[Nattefrost]

@Tomaka : le fait qu'un langage soit fonctionnel n'empêche pas qu'il soit objet, du moment que l'on manipule des objets et pas des types "primitifs" (comme on dirait en js), si ?
Je connais pas Haskell mais si je prend F#, y a bien des classes avec des constructeurs, de l'héritage, des méthodes. Et de ce que je lis rapidement sur Haskell, c'est le cas également, alors pourquoi

Le Haskell [...] que personne n'oserait qualifier d'orienté objet, a pourtant lui aussi des classes et de l'héritage.

Est-ce parce qu'on catégorise beaucoup les langages comme impératif/fonctionnel/objet/pas objet et qu'on considère ces types mutuellement exclusifs (peut-être à tort?) ou y a-t-il une raison plus technique ou philosophique que je ne comprend pas?

edit : Un autre exemple. Powershell, c'est objet, fonctionnel et impératif à la fois.

[Tomaka17]

La POO c'est un modèle. C'est pas quelque chose de scientifique, c'est juste un terme qui permet de présenter les choses.
Quand tu dis "tel langage est orienté objet", ça permet en quelques mots de dire au programmeur à quoi il peut s'attendre en essayant le langage. Dire qu'un langage est orienté objet alors qu'en réalité il est très éloigné des langages orientés objet classiques, je trouve ça mensonger, même lorsque c'est techniquement vrai.

La raison pour laquelle ce truc particulier me "trigger" systématiquement, c'est que quand quelqu'un dit "le langage X est orienté objet", il y a des gens qui entendent "cool, je vais pouvoir faire du java entreprise edition avec ce langage".
Au lieu de présenter aux gens de nouveaux paradigmes de programmation qu'ils n'ont pas forcément l'habitude de voir, on les encourage à programmer toujours de la même façon en changeant juste de syntaxe.