Michaël a écrit 2935 commentaires

Pareil, je suis toujours en train de me demander s'il y a encore en france des boites qui utilisent des unix propriétaires et pour quoi faire.

Une raison bête est la compatibilité: porter une application, ne serait-ce qu'un shell script, d'un Unix vers un autre est une tâche complexe. Si en plus il s'agit d'une version très particulière d'Unix pour laquelle on ne trouve pas de spécialiste à tous les coins de rue, on se retrouve avec un tas de raisons pratiques pour ne rien faire!

(Bien que le userland soit basé sur FreeBSD, on peut problablement classer Mac OS X comme un Unix propriétaire — mais ce n'est probablement pas celui auquel on pense le plus!)

Non, si je devais te citer une référence, je dirais… Tk! C'est vieux, obsolète, tout ce que tu veux, mais ça a le mérite d'être utilisable par tout le monde!

Tk est largement sous-estimé à mon avis. Les plus gros manque est probablement l'absence d'un widget qui affiche du HTML: rien de très important. Sans vraiment bien connaître l'historique des toolkits, ils semblaerait d'ailleurs que GTK ait beaucoup repompé sur Tk, au moins les widgets texte et canvas.

Dernier exemple : git est parfait pour l'administration système. Est-ce déjà utilisé systématiquement ?

Tu veux dire, pour gérer les fichiers de configuration d'une station de travail? Je ne vois pas trop en quoi ce serait un nouvel usage de GIT, à vue d'œil cela doit faire depuis au moins 20 ans que des sysadmins font ça — avec un autre SCM, forćement.

Ce qui compte, c'est surtout d'avoir un bon Makefile:

https://bitbucket.org/michipili/bsdmakepscripts/src/00afe03a2f47229533172372a7fcba4f7d1399b2/misc/conf.freebsd.mk?at=master

mais je ne vais pas commettre l'erreur de juger sans savoir une seconde fois :-)

Attendons vendredi, hein! :-)

Oublier la mémoire est une mauvaise idée; Je le vois tous les jours sur une aplli java, personne ne sais d'où vient un objet sa durée de vie et s'il est un jour déréférencé, résultat, le code fuit, et personne ne sais comment régler le problème.

Et les codeurs qui ont pondu ça deviennent magiquement meilleurs lorsqu'ils programment en C++ ?

Quelquefois on lit des docs super intéressants et très bien écrit (syntaxe, orthographe, etc..).

Pour les journaux sur LINUXFR, c'est un peu la même chose!

Bref, dans the darmod on est vraiment dans de l'infiltration alors que dans dark messiah on est dans l'action.

La vidéo que j'ai mise en lien est la première d'une série où le joueur parcourt tout le jeu sans se faire reprérer une seule fois par les adversaires — sauf les deux ou trois fois où cela est absolument inévitable. C'est assez fun et impressionnant.

En lisant la présentation j'ai tout de suite pensé à Dark Messiah of Might and Magic — un jeu certes pas libre du tout mais néanmoins de très bonne qualité, le scénario est très linéaire mais ce n'est qu'un prétexte à un excellent jeu d'action.

Comment se situe Dark Mod par rapport à Dark Messiah? Est-ce qu'il y a une volonté de créer un système de combat équivalent?

(Pour ceux qui ne connaissent pas, voilà le début, ça commence à 5:50 http://www.youtube.com/watch?v=X2NN6W6cnA4 . Pour les plus nostalgiques, Teng Shu sur la playstation est probablement un précurseur du genre.)

Ils sont sympas ceux de la collection «Skeleton» je leur trouve un petit côté steam-punk pas déplaisant — d'ailleurs je viens de voir que c'est écrit comme ça dans l'article! Mais bon 20.000–90.000$ c'est un peu loin de ma fourchette de prix (un facteur 1000, en gros)!

3) d’être amené par Mozilla, et pas par "une bande d'universitaire qui ne savent faire que des langages jouets" (rigolez pas, on me l'a déjà sorti).

J'avais une bonne opinion du milieu universitaire (j'ai fait 5 ans de recherche en maths) en ce qui concerne ses méthodes et sa productivité. Depuis deux ans je travaille dans l'industrie, et à vrai dire la pression et le lien au réel sont beaucoup plus gros à la fac qu'à mon nouveau boulot. Je pense qu'il y a un paquet des gens à qui ça va piquer les yeux de lire ça, mais mieux vaut faire la grimace que de remettre en question un bon préjugé bien crasseux avec lequel tout le monde est d'accord, pas vrai? La vérité, c'est que des gens qui se la touchent au boulot, il y en a partout.

