Axioplase ıɥs∀ a écrit 3037 commentaires

Il ne manque [du Cyberpunk et dans la réalité] que les membres cybernétiques et les interfaces neurales.

Ben, les interfaces neurales, ça existe, hein. Non, ça ne permet pas d'aller dans un monde virtuel, mais oui, ça permet d'interagir avec des ordis et machines.

C'est le mot <anglais>archive</anglais> avec une écriture rigolote (sans doute choisie par des amateurs de sk8board), donc je prononce <anglais>archive</anglais>.
Mais, honnêtement, ça fait plus de 10 ans que je l'utilise, et je n'étais pas dans la francophonie quand j'ai découvert, donc je ne sais plus si j'avais été bien surpris.

« Queuneau pisse » évidemment. Comme Bruxelles, quoi.

Le plaisir du bépo, qui m'a permis de facilement faire mes majuscules accentuées !

Les anglophones ont les mêmes règles infondées, telles qu'« on ne doit pas finir une phrase par une préposition » (e.g. "it's a thing I shan't put up ~with~").

En 2005, Bruce Schneier recommandait que l'on écrivît ses mots de passe sur papier et qu'on les mît dans son portefeuille.

Si je me souviens bien, il y a 20 ans de ça j'utilisais Glade pour faire des GUIs. Grosso modo, tu fais tout joliment dans une UI, et ça génère une config XML. Ensuite, t'as juste à coder ta logique en faisant référence aux identifiants de ta config XML. Un peu comme si tu faisais une app avec AndroidStudio.

Il y a certainement des alternatives pour QT, Swing, etc.

Cette vidéo de lui est, je crois, importante à regarder. Il y explique pas mal de résultats : https://www.youtube.com/watch?v=vWJvOJ8j4Co

Je me suis posé la question beaucoup récemment. Je pense que j'ai résumé à ça :
- continuer à apprendre, à croître
- être entouré de gens (plus) intelligents qui partagent
- avoir de la diversité dans le contenu

Le serpent, de la famille Boidae: https://en.wikipedia.org/wiki/Pelvic_spur

Les pythons et les boas ont des pattes rudimentaires, pourtant.

C'est toi qui a inventé l'histoire de moyenne. Il a juste écrit :

Mais pour les listes java semble un peu lourd. Mon exercice est simple, j'ai une liste t1 [1,2,3,4] et une liste t2 ["lundi","mardi","mercredi","jeudi"] et je veux créer une liste t3 [1,"lundi",2,"mardi",3,"mercredi",4,"jeudi"] à partir de t1 et t2.

Bref, pour faire simple: avec tes solutions, tu ne serais pas embauché chez du GAFA. C'est hyper long, hyper complexe, et fragile.

Encore une fois. Python, Java, et Excel, c'est pas la même chose. Il a des règles à suivre pour assurer la qualité du code, des règles qui ont été découvertes empiriquement depuis des dizaines d'années. "Je peux le faire" est différent de "c'est une bonne idée".
Relis ton code, relis le mien, et demande-toi "si je devais maintenir ce code et corriger un bug à 3h du mat quand des millions d'utilisateurs ne peuvent plus utiliser mon service, lequel choisirai-je ?" C'est mon job, et le choix est vite fait…

Rajoute un compteur pour compter les éléments, divise la somme par ce compteur. C'est trivial.

Ca n'a pas de sens. Si je dois calculer la moyenne sur une liste qui ne contient pas que des nombres, alors soit j'ai mal designé mon architecture, soit je fais

interface MyStuff {
  public Optional<Integer> toInt();
}

Et le reste devient

int result = 0;
for (MyStuff stuff : mystuff) {
    result += stuff.toInt().orElse(0);
  }
}

C'est propre et facile à comprendre.

Ma solution marche pour tous: Set, ArrayList, LinkedList, HashMap, etc. (Interface ou pas, les génériques acceptent mon type).
La tienne a réinventé la roue pour la liste. Si demain il veux utiliser une autre collection, il n'a pas de solution avec ta librairie.

Bref, Object, c'est mal, l'héritage (?) et l'Open-Closed, c'est bien.

Si le contexte est connu et n'est pas exposé par l'API, alors tu peux faire

final Class AouB {
private Type typ;
private final Optional<A> a;
private final Optional<B> B;
private print() {
switch (typ):
case Type.A: a.print(); break;
case Type.B: b.print(); break;
}
}

Et utiliser des sous classes ou une factory pour créer des objets de type AouB, mais ça n'est pas extensible par un utilisateur.

Au final, le truc, c'est qu'en Python, tu peux mettre n'importe quoi dans ta liste, et au final, tu peux avoir des erreurs de type à l'execution. En Java, il faut faire exprès pour se donner se problème, et c'est probablement une bonne idée de ne pas programmer ainsi. Tant pis si Python est plus facile et court à écrire.

Non seulement tu as des casts et des instanceOf, ce qui rend le code fragile, mais en plus l'utilisateur n'a plus de liste. Et comment tu ferais pour un Set? un ArrayList? un LinkedList? une HashMap? Tu vois pas un problème quelque part avec ta solution ?

