reno a écrit 3886 commentaires

'permis' n'est toujours pas le bon mot.

De toute manière, c'est une statistique biaisée: imaginons que ton OS te fournisse un moyen simple de faire tourner une appli que tu télécharge dans une sandbox,
par exemple: par défaut l'appli n'a le droit que d'accéder qu'a son propre répertoire disque.
Je parie que les 44% diminuerait pas mal, alors ces 44% c'est vraiment un problème d'interface chaise-clavier où bien d'OS?
Pas si facile à dire..

NB: Windows est un coupable assez facile, Linux ne m'a pas l'air bien mieux: il me semple qu'une appli X peut espionner les autres appli X, donc coté sécurité..

Donc tu n'aimes pas Scala car tu trouves qu'il a "Plein de syntaxes différentes pour dire la même chose" mais tu aimes Haskell?
Je trouve ça amusant..

Si C est encore utilisé aujourd'hui, c'est bien la preuve de ses indéniables qualités

Si le COBOL est encore utilisé aujourd'hui, c'est bien la preuve de ses indéniables qualités.

Donc je dirais que ta preuve est un peu fragile: C est très utilisé oui, mais pas que pour ses qualités, aussi par l'effet de "base installée": disponibilités de programmeurs, d'outils, etc..

on arrête d’utiliser ce que Steve Jobs a apporté, 5% des gens n’aurait plus d’ordinateurs et beaucoup n’aurai plus de baladeur/smartphone.
Si on arrête d’utiliser ce que Dennis Ritchie a apporté, 95% de ce qui est informatique ne fonctionne plus

Oui, enfin ce type de raisonnement a ses limites: Steve Jobs n'est pas le seul à se préoccuper du "design" des ordinateurs, il y a Sony par exemple et
si le C n'avait pas été inventé les gens n'auraient pas arrêté de faire de l'informatique: ils auraient utilisé un autre langages..

D'ailleurs si Richie est surtout connu pour le C, je préfère beaucoup Limbo, dommage qu'il n'ai pas eu de succès..

T'es quand même de mauvaise foi:
- Une base de registre est tout sauf une mauvaise idée

Donc ceux qui ne sont pas d'accord avec toi sont de mauvaise foi??
C'est intéressant comme point de vue! --> -1

Par contre, si quelqu'un peut me dire qui est le type à droite sur la photo…
C'est un ami de Dominique Strauss Kahn.

Bah, non: lui il n'y a jamais eu de doute que ses "coucheries" était avec une volontaire et non pas des viols..

L'optique "tout repose sur gnome-session" fait des outils gnome qui ne fonctionnent plus en dehors de gnome...

KDE y vient aussi apparemment: ils veulent remplacer xscreensaver par une implémentation dans kwin:
http://blog.martin-graesslin.com/blog/2011/10/new-screen-locker/

Ces derniers temps, le développeur à compris qu'il fallait arrêter d'implémenter de nouvelles fonctionnalités et il s'attache à réparer tous les bugs.

Normal: la bourse Européenne qui finançait Nepomuk est finie et maintenant il demande aux utilisateurs de le financer donc il fait ce qu'ils veulent: c'est à dire corriger les bugs pas implémenter des nouvelles fonctionnalités.

Maintenant pourquoi les devs KDE ont autorisé que Nepomuk soit activé par défaut quand il était dans le mode 'je me focalise sur les nouvelles fonctionnalités', autorisant même l'intégration d'une réécriture partielle intégrée APRES la dernière RC, ça je ne comprendrais jamais..

Je serai méchant je dirais qu'ils doivent trop s'occuper de la nouvelle nouveauté(Plasma Active) pour s’intéresser à quelque chose d'aussi banal que d'activer par défaut uniquement du code mature.

Linux fait exactement la même chose, quelqu'un propose une API l'implémente, on l'utilise, si c'est pas bon, on casse.

N'importe quoi: ça c'est vrai uniquement pour les API interne à Linux, les API externes du kernel sont très stables elle.

Le problème ne serait pas plutôt le manque de manpower chez Slackware ?

Ce serait plutôt qu'ils préféreraient une évolution "à la FreeBSD": on ne torche pas une API pour la refaire ensuite tous les 15 jours (PolicyKit, HAL and systemd..) , on prend le temps pour en faire une propre et ensuite elle dure, de ce point de vue là l'écosystème Linux c'est pas terrible..

Est-ce qu'on peut dissocier la non utilisation de Null d'une gestion d'exceptions ?

