freem a écrit 4965 commentaires

Tout est dans le titre, surtout si tu n'as que 2 ans pour refaire ton application.
Au final, ce qui importera probablement le plus, ce sera ta conception, le langage ne sert pour moi qu'a traduire.

Pour un soft de gestion, le plus gros sera fait par la BDD, et elles offrent toutes des bibliothèques utilisables dans tous les langages un minimum populaires (et pour les autres, il faut adapter la lib C, mais bon…). Tu peux aussi utiliser des technologies qui permettent de requêter n'importe quel SGBDR avec une seule lib, je ne sais plus comment elle s'appelle mais il y en a au moins une.

Bon, après, si tu es rouillé, je dirais évites le C, tu te prendra la tête pour pas grand chose (gestion des ressources (RAM, mais aussi connections à la BDD ou identifiants des fenêtres graphiques) manuelle, si tu oublies un truc tu as un crash ou pire, un bug longtemps après).

Ceci étant dit, je me pose la même question que d'autres: avant de coder, pourquoi ne pas regarder l'existant auquel tu peux avoir accès?
Je doute que tu aies des besoins transcendants après tout (si je comprend bien, tu as une petite structure) et partir d'un existant sera probablement bien plus léger en terme de charge. Sans parler du fait qu'un existant a une communauté déjà en place, tu n'aurais pas besoin de faire toute la maintenance tout seul.
Je pense notamment à dolibarr, qui a fait l'objet de plusieurs dépeches ici, mais il y en a probablement d'autres.

Swift n'a pas de gc. Arc est pure compile time, et 100% déterministe.

Ok. Faudra que j'y jette un oeil.

Comme pour du c++ de 1995 dans un projet c++17.

Dis-moi, tu as remarqué que j'ai parlé de C++ standard, et donc de 98?
As-tu aussi remarqué que je parlais de prendre un code source du vieux standard et de le compiler avec un compilateur moderne?

Si tu réponds oui, alors donne moi un bout de code répondant au 1er standard C++, c'est à dire de 1998 (donc, non, pas de 1995…) que je ne puisse pas compiler avec, par exemple, clang3.8.
Quant au C++17, vu qu'il n'est pas encore sorti, ça va être difficile de tester.

Et encore, même Java, ton code tu vas vouloir le moderniser.

Tout à fait. Mais pour moderniser, il faut encore être capable de compiler l'original.
Imaginons un peu, tu tombes un jour sur un logiciel open source sympa mais plus maintenu depuis 10-15 ans (allez, genre, autorealm. J'aimerai vraiment arriver à le recompiler lui… mais c'est du delphi, et je me sens pas motivé pour acheter une licence windows + whatever compilo juste pour moderniser et porter ce logiciel sous linux).
Le fait de pouvoir le compiler malgré l'absence de mise à la modernité pendant plus d'une décenie est un peu vital pour pouvoir le moderniser ensuite sans reprendre tout le code source.
C'est une des choses que je pense que C++ permets.

mais j'ai de plus en plus tendance à passer à Python+PyQt pour les GUI et interfacer avec un backend à plus hautes performances.

Je comprend.

On ne pourra pas passer par du C++ (ou n'importe quel autre langage qui utilise autre chose que pointeurs + types machines) tant qu'une ABI n'aura pas été définie ;

Sauf que ce bout de code:

struct foo
{
    int* ptr;
};

foo foo_make( void )
{
    foo f; f.ptr = 0;
    return f;
}

C'est du C++ parfaitement valide. L'ABI est stable, bien que j'aie un doute sur le fait que ce soit par convention ou par standard.
Le fait est que, bien sûr, il faut se débarasser de la totalité des fonctionnalités C++ dans l'API, mais bon… je pinaille, j'avoue :)
En tout cas, j'en retire que ce que tu fais avec python+rust, tu peux le faire avec python+C++.

En ce qui concerne Rust, il a une FFI plutôt correcte avec le C

Je ne suis pas expert, mais j'ai l'impression que c'est un peu la meme chose partout, de ce point de vue la. Enfin, non, puisqu'en C++, justement, il n'y a pas besoin d'autant de colle.
Objectivement, je dirais avantage à C++ en terme de quantité de code vital pour importer du code C, et pour cause, un sous-ensemble du C++ est entièrement compatible avec le C (mais pas l'inverse, parce qu'il me semble que le C++ réserve certains mots non réservés par le C, genre public).

Enfin, ce genre de trucs me rappelle la fois ou j'avais du interfacer du C++ avec powerbuilder12… j'avais fini par pondre un wrapper complet, qui permettait avec quelques macros (non nécessaires elles, mais ça réduisait méchamment le boilerplate) et beaucoup de template, histoire d'etre sur que quand ça plantait ça venait pas de la colle powerbuilder/C++… foutu langage proprio de merde, si tu veux mon avis.

erreurs catastrophiques

Existe-t-il un langage qui empêche complètement les erreurs catastrophiques? Qui n'expose jamais au risque de perdre des données, qui génère des programmes dont on est sûrs à 100% qu'ils ne planteront jamais?
A priori, ADA pourrait coller à la description, mais, je ne l'ai pas vu cité encore. J'ai vu cités Swift, Go, et d'autres dont je n'ai jamais entendu parler. Ceux-la, ils y collent à la description? Et en pratique, ça donne quoi?

temps de compilation ;

