Mais peut-être que ça n'est pas encore assez. Donc, voici encore quelques liens sur des problèmes de harcèlement à la DEFCON: (1, 2)
Il y a des problèmes au niveau mondial. La situation en France est quand même largement meilleure que dans le reste du monde (en moyenne), ce qui explique beaucoup d’incompréhensions dans ce genre de débats.
En France, le harcèlement sexuel (puisque c’est de ça dont on parle) est pénalement répréhensible. C’est là qu’il faut aller, même si c’est effectivement dramatique d’en arriver là. Le problème existe d’ailleurs aussi dans d’autres domaines (sports par exemple, typiquement arts martiaux où la mixité est restée), le restreindre à l’informatique, je crois que c’est se tromper.
À noter aussi qu’il suffit d’une minorité de cons pour créer un maximum d’emmerdements.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Quand bien même nous nous plaçons dans l'un des pays comptant parmi les plus progressistes, et quand bien même nous nous plaçons dans l'environnement de travail le plus favorable possible qu'est la Fonction Publique (seulement 20% des emplois en France), 'alenvers', fonctionnaire de son Etat, hostile au stage Girls Can Code, nous apprend que moins de 10% des informaticiens de la Fonction Publique sont des informaticiennes (je n'ai pas vérifié, mais je veux bien le croire). Au pays des Droits de l'Homme, de la démocratie, et du ballotage à 50%-50%, dans le sanctuaire de "Liberté-Egalité-Fraternité", 10% des informaticiens de la Fonction Publique sont des femmes. Et 90% sont des hommes. Je te laisse imaginer l'état de la parité dans le secteur privé.
Le même. Globalement, c’est celui qu’on trouve à la sortie d’école.
En revanche, vu que dans cette même fonction publique, on doit trouver cette sacro sainte parité de 50/50 aux échelons supérieurs, cela veut dire que les femmes ont beaucoup moins de concurrence que les hommes. Et fondamentalement, c’est un problème.
À noter qu’il y a vraisemblablement le problème inverse dans d’autres domaines que l’informatique. Le bilan, c’est que c’est surtout une mauvaise solution.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Pour finir, sur le fond, il existe en France des quotas pour l'embauche de personnes handicapées.
Je ne suis pas sûr que ce genre d’arguments serve la cause de l’égalité homme/femmes. Dans « handicapé », il y a « handicap », et pour avoir bossé avec des handicapés, oui, c’est lourd, oui, ce sont des contraintes supplémentaires, et oui pour un employeur un salarié handicapé est généralement moins productif qu’un non handicapé. Je ne crois pas qu’on puisse raisonnablement dire la même chose d’une femme.
Aux US et depuis la fin des années 60, le nombres de femmes diplômées n'a cessé de croître dans tous les disciplines (psychologie, physique, chimie, agriculture, ingénierie, sciences sociales, etc.). Vraiment toutes ? Toutes à l'exception de l'Informatique où le taux de filles dans cette filière n'a cessé de diminuer depuis les années 1980; et en Mathématique où les chiffres ont stagné.
Va regarder les chiffres en mécanique. C’est largement pire que l’informatique (mais effectivement, ça partait déjà de très bas, contrairement à l’informatique où on avait une relative parité – en même temps la discipline n’existait pas).
Dans ces conditions, des efforts pour rééquilibrer les choses spécifiquement dans ce domaine sont parfaitement justifiés: associations et stages pour programmeuses sont bienvenus. Encore une fois, c'est la différence entre égalité et équité.
La « discrimination positive », puisque c’est de ça dont on parle, a deux gros défauts :
* elle crée beaucoup de frustrations
* elle ne se conçoit que comme une mesure très temporaire, le temps de retrouver un équilibre
Autant je crois aux quotas par exemple en politique, là où on part d’une population de militants qui est grosso-modo à 50/50, autant je crois que des quotas à 50/50 quand tu pars d’une population qui est déjà à 90/10 (comme ça peut être le cas pour certains postes de chercheurs, par exemple) ne fait que créer des frustrations et n’encourage pas grand chose.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Ça donne un début d’explication. Après, attention toujours dans ce genre de débat à bien définir de quoi on parle. La situation en France est très différente de ce qu’elle peut être en Inde, au Brésil, aux États-Unis, au Burundi ou en Suède. Et il faut aussi moduler selon les tranches d’âge, car la deuxième moitié du 20ème siècle a vu beaucoup de choses évoluer.
Sinon, un détail qu’on oublie de mentionner facilement : la profession d’informaticien (de manière générale, et en France) s’est beaucoup masculinisée entre les années 60 et les années 2000. Je n’ai jamais lu d’explication probante.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Encore une fois, parce que le terme usuel qu’on trouve partout, dans tous les logiciels, est « Enregistrer ». Que « Sauvegarde » évoque plutôt une copie de sauvegarde, quelque chose qu’on fait à côté de son document de travail, pour en conserver une copie en cas de pépin.
Donc non, changer pour « sauver » ou « sauvegarder », ce serait pire :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Libreoffice a exactement les mêmes contraintes (j’ouvre un csv sous libreoffice calc, je rajoute une colonne avec des formules dedans, je choisis enregistrer), mais un comportement différent (ie il affiche une boîte de dialogue « êtes-vous sûr de vouloir faire ça, vous risquez de perdre des données » avec un bouton « Enregistrer en ods ».
Je ne prétends pas que cette solution est meilleure que celle de gimp. Je me désole juste que les deux logiciels ne se comportent pas de la même manière, et que je ne vois pas poindre d’issue à cette situation qui est pourtant « hostile » vis à vis de l’utilisateur final.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Perso, le Enregistrer/Exporter, j'ai rarement vu un débat plus stérile et inutile. Du commérage de capricieux.
En fait, pas tant que ça…
Le problème est que gimp est un « alien » quelque soit l’environnement de bureau utilisé (y compris mac / windows). Que ses menus et son ergonomie générale ne sont pas en cohérence avec le reste du bureau.
Inkscape fait la même différence enregistrer / exporter, mais d’une manière différente. Est-ce qu’elle est meilleure ou moins bonne, j’ai envie de dire que ça ne m’intéresse effectivement pas trop. Ce qui me gêne, en revanche, c’est d’avoir deux manières différentes, d’avoir des applis qui ne se comportent pas de la même manière.
Sous debian wheezy, faire alt-F4 alors qu’une image était ouverte fermait l’image, pas gimp. Je remercie le gars qui a corrigé ça pour que sous jessie le comportement soit celui attendu (gimp se ferme, éventuellement avec une boîte de confirmation s’il y a des modifs en cours), parce que le plus gênant, ce n’est finalement pas tel ou tel comportement, mais bien les différences de comportement entre les applications.
À terme, j’espère que gimp arrivera à un niveau de séparation outils/interface tels que qui que ce soit pourra pondre et maintenir une interface réellement adaptée à chaque environnement majeur. C’est un sacré chantier par contre et une charge supplémentaire par la suite, je comprends donc que ça ne soit pas dans les priorités.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
RPC permet de faire du synchrone, c’est plus proche du modèle « habituel », ça explique que les gens aient voulu pousser ça : le développeur n’a pas à changer ses habitudes. Même si au final, c’est plutôt une mauvaise idée.
Sinon, pour Erlang et la communauté scientifique, c’est surtout que la communauté scientifique travaille plutôt sur des modèles que sur du code, et donc, utilise des langages plus restreints (bip pour ne citer que lui, par exemple). Mais le modèle utilisé par erlang est énormément étudié et utilisé par la communauté scientifique.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Oui c’est un bon exemple opensll, ça a permis heartbleed sur bsd… (l’allocateur par défaut peut nullifier la mémoire qu’il alloue, avec un allocateur maison qui réemploie sa mémoire t’es baisé).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Il y a des composants qml qui reprennent le look and feel des composants de bureau. Qt components for desktop, par exemple, je ne sais plus quel est le nom en qml2.
Pour l’instant, je pense que l’intégration au reste du DE sera moins bonne qu’avec un qt standard, mais là on n’est pas dans ce cadre là si j’ai bien suivi.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
La programmation par contrat ne résout pas ce problème (en tout cas dans son acceptation classique) car comparer des contrats (des prédicats mathématiques en fait) n'est pas décidable. De plus les contrats sont en général optionnels et ce n'est pas si simple que cela de formaliser le comportement des fonctions.
Tu as raison mais c’est un argument de mathématicien / formaliste. Que ça ne résolve pas tous les problèmes ne veut pas dire que ça n’en résout pas une bonne partie. L’analyse statique de code n’est pas de la preuve formelle, la vérification statique de contrats rentre dans cette catégorie : trouver un maximum (≠ toutes) d’erreurs à la compilation.
Par exemple si std::marker::Copy est implémenté cela signifie qu'il est légal de se contenter de faire une copie du type pour obtenir un copie (pas de dépendance à copier en plus), pour autant Copy n'a aucune méthode attachée.
Je ne connaissais pas cet usage. En quoi est-ce différent de simplement définir l’opérateur d’affectation ? (en considérant que les types sont par défaut non-copiables – j’avais compris que c’était le cas en rust).
Enfin, c'est principalement l’absence d'un tel mécanisme qui rend les erreurs des templates C++ aussi verbeux. Car le compilateur n'a aucun moyen de faire des vérifications autrement qu'en essayant d'instancier réellement le template et de voir si ça marche. D'ailleurs ils veulent le rajouter dans la prochaine version de C++ sous le nom de "concepts" (j'imagine que c'est dans une version différente de ce qui avait été proposé et refusé pour C++11).
Oui et non. L’idée des concepts est de formaliser les dépendances que peuvent avoir des classes / algorithmes génériques, en partie pour produire de meilleures messages d’erreur, en partie parce que rajouter de la sémantique est généralement une bonne idée. D’ailleurs, la doc de la STL fait depuis très longtemps (au moins depuis C++03) référence à ces concepts, même s’ils n’existent pas dans le langage. Mais les concepts, tels que je les ai toujours vu présentés, ne se substituent pas au « duck-typing ». C’est à dire que le fait qu’un type soit compatible avec un concept sera déterminé automatiquement par le compilateur. C’est d’ailleurs une partie très problématique qui provoque le report des concepts d’année en année, sachant que le bénéfice final n’est pas si évident (meilleurs messages d’erreur, mais c’est à peu près tout).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
QML, c’est censé te faciliter la vie de ce côté là, et surtout, ça utilise la carte graphique, et donc permet de soulager le processeur et de faire des effets kikoolol assez facilement.
Par contre, tu vas devoir faire l’impasse sur la compatibilité Qt4 si tu franchis le pas (globalement, le QML inclus dans Qt4 est déprécié et n’est plus recommandé, c’est Qml2 que tu devrais utiliser).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Ce que tu montres, c’est que le compilo Rust est plus malin que le compilo C++.
Mais mon propos, c’était que la sémantique est la même. Et que donc, pour un programmeur C++, la sémantique en général de Rust ne doit pas poser de problème de compréhension.
Quand je lis ton code C++, je vois qu’il va merder (parce que l’exemple est simple). Idem quand je vois ton code Rust. Et le fait que l’un compile mais pas l’autre est un très bon argument en faveur de Rust, parce que dans la vraie vie l’erreur ne saute pas toujours aux yeux à la lecture du code :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
L’intérêt, c’est de ne pas avoir à déclarer explicitement l’implémentation (le terme est mauvais, je ne sais plus quel est le bon) d’un trait. Ce qui permet, notamment, si moi je définis un nouveau trait, et qu’il se trouve qu’un type de la lib standard/xyz respecte l’ensemble des propriétés de ce trait (et donc, est substituable au sens du LSP), que je l’utilise partout où j’ai déclaré que j’utilisais un type implémentant mon trait, même s’il ne déclare pas l’implémenter explicitement (je ne peux pas modifier la lib standard ou la lib xyz pour y rajouter mon trait).
Pour pratiquer cela couramment en C++, c’est utile. Mon impression est qu’avec un système de traits explicites, tu te restreins arbitrairement. Ça me fait un peu penser à de la généricité contrainte par classe de base, même si ce n’est pas tout à fait la même chose.
Après, il y des arguments pour ne pas l’avoir fait :
- ça simplifie beaucoup le boulot du compilateur
- l’existence et la signature d’une méthode (la seule chose que sait vérifier à ce niveau le compilo rust) ne suffisent pas à ce que sa sémantique soit identique / compatibles -> avec des traits explicites, on fait reposer cette responsabilité sur le développeur.
Note que le deuxième point pourrait grandement être corrigé par… la programmation par contrat :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Au final, les mécanismes de passage de paramètres sont grosso modo semblables à ceux de C++, à part le passage avec transfert de propriété (celui qui interdit de réutiliser l'objet après l'appel).
Ça existe aussi en C++, depuis C++03 avec auto_ptr (mais qui était une catastrophe), et correctement depuis C++11 avec la sémantique de mouvement / unique_ptr.
Donc pour un programmeur C++, ce n’est pas ce point qui devrait poser problème lors d’un passage à Rust. Ça fait longtemps que je n’ai pas regardé en détail, mais de mémoire, il n’y a rien de véritablement « nouveau » dans Rust, il y a plutôt un sous-ensemble sûr de fonctionnalités offertes par différents langages, majoritairement C++ mais il y a quelques emprunts ailleurs.
Les principaux reproches que j’avais à faire à l’époque (et je crois que ça n’a pas changé) :
- pas de duck-typing sur les traits
- pas de support de la programmation par contrats
J’avoue que même à l’époque (il y a deux ans environ) je n’avais pas assez joué avec pour voir jusqu’où on pouvait aller en terme de métaprogrammation. Je crois que c’est aussi un manque, mais les choses ont peut-être évolué de ce côté là.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Qu'est-ce qui fait dire à Mozilla que Rust va attirer les développeurs C/C++ ? Vu comment les développeurs C/C++ sont traités chaque fois qu'ils critiquent Rust, j'ai envie de dire que c'est mal barré.
Le fait que pas mal de développeurs Rust soient des gens qui connaissent très bien le C++, et qu’ils lui préfèrent Rust pour leur raison propres ? Et que donc, ils pensent sincèrement que les autres développeurs C++ devraient préférer Rust pour ces mêmes raisons. Ça n’est pas une bonne raison selon toi ?
L'industrie ne peut pas se permettre deux concurrents, et souvent, l'un des deux meurt.
L’industrie vit très bien avec des concurrents, à condition qu’ils soient interopérables. En informatique, ça veut dire : être capable de fournir une interface binaire « C » et d’appeler des fonctions binaires « C ». Rust est capable du second, pour le premier, je ne sais pas où ça en est.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Le truc, c’est que le principal souci de la structuration par indentation, c’est que c’est fragile :
if machin:
truc()
bidule()
autretruc()
C’est assez facile, lors de copier / coller malencontreux, de refactorisation de code (par exemple, en copiant collant quelque chose entre bidule et autretruc) de péter involontairement le bloc.
En tout cas personnellement c’est un problème que j’ai rencontré à plusieurs reprises. Il y a peut-être des techniques pour éviter cela, mais moi ça me fait préférer le fait d’utiliser des blocs bien délimités avec terminateur de bloc.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
J’ai déjà installé Kubuntu à un débutant et ça n’a posé aucun problème.
En fait, je crois que ça dépend vraiment des gens. Comme il y a quelques temps, je conseillais encore KDE :), j’ai vu une différence selon les gens. Chez certains, aucun soucis, chez d’autres, régulièrement du « mon icone a disparu, je suis perdu ». Le problème n’est pas vraiment avec les possibilités de configuration, mais que ces possibilités de configuration soient tout le temps présentes, et que donc, il est facile de les activer / désactiver sans le faire exprès.
Les « activités », par exemple, me semblaient un super concept : tu regroupes 3-4 applications par thème, ça se lance tout seul quand tu actives le truc, impeccable. Dans la réalité, c’est hyper fragile, puisque l’activité se modifie en permanence : si tu fermes l’application et pas l’activité, à la prochaine activation, l’appli ne sera pas lancée automatiquement. Aucun moyen (en tout cas, pas trouvé, si ça existe je serais ravi de l’apprendre) de « verrouiller » une configuration, pour que tout revienne toujours dans l’ordre.
Un autre exemple, niveau applicatif cette fois : dans kdenlive, chacune des petites « fenêtres » de l’interface est modifiable, supprimable à tout moment, par un simple clic (par exemple, sur le bouton « fermer »). Il n’y a pas de moyen simple de « verrouiller » le layout --> tu te garantis un appel de « ma fenêtre a disparu, c’est tout planté » (oui, c’est du vécu :) ). Il me semble que pas mal d’autres applis kde sont dans ce cas, mais je n’ai plus de kde sous la main pour vérifier d’autres exemples.
De mon point de vue, c’est vraiment ce point là que kde devrait améliorer. Car pour un déploiement à grande échelle (entreprise, administration, même pour une petite société en fait), c’est ce qui va faire diminuer le nombre d’appels au support, et ça c’est primordial vu le coût que ça peut représenter.
Pour le reste, Okki a bien résumé. L’essentiel c’est qu’il y ait le choix.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Euh j'ai une idée : laisse à GNOME le soin de faire des interfaces épurées, et laisse à KDE le soin de faire des interfaces moins épurées.
Parce que bon si c'est pour copier GNOME, je vois pas l'intérêt.
Effectivement.
Par contre, personnellement je ne conseille plus kde pour des gens peu à l’aise avec l’informatique en général. Il est trop facile de complètement casser son bureau ou ses applications en faisant n’importe quoi (donc, sans avoir touché à rien d’après l’utilisateur), alors qu’avec gnome, c’est beaucoup plus difficile.
Et plus que tout le reste, je crois que c’est ce critère qui est primordial pour un « débutant ».
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
Attention à ne pas confondre « designer » et « spécialiste interaction homme/machine » (ou interface utilisateur, ou ergonomie, on peut appeler ça comme on veut je m’en fous un peu).
Les interfaces de purs « designers », ça claque plus mais ça peut être autant une plaie à utiliser que les interfaces de développeur :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: La mixité est un échec !
Posté par whity . En réponse à la dépêche Stage collégiennes/lycéennes « Girls Can Code! » en août. Évalué à 6.
Il y a des problèmes au niveau mondial. La situation en France est quand même largement meilleure que dans le reste du monde (en moyenne), ce qui explique beaucoup d’incompréhensions dans ce genre de débats.
En France, le harcèlement sexuel (puisque c’est de ça dont on parle) est pénalement répréhensible. C’est là qu’il faut aller, même si c’est effectivement dramatique d’en arriver là. Le problème existe d’ailleurs aussi dans d’autres domaines (sports par exemple, typiquement arts martiaux où la mixité est restée), le restreindre à l’informatique, je crois que c’est se tromper.
À noter aussi qu’il suffit d’une minorité de cons pour créer un maximum d’emmerdements.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: La mixité est un échec !
Posté par whity . En réponse à la dépêche Stage collégiennes/lycéennes « Girls Can Code! » en août. Évalué à 4.
Le même. Globalement, c’est celui qu’on trouve à la sortie d’école.
En revanche, vu que dans cette même fonction publique, on doit trouver cette sacro sainte parité de 50/50 aux échelons supérieurs, cela veut dire que les femmes ont beaucoup moins de concurrence que les hommes. Et fondamentalement, c’est un problème.
À noter qu’il y a vraisemblablement le problème inverse dans d’autres domaines que l’informatique. Le bilan, c’est que c’est surtout une mauvaise solution.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: La mixité est un échec !
Posté par whity . En réponse à la dépêche Stage collégiennes/lycéennes « Girls Can Code! » en août. Évalué à 6.
Je ne suis pas sûr que ce genre d’arguments serve la cause de l’égalité homme/femmes. Dans « handicapé », il y a « handicap », et pour avoir bossé avec des handicapés, oui, c’est lourd, oui, ce sont des contraintes supplémentaires, et oui pour un employeur un salarié handicapé est généralement moins productif qu’un non handicapé. Je ne crois pas qu’on puisse raisonnablement dire la même chose d’une femme.
Va regarder les chiffres en mécanique. C’est largement pire que l’informatique (mais effectivement, ça partait déjà de très bas, contrairement à l’informatique où on avait une relative parité – en même temps la discipline n’existait pas).
La « discrimination positive », puisque c’est de ça dont on parle, a deux gros défauts :
* elle crée beaucoup de frustrations
* elle ne se conçoit que comme une mesure très temporaire, le temps de retrouver un équilibre
Autant je crois aux quotas par exemple en politique, là où on part d’une population de militants qui est grosso-modo à 50/50, autant je crois que des quotas à 50/50 quand tu pars d’une population qui est déjà à 90/10 (comme ça peut être le cas pour certains postes de chercheurs, par exemple) ne fait que créer des frustrations et n’encourage pas grand chose.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: La mixité est un échec !
Posté par whity . En réponse à la dépêche Stage collégiennes/lycéennes « Girls Can Code! » en août. Évalué à 3.
Pour le manque d’exemples féminins, cf http://www.bbc.com/news/science-environment-33157396
Ça donne un début d’explication. Après, attention toujours dans ce genre de débat à bien définir de quoi on parle. La situation en France est très différente de ce qu’elle peut être en Inde, au Brésil, aux États-Unis, au Burundi ou en Suède. Et il faut aussi moduler selon les tranches d’âge, car la deuxième moitié du 20ème siècle a vu beaucoup de choses évoluer.
Sinon, un détail qu’on oublie de mentionner facilement : la profession d’informaticien (de manière générale, et en France) s’est beaucoup masculinisée entre les années 60 et les années 2000. Je n’ai jamais lu d’explication probante.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Bépo
Posté par whity . En réponse au sondage Ma disposition de clavier préférée. Évalué à 1.
Une preuve de plus, s’il en fallait encore, que bépo permet de taper plus efficacement :)
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: contenu inutile.
Posté par whity . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 3.
Encore une fois, parce que le terme usuel qu’on trouve partout, dans tous les logiciels, est « Enregistrer ». Que « Sauvegarde » évoque plutôt une copie de sauvegarde, quelque chose qu’on fait à côté de son document de travail, pour en conserver une copie en cas de pépin.
Donc non, changer pour « sauver » ou « sauvegarder », ce serait pire :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: contenu inutile.
Posté par whity . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 1.
Certes, mais…
Libreoffice a exactement les mêmes contraintes (j’ouvre un csv sous libreoffice calc, je rajoute une colonne avec des formules dedans, je choisis enregistrer), mais un comportement différent (ie il affiche une boîte de dialogue « êtes-vous sûr de vouloir faire ça, vous risquez de perdre des données » avec un bouton « Enregistrer en ods ».
Je ne prétends pas que cette solution est meilleure que celle de gimp. Je me désole juste que les deux logiciels ne se comportent pas de la même manière, et que je ne vois pas poindre d’issue à cette situation qui est pourtant « hostile » vis à vis de l’utilisateur final.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: contenu inutile.
Posté par whity . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 3.
En fait, pas tant que ça…
Le problème est que gimp est un « alien » quelque soit l’environnement de bureau utilisé (y compris mac / windows). Que ses menus et son ergonomie générale ne sont pas en cohérence avec le reste du bureau.
Inkscape fait la même différence enregistrer / exporter, mais d’une manière différente. Est-ce qu’elle est meilleure ou moins bonne, j’ai envie de dire que ça ne m’intéresse effectivement pas trop. Ce qui me gêne, en revanche, c’est d’avoir deux manières différentes, d’avoir des applis qui ne se comportent pas de la même manière.
Sous debian wheezy, faire alt-F4 alors qu’une image était ouverte fermait l’image, pas gimp. Je remercie le gars qui a corrigé ça pour que sous jessie le comportement soit celui attendu (gimp se ferme, éventuellement avec une boîte de confirmation s’il y a des modifs en cours), parce que le plus gênant, ce n’est finalement pas tel ou tel comportement, mais bien les différences de comportement entre les applications.
À terme, j’espère que gimp arrivera à un niveau de séparation outils/interface tels que qui que ce soit pourra pondre et maintenir une interface réellement adaptée à chaque environnement majeur. C’est un sacré chantier par contre et une charge supplémentaire par la suite, je comprends donc que ça ne soit pas dans les priorités.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Retour sur les objets actifs
Posté par whity . En réponse à la dépêche Instantané sur le parallélisme et le code. Évalué à 2.
RPC permet de faire du synchrone, c’est plus proche du modèle « habituel », ça explique que les gens aient voulu pousser ça : le développeur n’a pas à changer ses habitudes. Même si au final, c’est plutôt une mauvaise idée.
Sinon, pour Erlang et la communauté scientifique, c’est surtout que la communauté scientifique travaille plutôt sur des modèles que sur du code, et donc, utilise des langages plus restreints (bip pour ne citer que lui, par exemple). Mais le modèle utilisé par erlang est énormément étudié et utilisé par la communauté scientifique.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Réponse à tous
Posté par whity . En réponse à la dépêche Elementary OS, une jolie distribution et facile pour tous, tout simplement !. Évalué à 1.
Juste en passant, si tu cherches un bon outil pour renommer en masse des fichiers, « pyrenamer » fait le job, et est fourni dans les paquets debian.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par whity . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 3.
Oui c’est un bon exemple opensll, ça a permis heartbleed sur bsd… (l’allocateur par défaut peut nullifier la mémoire qu’il alloue, avec un allocateur maison qui réemploie sa mémoire t’es baisé).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Premières impressions
Posté par whity . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 1. Dernière modification le 20 mai 2015 à 07:28.
Effectivement, j’ignorais cela, je ne l’avais pas vu passer dans les évolutions depuis mes derniers essais (qui datent un peu, je dois dire).
Va falloir que je m’y remette :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Les questions qui compliquent tout
Posté par whity . En réponse à la dépêche Sortie de Yarock 1.1.2. Évalué à 2.
Il y a des composants qml qui reprennent le look and feel des composants de bureau. Qt components for desktop, par exemple, je ne sais plus quel est le nom en qml2.
Pour l’instant, je pense que l’intégration au reste du DE sera moins bonne qu’avec un qt standard, mais là on n’est pas dans ce cadre là si j’ai bien suivi.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Premières impressions
Posté par whity . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
Tu as raison mais c’est un argument de mathématicien / formaliste. Que ça ne résolve pas tous les problèmes ne veut pas dire que ça n’en résout pas une bonne partie. L’analyse statique de code n’est pas de la preuve formelle, la vérification statique de contrats rentre dans cette catégorie : trouver un maximum (≠ toutes) d’erreurs à la compilation.
Je ne connaissais pas cet usage. En quoi est-ce différent de simplement définir l’opérateur d’affectation ? (en considérant que les types sont par défaut non-copiables – j’avais compris que c’était le cas en rust).
Oui et non. L’idée des concepts est de formaliser les dépendances que peuvent avoir des classes / algorithmes génériques, en partie pour produire de meilleures messages d’erreur, en partie parce que rajouter de la sémantique est généralement une bonne idée. D’ailleurs, la doc de la STL fait depuis très longtemps (au moins depuis C++03) référence à ces concepts, même s’ils n’existent pas dans le langage. Mais les concepts, tels que je les ai toujours vu présentés, ne se substituent pas au « duck-typing ». C’est à dire que le fait qu’un type soit compatible avec un concept sera déterminé automatiquement par le compilateur. C’est d’ailleurs une partie très problématique qui provoque le report des concepts d’année en année, sachant que le bénéfice final n’est pas si évident (meilleurs messages d’erreur, mais c’est à peu près tout).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Les questions qui compliquent tout
Posté par whity . En réponse à la dépêche Sortie de Yarock 1.1.2. Évalué à 4.
QML, c’est censé te faciliter la vie de ce côté là, et surtout, ça utilise la carte graphique, et donc permet de soulager le processeur et de faire des effets kikoolol assez facilement.
Par contre, tu vas devoir faire l’impasse sur la compatibilité Qt4 si tu franchis le pas (globalement, le QML inclus dans Qt4 est déprécié et n’est plus recommandé, c’est Qml2 que tu devrais utiliser).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Premières impressions
Posté par whity . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 6.
Ce que tu montres, c’est que le compilo Rust est plus malin que le compilo C++.
Mais mon propos, c’était que la sémantique est la même. Et que donc, pour un programmeur C++, la sémantique en général de Rust ne doit pas poser de problème de compréhension.
Quand je lis ton code C++, je vois qu’il va merder (parce que l’exemple est simple). Idem quand je vois ton code Rust. Et le fait que l’un compile mais pas l’autre est un très bon argument en faveur de Rust, parce que dans la vraie vie l’erreur ne saute pas toujours aux yeux à la lecture du code :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Premières impressions
Posté par whity . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 3.
L’intérêt, c’est de ne pas avoir à déclarer explicitement l’implémentation (le terme est mauvais, je ne sais plus quel est le bon) d’un trait. Ce qui permet, notamment, si moi je définis un nouveau trait, et qu’il se trouve qu’un type de la lib standard/xyz respecte l’ensemble des propriétés de ce trait (et donc, est substituable au sens du LSP), que je l’utilise partout où j’ai déclaré que j’utilisais un type implémentant mon trait, même s’il ne déclare pas l’implémenter explicitement (je ne peux pas modifier la lib standard ou la lib xyz pour y rajouter mon trait).
Pour pratiquer cela couramment en C++, c’est utile. Mon impression est qu’avec un système de traits explicites, tu te restreins arbitrairement. Ça me fait un peu penser à de la généricité contrainte par classe de base, même si ce n’est pas tout à fait la même chose.
Après, il y des arguments pour ne pas l’avoir fait :
- ça simplifie beaucoup le boulot du compilateur
- l’existence et la signature d’une méthode (la seule chose que sait vérifier à ce niveau le compilo rust) ne suffisent pas à ce que sa sémantique soit identique / compatibles -> avec des traits explicites, on fait reposer cette responsabilité sur le développeur.
Note que le deuxième point pourrait grandement être corrigé par… la programmation par contrat :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Premières impressions
Posté par whity . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 3.
Ça existe aussi en C++, depuis C++03 avec auto_ptr (mais qui était une catastrophe), et correctement depuis C++11 avec la sémantique de mouvement / unique_ptr.
Donc pour un programmeur C++, ce n’est pas ce point qui devrait poser problème lors d’un passage à Rust. Ça fait longtemps que je n’ai pas regardé en détail, mais de mémoire, il n’y a rien de véritablement « nouveau » dans Rust, il y a plutôt un sous-ensemble sûr de fonctionnalités offertes par différents langages, majoritairement C++ mais il y a quelques emprunts ailleurs.
Les principaux reproches que j’avais à faire à l’époque (et je crois que ça n’a pas changé) :
- pas de duck-typing sur les traits
- pas de support de la programmation par contrats
J’avoue que même à l’époque (il y a deux ans environ) je n’avais pas assez joué avec pour voir jusqu’où on pouvait aller en terme de métaprogrammation. Je crois que c’est aussi un manque, mais les choses ont peut-être évolué de ce côté là.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par whity . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 4.
Le fait que pas mal de développeurs Rust soient des gens qui connaissent très bien le C++, et qu’ils lui préfèrent Rust pour leur raison propres ? Et que donc, ils pensent sincèrement que les autres développeurs C++ devraient préférer Rust pour ces mêmes raisons. Ça n’est pas une bonne raison selon toi ?
L’industrie vit très bien avec des concurrents, à condition qu’ils soient interopérables. En informatique, ça veut dire : être capable de fournir une interface binaire « C » et d’appeler des fonctions binaires « C ». Rust est capable du second, pour le premier, je ne sais pas où ça en est.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Et devuan ?
Posté par whity . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 6. Dernière modification le 05 mai 2015 à 15:48.
« The domain devuan.com may be for sale. Click here for details. ». C’est une blague, hein…
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Mir est là...
Posté par whity . En réponse à la dépêche Sortie d’Ubuntu 15.04. Évalué à 2.
Ça exporte le bureau entier et pas une simple fenêtre, pour autant que je sache.
Et dans certains contextes, ça peut faire une sacrée différence.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: ES6
Posté par whity . En réponse à la dépêche RapydScript, le JavaScript qui se déguise en Python. Évalué à 4.
Le truc, c’est que le principal souci de la structuration par indentation, c’est que c’est fragile :
C’est assez facile, lors de copier / coller malencontreux, de refactorisation de code (par exemple, en copiant collant quelque chose entre bidule et autretruc) de péter involontairement le bloc.
En tout cas personnellement c’est un problème que j’ai rencontré à plusieurs reprises. Il y a peut-être des techniques pour éviter cela, mais moi ça me fait préférer le fait d’utiliser des blocs bien délimités avec terminateur de bloc.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Bureau ?
Posté par whity . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 6.
En fait, je crois que ça dépend vraiment des gens. Comme il y a quelques temps, je conseillais encore KDE :), j’ai vu une différence selon les gens. Chez certains, aucun soucis, chez d’autres, régulièrement du « mon icone a disparu, je suis perdu ». Le problème n’est pas vraiment avec les possibilités de configuration, mais que ces possibilités de configuration soient tout le temps présentes, et que donc, il est facile de les activer / désactiver sans le faire exprès.
Les « activités », par exemple, me semblaient un super concept : tu regroupes 3-4 applications par thème, ça se lance tout seul quand tu actives le truc, impeccable. Dans la réalité, c’est hyper fragile, puisque l’activité se modifie en permanence : si tu fermes l’application et pas l’activité, à la prochaine activation, l’appli ne sera pas lancée automatiquement. Aucun moyen (en tout cas, pas trouvé, si ça existe je serais ravi de l’apprendre) de « verrouiller » une configuration, pour que tout revienne toujours dans l’ordre.
Un autre exemple, niveau applicatif cette fois : dans kdenlive, chacune des petites « fenêtres » de l’interface est modifiable, supprimable à tout moment, par un simple clic (par exemple, sur le bouton « fermer »). Il n’y a pas de moyen simple de « verrouiller » le layout --> tu te garantis un appel de « ma fenêtre a disparu, c’est tout planté » (oui, c’est du vécu :) ). Il me semble que pas mal d’autres applis kde sont dans ce cas, mais je n’ai plus de kde sous la main pour vérifier d’autres exemples.
De mon point de vue, c’est vraiment ce point là que kde devrait améliorer. Car pour un déploiement à grande échelle (entreprise, administration, même pour une petite société en fait), c’est ce qui va faire diminuer le nombre d’appels au support, et ça c’est primordial vu le coût que ça peut représenter.
Pour le reste, Okki a bien résumé. L’essentiel c’est qu’il y ait le choix.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Bureau ?
Posté par whity . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 6.
Effectivement.
Par contre, personnellement je ne conseille plus kde pour des gens peu à l’aise avec l’informatique en général. Il est trop facile de complètement casser son bureau ou ses applications en faisant n’importe quoi (donc, sans avoir touché à rien d’après l’utilisateur), alors qu’avec gnome, c’est beaucoup plus difficile.
Et plus que tout le reste, je crois que c’est ce critère qui est primordial pour un « débutant ».
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Thème graphique
Posté par whity . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 10.
Attention à ne pas confondre « designer » et « spécialiste interaction homme/machine » (ou interface utilisateur, ou ergonomie, on peut appeler ça comme on veut je m’en fous un peu).
Les interfaces de purs « designers », ça claque plus mais ça peut être autant une plaie à utiliser que les interfaces de développeur :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0