reno a écrit 3881 commentaires

>>«je veux développer des programmes, pas faire des math.»
>Et moi j'en ai marre de ceux qui croient que programmer c'est juste pisser du code. Si tu programmer intelligemment, tu as besoin de notions théoriques.

Très peu.. La principale qualité d'un bon développeur c'est d'être capable de comprendre le besoin et ensuite de sortir du code maintenable pour y répondre, point.

>Premièrement tout programmeurs devrait penser à la complexité algorithmique de ses programmes

Un niveau de math *très différent* de celui réclamé pour essayer de comprendre Haskell, ce qui était le sujet de cette phrase de mon post.

>Deuxièmement tout programmeur devait aussi de poser des questions sur les bases théoriques des langages qu'il utilise.

Ah? Les langages que j'utilise le plus sont le C, le shell (et le Perl quand je ne peux pas l'éviter) et je regarde attentivement D pour le futur, qu'est ce que tu entends par 'base théorique' dans leur cas?

>Troisièmement, la tendance actuelle est clairment d'avoir des langages plus formels:: plus de typage, un typage plus fort et plus souple,

La tendance en recherche oui. Ailleurs c'est loin d'être évident: Ruby, D les langages qui montent, sont très différent d'Haskell, Coq et consorts..

Je ne vois pas pourquoi tu montes sur tes grand chevaux dans ton post: personne ne t'empeche de t'éclater avec de la preuve de programme, chacun son truc, je préfère écrire des programmes qu'essayer de comprendre des math comme celle utilisée pour Haskell ou Coq.

>Sauf qu'en D je ne pense pas que tu puisse directement inclure des instructions assembleur, si ?

Si: http://www.digitalmars.com/d/iasm.html

>Lisaac, tu peux directement inclure du code C

D s'interface assez bien aussi avec le C, un peu comme le C++ appelle du C et la syntaxe de D est assez proche de celle du C..

Pour le détail:
http://www.digitalmars.com/d/interfaceToC.html

>>absence de contrats : je ne connais pas trop cette manière de travailler, mais d'après Wikipedia, ca revient à tester des domaines de valeurs. les mots clé assert (Java 1.5) sont là pour ca, et au pire on pourra toujours utiliser le mécanisme des Exceptions si ca ne suffit pas.<<

On peut toujours faire tout dans chaque langage, le problème c'est la lourdeur du résultat.
En Eiffel, les contrats d'une classes sont hérités par les classes qui en héritent, tu peux dupliquer les assert ou dans l'assert d'un héritier appeler les assert de la superclass, mais c'est lourd.

Pour les closures, l'exemple type est pour les IHM, ou on a besoin de plein de petit bout de code a associer aux evenements, en Java c'est verbeux.

Je suis d'accord avec toi pour la complexité de la grammaire de Java, certes c'est plus compliqué qu'un Smalltalk mais beaucoup moins qu'un C++ ou un Perl.

Comme manque j'ajouterai:
-les "properties": c'est lourd toutes ces fonctions set et get
-le passage d'arguments par mots-clef.

Et pour les generic, je prefere celle de Scala qui peuvent être covariante ou contravariante.

Bof, il n'y a pas besoin de connaître la théorie des ensembles pour faire une requête sur une base de donnée, il n'y a pas non besoin de connaître la théorie des ensemble pour faire un logiciel de base de donnée.

Donc non une base de donnée ce n'est pas lié à la théorie des ensembles, après tu peux l'analyser en termes de théorie des ensemble si ça t'amuse mais bof.

Par ton raisonnement, je peux dire que la cuisine c'est des math..

>>Le langage D est vraiment tres bien sur le papier, mieux que C, C++, Java ou C# par exemple ; je precise que je ne lance pas de trolls. Pourquoi ne perce-t-il pas alors ? Peut etre parce qu'il soit sous copyright Digital Mars. Cet aspect "langage non-libre" a été soulevé par un autre intervenant.<<

Bof, il existe un compilateur libre de D: GDC.
Il n'est pas au niveau du compilateur 'officiel' sur certains points, mais il a l'air utilisable d'après les posts que je vois.