Oui: si tu as des types "non-nullable" et que tu essaye de leur affecter un type "nullable" alors tu as une erreur de compilation.
Pour convertir un types "nullables", en "non-nullable", il y a des langages qui fournissent le moyen de faire ça sans exception:
Exemple si une variable toto est de de type 'Toto?' (le point d'interrogation indiquant que ce type est nullable) alors
IfNotNull (toto) {
ici toto est considéré de type 'Toto' pas 'Toto?'
}

Je connais des allergiques aux exceptions (pourquoi ? je n'ai jamais réussi à avoir d'explication convaincantes)

Parce que ça complique la lecture de code car les exceptions peuvent te faire sauter 'n'importe où' aisément, ce qui complique les choses,
si tu lis l'Anglais va voir ici: http://www.d-programming-language.org/exception-safe.html
pour une bonne exposition du problème créer par les exceptions et des moyens possible de le contourner.

Intéressant: un avis opposé au mien, et c'est quoi les langages que tu préfères à Scala?
LISP? Python? Ils ont tout les 2 un typage dynamique ce qui a quand même pas mal de conséquences (perf, erreur détecté à l'exécution vs la compilation).

Ça me rappelle la fois où on prenait comme référence sur webm l'avis d'un développeur x264...

Hum, hum, c'est un raccourci très rapide: un développeur d'un codec vidéo sera beaucoup plus apte qu'un quidam moyen a faire une analyse technique d'un codec.
Maintenant son analyse sera t'elle biaisée par la compétition entre les codec?
Et bien ça dépend du gars et de la situation..

Pour un développeur "pur open-source" on pourrait espérer que, n'ayant pas d'intérêt financier dans la comparaison, il reste neutre,
pour ce développeur x264 il faut être rester prudent car leur projet est aussi intégrer dans des produits vendus.

Oups: D2 me paraît pas^Wassez intéressant.

Merci! Pas intuitif comme solution mais efficace.

Dans le etc, tu oublie quand même: implémentations pas forcément matures, syntaxe pas mal mais pas terrible par rapport à Scala.

Mais oui, D2 me paraît pas intéressant.

Le langage ML original a été développé dans les années 70.

Et a été très peu utilisé..
Je parlais de l'histoire vu par les langage "populaire", je te l'accorde c'est une vision très différente par rapport à l'histoire vu par les chercheurs.

Note que PBPG n'est pas le seul a critiquer ODF, je me souviens (vaguement) qu'un développeur d'AbiWord avait donné une interview dans laquelle il était assez critique de certains points d'ODF et j'avais trouver dommage qu'il ne participait pas au processus de normalisation car ses critiques me paraissait intéréssantes.

Je trouve amusant de soutenir Ada lors d'une critique sur la nécessité de se répéter: il me semble qu'Ada n'a pas l'inférence de type locale, non?

Historiquement parlant le typage dynamique (ce qui est très différence du "non typage") avait le gros avantage de faire du code plus court et plus lisible: pas besoin de répéter le type partout dans les déclarations de variable, ni de dupliquer du code pour la surcharge de fonctions.

Bon cet avantage a été quasiment annuler par 2 choses:
1- l'inférence de type ce qui permet d'éviter de déclarer le type des variables dans beaucoup de cas
2- les templates/generic qui permettent d'écrire une fonction qui sera appliqué a plusieurs types.

Ceci dit je trouve qu'en C++, les templates c'est plus pénible a lire qu'une fonction équivalente dans un langage a typage dynamique à cause de la syntaxe lourde, j'ignore s'il existe un langage statiquement typé avec une syntaxe agréable pour les templates/generic mais si c'est possible alors je ne vois effectivement plus d'intérêt pour les langages à typage dynamique..

Par rapport à Dart: ne supporte pas le typage optionel (bon je sais il y a Cython), multi-threadé vs mono-threadé (a la Erlang) ce qui doit ralentir la VM.
Par rapport à Javascript: pas implémenter par les navigateurs!

Et beaucoup plus important comme changement que le ';'!

Si je ne me trompes pas en JavaScript, tout les nombres sont des flottants ce qui conduit parfois a des comportements très bizarre (genre x+1 est égal à x), zlors que Dart a des entiers type 'big int' et des flottants sur 64 bit.

Je ne sais pas si en pratique c'est vraiment un problème pour les programmeurs JavaScript, mais cela me parait beaucoup plus sain comme comportement..

L'exemple est mauvais car il fait référence a une langage informatique alors qu'on parle d'un langage humain.
Ceci dit (et je fais partie de ceux qui pensent que Perl c'est de la daube) dans un langage humain "il y a plus d'une manière de faire" n'est pas si problématique et puis c'est une question de dose..