Faut dire que, quand on voit le code le STL de g++, on comprend que ce soit long à compiler… ça s'include dans tous les sens, avec des macros en veux-tu en voila, des héritages et aggrégations tortueux… et de manière générale un code illisible (chose amusante: ils indentent parfois avec des espaces, parfois avec des tabulations. Je ne parle pas d'aligner le code, mais bien de l'indentation!).
Je n'ai pas fait de comparaisons sur les temps de compilations, mais depuis quelques temps j'utilise libc++ de llvm. Rien que pour comprendre pourquoi un truc merde, c'est 10 fois plus simple (même si je reste gêné par le fait qu'il soit impossible d'interdire au compilo les inline quand on debug…).
Au final, j'utilise clang parce que plus rapide et plus clair que gcc depuis plusieurs années, et cette année j'ai commencé à utiliser leur STL.
Plus ça va, moins j'utilise d'outils GNU pour le dev, et mieux je me porte. Ca ne m'empêche par de reconnaître que je leur dois une fière chandelle, hein, mais je pense que certains défauts repprochés au langage C++ sont plus dus aux outils libres «standards de facto» qu'au langage lui-même. Ou du moins, que ces fameux outils sont une cause aggravante. Le poids de l'historique, sûrement.
Ah oui, j'oubliai: j'essaie aussi de tendre vers l'utilisation de musl, histoire qu'on me dise pas que j'ai oublié la libc :) (mais bon, oui, il me reste pas mal de trucs à remplacer, faut du temps, surtout que je fais ça pour le fun surtout).

le langage de templates qui est parmi les plus abscons, parce qu'il mélange les génériques et la métaprogrammation (ou alors je suis le seul à trouver les templates récursifs imbitables) ;

Existe-t-il un autre langage natif ayant un mécanisme de templates aussi puissant que celui du C++, et qui offre les mêmes perfs (à peu près, du moins)?
Rust, peut-être? (vraie question)

le préprocesseur, vraiment ?

Malheureusement, on en a besoin pour pouvoir utiliser des trucs codés en C. Dans certains cas, ça permets aussi de réduire le code boiler-plate.
Mais, c'est vrai: ce truc est un générateur de galères, quand il est utilisé abusivement. Les fonction inlinées sont par exemple bien plus intéressantes que les macros (surtout en combinaison avec les template), et pourtant dans certains bouts de code on voit encore des macros.
La dernière fois que j'ai vu des macros utilisées, c'était soit dans du code C, soit dans des framework de test, cela dit.
Reste donc que l'usage d'import de header, et je suis d'accord pour dire que ça serait pas mal qu'il saute.

(pourquoi on ne peut pas définir une classe template ailleurs que dans son header ?)

Tu peux. Il suffit qu'elle soit déjà définie quand elle est utilisée. Ca m'arrive de faire des petites structures templates internes à un fichier, que je n'expose pas publiquement ça aucun intérêt.
Je me doute que tu le sais, mais ce n'est pas nécessairement le cas de tous, je me permets donc cette clarification :)

'évolution rachitique

Vrai. C'est lent.
Je me demande quelle est la part de responsabilité liée à l'ISO, ceci dit. La plupart des langages qui sortent, au final, n'ont qu'une implémentation de référence, pas de normalisation réelle.
Hors, cette standardisation officielle et internationale est une force de C++ pour moi.
Du coup, je comparerai la lenteur d'évolution de C++ à Debian: c'est lent et vieux, c'est vrai, mais le fait que ça n'aille pas trop vite semble avoir pour conséquence que la maintenance est plus simple pour les utilisateurs (un vieux code C++ compile sur un compilo moderne sans trop de soucis, et une Debian peut être up/down gradée de la même manière). Pas la création d'un système fonctionnel, sa maintenance, j'insiste.

la gestion mémoire qui accumule plusieurs couches au fil des années (pointeurs nus, références, puis pointeurs intelligents [unique_ptr/shared_ptr/etc.]) ;

Marrant, c'est justement pour la gestion de la mémoire que j'apprécie le C++. Parce qu'en C++, si je veux utiliser un GC, je peux. Si je veux utiliser des pointeurs intelligents, je peux. Si je veux utiliser des pointeurs nus, je peux encore!
J'ai le choix, bon sang, et c'est bien d'avoir le choix, de la meme manière que c'est bien de pouvoir choisir entre windows, mac OS, Debian, voidlinux, FreeBSD, OpenBSD, etc.

C'est perfectible, bien sûr, mais quand je lis qu'il est obligatoire d'utiliser des pointeurs nus en C++, je comprend que l'auteur de la phrase lue ne connaît pas le C++ (je ne dis pas l'avoir lue ici, mais j'ai déjà lu ça, plus d'une fois).
Sincèrement, avec la STL, les références et les itérateurs, les pointeurs nu ne sont simplement qu'une façon de s'interfacer avec le C ou les vieilles bibliothèques. Rien de plus.
A noter un repproche que je fais aux pointeurs intelligents standard: ils ne savent gérer que la mémoire, alors que ce n'est qu'une seule des ressources que l'on peut manipuler (alors qu'un descripteur de fichier UNIX est un int, par exemple). Sans parler du fait qu'ils aient un overhead pour moi inutile (évident pour shared_ptr, moins pour unique_ptr, mais le fait est qu'un pointeur pour stocker l'@ du destructeur est maintenu et testé, alors que ça aurait pu être passé en template. Mais j'imagine que certains ont l'usage de modifier le destructeur au runtime?).

Maintenant, oui, je l'admets: utiliser des références ou des itérateurs ne protège pas contre les segfaults, et il n'y a rien à ma connaissance en C++ pour gérer ça. C'est un des points qui font que je veux me mettre à Rust, un jour.
Le C++ ne permets pas non plus, à ma connaissance, de vérification sur les under/over-flow d'entier. C'est un problème, pour moi, vraiment. D'un autre côté, ça permets un code plus léger et plus rapide, parce que si à chaque addition on devait faire une vérification à l'exécution, c'est du code en plus à exécuter, de la lenteur.
Ce que j'apprécierai vraiment, ça serait de pouvoir faire ça, uniquement pendant le debug.

mais pas de vector::delete_at)