Le problème de D est plus au niveau des librairies (la lutte entre Phobos et Tango n'aide pas) et du langage: certes la v1 est sortie, mais quasiment aussitôt la v2 a vu le jour qui ajoute plein de truc, alors que dans la v1 il y a des parties non implémentée (je crois que les contrats ne sont pas implémentés).

>Quels autres langages savent à la fois travailler à un niveau proche de la machine, et être de haut niveau ?

Le C++ :-) ?
Pas taper!

Plus sérieusement: D qui a le gros avantage justement d'être proche du C++, tout en étant mieux fait (c'était pas dur ;-) ).

Pour ta comparaison C/Haskell, bof: le C pour moi, a un gros avantage sur Haskell: je comprends ce que fait le compilateur, Haskell repose sur des concepts que je ne comprends pas (et oui j'ai lu plein de tutoriels sur les monad mais ça ne m'a pas éclairé).

Ceci dit, je suis d'accord qu'il y a mieux que le C, mais pour moi ce n'est pas Haskell: je veux développer des programmes, pas faire des math.

Certes, mais je dirais que PHP et Perl se sont ouvert des niches car ils sont arrivés les premiers sur leur créneau.

Après justement sur le créneau du Web et du scripting, Ruby gagne du terrain car justement il est plus élégant (avec beaucoup de difficulté car le poids de l'installé est énorme).

>Et pour Ruby, heureusement qu'il y a eu RoR: avant RoR, le langage était déjà aussi élégant, et pourtant presque personne ne l'utilisait.

Tout à fait exact.

Bon j'ai déjà fait la remarque, ne te sens pas visé, mais si on regarde SmallTalk, on voit qu'il n'a pas eu un grand succès, par contre Ruby lui, qui n'en est pas si loin que ça de Smalltalk, a bien décollé.

Il a décollé pour plusieurs raisons:
1- un langage très souple, mais ça Smalltalk l'avait déjà.
2- une syntaxe *très* agréable: car parlant au programmeurs C, shell, Perl, mais en plus propre.
3- une killer-app Ruby on Rails, qui a été réalisée car Ruby a 1 et 2.

Isaac a (1) mais pas (2) *a mon avis*..
Hors (3), le vrai déclic, ne vient que si suffisamment de programmeurs s'interesse au langage donc il faut d'abord avoir (1) (la c'est bon) *et* (2)..

Après chacun a ses préférences pour la syntaxe, mes favoris actuels sont Ruby et Scala.

Après je ne prétends pas avoir la recette ultime..

>>Il n'y a aucune trace dans les log du processus killer et si le processus est lancé en ligne de commande, il disparait tout simplement sans laisser de trace. C'est cela qui est génant, le fait de n'avoir aucune trace.<<

Si c'est vrai, c'est très génant, mais j'imagine que effectivement c'est difficile pour le noyeau de faire des traces..

Pour ce qui est du /var, cela me parait different: si un processus n'écrit pas dans le /var pourquoi serait-il géné par un /var plein? Donc le /var plein n'est pas un probleme global.

Pour l'OOM, il faudrait mettre des traces ok, mais tu proposerais comme quoi mécanisme pour le /var plein?
Critiquer c'est facile, mais proposer des solutions c'est plus difficile.

Immoral?
Non: si tu autorise quelqu'un a faire quelque-chose avec ton travail, ce n'est jamais immoral que ce quelque-chose soit fait puisque tu l'as autorisé a le faire.

Les developpeurs BSD ne trouvent pas immoral que les applications propriétaires utilisent leur code et de la même façon si un developpeur autorise au choix d'une la license A ou la license B, il n'est pas immoral de redistribuer avec uniquement une des deux licenses.

Après ce n'est pas forcément sage, mais ce n'est pas immoral.

Et puis l'assimilation developpeur utilisant la GPL==libriste est erronée, IBM utilise la GPL mais a aussi beaucoup de patentes qu'ils utilisent pour gagner de l'argent..
C'est ça la force de la GPLv2 d'ailleurs: elle plait aux libristes, mais aussi aux entreprises qui veulent un terrain d'échange "équitable".

Pour ce qui est de D, je le surveille avec attention ce langage mais j'ai juste joué avec, donc pas de conseil a donner.

Pour ce qui est de voter, même sans connaitre, non ça ne me choque pas: même si tu ne connais pas bien les politiciens, tu peux avoir envie d'éviter que LePen (un politicien d'extrème droite ici) passe par exemple et donc voter contre lui en votant pour un de ses adversaire..

Donc attend voir ça fait 26+4+28: 58s.

Bon c'est correcte pour un Linux, mais il faut toujours garder a l'esprit que dans l'absolu c'est très lent: un BeOS sur un Celeron333 avec 128Mo de RAM allait de lilo a un desktop utilisable (autlogin donc) en moins de 20s, j'ai 14s comme chiffre en tête (et sans avoir eu a faire aucun réglage).

OK, on ne boote qu'une fois par jour (économisez l'énergie ceux qui laissent leur station allumé la nuit), donc ce n'est pas important..

