CrEv a écrit 4577 commentaires

mais dont la lecture n’est pas intuitive

Oui mais c'est quoi intuitive ?

qu'il me permet d'avoir une valeur const/final sans avoir à créer une méthode pour ça

Ça c'est aussi que certains langages ne permettent pas des trucs cool.

En ruby on peut très bien avoir :

rowColor = if rowIndex.even?
             blue
           else
             red
           end

C'est comme tout, il y a les bonnes et les mauvaises utilisations.

Mais genre :

var rowColor = rowIndex.even ? blue : red

C'est un bon cas ou pas d'après toi ? (c'est juste pour bien comprendre où est la limite dans ce que tu dis)

par analogie, trop spécifiques au langage

Donc en fait tu n'utilises pas ce qui est offert par ton langage ?
J'avoue avoir du mal à comprendre. C'est parce que tu n'arrives pas à relire plus tard ? Dans ce cas c'est pas plutôt un problème d'apprentissage du langage ?

Tu peux détailler un peu plus, histoire de bien comprendre ?

myArray = […]
mySelection = myArray.select { |value| value.even? }

Bon, ok la syntaxe { |…| } peut perturber si on ne connait pas ruby.
Peut-être qu'un

myArray = […]
mySelection = myArray.select do |value|
  value.even?
end

peut aider, mais bref c'est un faux problème qui n'est pas le notre, là c'est juste être capable de lire les constructions de base du langage. C'est comme discuter de * et & en C++.

Donc ensuite, qu'est ce qu'on a ?
On a un objet qui reçoit le résultat de l'appel de la méthode select sur un tableau myArray. On en déduit quand même facilement (= juste en lisant les mots) qu'on réalise une sélection de myArray.
Ensuite un bloc est passé, et on retourne un booléen un pour chaque valeur, ici vrai s'il est pair.
Ben je sais pas mais moi quand je lis tout ça je lis "mySelection est la sélection de myArray en gardant les pairs".

Le truc c'est que si tu lis la première version du extrapole un comportement (qui est de sélectionner les pairs) alors qu'il est explicite dans la version concise.

mais pour moi c’est incompréhensible au premier abord

C'est un problème de concision, de langage ou de n'utiliser qu'un ensemble très réduit d'instructions, un dénominateur commun basique et pauvre qu'on retrouve partout ?

les types très strictement définis, je ne sais pas ce que c’est

C'est vague mais c'est par exemple pouvoir dire que mon type c'est un entier entre -2 et +15 uniquement, et qu'on ne peut pas avoir une autre valeur.

Bon au final Rust n'a donc rien à voir avec du Ada, sans même parler de certif.

Ce n'est pas la seule façon d'installer cargo :

• Build depuis les sources à coup de make && make install : https://github.com/rust-lang/cargo#compiling-cargo
• Installation depuis les nightlies : https://github.com/rust-lang/cargo#installing-cargo-from-nightlies Le script install.sh peut prendre un prefix d'installation (par défaut /usr/local)

Pour moi, le principal langage auquel comparer Rust, c’est Ada

Je vois souvent une comparaison à Ada. C'est vrai ça ?

Genre le système de typage de Rust permet de faire ce qu'on fait en Ada ? Par exemple deux types avec des valeurs entières ne sont pas mélangeable ?
On peut avoir des types très strictement défini, des types avec modulo, des types où on s'amuse à décrire très précisément la structure de donnée qui va être stockée - pour de l'embarqué -, etc ?

La concision du code, je ne suis pas évidemment contre.

Ben j'en sais rien, c'est toi qui écrit « Plus c'est "compact" moins c'est lisible ».

L'histoire de Perl Golf ça n'a rien à voir, et d'ailleurs on trouve ce genre de chose dans tous les langages (par exemple http://js1k.com/ pour javascript).
Perl Golf ce n'est pas fait pour être relu 6 mois plus tard et on s'en fiche.
Je vois pas trop ce que ça vient faire là.

De mon point de vue, un code concis permet surtout de réduire ce qui ne sert à rien et donc d'augmenter la lisibilité par un meilleur rapport signal/bruit.

Evidemment ça demande à voir des termes lisibles et compréhensibles. C'est certains que si on remplace select par s dans le code ruby, 6 mois après c'est plus compliqué.

Pour le coup de := et =, c'est la même chose qu'avec = et ==, c'est juste que le choix est différent. Et avec une police à chasse fixe c'est déjà mieux. Et on peut très bien avoir une coloration différente pour les deux.

var myHash = { … };
var keys = Object.keys(myHash);
var key;
for(var i = 0; i < keys.length; i++) {
  key = keys[i];
  // do what you want with key
}

vs

for(var key in myHash) {
  // do what you want with key
}

Ok, en js justement on n'écrirait pas le premier, mais c'est pour illustrer.
La concision vient entre autre du fait de structures de plus haut niveau.

Autre exemple en ruby :

myArray = […]
mySelection = []
myArray.each do |value|
  if value % 2 == 0
    mySelection << value
  end
end

ou alors

myArray = […]
mySelection = myArray.select { |value| value.even? }

On a, à mon avis, plus compact et plus lisible.

C'était mieux à vent !

Typiquement, quand il faut faire une IHM avec, par exemple, Qt, je n'utilise pas les QString ailleurs que dans les classes liées à l'IHM (et même là, je préfère éviter, mais c'est un exemple. Peut-être pas le meilleur…)

Tu peux détailler un peu plus ?
J'avoue ne pas vraiment comprendre pour quelle raison tu souhaites ne pas utiliser les QString dans des classes d'IHM de Qt…

Nope. Enfin si.

En fait tout le touchpad est un seul bouton. Sous mac selon comme tu le configures il interprète clic gauche droit selon l'endroit d'où tu actives le clic.
Après je ne l'utilise jamais, une tape -> clic gauche, une tape avec deux doigts clic droit. C'est ce que je trouve de plus confortable.

L'avantage de tout ça c'est que la surface du touchpad comprend ce qui est des boutons chez beaucoup d'autres.

En fait je ne comprend toujours pas pourquoi il n'y a pas plus de touchpad qui fonctionnent de la sorte. A chaque fois que je passe sur un autre c'est galère : trop petit, des boutons spécifiques (et donc je dois faire venir mon doigt dessus alors que je viens de me déplacer ailleurs), le scroll souvent sur une petite portion du touchpad, etc. Horrible.

des calculatrices qui ne comprennent pas "2 + 2" mais sur lesquelles ils faut taper "+ 2 2"

Mieux vaut une bonne HP 4x sur laquelle on entre 2 2 + ;-)

Sous mac j'utilise des gestures à 2, 3, 4 doigts. Sous win/mac rien, juste le scroll à deux doigts.
Et vu comme ça c'est géré comme une souris classique donc il n'y a pas de prob à priori.

Mais le vrai bon côté de celui-ci c'est sa taille, la hauteur (profondeur ?) utile du touchpad est identique à celle du clavier pour donner une idée à ceux qui n'en auraient pas.

à condition toutefois que leur contribution aille au-delà du sarcasme (du français dans le code ! quelle horreur… du français ! ;-)

Ce n'est pas une histoire de français (enfin si, je pense qu'un code — plutôt en langue anglaise — doit être commenté en anglais uniquement, cela évite beaucoup de redite inutile en général) mais surtout de constance et de cohérence.
Un code non cohérent (qui réinvente la roue) ne donne pas vraiment envie de contribuer.

