M. Vandemar a écrit 78 commentaires

> Tout ceci a un nom: le civisme...

Non.

Idem pour une (bonne) chaîne de télévision de service public, et l'intérêt qu'elle présente pour l'éducation et l'information en général. Un investissement pour un service public.

> Mais qui est ce Pierre au juste?

C'est Juste son prénom.

Je pense qu'une chaine devrait combler les deux, loisir et culture n'étant pas incompatibles. Prends une famille modeste avec quelques enfants et envoie tout le monde au cinéma, regarde ce que ça coûte... enfin bref, une telle chaine ne devrait pas tomber dans les "extrèmes" : ni uniquement documentaires intellos, ni excès de navets (la série complète du Gendarme qui repasse tous les ans, oui c'est clair que c'est du foutage de gueule...) C'est vrai qu'actuellement c'est pas fameux, mais une grille de programmes d'une chaine ca représente un paquet d'heures, je suis convaincu qu'un bonne chaine publique serait possible.

Non c'est la même chose, et si les chaines proposées sont minables ça ne remet pas en cause le principe d'une chaine de service public. Sinon, tu peux dire de la même manière que l'école est de mauvaise qualité, que tu éduques tes enfants autrements, et donc que tu ne veux pas payer (idem avec n'importe quel service public).

Evidemment, tout le monde est sans doute d'accord pour dire que la qualité n'est pas celle qu'on attend d'un service public (à part la cinquieme chaine, éventuellement).

La taxe ne concerne pas la télé mais une chaine de télévision de service public, ce qui est bien du même ordre que l'école (information, éducation, etc.)

Après tu peux gueuler sur d'autres points, comme le fait que certaines chaines sont indignes de ce rôle de service public. Mais ce n'est plus le même problème.
Tu peux gueuler aussi sur la forme : tout le monde paie le même prix, riche ou pauvre.

Je n'ai pas parlé des autres taxes, et je ne vois pas le rapport qu'elles ont avec la redevance.

Tu as mal lu, ils parlent d'appareil récepteur de télévision, abrégé ensuite en « téléviseur ». Un ordinateur équipé d'une carte TV est un téléviseur (peut-être pas d'après Robert, mais d'après la définition qu'ils donnent).

> Ba oui y'a des gens qui vivent sans télé; c'est pas vraiment indspensable et je vois pas pourquoi je devrais payer pour le tas de bouzes que je n'ai pas la "chance" de voir....

Et si tu n'as pas d'enfants, tu veux pas que le gouvernement te rembourse la part de tes impôts qui va aux écoles ?

Financement par un impôt sur le revenu. Election des dirigeants indépendamment du gouvernement.

> La redevance, je pense que tout le monde devrait la payer, ou bien personne.

Exactement, comme tous les services publics : on paie pour les écoles même si on n'a pas de gamins, etc. Et il serait plus juste que ce soit pris sur le revenu (l'impot) et non au même tarif pour tout le monde.

> Pour cela, j'aimerai savoir la proportion de ce que gagne le service public par la redevance et par la publicité.

Normalement, avec la redevance, il gagne théoriquement en indépendance, ce qui est le principal intérêt. Quand on voit des chaines publiques faire la course à l'audimat, c'est une véritable insulte à tous ceux qui paient la redevance (quelle que soit la part de la pub et de la redevance).

Et le unstable de Debian ne m'a jamais fait un truc pareil.

« etch »
(mais c'est en fait décidé dans les derniers moments par le release manager).

Dans un projet avec plusieurs developpeur de niveau differents et d'horizon differents (c'est ce qui arrive le plus souvent, tu auras rarement un ensemble de developpeurs expert en perl ), je n'utiliserai pas le perl, car sa syntaxe n'est pas assez deterministe.

Je n'utiliserais pas Perl si plusieurs développeurs ne le connait pas. Ou alors il y aurait une partie du projet en Perl, avec un ou deux experts en Perl, le reste dans un autre langage. (en général c'est aussi une bonne idée de séparer bas et haut niveau avec des langages adaptés).

Car ce langage leur donnera trop de liberté syntaxique au détriment de la clarté que je recherche. Les niveaux des developpeurs étant hétérogènes, j'aurai trop peur de perdre du temps sur des faux problèmes.

