[F] [mOved] Mon langage est mieux que le tien - Page 32

Passionnant débugging !

Mouarf

bon, c'est un peu apres la bataille, mais..

./860> omg... je crois que j'ai un peu vomi dans ma bouche..
./861 ./862>
./863> non, tu peux le faire avec le meme code, mais en lisible. c'est un challenge de tout mettre sur la meme ligne? parceque a part rendre ton code inmaintenable, inbitable, et beaucoup plus error-prone, ben ca sert a rien. Ca va pas etre plus optimise parceque tout est sur la meme ligne hein Ca te donne l'impression d'ecrire du l33t-code de tout bazarder dans les 3 statements de ton for? bref, ton exemple de solution marche peut-etre, mais honnetement, si tu passais un entretien chez nous, on chercherait meme pas a voir si ca fonctionne, c'est poubelle direct (et jpense pas qu'on soit les seuls), tu le refais en lisible, ou tu te barre.

./866> ouais ben meme si c'est vomitif aussi, c'est quand meme mieux, tu trouve pas?
./868> Pen^2 je t'aime
./877> idee marrante ^^
./880> inutilement verbeux
./888> self documenting, mais inutilement verbeux. juste pour self-documenting, t'aurais pu te contenter d'utiliser deux variables bool 'isDivisibleBy3' et 'isDivisibleBy5', par exemple?
quelqu'un qui ne connait pas les modulos? c'est de l'humour ? ou tu as perdu de vue le contexte de la discussion?
./899>

En fait ./866 ne passerais pas pour une simple raison, il y a au moins un IF de trop

boah, ca jsais pas, c'est peut-etre moins grave
enfin ca depend ce que tu cherche / demande au gars

ben faire un

if div3 & div 5 then print fizzbuzz
elif div3 then print fizz
elif div5 the print buww
else print number

Le candidat a un probleme de logique et d'optimisation du code, il y a un if de trop. M'enfin bon ya pire oui, mais si le candidat n'est pas capable de voir qu'on peux simplement supprimer un if c'est qu'il est vraiment novice.

Ton code ne répond pas aux critères, ça affiche buww

Mon code est plus rapide que le tien (si le compilateur ne l'optimise pas de toute façon en la même chose)! Tu testes div3 et div5 2 fois. Je teste chaque condition une seule fois. (Il y a 2 tests div5, mais un seul est effectivement exécuté, selon le résultat du test div3.)

PS: Personnellement, si je vois un code comme le ./936 dans une revue, je le critique immédiatement, surtout si "div3" et "div5" sont des appels de fonction! (Si tu stockes les valeurs de retour dans des variables booléennes, ça passe à la limite, mais ça reste une logique inefficace.)

bearbecue (./933) :
bon, c'est un peu apres la bataille, mais..

Tu n'as pas commenté ./889, cette version-là correspond-elle enfin à tes attentes?

C'est fou, tout ce qu'on peut chipoter sur un exemple tellement simple.

Si tu ne sais pas ce qu'est du pseudo code mon cher kevin, c'est que tu n'est pas pret a travailler dans ce marché, et que tu n'es rien de plus qu'un amateur qui se la pete.

Godzil (./940) :
Si tu ne sais pas ce qu'est du pseudo code mon cher kevin, c'est que tu n'est pas pret a travailler dans ce marché, et que tu n'es rien de plus qu'un amateur qui se la pete.

Je pense que Kevin sait ce qu'est du pseudo code...

On ne dirais pas pourtant

On devrait lui faire passer un test d'inscription sur yN

Plutôt que de troller inutilement encore 2 pages sur l'implémentation de Fizzbuzz, je signale que mon nouveau langage préféré ( enfin celui que je trouve le plus intéressant en ce moment), a enfin été stabilisé et sorti en version 1.0 : http://www.rust-lang.org/

Je trouve que son approche visant a combiner la sécurité par défaut avec un contrôle des performances semblable à ce que l'on a en C++. est vraiment sympathique.

Ouch, ça en fait de la lecture quand on commence l'histoire seulement maintenant. Il y a plein de concepts qui ont l'air sympa, en-dehors de la gestion de la mémoire ; en particulier les macros ont l'air d'être une solution plutôt élégante pour la génération de code compile-time sans pour autant proposer une seconde syntaxe qui n'a strictement rien à voir comme les templates en C++. Mais ça fait beaucoup de concepts à digérer avant de commencer à coder quoi que ce soit en Rust, j'ai l'impression

En fait mieux vaut commencer seulement maintenant car le langage a complètement changé depuis sa première annonce officielle. Si un regarde un code en 0.1 et 1.0, c'est difficile de deviner qu'il s'agit du même langage.
Pour ce qui est de la complexité, c'est vrai que Rust, même s'il est clairement moins complexe que le C++, n'est pas un langage visant la simplicité avant tout comme Go, Java, ...

Il nécessite de comprendre certains concepts qui sont gérés automatiquement, au prix d'une perte de contrôle des performances, dans la plupart des langages modernes. Ceci dit contrairement au C/C++ ou si on ne maitrise pas un concept on se retrouve, sans forcément s'en rendre compte, a faire du code troué niveau sécurité ou qui va planter aléatoirement, en Rust on se retrouve juste avec un code qui refuse de compiler.
Ce qui est choquant au début c'est le principe de durée de vie des variable qui fait que certains codes qui semblent anodins vont refuser de compiler, on finit par s'y faire cependant.

Pour les macros, il y a en fait 2 systèmes :
- Un simple avec une syntaxe spécifique. C'est un peu comme pour le C, mais quand même plus poussé : ça travaille sur les éléments du langage(au lieu de manipuler du texte brut) et gère l'hygiène (les variables de la macro n'interagissent pas directement avec celles du code)
- Un système plus complexe avec un module compilé en Rust qui manipule complètement l'AST. ll peut être utilisé pour faire des choses très puissantes comme pré-compiler des expressions régulières ou du SQL lors de la compilation du code Rust. Malheureusement ce type de module est encore expérimental.

Godzil (./940) :
Si tu ne sais pas ce qu'est du pseudo code mon cher kevin, c'est que tu n'est pas pret a travailler dans ce marché, et que tu n'es rien de plus qu'un amateur qui se la pete.

Je ne vois pas pourquoi tu dis ça, et pour le coup, même si je n'aurais pas fait comme il a fait, il a en tout seulement 2 tests éxécutés à chaque itération, ce qui est mieux que :

if div3 & div 5 then print fizzbuzz
elif div3 then print fizz
elif div5 the print buwwelse print number

Arvi: relis le code de kevin, c'est ce que ce pseudo code fait.

Et puis kevin ne parlais pas de ce que fait le code, mais du pseudo code en lui meme.

Ensuite le test du fizzbuzz n'est pas que savoir si le candidat sais faire des if/elseif, mais aussi de l'opitmisation car un simple

if div3 then print fizz
if div5 then print buzz
if not div3 and div5 then print number

permet de diminuer le nombre de tests a faire (et ce n'est pas parceque le code donne l'impression qu'on va faire le test au moins 3fois, que c'est le cas, le compilateur sais optimiser ce genre de chsoes)
Ca fait aussi de l'optmisation taille car par contre le compilateur ne sais pas optimiser des appels a une fonction (en l'occurence la fonction qui arriche, fizz ou buzz)

Sans compter que le code de kevin implique plus de saut, il suffit de remonter quelques posts pour voir que le code de kevin genere plus de code assembleur au final

ah ok, je viens de comprendre comment il avait interprété "if div3"

(et pour rappel sur l'optimisation du code de kevin: ./895 : 386 octets de plus pour la version simple de mon code ( ./882 ), et 402octets, si je me trompe pas dans les valeurs, dans ma version pour aider l'optimisateur du compilo ( ./894 que j'ai incorrectement nomme 886 dans le nom de fichier ) )

Peut-être serait-il temps de forker FizzBuzz pour ce qui est le plus optimisé/lisible/pseudocode.

Ou simplement laisser tomber, ce n'est pas comme si c'était une discussion passionnante non plus.

Bof, mais vous pouvez continuer votre discution sur la rouille ca a l'air tres interessant (cross avec zero)

Pour réunir les deux voila un FizzBuzz en Rust:

fn main() {
   for i in 1..101 {
       match (i%3, i%5) {
           (0, 0) => println!("FizzBuzz"),
           (0, _) => println!("Fizz"),
           (_, 0) => println!("Buzz"),
           _ => println!("{}",i)
       }
   }
}

Sympa comme syntaxe

Je préfère mon langage où les conditions sont définies à base de if/else plutôt qu'à base de smiley de hibou qui fait des clins d’œil.

Il y a aussi "if/else" en Rust mais j'ai utilisé le "match" histoire de varier un peu.

Qu'on peux facilement reproduire en C d'ailleurs:
enum { /* Div5, Div3 */ FF = 0, /* False, False */ FT = 1, /* False, True */ TF = 2, /* True, False */ TT = 3, /* True, True */ }; int main() { int i; for(i = 0; i <= 100; i++) { uint8_t result = ((number % 3) == 0)?1:0 | ((number % 5) == 0)?2:0 ) switch(result) { case FF: printf("%d\n", number); break; case FT: printf("Fizz\n"); break; case TF: printf("Buzz"); break; case TT: printf("FizzBuzz"); break; } } }
(je me demande la taille de code que ca genere d'aileurs)

Arvi89 (./947) :

Godzil (./940) :
Si tu ne sais pas ce qu'est du pseudo code mon cher kevin, c'est que tu n'est pas pret a travailler dans ce marché, et que tu n'es rien de plus qu'un amateur qui se la pete.

Je ne vois pas pourquoi tu dis ça, et pour le coup, même si je n'aurais pas fait comme il a fait, il a en tout seulement 2 tests éxécutés à chaque itération, ce qui est mieux que :

if div3 & div 5 then print fizzbuzz
elif div3 then print fizz
elif div5 the print buwwelse print number

C'est exactement ce que j'ai dit dans le ./938.

Ma solution:

if (div3) {
  if (div5)
    print fizzbuzz
  else
    print fizz
} else {
  if (div5)
    print buzz
  else
    print number
}

• 2 tests dans tous les cas.
• Chaque condition n'est testée qu'une fois dans tous les cas.

La solution de Godzil:

if (div3 && div 5)
  print fizzbuzz
else if (div3)
  print fizz
else if (div5)
  print buzz
else
  print number

• Entre 2 et 4 tests selon le cas. (Je compte 4 parce que if (x && y) est implémenté avec un code de type if (x) if (y) en assembleur.)
• Les conditions div3 et div5 sont testées jusqu'à 2 fois chacune.

Cela en présupposant évidemment que le compilateur n'optimise pas le code en ma solution.

Pour les optimisations de compilateur je ne dis rien car je n'y connais absolument rien ^^

Sinon, rien à voir : http://www.journaldugeek.com/2015/05/28/sony-mobile-nest-pas-vraiment-emballe-par-les-ecrans-2k/
Enfin, et s'ils faisaient plus de recherche sur la batterie ce serait le top