Alex a écrit 1849 commentaires

C'est un choix, qu'on fait la plupart des langages de scripts pour garder la possibilité d'avoir des bindings C, sans pour autant se casser la tête à savoir ce qui est thread safe ou pas. Au final on peut tout de même utiliser le multicore à "l'ancienne" à coup de forks.
On critique la lourdeur de java, la question est de savoir si forker n fois une vm n'est au final pas plus consommateur de ressources (ptet pas pour 2 cores... mais bon quand on voit qu'intel à préparer un proto à 80 cores...)

Changer de langage (Si j'ai bien compris, Jython ou IronPython ne sont pas 100% compatible avec Python, c'est ça?)

jconnais pas python, mais si jai tout compris, si le langage reste le même, c'est tout ce qui a autour qui change (bindings C d'un coté, java ou .net de l'autre). Etant donné la variété de libs java qui éxiste, je ne pense pas que ça soit un gros problème. En fait AMHA la question est de savoir si les frameworks python (django, zope et cie) sont compatibles.

c'est ce que fait eclipse pourtant.

C'est bien ce que je disais ;)
Squeak arrive à faire ça très bien sans pour autant faire bruller ma machine ;)

Completement

A la rigueur je préfère la méthode c++ avec des valeurs par défaut aux paramètres

enfin ca indique surtout que l'approche des threads n'est pas la seule pour exploiter les machines multi-coeurs/processeurs.
Les threads pratiques ? évidemment, mais ils apportent leur lots de galères
Les forks plus surs ? surement, mais ça manque de souplesse. L'idéal serait encore de laisser le choix aux dev (c'est un peu le cas avec jython ou jruby, mais je me laisse dire que ces implémentations ne sont pas encore au point, en tout cas c'est le cas pour jruby).

Néanmoins l'appoche de python semble avoir été faite dans un soucis de gain de perfs si j'en crois ce qui a été écrit ailleurs dans cette discussion.

enfin bref, ce qui interesse cest un bon ide
et un bon ide ne se prend pas la tête à compiler à chaque fois que tu tapes une ligne, sinon quelle horreur pour les ressources.

Bon je suis daccord pour rails, a mon grand malheur.
Néanmoins faut pas éxagerer, php et python sont énormément utilisés, même si bien sur on reste loin de java.

Ah ces SSII, qu'est ce qu'elles attendent pour coder en Python ? Qui veut coder une application qui dans 10 ans sera inmaintenable parcque Python 5 aura cassé 2 fois la compatibilité

Mouais, enfin cest argument était également applicable à java à sa sortie : pourquoi prendre le risque de miser sur une techno faites pour l'embarqué, alors qu'on avait déjà smalltalk, c++, etc... et dont on avait à l'époque pas plus de garantie sur la compatibilité ascendante.

Gni ? Une analyse statique ça peut être bien bourrain potentiellement suivant ce que tu veux analyser ... étant donné la difficulté du problème de vérification du code.

Tout à fait, je pensais en fait juste aux erreurs de syntaxes et de typage, bref ce que le compilo vérifie également

Pour être complètement honnête, je n'ai utiliser la compilation incrémentale qu'en c++, ou éclipse refait un make all à chaque fois. Possible qu'en java cela soit mieu géré.

Pour ton histoire de pointeur, pas compris à quoi tu voulais faire référence

http://techbase.kde.org/Policies/Binary_Compatibility_Issues(...)
En c++ ce genre de truc est nécéssaire pour assurer la compatibilitée de tes libs. En réalité c'est un problème de mangling, mais bon, du point de vue développeur, ton programme plante à l'utilisation d'une classe précise (raccourci facile ? bon daccord... ;) )

je pense que tu dérives un peu du débat, on parlait juste de la compilation.
Ce que je voulais dire, c'est que par exemple en ocaml on peut développer en mode interprété et compiler pour la livraison, il me semble qu'en python c'est également le cas, où l'on peut compiler en pyc pour la livraison.