Mais j'avoue que ça me fait toujours mal de lire l'équivalent de 'mon Linux démarre vite, il met une minute a demarrer'..

Bof si j'ai bien tout compris il y avait deux problemes:
- du code sous licenses BSD dont le copyright a été retiré par un dev, c'était une erreur et cela a été corrigé très rapidement par les dev Linux.

- du code sous double license BSD et GPL dont la license BSD a été retiré, et la il n'est pas du tout sur que ce soit illégal: si tu license un fichier sous (license A ou license B), je ne vois pas ou est le probleme de modifié le fichier pour qu'il n'y ait plus qu'une des deux license.
Et la Théo est décevant: il est si sur de lui qu'il est insultant envers toute personne qui ne partage pas son avis, alors que ça me parait bien floue comme problème..

De mon point de vue, ce n'est ni illégal, ni immoral (traduction de unethical?), par contre ce n'est pas sage: s'allier avec les BSD-iste permettrait d'avoir un bien meilleur pilote au final plutôt que de les offenser en récupérant leur code sans leur laisser la possibilité de récupérer les amméliorations en retour.

>>Pour Ubuntu par exemple tout le monde trouve normal d'avoir ces éléments installé par défaut, mais pourquoi pour Windows ça ne serait pas normal ?<<

Parce que Windows a le monopole des PC.

>>Ne serait-ce pas plutôt la faute aux revendeurs, qui eux peuvent personnaliser la configuration en fonction du clients ?<<

Hein?? Soit tu trolles, soit tu es un poil ignorant: pendant des années Microsoft a "interdit" aux revendeurs de faire la moindre configuration des OS qu'ils vendaient, et ne parlons même pas de dual boot!
Interdiction soit contractuelle soit plus subtile: on vous fait telle réduction uniquement si vous installez le PC comme on le désire.

Depuis le proces anti-trust aux USA, j'ignore ce qu'il en est, si ces pratiques ont été interdites ou pas.

>Le chapitre 11 suspend aussi automatiquement toute procédure judiciaire en cours

Toute procédure judiciaire 'civile' pas criminelle, il n'y en a pas pour l'instant mais ça pourrait venir j'espère:
dans le procès SCO vs Novell, SCO avait dit qu'ils n'avaient pas besoin de mettre les fonds réclamés par Novell sur un compte séparé car ils ne risquaient de faire banqueroute (il y a un ou deux mois, je ne me souviens plus), et maintenant ils demandent la mise en liquidation judiciaire, mmmm ça va chercher dans les combien le faux témoignage devant un juge?

Certes, mais existe-t'il des cartes Intel pour PC de bureau?

J'ai l'impression que les Intel sont restreints aux laptop, voire intégré sur la CM, en plus leurs perfs comparé a une 9800Pro..

>Le projet opengraphic qui visait à avoir une carte totalement libre risque de prendre du plomb dans l'aile...

Il était toujours actif ce projet? Ca fait longtemps qu'on n'en a plus entendu parler..

AMHA, il avait déja du plomb dans l'aile avec les pilotes open-source d'Intel alors avec ceux d'ATI la..

