reno a écrit 3888 commentaires

>le fait qu'ils nous vendent toujours de l'ADSL au lieu de SDSL

Pas la première fois que je vois cet argument qui m'a l'air assez spécieux: la plupart des consommateurs utilisent beaucoup plus de download que d'upload, donc les opérateurs se sont adaptés en proposant l'ADSL.

C'est donc plus difficile de trouver des offre SDSL qui sont plus cher.

OK, mais je ne vois pas ou est le probleme: du point de vue économique cela me parait tout à faire normal: si tes besoins sont différents de la majorité des clients, tu paye plus cher.

Il est ou le problème?

>>Ce qu'il y a d'extraordinaire avec Perl ce sont les clichés qu'il trimballe.<<

Bof, certains des clichès invalides, tu les as ressorti toi même (je ne me souviens pas avoir lu dans ce sujet que Perl n'était utilisé que pour de petit programmes et c'est faux hélas).

>> Tout le monde que Perl c'est illisible, donc Perl est illisible. (sur ce point il est ex-æquo avec ce pauvre LISP qui dispose pourtant de la syntaxe la plus simple qui soit) <<

Si tu manges sans sel ce n'est pas très bon, si tu manges trop salé, ce n'est pas bon non plus.
Créer un langage qui soit utiliser pour faire des programmes lisibles 'par défaut', c'est comme faire la cuisine c'est un équilibre délicat: il ne faut pas être trop artificiel comme Lisp ou trop 'baroque' comme le Perl, ceci dit il y a encore pire que le Perl: APL!


>> Faire du Perl "maintenable" et lisible (pour quelqu'un qui connaît un peu le langage évidemment), c'est FACILE <<

Je ne dirais pas facile, mais juste "pas difficile".
Le problème c'est que:
1) ce n'est pas le comportement par défaut donc les débutant ne le font pas
2) ce n'est pas vraiment encouragé car beaucoup d'exemples que tu trouves sur le web n'utilisent même pas les bases comme 'use strict' et autre.
3) très peu de programmeurs expérimenté le font, car ils préfèrent utiliser leur idiome..
Donc ce qui est facile en théorie, est rarement appliqué en pratique..

Mouai, bah il peut défendre son TMTOWTDI tant qu'il veux Larry Wall, moi je vois que quand je lis du code Perl, 9 fois sur 10, ça m'explose le cerveau ce qui est moins le cas pour du Python (et aussi Ruby): et pourtant j'ai eu une formation en Perl mais pas en Python!

Donc si j'ai le choix entre faire du Perl ou du Ruby|Python, je ne choisirai pas Perl, malheureusement je n'ai pas le choix à cause de la base installée en Perl: de mon point de vue, Perl est le COBOL des langages de scripts.

Pour ce qui est de voir le coté programmation par script, bof, a par le poids de l'existant, je ne vois pas trop ce que Perl apporte par rapport a Ruby ou Python.

La remarque de letsyl me parait pertinente d'un point de vue encapsulation si le display doit connaittre tout tes objets, c'est pas terrible comme encapsulation.
Et '"Hello world".print();' est un raccourci de '"Hello world".print(display)'

Personnellement j'aurais mis D comme 'langage systeme' a la place de Go: il est développé depuis plus longtemps et me parait mieux armé comme alternative au C++.

Je connais le langage (Perl5 pas Perl6 qui est un tout autre langage malgrès le nom) et plus je connais moins j'aime donc je suis d'accord que tu ne loupes rien.

C'est un langage assez difficile a apprendre, les débutants font donc du code assez horrible, ça c'est assez normal, par contre là ou c'est plus génant c'est que les gens expérimenter en Perl ont développer chacun leur propre style et là niveau maintenance c'est pas terrible!

Ben voyons, et tu vas me dire donc que XSLT est une syntaxe agréable? Pareil pour APL?

Visiblement l'auteur de reia aime bien les objets 'lourds': d'après l'example, String a une methode puts et d'après son blog une methode 'parse': '2+2'.parse.

Bof, ce n'est pas le style que je prefere mais bon le langage a l'air intéressant parce que la syntaxe d'Erlang, beurk!

>UML c'est juste un ensemble de pictogrammes dont tu fais ce que tu veux.

Pictogrammes assez mal fichu: un rond plein ça dire X, un rond vide Y, bof..

Pourquoi pas mettre tout simplement des nombre au dessus des fleches pour indiquer le nombre de relations possible.

Les parentheses 'inutiles' montrent au lecteur qu'il s'agit d'un appel de fonction, en plus ici avec effet de bord!, je ne les trouve pas si inutiles..

Je ne vois pas en quoi le coté XML intervient la dedans: XSLT ce n'est pas du code selon toi??

Et bien ça dépend des images, une image SVG peut être considérèe comme du code je pense.

Uniquement si tu as une vision très, très limitée (limite aveugle): tout ce qui est produit par ou pour l'international et qui contient un codec MPEG-4, tu paye potentiellement(*) pour ça dans le prix de l'appareil.

Et donner de l'argent a MPEG-LA ne me parait vraiment pas une bonne idée!

*: car dans certains cas MPEG-LA ne fait pas (encore) payer: ils attendent que le poisson soit bien ferrer.

>> Car arriver à coller des bouts de code qui ont l'air de rien lors des relectures, qui ne sont pas obfusqués, mais qui supportent donc un certain type "d'appel" permettant de mettre en route des fonctionnalités cachées, ce n'est plus que du code, c'est du grand art. <<