Ce sont des contraintes que tu ajoutes (faible niveau de compétence), ça n'a rien à voir avec le langage puisque lui-même n'est pas plus difficile que d'autres : seulement si tu embauches un développeur Java pour le faire faire du Perl, c'est sûr que ça va poser problème. Prend un développeur Perl, quitte à payer la formation. Si ce n'est pas possible c'est une considération matérielle indépendante du langage.

Si pour toi, un bête incrémenteur 'index' dans une boucle for est inutile, je ne sais pas quoi te dire.

Tu n'as pas d'arguments justifiant sa présence ? Parce que je ne parle que des cas où il est effectivement inutile.

La boucle for est un élément clef dans l'algorithmique. Essaie de faire l'exemple suivant avec des foreach je vais bien me marrer.

Je ne comprends pas que tu programmes (apparemment avec pas mal d'expérience) en faisant autant d'erreurs de logique dans notre discussion : il y a des tonnes de cas où on va garder un for classique, évidemment ! Il ne faut pas être extrémiste : je parle bien de n'utiliser des notations plus claires que lorsqu'elles sont possibles, effectivement plus claires, ou aident à comprendre. Il n'est évidemment pas question de chercher à transformer tout for en foreach. Il est appréciable de le faire quand on parcourt un conteneur et que l'on n'a pas besoin de l'indice ou d'un itérateur, par exemple. J'espère que tu vois en quoi ton exemple n'apporte rien : bien sûr que souvent, il faut garder la forme avec index explicite ! Parfois, mais pas tout le temps. Une grande expressivité aide à employer la tournure la plus parlante, la plus compréhensible.

Avant, c'est une espace fine insécable. Vous êtes le maillon faible.

En Java (<= 1.4) ou en Ada, c est la syntaxe qui l'impose. C'est justement là ou je veux en venir. J'ai d'autres choix à fouetter (algorithmique, architecture, tuning, délais, etc ,) que de choisir parmi un ensemble de syntaxe (qui font là même chose !!! ) la plus expressive , "la meilleure" pour parcourir un tableau.

La syntaxe est aussi triviale à choisir qu'à lire. Les difficultés, comme tu le dis, sont ailleurs. Ce n'est vraiment pas un problème de pouvoir énoncer les choses clairement quand on le souhaite.

En java (<= 1.4) ta boucle for aura cette tête là. Note la présence de la variable d'index qui n'est pas sous-entendu comme en perl. "Ce qui ce conçoit bien, s'enonce clairement".

Les choses inutiles n'ont justement pas à être énoncées. Ca rend le code moins clair.

Le passage que tu donnes en exemple est infect, et je regrette bien de devoir souvent passer par ce genre de choses en C++. (for_each & compagnie aident bien quand même).

Le perl a développé tout un tas de mécanismes "pratiques" pour faire des raccourcis dans les scripts qui enlèvent à la clarté du code (ascii art)

Non c'est là pour la clarté. Evidemment ça ne parait pas clair à quelqu'un qui ne connait rien au langage : moi non plus le chinois (auquel je ne connais rien) ne me parait pas clair.

maintenant je n ai pas dis que ce n'est pas bien, je dit simplement que c'est moins clair !

C'est à la fois bien et plus clair. C'est un peu le but de la manoeuvre, on n'ajoute pas des choses dans un langage juste pour faire un peu de code à l'allure exotiques. C'est une véritable insulte aux concepteurs de ce langage. Java fait le choix de la simplicité de la syntaxe, et non de sa clarté. Un autre exemple : la surcharge des opérateurs, impossible en Java. Ne pas en avoir est plus simple, mais l'avoir et l'utiliser correctement est plus clair.

Un mec qui bien connait le perl développera super vite, au détriment de la portabilité, de la maintenance et de l'evolutivité.

C'est supposer que les gens chargés de la portabilité/maintenance sont des incompétents. Le développement se fait vite non pas parce qu'on gagne quelques caractères, mais parce que le code ne contient que des choses utiles. C'est pour ça que la maintenance est aussi plus simple, pourvu que l'on soit compétent, mais c'est une condition évidente et nécessaire pour tous les langages, y compris Java.

Je reprends donc. Un langage dont la syntaxe permet d'ecrire du code illisible qui est validé par l'interpréteur, n'est pas un langage avec une syntaxe claire, donc ce n'est pas un langage que je qualifierai de clair.

C'est alors ta notion de lisibilité qui est mauvaise. La lisibilité c'est la clarté d'un code pour quelqu'un de compétent, et non la clarté que tu supposes, toi, en étant peu (ou pas assez) compétent sur ce langage.

En perl la boucle for peut s'écrire de plusieurs façon differentes. Et si il prends à un développeur au cours d'un même script, d'utiliser toutes ces façons, le code n'est pas clair.

Non, s'imposer toujours la même écriture est parfaitement idiot : il faut, à chaque fois, choisir la meilleure, la plus expressive. Ainsi chaque boucle sera claire.

Donc comme le langage le permet, le langage n'est pas clair.

Mauvaise définition.

Si, et c'est juste après qu'on décide de tout formater, en général.

Si tu veux savoir pourquoi un paquet ne passe pas dans testing, voir (dans le cas de Gimp) : http://packages.qa.debian.org/g/gimp.html(...)

Si ça ne concerne que quelques paquets, regarde si un petit mix sarge/sid ne te ramène pas trop de dépendances de sid.

C'est normal, tu as du lancer vi depuis un shell emacs.

Monsieur est un petit drôle et attaché à la langue française en plus. Premièrement, rendons à Francky Vincent ce qui lui appartient il a dit "Il n'y a pas que la fesse dans la vie il y a le sexe aussi." Donc tu es totalement à coté de la plaque sur ce coup là. Tu voulais surement dire par là que dans ta vie tu fais pas que programmer et que toi tu avais des activités sexuelles, en tout cas tu devrais préciser parce que c est pas clair !! Mais bon dans le doute je précise, ne t en fais pas pour moi va !

Non, si ça peut te rassurer, tu n'as rien compris.

Revenons à nos moutons ! ton français était "Mais finalement au moment de choisir son langage, on regarde les priorités, et Java est rarement la solution" Il ne m'a fallu prendre qu'un exemple pour te contredire : le developpement web. J'aurai pu t'en prendre un autre mais cela suffit amplement. T'as juste dit que en fonction des priorités, java est rarement la solution, t'es resté (volontairement ou en manque d'arguments) dans le vague le plus complet, donc tu t es fait avoir !

Tu as de gros problèmes de logique. J'ai dit dès le départ qu'il y avait des contre-exemples, si j'avais pensé qu'il n'y en a pas, je n'aurait pas dit « rarement » mais « jamais ». Je pensais en particulier au développement web pour lequel la qualité de Java est reconnue, mais ce n'est pas un scoop, tout le monde est au courant. Le donner comme contre-exemple ne sert à rien et n'est pas une réponse. La contradiction serait de donner de nombreux contre-exemples variés.

Bon monsieur veut des exemples du spectre alors on va lui en donner. On va même prendre perl à coté comme tu as l'air de bien aimé (moi aussi cela dit :) pour que tu vois bien la différence :
...
Bref voici une partie du spectre de java et celui de perl tu vois bien qu'il n'y a pas photos

Ces exemples ne valent rien : il faudrait que Java soit au même niveau que son premier concurrent, en fonction du domaine. Il va de soi que ce concurrent n'est pas toujours Perl. A nouveau, tu fais une grossière erreur de logique en répondant.

Tu réponds avec de grosses erreurs de logique, et en prenant tout au premier degré. N'en fais pas si long les prochaines fois, car comme tu réponds à coté je crois que tu perds vraiment ton temps.

Si c'est un argument ! un langage de programmation doit pouvoir s'ecrire clairement !

Perl s'écrit clairement. Encore faut-il être compétent avant de prétendre lire ou écrire dans un langage donné. Si tu veux critiquer des gens qui font de l'obsuscation, critique-les, faire ce genre de choses en Perl, en C ou en Java est aussi idiot. Mais ça n'a rien à voir avec le langage. Un langage permettant une plus grande élégance dans l'expression peut sans doute être détourné plus facilement pour de l'obfuscation, mais ce n'est certainement pas un argument contre le langage.

Si justement la documentation des apis et du langage ont à avoir avec le langage lui même, si tu ne sais pas quel fonction appeler pour une action donné ton langage n'est pas opérationnel !

Comme je le disais ça n'a rien à voir avec le langage, mais quoiqu'il en soit C++ ne manque pas de bonne documentation. Evidemment si on ne connait que le C++ Pour Les Nuls ou livre du même niveau, on ne va pas loin.

Encore une fois tu n'argumentes pas ! dans quel cas l'objet est adapté ?
Dans Java <= 1.4 tout n'est pas objet les type primitifs ne le sont pas.

Ce n'est pas sérieux, tu es incapable de tenir une contre-argumentation. On parlait de la bibliothèque dans ce passage, son approche objet étant censée être miraculeuse. J'ai souligné que c'était une affirmation gratuite et tu n'as rien apporté de plus. Et surtout tu n'as pas compris le sujet de la discussion. Tu réponds tout le temps à coté en passant à coté des arguments soutenus.

C# corrige quoi comme défauts ? je suppose en plus que tu ne parles que de la syntaxe !

Les templates ce n'est pas que de la syntaxe. Si tu ne connaît pas Google je te le conseille pour tes recherches : http://www.google.fr(...)

Si c'est la mémoire, ça ne devrait pas planter aussi avec Linux ? (même machine)

Suis-je le seul à aussi expérimenter des plantages de Windows XP ? J'entends souvent parler d'incroyable stabilité de cet OS, mais il me semble qu'il l'est surtout comparé à ses prédécesseurs, mais que ce n'est pas encore tout à fait ça... ou je n'ai vraiment pas eu de bol et c'est la Main de Dieu soi-même qui m'incite à fuir cet éditeur ?

Perl, c'est bon pour ceux qui aiment la programmation de scripts, mais pour ceux qui veulent un langage de haut niveau avec une syntaxe qui soit autre chose que de l'ascii art, mieux vaut passer à autre chose !

J'espère que ce n'est pas un argument. Je ne suis pas fan de Perl mais c'est un langage de haut niveau (les autres feraient bien de s'en inspirer sur certains points), obscur quand on ne connait pas (normal) mais néanmoins élégant. Je n'en ai pas beaucoup fait mais ça m'a suffit pour ensuite regretter $_ ou les listes dans d'autres langages, sans parler d'une écriture souvent plus naturelle (un for qui prend un tableau sans s'emmerder avec les indices, par exemple).

Franchement dans C++ combien de fois a-t-on chercher la doc pour des fonctions sans la trouver ?

Ca n'a pas grand rapport avec le langage, mais si tu veux que je te trouve de mauvais bouquins sur Java ça doit pouvoir se faire. Avec de bons bouquins, je n'ai pas eu ce problème là en C++.

En plus la librairie standard java a vraiment une approche orientée objet alors que C++ ça n'est pas vraiment le cas (trace du bon vieux C)

J'espère que ce n'est pas censé être un avantage. L'objet c'est bien là où c'est adapté. Le fait de forcer tout à être objet, même quand ça complique, est un inconvénient. Où est-ce que la SL n'est pas suffisamment objet ?

Bref si java était vraiment libre ça serait le top, mais il ne faut pas se voiler la face, c'est un produit propriétaire bien plus ouvert que ses concurrents ! (Faites confiance à Krosoft et .Net !)

C# corrige de nombreux défauts de Java mais en effet, étant donné le danger Microsoft, il est exclu.

Moi ça me fait bien rire quand tu dis "Mais finalement au moment de choisir son langage, on regarde les priorités, et Java est rarement la solution" Je vais rester dans un contexte précis que je n'ai pas donné en example juste avant "le developpement d'application web". Soit avant de dire ça tu n as pas testé, soit c est de la mauvaise foi !!

Non je me suis simplement exprimé en français, avec des mots français, dans leur sens français. Rarement ne veut pas dire qu'il n'est jamais la solution. Et si je n'ai pas dit jamais c'est bien parce qu'il y a un domaine où Java est la solution : le développement web. Nous sommes bien d'accord là-dessus. Mais pour reprendre le bon mot de Francky Vincent : « il n'y a pas que le développement web dans la vie, il y a le sexe aussi ».

Un langage ne peut forcément pas répondre à tous les besoins comme tu dis. Mais avec java tu as pris un mauvais exemple car il a un très large spectre !

Justement non, tu as été obligé de prendre comme exemple le seul domaine où il est vraiment le langage le plus adapté. C'est pas un large spectre ça.