J'ai eu aussi ce genre de problème sur fnac.com : lien manquant pour télécharger le livre (oui, manquant, pas seulement dysfonctionnant !).
En revanche, je n'ai pas réussi à contacter l'assistance (tu as eu beaucoup de chance !).
En googlant un peu j'avais fini par comprendre que je trouverais le lien sur le site de Kobo. Soit.
La moralité : acheter un e-book en passant par fnac.com semble très risqué. De toute façon, si j'ai bien compris, ce n'est qu'une façon indirecte d'acheter chez Kobo.
En ce qui concerne ADE, le logiciel fonctionne en effet très bien sous wine, mais
- pas la dernière version d'ADE, j'ai cru comprendre, donc la dernière version du DRM est incompatible avec Linux (si on souhaite lire sur le PC) ;
- et l'USB pour envoyer sur la liseuse ne marche pas, il me semble aussi.
2017 rentre dans une calculatrice, 20172017 aussi,
Attention 20172017, c'est déjà une opération.
mais le résultat te donne une erreur.
C'est un bon comportement pour une calculatrice de base, ça rejoint ce que je disais à la fin. Pour un logiciel de calcul formel, on peut laisser 20172017 tel quel, en espérant qu'une simplification ait lieu plus tard, ce n'est pas pire que de laisser eπ tel quel.
On parlait bien de calculateur formel ? (tu embrayes sur la calculatrice là).
Je parlais juste des possibilités théoriques pour tout calcul effectué par un ordinateur concret. La calculatrice n'est qu'un cas particulier important.
la somme des
Ouhla, on parlait de nombres rationnels ! Cela dit, là encore, il est tout à fait possible de programmer le logiciel de telle sorte qu'il donne (une sur-approximation de) les marges d'erreur.
Ce que je voulais dire, c'est qu'à défaut de promettre de réussir tous les calculs, il est possible d'avertir l'utilisateur qu'un résultat est (ou est susceptible d'être) aberrant. Dans les cas simples, l'utilisateur averti s'en doutait déjà, mais ça ne saute pas forcément tout le temps aux yeux (cf. calcul à virgule flottante dans les langages de programmation classiques).
Aucun système de calcul basé sur les machines actuelles ne peut prétendre ne serait-ce que de manipuler correctement les réels de [0;1].
Ce genre d'énoncé est bien trop flou. Pris tel quel, il est trivial (cf. fonctions non calculables). Pourtant, avec quelques aménagements, on peut avoir des systèmes de calcul corrects et utiles (p. ex. : restriction aux opérations continues calculables et résultats avec intervalles d'erreur).
Bon de toute façon, on ne parlait pas de nombres réels.
Si tu veux pinailler, pinaillons. Ca fait très, très, très peu d'entiers "ceux dont l'écriture est limitée par la mémoire de la machine" puisque c'est fini de chez fini ! C'est peanuts :)
C'est peanuts, mais ça inclut les nombres qu'un utilisateur humain entre dans une calculatrice (= rationnels décimaux avec nombre de chiffres à taille "humaine").
Pouvoir faire des calculs exacts sur cet ensemble-là est un besoin récurrent.
Ainsi, pour te paraphraser, on est dans le sujet du journal.
La promesse de l'infini est une illusion totale et ce n'est d'ailleurs absolument pas celle tenue par les logiciels de calcul formel munis de librairies d'arithmétique multiprécision.
Loin de moi l'idée de promettre l'infini.
Il est en revanche possible de promettre de ne pas retourner de résultat faux ou imprécis, pour peu qu'on s'autorise à retourner "je ne sais pas", quand on sort (ou risque de sortir) des capacités de la machine pour la représentation utilisée.
On peut utiliser des librairies qui augmentent le nombre de chiffres de la mantisse et donnent l'illusion d'une précision infinie, ce qui est évidemment totalement faux.
Certes. Mais il n'y a pas que les représentations en virgule flottante dans la vie.
Avec d'autres représentations, il est tout à fait possible de réaliser des calculs exacts avec n'importe quels nombres rationnels (limités seulement par la mémoire de la machine). En effet, dans toute base, un rationnel admet une représentation finitaire, par exemple :
- sous la forme d'une fraction d'entiers,
- ou bien sous la forme d'un début de développement et d'une période (séquence de chiffres qui se répète à l'infini).
Dans les deux représentations, on peut implémenter les opérations usuelles. C'est moins efficace que des flottants (même des "gros" flottants), mais absolument pas impossible.
la valeur de l'entier 101090 n'est pas représentable en machine
Pour pinailler, c'est faux aussi : nous venons tous deux de le faire (ok, je botte en touche : une séquence aléatoire qui aurait autant de chiffres, elle, ne serait pas représentable).
Je ne connais pas ce monsieur, encore moins le fond de sa pensée et ce n'est qu'une interview avec ses contraintes de format. Et encore, le sujet de l'intelligence artificielle n'est qu'une toute petite partie de l'article.
N'empêche qu'encore une fois, on a l'impression de voir quelqu'un qui essaye de se rattraper aux branches pour désespérément trouver et défendre quelque propriété qui serait le "propre de l'homme" à grands renforts de jugements d'autorité.
Comment parler d'intelligence, de conscience, de sentiments, sans entrer dans les principes font du cerveau humain ce qu'il est et sans entrer dans le fonctionnement de l'intelligence artificielle ? Les mécanismes d'apprentissage et de renforcement ne sont-ils pas similaires ? Dans les deux cas, les phénomènes émergents ne prennent-ils pas le pas sur la physique des composants de base (neurones, transistors, … ) ?
Bien sûr on n'a pas encore programmé d'IA capable de faire l'ensemble de ce que peut faire un cerveau humain.
Mais voilà, la problématique peut être formulée de façon scientifique. On peut donc essayer de l'aborder et de se l'expliquer par des procédés d'ordre philosophique, si on veut (c'est même très intéressant), mais une réponse non basée sur des arguments scientifiques n'a que peu d'intérêt.
Où est-ce que Gufo se situe par rapport à Ammonite-Shell (un shell UNIX basé sur le REPL Ammonite pour Scala) ?
Ce shell, c'est en gros une REPL Scala avec quelques fonctions et facilités (DSL) pour interagir avec le système (notamment exécuter des commandes externes). Donc on y retrouve toutes les spécificités de Scala : langage objet et fonctionnel, sûreté de typage, etc.
L'inconvénient (par rapport à bash), c'est que du coup, c'est plutôt verbeux pour faire les choses simples.
Tout à fait. D'où les modalités entre parenthèses.
c'est ce qui se rapproche le plus sémantiquement de l'asm
Oui, c'est toujours l'argument de la facilité, que j'entends. Toujours est-il que la valeur ajoutée est plus faible que si on avait traduit vers un langage capable d'abstraire efficacement les différentes entités du jeu (favorisant la ré-utilisabilité, l'extensibilité et la maintenabilité, etc. etc. je ne refais pas tout le topo). Évidemment, ce genre de traduction ne peut pas encore se faire de façon automatique (ça relèverait probablement du domaine de l'IA : reconnaissance de motifs, etc.), donc il faudrait plus d'huile de coude (initialement).
C'est du jeunisme bas de gamme.
Peut-être le terme antédiluvien est-il un peu provocant. Mais le propos était juste de réfuter l'argument comme quoi on ne pouvait pas comparer l'ancien et le nouveau. Cela n'est pas du jeunisme, mais du pragmatisme : la question se pose très concrètement à chaque fois qu'il faut faire le choix d'une technologie pour arriver à un but donné.
Non mais, en fait, je suis d'accord avec tout ça !
Ma question initiale était juste pourquoi le C (sous-entendu, pour un projet personnel pour se faire plaisir, qui ne fait partie d'aucun des domaines de prédilections du C que tu listes, c'est plutôt un plaisir masochiste !). Je me demandais s'il n'y avait pas une raison un peu profonde.
Mais vraisemblablement, la réponse ne va pas plus loin que "bah, c'était facile à faire avec asm2c".
Premièrement, chaque fois qu'on parle de C ou C++, on a des rabat-joie qui sont là pour nous rappeler à quel point ce sont de mauvais langages et qu'il faut absolument s'excuser d'utiliser ces langages et qu'on est tellement bête de ne pas utiliser des langages top moumoute qui font le café.
Et à chaque fois qu'on ose critiquer le C ou le C++, il y a une meute de programmeurs qui se sentent insultés et nous tombent dessus à bras raccourcis.
Au passage, je n'a jamais dit le C saynul ou saylemal. J'ai juste remarqué qu'il y avait mieux (à nuancer selon le domaine, bien sûr, mais plus ça va, moins je vois où se trouve le pré carré du C).
Par exemple, je pense que C et le C++ (surtout le C) sont excellents d'un point de vue pédagogique car ils permettent de mettre en évidence les mécanismes sous-jacents à tout langage de programmation, moderne ou non (et non je n'ai pas été maltraité par un professeur de C ou C++, merci bien !). Notamment, beaucoup de bonnes idées de Rust (ex. : pointeurs intelligents) proviennent de C++ (le principal tort de C++ étant de permettre d'utiliser aussi les mauvaises idées trop facilement !). En plus leur syntaxe reste l'inspiration principale de celle des langages modernes, donc on n'est pas dépaysé (et on perd moins de temps sur ces aspects annexes).
Ce que je dis plus haut, c'est que C et C++ sont intéressants pour enseigner la théorie des langages de programmation. Par contre, je ne les conseillerais pas pour apprendre à (bien) programmer : ces langages sont bien trop permissifs.
on compare des choux et des carottes, c'est-à-dire des langages qui ont été conçus dans les années 70-80 avec des langages qui ont été conçus il y a une dizaine d'année […]
Et alors ?
En quoi cela est-il un argument pour défendre l'utilisation de ces outils antédiluviens ?
Si je compare les mérites de la charrue et de la moissonneuse-batteuse, dans le contexte de quelqu'un qui monterait une nouvelle exploitation agricole, est-ce que tu lui conseillerais la charrue parce qu'elle fonctionne avec une foultitude d'architectures exotiques, qu'elles ont été maintes fois normalisées, et qu'elles sont rétro-compatibles avec les champs égyptiens, babyloniens et sumériens ?
Et pendant ce temps…
(Note : il ne s'agit pas de conversion automatique vers Rust, mais de l'écriture de bindings Rust pour GStseamer. Néanmoins, c'est encore un symptôme de l'inadéquation/l'obsolescence du C ressentie par plus en plus de développeurs !)
On utilise souvent le C, soit parce qu'on connaît déjà, soit parce qu'on travaille sur un projet qui était déjà écrit en C.
Le reste du temps (hors niches, dont, je pense, le développement d'un jeu à la Bomberman ne fait pas partie… mais je peux me tromper !), il y a probablement assez peu de raisons valables de démarrer un nouveau projet en C quand on connaît mieux.
Concernant les autres langages, je ne pense pas qu'il en existe un seul qui empêche quelqu'un de vraiment déterminé à mal programmer. Disons que quand-même tous les langages ne sont pas aussi convaincants les uns que les autres sur cet aspect-là !
La proximité sémantique a facilité le portage vers C, mais ne justifie pas de son utilité.
Je ne propose pas de langage, ça dépend des préférences et objectifs des développeurs.
Si un effort de portage a été fait, j'imagine que c'est qu'ils comptent améliorer/ajouter des fonctionnalités. Donc n'importe quel langage moderne favorisant un style de programmation sain et maintenable aurait été un meilleur choix que C (qui n'est au fond qu'un assembleur un peu plus lisible et multi-plateforme).
Pour un bomberman-like, sur les machines d'aujourd'hui (fixes comme mobiles), on n'a plus vraiment besoin de faire de micro-optimisations, donc, selon moi, le meilleur compromis se situerait plutôt dans le (très) haut niveau (je verrais probablement objet+fonctionnel… mais après, chacun ses préférences).
Indépendamment du paradigme du langage, un atout de poids serait la possibilité de compiler vers différentes plateformes natives fixes comme mobiles, mais aussi vers JS ou WebAssembly pour en faire une appli web (mais je crois qu'on peut le faire avec le C, via Emscripten).
Sans vouloir troller (bon, un peu quand-même : les questions du genre pourquoi tel ou tel langage… c'est toujours trollogène), en gros, on passe de la pierre taillée à la pierre polie ?
Pour faire les questions et les réponses, j'imagine que de toute façon, un outil automatique ne peut pas inventer un programme "haut niveau" depuis de l'assembleur, alors que vers le C, ça doit se faire "tout seul".
Mais est-ce que les auteurs envisagent cette version en C comme
- une fin en soi ?
- une démo pour asm2c ?
- ou bien seulement comme une étape obligatoire avant de passer à un langage de notre millénaire ?
Mais il faudrait sans doute compléter un peu. La liste complète des nouveautés est ici.
Dans les nouveautés sympathiques (non citées dans le journal), je vois aussi :
- les méthodes privées dans les interfaces (pour partager le code entre méthodes default ou static)
- les fabriques statiques pour les collections immuables : Set.of(…), List.of(…), Map.of(…)
- implémentation de Reactive Streams (classe Flow)
Bon bien sûr, tout le monde ne s'intéresse pas aux mêmes fonctionnalités !
Le principe est le même, on enrichi notre type (ici notre classe), avec des informations qui n'ont pas de rapport avec les données contenues, mais qui permettent d'indiquer au compilateur ce que l'on autorise ou non. Bizarrement, je vois rarement de code java mettre en œuvre cette pratique, qui me paraît pourtant être une manière presque naturelle…
Je suis peut-être un peu naïf, mais dans les langages objet, l'idiome naturel pour arriver à cette fonctionnalité c'est d'utiliser l'héritage (à moins que je n'aie pas compris ce qu'on cherchait à faire), exemple en Java :
abstract class A {
/* vraies fonctionnalités */
}
final class B extends A { /* rien de particulier */ }
final class C extends A { /* rien de particulier */ }
Clairement, on peut avoir des méthodes acceptant B mais pas C ou vice versa.
B et C ne jouent que le rôle de marqueurs (comme les types fantômes, non ?) et A, étant abstract, ne peut pas être instancié directement tel quel (tout comme les types dépendants en OCaml ou ailleurs).
Bien sûr on peut aussi faire avec des génériques, mais ça me paraît moins naturel d'introduire un paramètre de type qui ne sera jamais utilisé à l'intérieur de la définition du type.
Plus haut, dans le journal, je vois la mention "autrement qu'en faisant des classes". Je ne comprends pas cette remarque. Les classes sont la façon normale, parfois la seule, de définir la structure d'un type dans un langage objet (on pourrait remplacer "classe" par "interface", mais j'imagine que ça ne change rien à la remarque). On ne peut pas reprocher à un langage non-fonctionnel de ne pas disposer de syntaxes de définition de type à la façon "langage fonctionnel".
Je n'en suis même pas à parler de l'existence de nombres transcendants, seulement de celle de nombres non entiers.
Mais c'est vrai que ce que j'ai montré, c'est plutôt : si on choisit une définition de nombre incluant tous les rapports de longueurs de figures géométriques construites selon telle ou telle règle (permettant de tracer des cercles), alors il existe des nombres non entiers (et puis par extension, sans ajouter d'axiome, on devrait pouvoir prouver assez facilement qu'il existe des nombres non rationnels et puis, moins facilement, des nombres non algébriques/transcendants).
L'existence dépend de la réalité considérée (pour ça qu'en mathématiques on quantifie toujours à l'intérieur d'un ensemble donné).
En métaphysique, on peut aussi faire ce genre de raisonnement. Mais pour que ça ait du sens, il faut que le domaine considéré et les axiomes introduits correspondent bien à la réalité physique (ou au moins ne la contredisent pas).
Il n'y a pas de morale athée, pas dans le sens où les athées sont immoraux, mais dans le sens où il n'y a pas une morale athée et que les athées ont souvent tendance à essayer de réfléchir chacun de son côté pour bâtir son système moral.
Cela dit, je pense que ce n'est que très partiellement vrai. Être athée ne fait pas automatiquement de soi un grand penseur et il existe des bel et bien des systèmes moraux athées "prémâchés" qui sont communs à des grands groupes d'êtres humains (ex : morale communiste, etc. ).
J'aimerais revenir sur ce point, parce que « prouver par la structure réelle », ça veut dire quoi ?
Je ne voulais pas directement opposer raisonnement mathématique et physique.
Je restais dans le cadre de la logique mathématique, dans lequel une assertion peut-être soit être fausse en dehors de tout contexte si elle est auto contradictoire, soit être fausse après interprétation dans un certain cadre sémantique. Ce serait, par exemple, une formule de logique de premier ordre, cela correspondrait à choisir le domaine des variables et la valeur des différents symboles de constantes, fonctions et prédicats. Dans le cas de la définition de Dieu, cela consisterait à la plaquer dans le monde réel avec tout ce qu'on sait de lui, pour se rendre compte qu'elle n'est pas compatible.
Il y a plusieurs façon de prouver la non-existence de quelque chose.
J'en vois deux principales : 1, comme dans tes exemples, chercher une contradiction logique (souvent indépendante de la structure réelle dans laquelle on interprète l'assertion à prouver), 2, dans un monde fini (ou du moins avec une certaine notion de finitude), effectuer une recherche exhaustive infructueuse.
Pour l'existence de Dieu, le problème est que la définition est souvent bien trop vague pour arriver à une contradiction logique, sauf à fixer une définition très stricte et très forte : omnipotence absolue, omniscience, faiseur de miracles, etc. Mais là, il n'y a que deux possibilités : soit on est membre (rigoriste) du culte qui décrit Dieu exactement de cette façon, et la logique passe au second plan, soit on ne l'est pas… et ça ne vaut pas plus le coup de réfléchir à l'(in)existence de ce dieu qu'à celle du Père Noël ou du Monstre Spaghetti Volant (et puis c'est risquer de se fâcher inutilement avec les membres dudit culte !).
Pour des définitions moins contraintes, il reste alors la recherche exhaustive, mais le terrain de recherche étant l'univers qui, bien que fini, reste largement inaccessible. On se trouve alors dans une impasse.
Par ailleurs, même si on arrive à "explorer" l'univers physique par une expérience réelle ou par la pensée, alors apparaît la botte secrète imparable consistant à dire que Dieu ne se manifeste pas dans le plan physique. Mais là, la discussion peut s'arrêter, vu que l'existence ou non de ce Dieu n'a aucun impact sur le monde qu'il était censé devoir expliquer, ce n'est plus qu'une hypothèse inutile, mais qui ne coûte rien non plus.
Finalement, prouver l'inexistence de Dieu est soit inintéressant, soit impossible, soit inutile, en fonction du type de Dieu considéré.
# #metoo
Posté par Aldoo . En réponse au journal Galère lors de l'achat d'un livre numérique. Évalué à 6. Dernière modification le 24 janvier 2018 à 13:43.
J'ai eu aussi ce genre de problème sur fnac.com : lien manquant pour télécharger le livre (oui, manquant, pas seulement dysfonctionnant !).
En revanche, je n'ai pas réussi à contacter l'assistance (tu as eu beaucoup de chance !).
En googlant un peu j'avais fini par comprendre que je trouverais le lien sur le site de Kobo. Soit.
La moralité : acheter un e-book en passant par fnac.com semble très risqué. De toute façon, si j'ai bien compris, ce n'est qu'une façon indirecte d'acheter chez Kobo.
En ce qui concerne ADE, le logiciel fonctionne en effet très bien sous wine, mais
- pas la dernière version d'ADE, j'ai cru comprendre, donc la dernière version du DRM est incompatible avec Linux (si on souhaite lire sur le PC) ;
- et l'USB pour envoyer sur la liseuse ne marche pas, il me semble aussi.
[^] # Re: Rien de surprenant
Posté par Aldoo . En réponse au journal [Humour] vers un monde différent. Évalué à 3.
Attention 20172017, c'est déjà une opération.
C'est un bon comportement pour une calculatrice de base, ça rejoint ce que je disais à la fin. Pour un logiciel de calcul formel, on peut laisser 20172017 tel quel, en espérant qu'une simplification ait lieu plus tard, ce n'est pas pire que de laisser eπ tel quel.
Je parlais juste des possibilités théoriques pour tout calcul effectué par un ordinateur concret. La calculatrice n'est qu'un cas particulier important.
Ouhla, on parlait de nombres rationnels ! Cela dit, là encore, il est tout à fait possible de programmer le logiciel de telle sorte qu'il donne (une sur-approximation de) les marges d'erreur.
Ce que je voulais dire, c'est qu'à défaut de promettre de réussir tous les calculs, il est possible d'avertir l'utilisateur qu'un résultat est (ou est susceptible d'être) aberrant. Dans les cas simples, l'utilisateur averti s'en doutait déjà, mais ça ne saute pas forcément tout le temps aux yeux (cf. calcul à virgule flottante dans les langages de programmation classiques).
Ce genre d'énoncé est bien trop flou. Pris tel quel, il est trivial (cf. fonctions non calculables). Pourtant, avec quelques aménagements, on peut avoir des systèmes de calcul corrects et utiles (p. ex. : restriction aux opérations continues calculables et résultats avec intervalles d'erreur).
Bon de toute façon, on ne parlait pas de nombres réels.
[^] # Re: Rien de surprenant
Posté par Aldoo . En réponse au journal [Humour] vers un monde différent. Évalué à 2.
C'est peanuts, mais ça inclut les nombres qu'un utilisateur humain entre dans une calculatrice (= rationnels décimaux avec nombre de chiffres à taille "humaine").
Pouvoir faire des calculs exacts sur cet ensemble-là est un besoin récurrent.
Ainsi, pour te paraphraser, on est dans le sujet du journal.
Loin de moi l'idée de promettre l'infini.
Il est en revanche possible de promettre de ne pas retourner de résultat faux ou imprécis, pour peu qu'on s'autorise à retourner "je ne sais pas", quand on sort (ou risque de sortir) des capacités de la machine pour la représentation utilisée.
[^] # Re: Rien de surprenant
Posté par Aldoo . En réponse au journal [Humour] vers un monde différent. Évalué à 3.
Certes. Mais il n'y a pas que les représentations en virgule flottante dans la vie.
Avec d'autres représentations, il est tout à fait possible de réaliser des calculs exacts avec n'importe quels nombres rationnels (limités seulement par la mémoire de la machine). En effet, dans toute base, un rationnel admet une représentation finitaire, par exemple :
- sous la forme d'une fraction d'entiers,
- ou bien sous la forme d'un début de développement et d'une période (séquence de chiffres qui se répète à l'infini).
Dans les deux représentations, on peut implémenter les opérations usuelles. C'est moins efficace que des flottants (même des "gros" flottants), mais absolument pas impossible.
Pour pinailler, c'est faux aussi : nous venons tous deux de le faire (ok, je botte en touche : une séquence aléatoire qui aurait autant de chiffres, elle, ne serait pas représentable).
# Pilule rouge
Posté par Aldoo . En réponse au journal [Humour] vers un monde différent. Évalué à 10.
https://fr.wikipedia.org/wiki/Virgule_flottante#Pr%C3%A9cautions_d'emploi
De rien.
(Sinon, attention au copié/collé : le résultat affiché est -5.551115123125783e-17 et non -5.551115123125783e-1, sinon c'est une sacrée erreur !)
[^] # Re: "Intelligence artificielle"
Posté par Aldoo . En réponse au journal Société de Cristal de Max Harms. Évalué à 2.
Je ne connais pas ce monsieur, encore moins le fond de sa pensée et ce n'est qu'une interview avec ses contraintes de format. Et encore, le sujet de l'intelligence artificielle n'est qu'une toute petite partie de l'article.
N'empêche qu'encore une fois, on a l'impression de voir quelqu'un qui essaye de se rattraper aux branches pour désespérément trouver et défendre quelque propriété qui serait le "propre de l'homme" à grands renforts de jugements d'autorité.
Comment parler d'intelligence, de conscience, de sentiments, sans entrer dans les principes font du cerveau humain ce qu'il est et sans entrer dans le fonctionnement de l'intelligence artificielle ? Les mécanismes d'apprentissage et de renforcement ne sont-ils pas similaires ? Dans les deux cas, les phénomènes émergents ne prennent-ils pas le pas sur la physique des composants de base (neurones, transistors, … ) ?
Bien sûr on n'a pas encore programmé d'IA capable de faire l'ensemble de ce que peut faire un cerveau humain.
Mais voilà, la problématique peut être formulée de façon scientifique. On peut donc essayer de l'aborder et de se l'expliquer par des procédés d'ordre philosophique, si on veut (c'est même très intéressant), mais une réponse non basée sur des arguments scientifiques n'a que peu d'intérêt.
# Ammonite-Shell
Posté par Aldoo . En réponse au journal Gufo: un langage de shell moderne!. Évalué à 2.
Puisque chacun y va de son alternative…
Où est-ce que Gufo se situe par rapport à Ammonite-Shell (un shell UNIX basé sur le REPL Ammonite pour Scala) ?
Ce shell, c'est en gros une REPL Scala avec quelques fonctions et facilités (DSL) pour interagir avec le système (notamment exécuter des commandes externes). Donc on y retrouve toutes les spécificités de Scala : langage objet et fonctionnel, sûreté de typage, etc.
L'inconvénient (par rapport à bash), c'est que du coup, c'est plutôt verbeux pour faire les choses simples.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 2.
Tout à fait. D'où les modalités entre parenthèses.
Oui, c'est toujours l'argument de la facilité, que j'entends. Toujours est-il que la valeur ajoutée est plus faible que si on avait traduit vers un langage capable d'abstraire efficacement les différentes entités du jeu (favorisant la ré-utilisabilité, l'extensibilité et la maintenabilité, etc. etc. je ne refais pas tout le topo). Évidemment, ce genre de traduction ne peut pas encore se faire de façon automatique (ça relèverait probablement du domaine de l'IA : reconnaissance de motifs, etc.), donc il faudrait plus d'huile de coude (initialement).
Peut-être le terme antédiluvien est-il un peu provocant. Mais le propos était juste de réfuter l'argument comme quoi on ne pouvait pas comparer l'ancien et le nouveau. Cela n'est pas du jeunisme, mais du pragmatisme : la question se pose très concrètement à chaque fois qu'il faut faire le choix d'une technologie pour arriver à un but donné.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 4.
Non mais, en fait, je suis d'accord avec tout ça !
Ma question initiale était juste pourquoi le C (sous-entendu, pour un projet personnel pour se faire plaisir, qui ne fait partie d'aucun des domaines de prédilections du C que tu listes, c'est plutôt un plaisir masochiste !). Je me demandais s'il n'y avait pas une raison un peu profonde.
Mais vraisemblablement, la réponse ne va pas plus loin que "bah, c'était facile à faire avec asm2c".
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 3.
Pardon, je voulais dire tracteur tirant une déchaumeuse, pas une moissoneuse-batteuse (qui sert à autre chose !). Mais revenons à nos moutons !
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 7.
Et à chaque fois qu'on ose critiquer le C ou le C++, il y a une meute de programmeurs qui se sentent insultés et nous tombent dessus à bras raccourcis.
Au passage, je n'a jamais dit le C saynul ou saylemal. J'ai juste remarqué qu'il y avait mieux (à nuancer selon le domaine, bien sûr, mais plus ça va, moins je vois où se trouve le pré carré du C).
Par exemple, je pense que C et le C++ (surtout le C) sont excellents d'un point de vue pédagogique car ils permettent de mettre en évidence les mécanismes sous-jacents à tout langage de programmation, moderne ou non (et non je n'ai pas été maltraité par un professeur de C ou C++, merci bien !). Notamment, beaucoup de bonnes idées de Rust (ex. : pointeurs intelligents) proviennent de C++ (le principal tort de C++ étant de permettre d'utiliser aussi les mauvaises idées trop facilement !). En plus leur syntaxe reste l'inspiration principale de celle des langages modernes, donc on n'est pas dépaysé (et on perd moins de temps sur ces aspects annexes).
Ce que je dis plus haut, c'est que C et C++ sont intéressants pour enseigner la théorie des langages de programmation. Par contre, je ne les conseillerais pas pour apprendre à (bien) programmer : ces langages sont bien trop permissifs.
Et alors ?
En quoi cela est-il un argument pour défendre l'utilisation de ces outils antédiluviens ?
Si je compare les mérites de la charrue et de la moissonneuse-batteuse, dans le contexte de quelqu'un qui monterait une nouvelle exploitation agricole, est-ce que tu lui conseillerais la charrue parce qu'elle fonctionne avec une foultitude d'architectures exotiques, qu'elles ont été maintes fois normalisées, et qu'elles sont rétro-compatibles avec les champs égyptiens, babyloniens et sumériens ?
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 1.
Et pendant ce temps…
(Note : il ne s'agit pas de conversion automatique vers Rust, mais de l'écriture de bindings Rust pour GStseamer. Néanmoins, c'est encore un symptôme de l'inadéquation/l'obsolescence du C ressentie par plus en plus de développeurs !)
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 2.
Oui, j'exagère un peu : le typage c'est déjà énorme (le polissage du silex ? ;-) ).
Peut-être un minimum vital pour tout projet à partir d'une certaine taille (évidemment, je ne suis pas fan de PHP non plus !).
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 2.
On utilise souvent le C, soit parce qu'on connaît déjà, soit parce qu'on travaille sur un projet qui était déjà écrit en C.
Le reste du temps (hors niches, dont, je pense, le développement d'un jeu à la Bomberman ne fait pas partie… mais je peux me tromper !), il y a probablement assez peu de raisons valables de démarrer un nouveau projet en C quand on connaît mieux.
Concernant les autres langages, je ne pense pas qu'il en existe un seul qui empêche quelqu'un de vraiment déterminé à mal programmer. Disons que quand-même tous les langages ne sont pas aussi convaincants les uns que les autres sur cet aspect-là !
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 2.
La proximité sémantique a facilité le portage vers C, mais ne justifie pas de son utilité.
Je ne propose pas de langage, ça dépend des préférences et objectifs des développeurs.
Si un effort de portage a été fait, j'imagine que c'est qu'ils comptent améliorer/ajouter des fonctionnalités. Donc n'importe quel langage moderne favorisant un style de programmation sain et maintenable aurait été un meilleur choix que C (qui n'est au fond qu'un assembleur un peu plus lisible et multi-plateforme).
Pour un bomberman-like, sur les machines d'aujourd'hui (fixes comme mobiles), on n'a plus vraiment besoin de faire de micro-optimisations, donc, selon moi, le meilleur compromis se situerait plutôt dans le (très) haut niveau (je verrais probablement objet+fonctionnel… mais après, chacun ses préférences).
Indépendamment du paradigme du langage, un atout de poids serait la possibilité de compiler vers différentes plateformes natives fixes comme mobiles, mais aussi vers JS ou WebAssembly pour en faire une appli web (mais je crois qu'on peut le faire avec le C, via Emscripten).
# Pourquoi en C en 2017 ?
Posté par Aldoo . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 1.
Sans vouloir troller (bon, un peu quand-même : les questions du genre pourquoi tel ou tel langage… c'est toujours trollogène), en gros, on passe de la pierre taillée à la pierre polie ?
Pour faire les questions et les réponses, j'imagine que de toute façon, un outil automatique ne peut pas inventer un programme "haut niveau" depuis de l'assembleur, alors que vers le C, ça doit se faire "tout seul".
Mais est-ce que les auteurs envisagent cette version en C comme
- une fin en soi ?
- une démo pour asm2c ?
- ou bien seulement comme une étape obligatoire avant de passer à un langage de notre millénaire ?
[^] # Re: Dépêche ?
Posté par Aldoo . En réponse au journal Java 9 est dehors. Évalué à 8.
Clairement !
Mais il faudrait sans doute compléter un peu. La liste complète des nouveautés est ici.
Dans les nouveautés sympathiques (non citées dans le journal), je vois aussi :
- les méthodes privées dans les interfaces (pour partager le code entre méthodes default ou static)
- les fabriques statiques pour les collections immuables : Set.of(…), List.of(…), Map.of(…)
- implémentation de Reactive Streams (classe Flow)
Bon bien sûr, tout le monde ne s'intéresse pas aux mêmes fonctionnalités !
[^] # Re: Type fantôme
Posté par Aldoo . En réponse au journal Une petite histoire d'utilisation type fort dans Ocaml. Évalué à 2.
Je suis peut-être un peu naïf, mais dans les langages objet, l'idiome naturel pour arriver à cette fonctionnalité c'est d'utiliser l'héritage (à moins que je n'aie pas compris ce qu'on cherchait à faire), exemple en Java :
Clairement, on peut avoir des méthodes acceptant B mais pas C ou vice versa.
B et C ne jouent que le rôle de marqueurs (comme les types fantômes, non ?) et A, étant abstract, ne peut pas être instancié directement tel quel (tout comme les types dépendants en OCaml ou ailleurs).
Bien sûr on peut aussi faire avec des génériques, mais ça me paraît moins naturel d'introduire un paramètre de type qui ne sera jamais utilisé à l'intérieur de la définition du type.
Plus haut, dans le journal, je vois la mention "autrement qu'en faisant des classes". Je ne comprends pas cette remarque. Les classes sont la façon normale, parfois la seule, de définir la structure d'un type dans un langage objet (on pourrait remplacer "classe" par "interface", mais j'imagine que ça ne change rien à la remarque). On ne peut pas reprocher à un langage non-fonctionnel de ne pas disposer de syntaxes de définition de type à la façon "langage fonctionnel".
[^] # Re: Compréhension
Posté par Aldoo . En réponse au journal Urbit - Le nouveau MultiDeskOS aka le retour de Jayce ?. Évalué à 3.
C'est lumineux !
[^] # Re: Dieu n'existe pas
Posté par Aldoo . En réponse au journal Paris sous les balles. Évalué à 2.
Ça doit pouvoir arriver si tu tartines le dos d'un chat. Mais j'avoue que ce n'est pas facile.
[^] # Re: Dieu n'existe pas
Posté par Aldoo . En réponse au journal Paris sous les balles. Évalué à 5.
Pas sympa pour ta grand-mère…
[^] # Re: Dieu n'existe pas
Posté par Aldoo . En réponse au journal Paris sous les balles. Évalué à 2.
Je n'en suis même pas à parler de l'existence de nombres transcendants, seulement de celle de nombres non entiers.
Mais c'est vrai que ce que j'ai montré, c'est plutôt : si on choisit une définition de nombre incluant tous les rapports de longueurs de figures géométriques construites selon telle ou telle règle (permettant de tracer des cercles), alors il existe des nombres non entiers (et puis par extension, sans ajouter d'axiome, on devrait pouvoir prouver assez facilement qu'il existe des nombres non rationnels et puis, moins facilement, des nombres non algébriques/transcendants).
L'existence dépend de la réalité considérée (pour ça qu'en mathématiques on quantifie toujours à l'intérieur d'un ensemble donné).
En métaphysique, on peut aussi faire ce genre de raisonnement. Mais pour que ça ait du sens, il faut que le domaine considéré et les axiomes introduits correspondent bien à la réalité physique (ou au moins ne la contredisent pas).
[^] # Re: Dieu n'existe pas
Posté par Aldoo . En réponse au journal Paris sous les balles. Évalué à 5.
Il n'y a pas de morale athée, pas dans le sens où les athées sont immoraux, mais dans le sens où il n'y a pas une morale athée et que les athées ont souvent tendance à essayer de réfléchir chacun de son côté pour bâtir son système moral.
Cela dit, je pense que ce n'est que très partiellement vrai. Être athée ne fait pas automatiquement de soi un grand penseur et il existe des bel et bien des systèmes moraux athées "prémâchés" qui sont communs à des grands groupes d'êtres humains (ex : morale communiste, etc. ).
[^] # Re: Dieu n'existe pas
Posté par Aldoo . En réponse au journal Paris sous les balles. Évalué à 3.
Je ne voulais pas directement opposer raisonnement mathématique et physique.
Je restais dans le cadre de la logique mathématique, dans lequel une assertion peut-être soit être fausse en dehors de tout contexte si elle est auto contradictoire, soit être fausse après interprétation dans un certain cadre sémantique. Ce serait, par exemple, une formule de logique de premier ordre, cela correspondrait à choisir le domaine des variables et la valeur des différents symboles de constantes, fonctions et prédicats. Dans le cas de la définition de Dieu, cela consisterait à la plaquer dans le monde réel avec tout ce qu'on sait de lui, pour se rendre compte qu'elle n'est pas compatible.
[^] # Re: Dieu n'existe pas
Posté par Aldoo . En réponse au journal Paris sous les balles. Évalué à 9.
Il y a plusieurs façon de prouver la non-existence de quelque chose.
J'en vois deux principales : 1, comme dans tes exemples, chercher une contradiction logique (souvent indépendante de la structure réelle dans laquelle on interprète l'assertion à prouver), 2, dans un monde fini (ou du moins avec une certaine notion de finitude), effectuer une recherche exhaustive infructueuse.
Pour l'existence de Dieu, le problème est que la définition est souvent bien trop vague pour arriver à une contradiction logique, sauf à fixer une définition très stricte et très forte : omnipotence absolue, omniscience, faiseur de miracles, etc. Mais là, il n'y a que deux possibilités : soit on est membre (rigoriste) du culte qui décrit Dieu exactement de cette façon, et la logique passe au second plan, soit on ne l'est pas… et ça ne vaut pas plus le coup de réfléchir à l'(in)existence de ce dieu qu'à celle du Père Noël ou du Monstre Spaghetti Volant (et puis c'est risquer de se fâcher inutilement avec les membres dudit culte !).
Pour des définitions moins contraintes, il reste alors la recherche exhaustive, mais le terrain de recherche étant l'univers qui, bien que fini, reste largement inaccessible. On se trouve alors dans une impasse.
Par ailleurs, même si on arrive à "explorer" l'univers physique par une expérience réelle ou par la pensée, alors apparaît la botte secrète imparable consistant à dire que Dieu ne se manifeste pas dans le plan physique. Mais là, la discussion peut s'arrêter, vu que l'existence ou non de ce Dieu n'a aucun impact sur le monde qu'il était censé devoir expliquer, ce n'est plus qu'une hypothèse inutile, mais qui ne coûte rien non plus.
Finalement, prouver l'inexistence de Dieu est soit inintéressant, soit impossible, soit inutile, en fonction du type de Dieu considéré.