Du grand art, oui, mais ce n'est pas impossible: il y a même un concour basé sur ce sujet: codé en C quelque-chose qui semble correct mais ne l'est pas.
La sémantique du C étant assez pourrie (variables non-itialisées par défaut, non-détection des débordements entier, des débordements de tableaux), les meilleures entrées dans le concours sont excellentes!

En Ada, ce serait déjà plus difficile..

Pas totalement indetectable, tu retardes..
En utilisant un autre compilateur, on peut trouver le probleme:
http://www.dwheeler.com/trusting-trust/dissertation/html/wheeler-trusting-trust-ddc.html

Probabilité moindre je suis d'accord, mais moindre n'est pas nul: souvient-toi du bug de l'installeur Ubuntu, c'est du même niveau:
https://launchpad.net/ubuntu/+bug/34606

>> Du coup, C ou Java, qui simplifient certains principes à l'extrême (genre pas de tail-call-optimisation et obligation de construire soi-même son trampoline, gestion de la mémoire incompréhensible "pour votre bien", etc. ) correspondent bien mieux à la définition du "worse is better". <<

Tu as du te planter dans tes exemples: Java a un GC..

Pour le TCO, quand je vois comment la plupart des examples qui utilisent TCO sont moches franchement cela ne me manque pas, beurk..

Pour C++, ce n'est pas tellement "worse is better" mais "cheap is better" a mon avis le C++ doit son succès au fait qu'il a des performances plutôt bonne et a eu une compilateur gratuit rapidement, le DoD aurait dut sponsoriser un compilateur gratuit pour Ada beaucoup plus tôt: maintenant tout le monde utiliserait Ada au lieu de C++..

>> - System.Web : le namespace pour faire des requêtes HTTP... Si Microsoft a des brevets là dessus, c'est pas les applications Mono qui vont avoir spécifiquement des enmerdes, c'est beaucoup plus de monde. <<

La, tu exageres, tu sait très bien que Microsoft peut avoir des brevets sur l'implementation de System.Web sans qu'ils aient des brevets sur HTTP.

En plus pour ton point, les drafts ça peut durer *très longtemps* parfois, voire ne jamais se concrètiser donc je trouve loin d'être ridicule de le compter.

> A l'époque, un recruteur ne venait pas te dire : "Vous êtes pas sur FB, vous avez sûrement des trucs à cacher"

Bôf, "Les cons ça ose tout, c'est même à ça qu'on les reconnait." je ne vois pas en quoi c'est une spécialité FB.

Tu lui réponds que tu préfère parler à tes ami(e)s en direct et puis c'est tout.

> Le rapport à la vie privée était différent

"vie privée" hum, si tu prends le comportement (raisonnable) que tout ce que tu mets sur FB est publique, ça limite déjà beaucoup le problème.

commencer a fumer est débile car l'acte de fumer est néfaste pour la santé, donc pour que ton analogie tienne la route, il faut que tu démontre que FB soit néfaste pour la santé..

Donc ton analogie est toute pourrie.

Les coté néfaste de FBs sont:
1) dévoiler sa vie privée sur FB/critiquer son boulot sur FB, la c'est stupide car par définition tout ce que tu mets en ligne est potentiellement publique,
2) quelqu'un te prend en photo dans une situation spécieuse, t'attaque dans un texte.

Pour le (1), il suffit de réfléchir dans ce qu'on met en ligne.
Pour le (2), ce n'est pas limité a FB ,un blog ça marche pareil et ça marchait même déjà avec le courrier postal avant!

Exactement.

Pour répondre, à Axioplase note que je n'ai jamais dit qu'un appel de fonction non terminal pouvait être préférable à un appel de fonction terminal.
J'ai juste dit que s'il n'y a pas d'annotation, il est très facile dans une maintenance de modifier une fonction en rendant le dernier appel non terminal..

> La D2 est stable

Ahem, ça dépend de la définition de stable..
Ma définition de stable, c'est stable comme un compilateur C.
D2 en est loin..
La spec est stable, les implémentations .. non.

Au niveau de la syntaxe D est pas mal effectivement, dommage qu'il ait gardé la syntaxe de la déclaration de variable a la C, heureusement qu'il y a l'inférence de type..

> Note: GDC sera intégré en standard a partir de gcc 4.7

ça c'est une très bonne nouvelle!!

Il a bossé sur trop de langages shapiro (Eros, BitC, ...), je n'ai pas réussi à retrouver ou il mettait cela.

Mais tu as raison qu'un type de retour vide permet d'éviter ça..

Non, je n'en connais pas, mais ce serait une annotation intéréssante d'un point de vue maintenance d'un programme..

> C'est faux. Ce problème a été réglé.

Dis plutôt que ce problème est en train d'être regler pour D2 (qui il me semble n'est pas encore sorti en version stable), mais que problème restera pour D1 ou la communauté des utilisateurs devant le manque de fonctionnalité de Phobos a realisé une autre 'librairie standard' incompatible techniquement et avec aussi une licence differente de celle de Phobos (une recherche google sur "SHOO's time library" montre bien le bazar résultant).

Ce qu'on peut résumer facilement en: un *gros* bordel, qui ne donne vraiment pas confiance dans la "plateforme D"..

Ce n'est donc *pas* un mauvais argument..