Et pour faire de la parallélisation sur List.map, tu peux utiliser parmap, ça marche très bien.

Tu as des informations ou des références sur l'utilisation de parmap sur des gros calculateurs (avec un grand nombre de cœurs).

OCaml est une galère pour le multithreading,

Ce sujet m'intéresse, donc est ce que tu aimerais développer?

et c'est pas près de changer car les travaux de Luca Saliu vont rendre impossible la communication entre fil d'exécution.

Je ne sais pas qui est ce Luca Saliu, que mijote-t-il donc? Qu'est ce que tu veux dire par rendre impossible la communication entre fils d'exécution?

Ce qui implique qu'un List.map ne va pas paralléliser automatiquement.

D'autant que je sache, List.map est déjà non parallèle (je ne comprends pas de quel futur tu parles).

De toutes façons, comme OCaml est un langage impur, cela peut être incorrect de paralléliser un map. Comme dans par exemple:

let count =
  let n = ref 0 in
  fun _ -> incr n; !n

List.map count [ 'a'; 'b'; 'c' ]

Il me semble que le compilateur ne s'amuse pas à se souvenir si une fonction est «purement fonctionnelle,» si?

C’est pas tellement plus compliqué[…]

Peut-être mais ce qui compte c'est que c'est plus compliqué: il y a un concept supplémentaire, donc une nouvelle source d'incompréhension, une nouvelle source d'erreurs, un nouveau choix à faire dans la conception d'un logiciel, des questions de performance, etc.

Dans 90% des programmes on n’utilisera que ~ et &.

Peu importe: même si tout ce qu'il faut savoir se résume à cette simple phrase (celle que je cite): pour obtenir le ramasse-miette qui fonctionne dans chaque thread (avantage de Rust sur OCaml) il faut accepter de travailler avec un langage plus compliqué puisqu'il distingue plusieurs sortes de références (modèle mémoire de OCaml plus simple).

Même si ce que tu dis est vrai ce n'est pas une amélioration gratuite: on échange un avantage contre un inconvénient, à chacun d'apprécier l'un et l'autre — ton opinion semble être que l'avantage est plus important que l'inconvénient, mais ça dépend des gens, de l'application, etc.

L'existence du multithreading à mémoire partagée plutôt que seulement passage de messages ?

Je ne dirais pas que c'est mieux foutu: en Rust il semble il y avoir trois ou quatre sortes de référence mémoire, en OCaml on ne se préoccupe tout simplement pas de ce genre de choses. Un équilibre différent a été choisi, mais ce n'est pas «globalement mieux foutu».

Le c++ n'étant pas le plus rapide à ce niveau la, sans doute en partie du à la complexité de la chose pour les templates

Un des points faibles du C++ en matière de performance est le préprocesseur, tout bêtement. C'est quelque chose qu'il aurait fallu abandonner, en ne fournissant qu'un support limité à des modules dédiés chargés de faire l'interface avec C.

Regarde derrière toi. :)

Désolé de te le dire, mais tout ne tourne pas autour de ta petite personne

Gnii? De quoi tu parles?

parceque tu ne comprends pas que je ne te reponds pas directement, j'utilise ton poste pour completer,

C'est quoi les indications que tu as laissées pour comprendre ton message dans ce sens?

Le reste je m'en fou un peu, j'ai autre chose a faire dans la vie de checker si un type a repris une de mes phrase dans un forum.