La compilation incrémentale peut être un plus, en pratique sous eclipse ça a plus tendance à mettre ma machine sur les genoux et à m'empecher de bosser, de plus le fait de compiler est toujours plus lourd qu'une "simple" analyse statique du code.

Au sujet du duck typing je suis daccord avec toi, néanmoins ça arrive aussi avec du code compilé, comme par exemple en C++ quand le dev de la lib oublie d'utiliser un pointeur d ( c'est du vécu... et en plus c'était moi le dev en question ;) )

Allez j'en rajoute une couche,
ton compilateur qui sert à rien :
- il rend ton programme plus rapide que si celui-ci était interprété
- il me permet de transformer mon programme dans un format standard utilisable par d'autre langages et outils.
- il me permet d'obtenir un fichier "portable" sans seposer de question existentielle sur l'encodage par défaut sur telle ou telle machine.

J'ai tendance a être daccord avec ploum
oui tu donnes de bonnes raisons d'utiliser un compilo, mais en phase de dev, je trouve que c'est un poids, une vérif statique du code ou une compile entre midi et 2 ou la nuit, ça me suffit, le reste du temps je trouve que c'est un poids, car souvent long.

De rien, mais en fait j'ai éxagéré en parlant de script de 3 lignes
Ca ca me permet de faire une copie de chaque fichier que je change.
Si tu utilises plusieurs machines simultanément, il faut aussi que le serveur t'indique si il a un nouveau fichier.

Pour ça j'utilise knockd, ça ne sert pas à ça, mais c'est une manière comme un autre pour que ma machine indique qu'elle est connectée au près du serveur, le serveur ensuite lance le même script avec l'ip de mon pc.

Cette outil m'a l'air très bien, mais finalement, c'est un outil de backup, alors que dropbox me semble plus être un outil de synchro, qui permet donc de faire des mises à jours dans les 2 sens (pc <-> serv, au lieu de pc->serv).
Lorsque plusieurs machines se synchronisent au près de ce serveur, je ne suis pas sur que cet outil soit adapté.

ah oui, faut également aussi lancer unison au tout début pour récuperer les dernières modifs présentent sur le serv.

euh jsuis au taf, donc jlai pas sous la main
mais en gros il ressemble à ça (méthode larrache)


while test 1
do
/bin/ping -c1 <mon serv> &> /dev/null
if [ "$?" = "0" ]
then
inotifywait -r -e create,modify,delete,move --format "%f" -q ~/Documents/ --excludei "\.?.*(~|tmp|swp)" | uniq | xargs --no-run-if-empty -n1 -I {} unison documents -ui text -batch
else
sleep 120
fi
done


en gros, je teste que mon serv est accessible, j'utilise inotifywait pour surveiller mon repertoire ~/Documents/ et je balance tout à unison.
A noter que je viens de le tester rapidement ici, et l'option create pour inotifywait me fait n'importe quoi, je n'ai ce problème de chez moi.

le 800
surtout que la "norme" est plus vers des barres de menus horizontales
sous kde on peux passer a peu près tout sur les cotés, ce n'est malheureusement pas toujours le cas, comme avec mozo

sous linux inotifywait + unison + 3 lignes de scripts + mon serv
marche très bien, je l'utilise pour mes photos , bookmarks, etc... et je chiffre le tout
Bon bien sur je paye un serveur dédié, mais je crois bien qu'il éxiste un module fuse pour gmailfs

Par contre pourquoi une ihm ? jsuis pas anti-clickodrome, mais après tout l'interêt de ce genre de solution c'est d'être invisible pour l'utilisateur

Jsuis loin d'être un pro du smalltalk, mais il me semble que gnu smalltalk ne propose pas l'environement associé, de plus il est sous license gpl.

Et pourquoi pas piet
On pourrait enfin faire comprendre à l'humanité, et surtout à madame Michu, qu'un geek, c'est avant tout un artiste !