Et ça n'arrivera jamais, j'espère. Si une telle fonction devait exister, elle aurait plutôt sa place dans les algorithmes, autrement dit, ce serait std::delete_at( iterator it, container& cont ); ou un truc de goût là.
Les APIs de la STL sont déjà assez moyennes comme ça, à mon avis (à la fois trop riches et pas assez: trop riches parce que, par exemple, std::vector::insert pourrait être implémenté en dehors du conteneur (avec une combinaison de std::move&std::inserter par exemple) alors qu'il est difficile de connaitre le cout mémoire réel d'un conteneur (pour vector c'est faisable, mais pour std::map?) ).
En tout cas, c'est marrant, dans la liste des défauts de la STL, j'aurai pensé voir std::string au moins une fois (parce qu'elle s'interface relativement mal avec le reste de la lib standard, et que pour une gestion de chaine de caractères, ça ne permets meme pas de diviser facilement… bref je la trouve bancale.).

rétro-compatibilité avec le C, mais pas vraiment non plus.

Comme tout les langages sauf le C, en fait. Je pense que l'on devrait arrêter de ce soucier du C, franchement.
Je pense qu'une bonne part des emmerdes du C++ viennent du C.

dont une bonne partie sont ÀMHA imputable à son âge.

Personnellement, si j'apprécie énormément le C++, c'est parce que c'est un langage qui donne le choix.
Il me donne le choix d'utiliser les template.
Il me donne le choix d'utiliser le modèle mémoire que je veux (GC, pointeurs intelligents, pointeurs nu. Bon, ok, pour le GC il n'y a rien dans la lib standard, probablement parce que la culture C++ préfère la RAII).
Il me donne le choix d'utiliser la RTTI (j'inclue dedans les méthodes virtuelles).
Il me donne le choix de faire de l'héritage multiple et même en diamant (ça m'est déjà arrivé une fois de m'en servir).
Il me donne le choix d'utiliser les exceptions (à condition de se passer de la STL, certes).

Rien n'est obligatoire, il faut choisir ce que l'on utilise. Pour certains, c'est un défaut. Pour moi, c'est une force.
Pour refaire le parallèle avec les distributions Linux: pour moi, l'apparition de Devuan, d'Ubuntu, d'Archlinux, et j'en oublie, ce sont de bonnes choses, parce que ça donne le choix.
Alors bien sûr, avoir le choix implique de prendre des décisions, mais pour moi c'est un peu le coeur de métier d'un développeur, de prendre des décisions.

Mais ce n'est pas parce que j'aime beaucoup C++ que je dis qu'il n'a aucun défaut. Seulement, à l'heure actuelle, je ne vois que Rust pour le remplacer, et il est encore jeune, on n'a pas encore eu le temps de voir comment il vieillit.
Avant de dire que Rust peut remplacer C++, il faudra au moins 5 ans d'écart entre la sortie de sa 1ère version stable et l'heure du jugement, justement pour avoir du recul.
On n'a aucun recul sur Rust, contrairement à C++ ou l'on parle de près de 20 ans ( ~18 de standard ISO).

les temps de compilation sont long, tres long.

Je ne le nie pas, les temps de compilation C++ peuvent être longs. Ceci étant dit, quelle est la part de lenteur due au langage, et quelle est la part due aux outils, make, par exemple?
Parce que selon certains, pour une compilation incrémentale, make est inutilement très lent.

Et aussi, je pense que comparer uniquement les temps de compilation est une erreur de nos jours. Après tout, si on prend Java ou C#, il me semble bien qu'une partie de la compilation est faite au lancement de l'exécutable.
Du coup, ce qui serait objectif, c'est de comparer compilation + temps de première exécution, non?

Je ne travaille qu'avec Rust, mais je n'ai pas eu pour le moment besoin de GUI. Et si je devais en faire une, je pense que je m'en ferais une en Java/Kotlin/C# interfacé avec le backend Rust.

Intéressant.
Donc ce n'est pas un problème si C++ ne gère pas les GUI, puisqu'on peut aussi interfacer avec du "Java/Kotlin/C#" (même s'il faut passer par du C++ Céifié à cause de l'ABI, mais c'est un autre sujet que l'absence de GUI, et j'ai beau aimer le C++ je sais que le manque d'ABI stable est un véritable problème. Enfin, je ne sais pas comment ça se fait en Rust, non plus).

Intéresant. Donc, si je te suis bien, le seul langage dans la même catégorie que C++ est Rust, dont la pérénité n'est pas assurée.

Du coup, l'intérêt de C++ me semble tout trouvé?

Je voit pas ce que Python vient faire dans la catégorie

Moi non plus, mais je pense que c'était une provocation pour mettre en exergue le fait que de tous les langages que zenitram à vus cités ici, seul Rust est dans la meme catégorie que le C++ (et le C) notamment pour le fait de ne pas forcer (je ne suis pas sur, mais il me semble que Swift et Go le font) à utiliser un GC.
Je peux me tromper.

Ensuite, je suis surpris. Je n'imaginais pas python si vieux. Mais du coup, j'ai une question: quelle garantie a-t-on de pouvoir exécuter un code python de la première heure avec la dernière version stable?
Je me pose la meme question pour Swift et Go.
En C++ standard (ansi, ou 98, donc bien moins vieux que la première version de python, on est d'accord), je ne me pose pas de question, je suis sur à 95% que ça se fait sans souci.
Bon, sans souci… ça ne va peut-etre pas durer longtemps puisque std::auto_ptr sera retiré dans C++17. Par contre, il s'agit de la lib standard, et moi, je distingue la lib standard du langage (chose sur laquelle je suis persuadé que mon avis diverge de la moyenne).

PS: désolé pour le manque d'accents, petit problème de config clavier Xorg sous void…

Ok, donc l'accusatif est la marque qui permets de savoir sur qui le verbe agit, autrement dit, qui il accuse. Ça confirme ce que je pensais: je me plantais sur le sens de ce mot :)

Ma foi, pour le jap', j'avais déjà constaté que l'ordre des mots différait, grâce aux sous-titrages (pourtant pas toujours de super qualité, mais bon, étant gosse j'apprenais le français en devinant le sens des mots, j'ai un peu perdu cette faculté, mais pas tout j'imagine).

Merci.

Bien sûr ça ne suffit pas à comprendre une langue, mais en fait ça suffit à la rendre familière.