C'est pas toi qui en remet 36 couches?

ne soit pas agressif,

Je ne suis pas agressif. (?)

j'ai voulu donner une astuce, un moyen memotechnique pour expliquer d'ou vient cette notation qui n'est pas trivial.

C'est gentil mais trouver «un moyen memotechnique pour expliquer d'ou vient cette notation qui n'est pas trivial» n'a pas grand chose à voir avec la choucroute.

Le problème est que des notations d'apparence similaire sont utilisées pour des choses différentes (initialisationde variable immédiate dans un cas, initialisation d'objet dans l'autre) ce qui du coup induit le programmeur en erreur. (Ici il confond le pointeur et l'objet pointé, et le compilateur analyse l'erreur d'une autre façon, ce qui aboutit à un message d'erreur pas utile.)

Ne prends pas ça pour toi, quand tu sera calmé tu pourra relire, tu vera il n'y a pas d'agression de ma part.

Pas de problème, la prochaine fois que quelqu'un fera un commentaire hors sujet qui se termine par «une fois qu'on a compris ça va mieux» je lui enverrai une carte postale avec des petits chatons. :)

Appart le fait que l'un est plus lisible, tu peux quand même mettre n'importe quoi dans chacune des fonction donc tu dois savoir ce qu'elle font. En général un bon IDE te met un tooltip par dessus l'opérateur et te permet de sauter directement à son implémentation.

Voilà, donc en C tu peux relire un patch mais pas en C++ puisque tu as besoin de ton IDE pour savoir ce qui se passe. Donc contrôler les commits dans un projet en C++ est plus difficile qu'en C, en particulier pour la sécurité.

(Plus difficile ça ne veut pas dire infaisable.)

Entre la fonction qui peut être surchargée, la classe du paramètre qui peut définir des opérateurs de conversion, le tout passé en référence et des éventuels petits const en prime, on se retrouve dans un mélimélo complétement incompréhensible.

Pour bien faire il aurait fallu ajouter un spécialisation de template. :)

Tu as complètement raison, il n'y a aucune commune mesure entre la complexité des messages du C++ et de ceux du C.

C'est au final le meme probleme qu'avec la surcharge d'operateur, on lit le code, mais on ne peut pas voir l'ensemble des appels de fonction et de logique que cela va declencher.

Tu n'es pas le seul à penser ça! C'est aussi dans les coding style rules de Google.

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Je ne pense pas. Il est déjà possible de cacher plein de truc avec des macros ou autre,

C'est quoi «ou autre»? Tu jettes tous les éléments de ma liste sauf un, ajoute du vent, et tu conclues «c'est pareil». Si ce n'est pas de l'argumentation de qualitay, ça!

Oui tu as bon!

Les 3 derniers relèvent un peu du même contexte : besoin d'intégration avec d'autres trucs que du C++

Il y a un truc que tu as loupé dans ta liste c'est la sécurité. En 2003 quelqu'un a commité une backdoor dans le noyau Linux:

http://marc.info/?l=linux-kernel&m=106807279904947&w=1

En C++, entre la spécialisation de templates, la surcharge d'opérateurs, les références et les namespaces, un individu mal intentionné a un attirail de bien meilleur qualité pour brouiller les pistes. C'est beaucoup plus facile de relire du code C que du code C++.

par exemple la surcharge d'opérateur qui ne se combine pas super bien avec les namespaces.

Tu peux élaborer ?

On prend l'exemple suivant

namespace a {
  class Example {};
}

Je veux écrire un opérateur << pour mon Example. Laquelle de ces déclarations est la bonne?

namespace a
{
  std::ostream& operator<<(std::ostream& os, const Example& x);
}

ou bien

namespace std
{
  ostream& operator<<(ostream& os, const a::Example& x);
}

ou encore

std::ostream& operator<<(std::ostream& os, const a::Example& x);

Si tu mets plus de 5 minutes à répondre à la question ou que tu utilises un compilateur, j'ai gagné, okay?