En termes de perf pour les cgi, cest pas vraiment mieu que du script (même pire), surtout à haute charge. A moin de tout faire dans un module apache.

Et d'un autre côté je ne sais pas si c'est une bonne chose que ça se généralise car ça bouffe de la place avec des doublons (comme sous Windows ou MacOSX).

En même temps l'important n'est il pas d'avoir le choix
Si monsieur Beranger se plaind du cycle de release (hors de tout ce qui est distro spécifique bien sur), il peut utiliser ce système là
La question est bien sur : est-ce que ca ne peut pas casser le système, est-ce que c'est proprement désinstallable.

Tu as de la chance, j'ai toujours eu du mal à afficher correctement du flash avec konqui

ben voilà un autre exemple alors

Tu disais que tu regrettais l'époque où les chose était juste stable, donc avant OOo d'où ma question, tu faisait comment avant? Et pourquoi tu ne peux plus l'utiliser.

avant je faisais de l'ascii avec emacs, ou en effet du latex. Pourquoi je n'utilise plus ses outils ? ben parce que mes besoins ont évolué: il faut que je fasse mes docs plus vite, tout en intégrant des données provenant d'un tableur, etc... c'est possible en tex, mais cest beaucoup plus chiant

2 prefix différents ? c'est comme ça que j'ai fait (bon daccord, tout est dans /opt, c'est pas ce qui a de plus propre)
D'autres distro l'ont fait aussi
Mais bon je veux pas lancer de troll, ils ont sans aucun doute des raisons d'avoir fait ce choix
Je le trouve tout de même étonnant.
En même temps si on considère que c'est un mauvais choix, doit on en vouloir a la distro, qui si je ne me trompe pas, à comme principe de livrer les dernières versions stables, ou a kde qui a annoncé que kde était stable.

C'est une critique d'un logiciel proprio mal adapté à Linux, si était libre, il serait sans doute meilleur.


cest surement vrai, mais là c'était une critique à firefox, sous konqui, je peux limiter les ressources prises par flash, et bizarrement ça va plus vite.
Néanmoins tu as raison, flash serait libre ou le format ouvert, il n'y aurait pas besoin de rajouter un moyen de limiter les ressources que le plugin utilise

Et avant OOo, tu utilisais quoi pour rédiger des textes, vi+latex? Tu peux toujours le faire.

Ce n'est pas le problème, et accessoirement, OOo, ce n'est pas qu'un traitement de texte
Ce que je dis, c'est qu'on se retrouve avec des outils non finit. AMHA il est plus judicieu d'avoir un outil qui fait bien son travail, plutot que de tenter de tout faire.

mdr ;)

non, et quand je parle de linux, je parle de GNU/Linux en général, pas d'une distro spécifique.
Quand je dis "baisse en qualité", c'est que je trouve mon système moin stable. Je trouve de plus en plus de features, mais qui ne marche pas toujours, typiquement, le support des webcams dans kopete, qui lors des premières versions ne marchait pas du tout,
Kde4 qui est sortit en étant loin d'être finit,
le support de flash dans firefox me prend tout mon proc,
OOo qui est pour moi d'une lourdeur catastrophique et d'une stabilité douteuse
etc...

Bref, a mon avis, linux esasye trop de suivre les autres, et c'est sans doute ce qu'il faut faire si on veut attirer du monde, mais j'ai le regret de l'époque ou les choses étaient juste stables

Bon par contre je t'accorde qu'il y a eu de gros progrès : je ne prends plus 3 jours pour faire marcher ma carte son, je ne passe plus 3h a chercher sous quel est le nom de je ne sais plus quel disque, etc...

Avec kubuntu 8.10 y a plus de paquets 3.5

Autant pour moi, je ne savais pas
Moi aussi je trouve cette décision étonnante

kde4 est un peu une beta... c'est bien dommage...
en même temps, si tu n'aimais pas gnome, rien ne t'empêche de rester sur kde 3.5.x