(c'est pas sarcastique, direct peut-être)

En fait, rien que chaines.c et des trucs comme string_ajout ou string_p*g*_escape qui fait un PQEscapeString c'est moche.
Le franglais dans les noms de fonction c'est juste toujours horrible.

J'utilise en général des touchpad, mais celui que je préfère c'est mon magic trackpad d'Apple.
Déjà ceux des macbook sont plus grand que les homologues "pc" mais la version externe est encore plus grande.
Et associé à un clavier sans pavé numérique (donc moins de déplacement de la main) c'est nikel. A moins d'avoir des besoins spécifiques (jeux, softs 3D, cao, etc) je n'utilise plus de souris.

ho mince, tu as raison, en fait en C++14 (avec -std=c++1y) ça passe direct.

Donc au final entre Rust et C++ c'est C++ qui gagne avec

  auto square = [](auto x) { return x * x; };
  auto twice = [](auto x, auto f) { return f(x) + f(x); };

A priori obligé de l'écrire.

Ou même :

using namespace std;

int main() {
     auto square = [] (int x) -> int { return x * x; };

     auto twice = [] (int x, function<int(int)> f) -> int { return f(x) + f(x); };

     cout << twice(5, square) << endl; // 50
     return 0;
}

je n'arrive pas à comprendre comment Java peut être aussi populaire

Parce que un peu comme pour PHP il suffit d'être médiocre pour arriver à faire des choses avec.

De rien, ne me remerciez pas… --->[]

sauf que c'est pas comparable, on a d'un côté que du int, de l'autre du générique.

Si tu veux la même chose que l'exemple Rust c'est ici : https://linuxfr.org/users/outs/journaux/rust-en-version-0-12#comment-1567855

D'ailleurs la première version s'écrirait plutôt :

int twice(int x, std::function<int(int)> f) {
    return f(x) + f(x);
};

int main() {
    auto square = [] (int x) { return x * x; };

    std::cout << twice(5, square) << std::endl;

    return 0;
}

En fait si on veut avoir la même chose avec les std:function et que ça marche :

#include <iostream>
#include <functional>

template <class T> std::function<T(T x)> square = [] (T x) {
    return x * x;
};

template <class T> std::function<T(T x, std::function<T(T x)> f)> twice = [] (T x, std::function<T(T x)> f) {
    return f(x) + f(x);
};


int main() {
    std::cout << twice<int>(5, square<int>) << std::endl;
    std::cout << twice<double>(5.1, square<double>) << std::endl;

    return 0;
}

Par contre il faut se méfier, il faut activer c++1y g++ -std=c++1y main.cpp pour avoir des variables paramétrables.

En fait square et twice sont des variables de type std::function mais paramétrés (version template).

Après si on veut simplifier un poil, on peut utiliser auto :

#include <iostream>
#include <functional>

template <class T> std::function<T(T x)> square = [] (auto x) {
    return x * x;
};

template <class T> std::function<T(T x, std::function<T(T x)> f)> twice = [] (auto x, auto f) {
    return f(x) + f(x);
};


int main() {
    std::cout << twice<int>(5, square<int>) << std::endl;
    std::cout << twice<double>(5.1, square<double>) << std::endl;

    return 0;
}