C'était un risque connu, mais le gars a l'origine du projet a du probablement y perdre de l'argent..

Pas betes, ta méthode pour installer les dépendances d'une application 'indépendante', bon il faut qu'il y ait une ancienne version de l'application géré par ta distribution..

Si les applications indépendantes avaient un fichier pour lister les dépendances, on pourrait utiliser le gestionnaire de paquets pour les charger (si possible automatiquement), après le problème c'est que les distributions changent le nom des paquets..

Pas grand chose d'interressant, dans les rapports a la commission boursière américaine, les entreprises doivent lister tous les risques potentiels auquels ils sont soumis pour que les investisseurs puissent se faire une meilleur idée de la valeur de la société.

>Pour l'internationalisation d'un programme, on peut aisément changer l'ordre des arguments dans la chaîne de formatage car les arguments sont numérotés<

Beurk et rebeurk:numéroté les arguments c'est super-pénible et c'est une source d'erreur.

Une chaîne de format qui contient le nom des variables est bien meilleur, j'ai fait une librairie en D(assez moche) qui comprend ce genre de format:
"Bonjour %{prenom} votre age est %03d{age}"

Comparé a "Bonjour {0} votre age est {1}", je crois qu'il n'y a pas de doute sur ce qui est le plus lisible, surtout si les chaines sont stockées dans un fichier séparé..

Merci pour l'explication, je m'étais trompé bien sûr.

Quelques questions:
>long a été renommé en int
Pour les non-pythoniens, il faut préciser: en Python un int est un long C et un long est un 'big int', utiliser par défaut des 'big int' dans un langage de script me parait une bonne idée, mais d'après ce que tu dis >qu'un type pour représenter les entiers< il n'y a pas de raw_int ou équivalent qui remplace int, ce que je trouve curieux: j'aurais tendance a penser que les 'big int' sont plus lents et/ou utilisent plus de mémoire que les 'raw int' et que pour des raisons d'optimisations, garder l'accès au 'raw int' serait intéréssant..

>1/2 retourne maintenant 0.5
Une bonne idée. Dans des langages type C ou ce n'est pas vraiment faisable (quel type flottant utilisé? il y en plusieurs) AMHA on devrait remplacer le '/' entier par 'div' ou 'idiv' cela éviterait des confusions.

>def spam(a, (b, c)) est maintenant invalide. À la place, utilisez def spam(a, b_c): b, c = b_c
Tu es en train de dire que le souligné _ est l'opérateur de concaténation des tuples?? Beurk!

>0666 est maintenant une erreur syntaxique, la syntaxe correcte est 0o666
Pas trop tôt! Cette hérésie devrait déja avoir disparue des langages depuis longtemps..

>nonlocal
Bin oui quand il y a déclaration implicites des variables, on se retrouve a devoir faire des bidouilles comme ça, beurk.
En Limbo, pour déclarer une variable, c'est un/1 caractére(!), le deux-points ':', par exemple "a := 10" déclare et initialise a.
Ce qui montre bien qu'on peut faire des déclarations explicites sans que le résultat soit lourd a lire.


Ce que je trouve dommage, c'est que:
1) l'abus de self n'est pas corrigé, quand tu lis du python, cest "def f(self, ...) def g(self, ...)": pénibles ces self partout.
2) pour l'indentation, je me demande si autoriser a la fois les espaces et les tabulations est une bonne idée et s'il n'aurait pas fallu rejeter les tabulations.

Le 'unix haters book' que j'ai lu récemment faisait remarquer qu'il y a une différence entre la simplicité d'implémentation et la simplicité d'utilisation et de leur point de vue Unix se focalisait trop sur le premier point au détriment du second.

Exemple: VMS qui proposait par défaut un système de fichier versionné global ce qui évitait les dizaines de variantes particulières a chaque application pour conserver les versions originales.

Compiz était l'ancien nom du projet avant qu'il y ait un fork puis un regroupement, d'ou le nouveau nom compiz fusion.

Bah, bientôt ils vont intégrer le GPU au CPU donc les effets vont revenir sur le processeur ;-)

Jusqu'au prochain cycle..