Je ne dirais pas familière (mais tout dépend de comment on détermine le sens de la familiarité), mais comprendre quelques mots d'une culture peut potentiellement pousser à les utiliser quand on est dans un cercle qui regarde/lit le même genre de choses, même si à l'époque je ne m'intéressait pas aux mangas.
D'un autre côté, il m'est arrivé de remarquer qu'un anime était d'origine chinoise: je n'en comprenais pas un traître mot alors que les sonorités étaient, à mon oreille mal éduquée, proches.

Et c'est exactement grâce à ça que des gens nous répètent tous les jours qu'ils trouvent l'anglais "facile" alors qu'ils ne savent pas aligner trois phrases: comprendre un slogan publicitaire qui est placardé partout et répété tous les jours à la télé, ce n'est pas comprendre la langue.

Ces même gens peinent souvent à lire ou écrire le français correctement, malheureusement.
Je me souviens d'une période ou des journaliste radio avaient un reportage en boucle (comme souvent) ou ils ajoutaient tous "ement" à la fin d'un mot qui était déjà un adverbe. Promis, à cette époque j'en ai bavé pour ne pas éteindre les radios de force autour de moi.
Je ne parlerais pas non plus des publicités bourrées de fôtes, h1, mais voila, c'est ce que j'ai vu. C'est peut-être l'évolution de la langue, mais bon sang, si l'évolution c'est de sacrifier les règles, plus personne ne se comprendra… enfin, pas sûr que ça changera grand chose en France.

Bon ce n’est malheureusement pas sourcé mais j’ai croisé beaucoup d’études du genre donc je suis assez confiant sur le fait que, même si la différence est peut-être pas aussi violente que dans cet exemple, l’espéranto est beaucoup plus facile que les langues habituellement enseignées.

Donc, un vécu dans certaines conditions à valeur scientifique?

Parce qu'un fork déplairait non seulement aux locuteurs de la langue originale

Valable uniquement dans le cas d'une langue vivante. Les autres, n'ayant aucun locuteur encore vivant, ça ne devrait pas poser trop de problèmes.
Évidemment, dans le cas du latin, on peut supposer que Italiens se considèrent comme tels (j'en sais rien, comme indiqué dans le mot "supposer", tout comme "ressenti" voulais bien dire que je n'avais aucune certitude…) mais bon, je n'ai pas parlé de forker le latin. Juste, j'ai demandé pourquoi ne pas juste forker une langue, et tes arguments sont bons.
Le coup du fork latin, c'est pas de moi, mais toi qui as mal compris mes propos (eux-même sûrement mal exprimés).

1. Beaucoup de mots latins sont passés aussi dans des langues non-latines comme l'anglais ou l'allemand.

Dans le cas de l'anglais, ça s'explique assez facilement: l'Angleterre à été conquise par la Normandie, qui à imposé son langage, un dérivé de la langue d'oil, elle-même très latinisée.
Pour l'Allemand, je ne sais pas exactement, mais l'histoire de l'Europe est faite d'invasions, qui favorisent les échanges de langue.

Par exemple le mot domo vient à peu près autant du latin domus que du russe дом, également présent dans la plupart des langues slaves;

Hum… il me semble que la Russie à été fondée par les vikings, eux-mêmes proches de l'europe de l'Ouest par leurs commerces et combats.
D'ailleurs, il me semble que le terme "mère russie" pourrait être lié au fait de la fondatrice, selon la légende, serait une reine nommée "Rus".

Et pour remonter plus loin, à l'indo-européen

Je connais la théorie de la langue commune indo-européene, enfin, en surface, même si je ne suis pas linguiste. D'ailleurs, cette théorie porte un nom assez intéressant: indo-européenne. Quid de l'Afrique? Je pourrais essayer de parler de régions incluses dans l'Asie, mais je ne suis qu'un curieux, et donc, il y a de fortes chances que je me ridiculise encore plus.

1. la manière dont les racines, fussent-elles latines, se combinent entre elles pour former des mots nouveaux, n'a pas d'équivalent ni en latin ni dans les langues latines, c'est à la limite plus proche de ce qu'on fait en allemand;

Malheureusement, je n'ai aucune connaissance en langues slaves. Comme tu l'auras compris, je ne considère pas l'Anglais comme telle, tant de ses mots sont de manière totalement évidente du vieux français… ce qui m'a d'ailleurs plus qu'un peu aidé à l'école. Ça à compensé le fait que j'en branlais pas une :p
Sans parler de sa quasi absence de conjugaison, ce qui, vu mon assiduité, n'est pas plus mal. Cela dis, je ne considère pas l'anglais comme une panacée: pour un français, il n'est pas toujours aisé de comprendre que le sens viens d'un assemblage de mot plutôt que d'un seul. J'imagine qu'un anglais se fera la réflexion exactement inverse.

De manière générale, sache, quand même, que je n'ai JAMAIS étudié le latin. J'ai bien, d'ailleurs, parlé d'impression, et pas plus. Les seules choses que je connais du latin, c'est parce que plus tard je me suis intéressé à l'étymologie, qui est très loin d'être une science exacte. Mon impression venais plus du fait que les mots sonnent comme ceux des langues plus franchement latines, type italien/espagnol (que j'ai fait semblant d'étudier quelques années) sans être exactement les mêmes.
Ceci dit, si un naturel d'une langue type chinois disais la même chose (que ça ressemble au mandarin), alors, ça confirmerait de nos témoignages réunis que le but souhaité est atteint: tout le monde comprendrais des bribes sans même l'étudier, donc fatalement l'étude serait triviale.

En tout cas, cette réponse, entres autres, me semble confirmer un détail: c'est une langue faite pour les européens. Tu indiques des mécanismes plus inspirés d'autres langues, mais je n'ai vu aucune référence aux langues plus… disons, «sudistes»: turquie, afrique, etc. Bien sûr, j'oublie d'autres régions du monde. Genre, je sais pas, mais le grec (pas une autre région du monde, mais juste, s'est-on posé la question?)?

Bref, non, pas si internationale.