C'est pas ce que je veux dire par « extensible ». Ton code n'est pas utilisable par quelqu'un qui utilise ta librairie et souhaite aussi mettre des caractères, des flottants, des voitures, ou des éléphants dans la liste. Ta liste est restreinte aux entiers et chaînes par définition.

Elle est pas exensible.

Que va retourner un objet EntierOuChaine si il a une méthode disons getValue ? Bin un Objet.

Si tu as besoin de coder Object getValue(), alors tu as un problème de design orienté objet.

Les développeurs de Perl ont donc décidé de se débarrasser de ce « fardeau » [de quel fardeau parlent‑ils ?] et d’activer un bon nombre de ces « défauts » qui sont quasi‑incontestables.

Il semblerait qu'un commentaire datant de l'ébauche de la nouvelle se soit retrouvé publié :)

Sinon, c'est interessant. Je ne savais pas que « Perl 6 n'était plus Perl » donc j'irai y jeter un œil aussi.

J'aurais pas été contre un petite liste des fonctionnalités activées de base aussi. use strict et tout.

Alors, "concis", c'est pas la bonne métrique. Si t'as envie de jouer au golfe, tant mieux. Mais je n'ai aucune envie de maintenir du code qui préfère la concision (et les potentiels bugs à l'execution) simplement car c'est concis. Tu veux un containeur qui contient tes objets spécifiques, et rien d'autre, mais qui soit extensible sans aucun changement.

import java.util.ArrayList;
import java.util.List;

class ListeExtensible {

    interface MyStuff { 
        public void print();
    }

    class MyInt implements MyStuff {
        final int i;
        public MyInt(int i) {
            this.i = i;
        }
        public void print() {
            System.out.println(this.i);
        }
    }

    class MyString implements MyStuff {
        final String s;
        public MyString(String s) {
            this.s = s;
        }
        public void print() {
            System.out.println(this.s);
        }
    }

    public void doStuff() {
        List<MyStuff> maListe = new ArrayList<>();
        maListe.add(new MyInt(1));
        maListe.add(new MyString("hello"));
        for (MyStuff element : maListe) {
            element.print();
        }
    }

    public static void main(String[] args) {
        ListeExtensible l = new ListeExtensible();
        l.doStuff();
    }
}

Pas besoin de casts (vu qu'on ne retourne jamais "Object"), on ne peut pas avoir d'erreur à l'exécution, et on peut ajouter autant de nouveau sous-types qu'on veut sans qu'on doive modifier aucun code existant. C'est, je crois, la manière de s'y prendre en Java. Alors, oui, c'est plus compliqué que Python, mais c'est ainsi. Language différent, paradigme différent.

Comment les generics permettent-ils de mettre deux types qui n'ont pas de relation de sous-typage dans la liste (ce que l'OP cherche à faire), sans passer par Object (qui est objectivement une mauvaise approche en termes de design/architecture Java) ou un nouveau type ? Je ne vois pas le rapport, et mon exemple utilise des génériques (List<Integer> par exemple). Si tu pas un passage précis dans les 20+ pages de ton lien qui indique comment mettre des entiers et des chaînes dans une liste, n'hésite pas à le partager.

S'il veut commencer par des choses plus douces, alors résoudre des exos Python en Java n'est pas une bonne idée. Python et Java sont très différents, et ce qui est élégant et simple dans l'un ne l'est pas forcément dans l'autre…

"Comment mélange-t-on des entiers et des chaînes dans une liste en Java ?" -> On ne le fait pas, ou alors on créée une liste d'objets "EntierOuChaîne". C'est à la fois plus dur, et la manière la plus simple.

Ah, non, ça c'est parce que le dernier project que j'ai écrit était en Python, où justement les types sont 'str' et 'int', donc je tape ça automatiquement…

Mais la syntaxe, on s'en cogne. Ton compilateur/IDE s'en charge pour toi. En revanche, utiliser Object au lieu d'un conteneur adéquat (ou d'une conversion vers une chaîne si c'est juste pour faire un affichage), c'est un problème d'un tout autre ordre…

Nan, mais faut pas abuser. Le langage est typé et objet, donc c'est beaucoup mieux d'utiliser une classe qui peut contenir n'importe lequel des deux type, plutôt qu'Object. Traduire Python en Java, c'est idiot. Autant apprendre à penser en Java : tu veux stocker deux types, tu crées un conteneur, et tu fais du Open/Close au lieu de faire des casts et des IFs…

En java, tu ferais qqchose comme ça:

List maListeDeNombres<Int> = new ArrayList<>();
maListeDeNombres.add(1);

List maListeDeChaines<Str> = new ArrayList<>();
maListeDeChaines.add("lundi");
...

Mais tu ne peux pas mettre 1 et "lundi" dans une même troisième liste. Tes choix sont:
* convertir les nombres en chaînes de caractères
* créer une classe NombreOuChaine qui peut contenir un nombre ou une chaîne, et créer List<NombreOuChaine> t3.

Oui, c'est un peu lourd. Mais ça évite pas mal de bugs que tu pourrais avoir en Python sur des projets plus larges, ou évite que tu regardes le type à l'exécution.