Pour faire court: je ne «lis» pas les vidéos données en lien. Jamais.
En dehors de la sémantique, la raison est simple, très simple: une vidéo, ça gaspille un max de temps. En tout cas, moi, je peux lire plus vite un texte que si on me le récite, sans même parler du fait qu'écouter une vidéo dans une potentielle langue étrangère est bien plus ardu que la lire.
Je parle de langue étrangère, mais en fait, ça vaut aussi pour les accents, ou les micros mal réglés, ou… j'en passe et des meilleures, j'ai eu assez de mauvaises expériences à m'emmerder à «lire» une vidéo supposément intéressante pour au bout de 2H m'apercevoir avant la fin qu'en fait c'est juste creux ou ramassis de généralités.

Donc, les vidéos, c'est pour moi uniquement soit pour me distraire (machins streaming au contenu relativement superficiel), soit des conférences sur des sujets pour lesquels j'ai au moins quelques notions.
C'est sûrement très années 00 (ouai bon, 2000 quoi) mais je trouve ça plus efficace. En gros, je n'irai pas voir une conférence sur python, tandis que je pourrais apprécier une conférence C++, de la même manière que je fuis les tutoriels vidéo (rien que le fait qu'il soit impossible de faire une copier/coller pour vérifier un truc me gêne énormément).
De temps en temps, on à doit à un sous-titrage, le plus souvent automatique et qui ne veux rien dire… genre traduction google (Ce qui n'est pas décorrélé au final, mais c'est plus l'image qui m'intéresse ici).

Accessoirement, une vidéo, pour savoir quand elle à été créée, c'est la croix et la bannière. Pour un texte d'un site, c'est délicat, mais on peut s'en sortir un peu plus aisément. Et cette question est importante au sujet de l'obsolescence du sujet. Je veux bien entendre que l'espéranto n'évolue pas ou prou, mais dans ce cas, ça risquerait de ressembler dans mon esprit à l'interlangue dans mythale (un bouquin d'Ayerdhale, pas sûr que ce soit très connu), bref, pas spécialement flatteur.
Ça, c'est pour le lien vidéo, qui est une grande partie de ton commentaire.

Maintenant, clairement, j'ai un énorme doute sur le fait qu'ajouter 3H d'apprentissage/semaine d'une langue permettra de réduire d'au minimum 3H le reste des langues et, tu l'as dis toi-même, le temps d'apprentissage des maths.
Allez, citons l'autre lien:

On peut faire l'analogie de la flûte à bec, considérée comme une bonne introduction à l'apprentissage d'un autre instrument de musique.

Ah bon. Donne 200H à quelqu'un pour apprendre la flûte, puis 100H pour apprendre la guitare. Donne à un autre individu 300H pour apprendre la guitare. Selon cet article, le type qui aura appris la flûte sera le plus doué en guitare? j'en doute.
J'exagère bien sûr: oui, apprendre la flûte en 1er aide à apprendre la guitare, parce qu'il existe une partie commune: les partitions. Sauf que c'est valable à l'envers aussi.
Donc, oui, c'est corrélé, mais j'imagine, tu ne vois toujours pas le rapport?

Je peux me tromper, mais vos idées, bien qu'intéressantes, semblent avoir quelques problèmes de jugement. Par jugement, je ne remet pas en cause le votre, mais le fait qu'on ne peut être juge et partie. La confiance en l'humanité, ça va bien quand on est jeune, mais à un moment, il faut bien se rendre compte qu'on à tous un certain degré de pourriture (et je doute que le mien soit inférieur aux vôtres, juste au cas ou). L'accepter permets d'imaginer des choses plus gérable, peut-être?
En tout cas:

• Quid d'un utilisateur qui signalera un bug comme ouvert mais sans jamais confirmer sa résolution?
• De même, quid d'un projet qui ferme les bugs sans les avoir résolus?

Je ne parlerais même pas du fait que signaler un bug, c'est initier un échange, qui peut consommer pas mal de temps (et d'argent, donc) aux deux parties, et il n'est pas trivial de signaler un bug correctement: si on mets de côté les problèmes liés à la plate-forme (récemment, j'ai préféré faire un rapport de bug sur un forum, parce que j'avais un timeout sur le bugtracker lié… sur lequel j'étais surpris d'avoir déjà un compte!) il faut tout de même penser que tout le monde ne pensera pas à indiquer le numéro de build/version (et même, parfois, le dev ne fera pas attention à ce numéro, encore une expérience personnelle récente). Et je ne parle que de la version, pas du fait de décrire les étapes nécessaires à la repro du bug, qui peut être lié au reste du système.
Moi qui suis codeur, je tente toujours de faire attention à expliciter au maximum mon environnement, et c'est rarement suffisant. Pour un simple utilisateur, rien que d'être en mesure d'affirmer qu'il utilise windows 8 et pas 8.1 peut être délicat…

En tout cas, je pense que c'est la meilleure façon de vivre du code libre, donc si l'un de vous mets en place un tel système, alors, juste, bravo. Peut-être plus quand j'y serais prêt.

Il y a des DVD voire Blu-Ray de séries disponibles en espéranto ?

Je voudrai rebondir sur ce point. Sans la moindre prétention, les sous-titre, en l'occurrence japonais, m'ont appris à reconnaître quelques mots, avec le son en jap' et le sous-titre en français ou anglais.

De la a dire qu'il est possible d'apprendre une langue avec juste des sous-titre, non, ça ma paraît impossible à un adulte.
En tout cas, il me semble probable que le sous-titré, si tant est qu'au moins une langue est connue par l'interlocuteur, et, de préférence, celle qui est parlée et non écrite, est plus efficace pour répandre la culture de cette langue… et de ce pays, dernier point dont manque volontairement l'esperanto.

l'accusatif

Bon, ok, je suis sûrement le seul à oser demander ça sans (trop de) honte, mais, pourrais-tu me rappeler ce qu'est l'accusatif? Après avoir lu le reste de ta prose, je pense que je me plante plus qu'un peu…

Ma foi… pour ta gouverne, tu n'as pas éclairé qu'une seule lanterne. Je te remercie en tout cas pour ta vison de marx, que je ne connais que de nom.

il y a même des locuteurs dont c’est la langue maternelle.

Ça veut dire qu'il existe un pays dans lequel il s'agit d'une langue officielle, ou alors c'est juste un simple argot parlé dans une région?
Dans le second cas… hum, c'est plus une barrière qu'autre chose pour sortir de sa région, et ce serait dommage.

Pour le vocabulaire oui les racines sont probablement européano-centrée mais idem mieux vaut prendre une base que partir de rien.

Dans ce cas, pourquoi ne pas forker une langue existante, plutôt que d'en créer une nouvelle à partir de… rien? non, presque rien, parce qu'on ressent (en tout cas, j'ai ressenti dans l'exemple de l'article) une grosse influence latine. Ce qui est pire qu'européen, parce que c'est partial.
Ironiquement, si je n'y avais rien compris, j'aurai été plus indulgent. Moins ironiquement, je pense que l'esperanto n'a d'espoir que dans l'europe de l'ouest.

L’ido j’ai arrêté de me renseigner dessus dès que j’ai vu que ça remettait en cause le principe de base une lettre = un son

Ça, ça me semble sensé à première vue. Mais, j'ai une question qui me semble très pertinente (contrairement à mon ton, qui est plutôt impertinent voire provocateur): la ponctuation, au visio-oral, c'est à dire en face à face, est très simple à gérer: ça va avec le souffle, et l'expression faciale.
Alors que, même si l'écrit est trop complexe sur certains points dans certaines langues, il permets potentiellement à ceux qui le maîtrisent de passer les mêmes sentiments à leurs lecteurs, et cela inclue les lecteurs distants de plusieurs décennies. Ça s'appelle la poésie, entres autres. Qu'est-ce que l'espéranto peut m'apporter de ce point de vue?

De toute façon, apprendre une langue n'est quelque chose que les gens sont enclins à faire, et les méthodes pour mesurer la simplicité de maîtrise d'une langue me sont totalement inconnue. Peut-être serait-il bon, pour inciter les gens, de leur prouver qu'avec une telle langue ils peuvent se faire comprendre partout, y compris dans les pays parlant actuellement partiellement anglais et n'ayant pas accès à la connaissance comme nous?

Pré-scriptum (j'aurai pu dire PS, mais ça aurai été étrange en début de message): je doute que tout le monde connaisse le sens du terme propédeutique. Moi, je ne savais pas que ce mot existait avant de le lire ici… et j'aurai été incapable de le deviner. Bref.

Si, c'est exclusif. Les enfants ont (en moyenne souhaitable, si on considère 8H de sommeil) moins de 16H utilisables par jour pour acquérir de nouvelles connaissances. Ajoutes dessus le fait de devoir manger (disons, 2H par jour), de pouvoir faire autre chose que bosser (mettons, 25% du temps passé à ne pas travailler, sachant qu'il reste que 14H:) 10H30. Et je suis sûr que je surmène encore.
Bref, 10H30 pour enseigner la langue natale (français ici), la culture natale (histoire, notamment, mais aussi géographie du pays par exemple), les maths, les bases de la science (physique, chime, biologie, informatique, et j'en oublie peut-être), le sport (j'avoue, si j'avais pu, j'aurai aimé éviter, surtout vue ma condition à l'époque), une langue étrangère [u]actuellement utile[/u], ajouter une langue potentiellement inutile me semble une mauvaise idée, parce qu'alors ça ne fait que 1H30 par matière en moyenne.
Compte tenu de l'importance de certaines matières déjà en problèmes de nos jours (genre, la langue natale… ici ça va, les gens savent parler, mais lire ailleurs pique les yeux, et quand j'achète un livre, je suis souvent tenté d'acheter des lunettes pour y voir flou… histoire de ne pas voir les fautes!)

Je ne suis pas du genre à dire qu'on devrais éviter de fatiguer les enfants, mais empiler les matières à maîtriser est le meilleur moyen pour qu'ils ne puissent en maîtriser aucune, donc, si, c'est un peu exclusif: ajouter une langue qui, dans les faits, est quasi-inutile, ne me semble pas une bonne chose. Par contre, ajouter cette langue comme langue tertiaire potentielle, au lieu de l'espagnol ou de l'allemand (niveau collège à mon époque) ok. Mais pas avant. Et même (surtout?) au collège, il faut que ce soit volontaire de la part de l'élève: honnêtement, je ne voulais pas apprendre l'espagnol, et de nos jours, je n'y connais rien. C'était pourtant ma LV2.

En tout cas, avant d'enseigner une nouvelle langue, il serait déjà bien que les enfants apprennent correctement une langue.
Je ne pense pas être le seul ici à avoir du échanger avec des gens qui ne maîtrisent pas même leur langue natale, et je pense que maîtriser une langue est nécessaire pour arriver à être décent dans d'autres.

Juste pour insister sur le fait que… ce lien, il vaut le coup. D'ailleurs, ça fait longtemps que j'avais pas vu un lien de dtc, ça file un coup de vieux… ou de vieille, selon les goûts :p

En gros, tu dis qu'on ne peut prouver sans enfreindre l'éthique de notre société actuelle qu'un fait est de nature génétique ou éducationnelle, incluant les préférences pour les jeux bleus pour les garçons et roses pour les filles?
Ceci n'étant, bien sûr, qu'un exemple archétypé.

Moi, ce qui m'intrigue, c'est une question assez fondamentale. Comment pourrait-on faire une société juste dans laquelle il n'y aurait pas de différence entre les individus mâles et femelles?
Parce que clairement, c'est hyper complexe.
Le cas typique, c'est la fameuse «la même paye»? Ok. Je suis pour. Une société ou les gens payent et sont payés égalitairement par individu, sans compte tenu du sexe. Super.
Déjà, commence par pénaliser nos employeurs. C'est ce que vous faites depuis des années? Oups. Bien. Maintenant, pénalises donc nos… assureurs voiture. Et oui, un mâle français paye plus cher d'assurance qu'une femelle de même nationalité à priori.
Bien entendu, les femmes peuvent avoir des enfants (inaptes au travail pendant plusieurs mois) y compris au pire moment pour l'employeur? En quel honneur cela ne devrait-il pas être pris en compte (dans le modèle de société actuelle)?

Je ne suis pas féministe. Je ne suis pas non plus masculiniste. Je suis plus égalitariste, mais je n'irai pas proposer que le sexe n'apparaisse nulle part sur nos ID et qu'on doive se planquer dans des toges amples et se raser tous les jours pour pas qu'on puisse savoir si on est un homme ou une femme!!!

Je suis d'accord sur le fait que les lois doivent promouvoir une égalité partielle entre les sexe.
Oups, j'ai dit partielle? Oui.
Pourquoi? Parce-que les femmes peuvent enfanter, et que ça implique un temps d'inaptitude au travail, pendant lesquelles elles doivent être protégées, c'est un fait, sinon l'humanité est juste foutue. Science mise à part (sinon, elles peuvent se passer des hommes et les hommes d'elles).
D'un autre côté, des études prouvent que les femmes vivent plus longtemps que les hommes. Objectivement parlant, les femmes devraient donc travailler plus longtemps que les hommes avant la retraite? Ou pas? C'est un sujet vraiment complexe, et quand je vois des boulets de pseudos-féministes à deux balles rabattre ça à "les filles jouent-elles à des FPS ou pas?" ou "doit-on dire «une maire»" j'avoue, ça me gave parce que je me dis qu'en terme d'égalité des sexes il y a autre chose de plus important à régler.

D'ailleurs, peut-être serait-il possible de les régler plus facilement si on arrêtait de considérer que les citoyens doivent être en couple, et donc d'arrêter de sanctionner ceux qui ne le sont pas?
Ou de rémunérer ceux qui le sont, ainsi que de rémunérer au nombre de gosses alors que l'on n'est plus dans la période de reconstruction après-guerre ou ces lois étaient nécessaires?
Pas mal de problèmes liés au théorético-classique Homme+Femme>Homme>femme pourraient être résolus aisément… mais ça choquerait la morale. CF le meilleur des mondes par exemple.

Tout d'abord, bienvenue.

En préambule, j'aimerai expliquer quelques petits détails:

• la «communauté» linux est consituée de gens assez enthousiastes, à tord ou à raison, et comme certains l'ont dit par le passé, le QI d'une foule est égal à celui de son plus faible individu divisé par le nombre d'individus :)
• Mint est dérivée soit d'Ubuntu, qui est elle-même dérivée de Debian, soit directement de Debian (LMDE, je crois?). Debian étant réputée pout n'embarquer que des versions de logiciels un peu âgées et uniquement libres par défaut (donc, pas de pilotes propriétaires, ce qui peut poser des problèmes), Ubuntu est née pour essayer de résoudre ces soucis. Je ne connais pas les motivations derrière Mint, mais je suppose que c'est lié à une protestation contre le fait qu'Ubuntu soit possédée par une entreprise.
• Linux, l'OS quotidien de la plupart des gens ici, est un morceau d'une distribution. Les distributions ont d'autres morceaux, que sont les environnements de bureau, autrement dit, comment tes applications sont affichées à l'écran et comment tu peux interagir avec elles.
• L'environnement de bureau n'ayant rien à voir avec Linux, très souvent il est possible d'utiliser n'importe lequel avec ta distribution de façon très simple: il suffit de l'installer.

Maintenant que ces points sont à peu près établis (j'ai essayé d'être accessible, donc j'en ai enlevé un peu) si tu nous dis quelle version de windows tu as le plus apprécié au niveau interface, on pourra te dire quel environnement de bureau y ressemble le plus. Celui-ci sera très certainement installable sous Ubuntu. Oui, c'est compliqué, d'avoir le choix, on est tous passés par là :)
Personnellement, j'aimais beaucoup les windows 9x à mes débuts, donc j'ai vite adopté XFCE, puis LXDE. Je ne me rappelle pas trop de KDE (qui était de mémoire plus proche d'un windows récent, mais aussi plus lourd que XFCE, question de goût) ni de gnome (qui ressemblait plus aux rares systèmes mac OS que j'ai pu voir, par défaut). Quant à unity, je n'ai jamais fait l'effort de regarder, depuis j'ai «forgé» mon propre environnement, qui n'a, d'ailleurs, plus rien à voir avec windows :D mais il faut un peu d'expérience (et d'«amour») pour ça.

Pour ton autre question, compte tenu du fait que tu es un débutant et que du coup tu ne sais pas comment le tout fonctionne, je pense que c'est le bon choix.

Ceci étant dit, je pense que mettre le /var sur le HDD ne serait pas une mauvaise idée, ce dossier contenant en effet pas mal de fichiers temporaires ou rarement utilisés tels que des journaux système et caches applicatifs.
En fait, pour être précis, c'est surtout /usr qui me semble utile sur le SSH, parce que c'est là ou résident les logiciels installés par Debian et ses filles (dont Ubuntu et Mint font partie… les linuxiens sont un peu comme les hobbits, on aime connaître la généalogie de nos systèmes :D). Ce n'est pas forcément vrai sur toutes les distributions (une distribution est un «windows» à part entière).

Oui, dans ce cas, l'écran laisse l'utilisateur saisir un texte et l'affiche, ce qui est l'un des cas que j'ai décrit.

Quant à l'auteur, je doute qu'il ait encore la commande dans son historique :)

Justement, je l'ai fait, le test. Enfin, j'ai copié/collé le cat cité plus haut que je suppose avoir un espace insécable.

C'est ainsi que j'ai eu l'un des cas que j'ai décris, mais je reconnais avoir supposé les 2 autres, en fonction de l'implémentation de cat et du shell (qui peut très bien avoir implémenté cat en built-in et dans ce cas, il est délicat de prédire le comportement).

Tiens, un truc qui m'interpelle au passage :

Tu te focalises trop sur la tension, qui ne signifie pas grand chose par elle même.
Si tu as 220V avec 0.01A, ça te fait 2.20W, et je doute que tu arriveras à faire fondre un fil avec ça, ou alors il est vraiment très, très fin, style comme un cheveux, voire plus (dépend du matériau, forcément).

La tension, c'est la «vitesse» de l'électricité. L'intensité, c'est le «volume» et la puissance le «débit». C'est pour simplifier, parce que les gens comprennent souvent plus aisément l'hydraulique que l'électricité. Mais en gros, parler juste de tension, c'est comme parler juste de vitesse pour comparer des débits: ça n'a aucun sens. Ce qu'il te faut, c'est vitesse * volume, autrement dit: le débit, la puissance.

Pour ce qui est des ordis, ainsi que de pléthore de machines actuelles, le transformateur ne fait pas que de conversion de tension/intensité/puissance.
Par exemple, dans le cas du PC, il s'agit d'une alimentation à découpage, qui convertit un signal alternatif de 50Hz & 220V (en France, ailleurs ça peut être différent) en signal alternatif de 12V continu.
Ou pas.
En fait, ton alim PC, elle fournit du 12V, mais pas que (il y a aussi du 5V, et je ne saurai être catégorique sur le fait qu'il n'y ait rien d'autre, sans parler du fait que certains de ces signaux continus sont ensuite convertis en signaux carrés de diverses fréquences!).
Pour faire le lien avec les réseaux informatiques, ça reviens à changer le protocole de niveau 1 du modèle OSI.

La seule solution que je vois à ton problème, qui est de réduire le nombre d'adaptateurs dans ton chez toi, et ainsi de réduire les pertes énergétiques (probablement négligeable, bien que je n'aie aucune preuve) liée aux transformations, serait d'installer une alimentation à découpage sur une des sorties de ton compteur électrique, qui ait assez de sorties aux VA (Volt/Ampères) corrects pour les machines qu'elle doit alimenter. Ah, et, bien sûr, elle doit formater le signal correctement à chaque fois aussi (c'est pour ça que je n'ai pas parlé de Watt, la puissance dépendant de la forme du signal).
Parfois ça sera du continu, parfois de l'alternatif, parfois des trucs exotiques, et je ne te parle même pas des horloges.
Juste au cas où, il te faudra aussi virer les adaptateurs/tranformateurs intégrés à tes machines, puisque ce serait fait en aval et donc incompatible.

Je parie personnellement que le résultat sera bien plus coûteux à maintenir que le modèle actuel.
Je ne parle pas qu'au niveau financier/industriel, mais aussi au niveau écologique.
Chaque signal devra voyager sur un câble différent et, si on admets que tu n'as pas de triphasé chez toi (c'est assez probable, de nos jours, chez un particulier), ça te fera 2 fils de cuivre par type de signal, chacun étant blindé (ça se fait en général avec de l'aluminium, peu cher), et il est probable que tu auras besoin de répétiteurs également.
Notes d'ailleurs que la faute n'est pas à EDF, mais bien à celui qui à fait la distribution électrique dans ta maison. Ou alors tu souhaites que EDF fournisse du 5V/12V continu dans les lignes haute tension? Dans ce cas, je n'oserais affirmer que tu ne sais pas de quoi tu parles, parce que je n'ai qu'un vague souvenir, mais il me semble bien que si justement le signal sur 50H alternatif à été choisi, c'est pour limiter les pertes par effet joule sur l'énorme longueur de câble qui te relie à la plus proche centrale.

Mais revenons-en au modèle local, «LAN» formé par l'endroit ou tu vis (toi, ou moi, ça ne change pas grand chose au final).

Moi, je ne pense pas que la perte énergétique (effet joule*) engendrée par la transformation du signal au plus près du consommateur + la perte induite par 2 fils par échelle de puissance (en gros, les lumières, les chauffages, les prises. Je simplifie, certes, j'omets volontairement la terre et le signal jour/nuit, et peut-être d'autres, pas sûr, suis pas électricien, malgré que j'aie étudié l'électronique) soit plus coûteuse que la transformation généralisée en amont + la perte induite par 6 fils (tu auras besoin de l'alternatif 220V pour les machines de puissance, mais aussi du 12V et 5V continus pour l'électronique, et c'est le minimum, je simplifie ici aussi) par échelle de puissance + l'amplification nécessaire à la répétition de signal. Parce qu'un signal trop faible deviens flou, et dans le cas par exemple d'un signal carré, ça peut transformer un 0 en 1, et vice versa.
Il me semble au final bien plus simple de former un ensemble de signaux à partir d'un seul signal à peu près sinusoïdal d'à peu près 50Hz et d'environ 220V (ben oui, avec les pertes et les déformations dues à divers paramètres, telles que la proximité de machines de puissance type machine à laver, on est jamais sûrs du signal exact en entrée) que de devoir traiter un faisceau de signaux peu fiables.

En fait, l'électricité, c'est comme le code: il ne faut jamais faire confiance à l'arrivée si on veut éviter de tout faire péter.

Conclusion: as-tu une idée ne serait-ce que vague de comment les machines électriques fonctionnent?

• le principe même du chauffage électrique soit dit en passant (l'énergie sous forme d'électricité se transforme en chaleur dans certaines conditions)… la seule chose qui change dans les chauffages économiques, c'est s'ils sont capables de:

1. stocker l'énergie pendant les périodes creuses (ce qui est aussi écologique sur le modèle global dans certaines conditions car ça permets de limiter le nombre de centrales nécessaires en moyenne),
2. répartir correctement la chaleur dans les bonnes pièces aux bons moments (ce qui nécessite une soufflerie, bien souvent…) et
3. Rien. Vraiment. C'est tout.

donc ça me fait marrer quand j'entend parler de chauffages qui consomment moins: c'est de la pure foutaise.