Moonz a écrit 3537 commentaires

> , d'ailleurs, les seuls moments où on a recours au pointeur de char, c'est des "const char*", donc pas pour les manipuler.
Haem...
http://cplusplus.com/reference/iostream/istream/getline.html
http://cplusplus.com/reference/iostream/streambuf/xsgetn.htm(...)

> en C++, on n'utilise pas de chaine de charactères en char*
Tu veux dire, comme avec std::fstream ? :)

Tu as raison, j'ai posté trop vite.
Mea culpa, la prochaine fois je tournerai ma langue 7 fois avant de cliquer sur envoyer (je dis ça à chaque fois...)

> Non. On n'a pas besoin de trier un ensemble pour en extraire les éléments uniques.
Oui, mais avec une complexité (algorithmique, s'entend) beaucoup plus grande...

Bon, on va répéter pour ceux au fond qui n'ont pas écoutés:
Le but est (entre autre) d'être directement et nativement compatible au niveau ABI (et quasi immédiatement au niveau API) avec GObject (c'est un projet Gnome, après tout), même pour le modèle objet. Tu peux m'expliquer comment tu fais ça avec D ? L'ABI de D est très proches de celle du C++, et n'a rien à voir avec celle de Vala/GObject qui est du pur C.

Pour faire encore plus clair, supposons que je fasse en Vala puis en C++ ou en D une classe Foo avec une méthode bar. Maintenant, je veux appeler cette méthode dans un programme C (disons, pour simplifier, que j'ai déjà une instance f). Si ça a été codé en vala:
foo_bar(FOO(f)); (fonctionne de la même manière que gtk_window_set_title(GTK_WINDOW(w), "Hello, world"); )
en C++:
_ZN3Foo3barEv(f); (je ne l'ai pas inventé, c'est le nom qu'a donné G++ à la méthode...)
Et encore, ce code dépend de l'ABI C++ du compilateur, et j'ai considéré que la fonction n'était pas virtuelle. Vois tu où se situe Vala, maintenant ?

Pour rentrer dans le troll, j'avais regardé du côté de D il y a quelques années lorsqu'il venait à peine d'être libéré, et c'était à l'époque assez intéressant. Mais maintenant qu'aujourd'hui on a GCJ, j'ai du mal à voir l'intérêt.

> L'avantage est que le compilateur est un front-end à gcc et qu'il peut donc être disponible sur un grand nombre de plate formes.
Vala transformant en code C pour le faire avaler à GCC, je pense qu'on peut difficilement faire plus portable :)

C'est le cas d'à peu près tous les langages (sauf peut être Brainfuck ;)), et je n'ai jamais dit que C++ était une sous merde inutilisable que seul un barbare sous l'emprise de substances illicites utiliserait, hein (c'est "l'approche windows" qui a choqué ? ce n'était pas dans un but péjoratif, c'était juste pour illustrer que philosophiquement, il y avait un gouffre énorme entre Objective-C et C++). Tout ce que mon message dit, c'est que l'Objective-C est au C++ ce que kate est à KDevelop. Je conçois et respecte que l'on puisse aimer les IDEs-usine-à-gaz, mais d'autres aiment bien les éditeurs simples et sobres.

Non, le code généré par Vala est très lisible et extrèmement proche de ce qu'aurait écrit un développeur C+GObject (certains argueront que ce n'est justement pas lisible, mais là n'est pas le troll :))

> Et qu'est ce que ça change ?
100% et immédiatement compatible avec le C et l'énorme paquet de code GObject existant, le tout avec une syntaxe un peu moins lourde

> Créer un langage propre et qui marche est loin d'être trivial...
Justement, c'est plus proche d'un préprocesseur que d'un vrai langage...

Étant "fanboy" (comme le mot est à la mode ici) d'Objective-C, je vais vaguement essayer d'expliquer l'intérêt de ces langages.
En un mot: C++ est une couche très épaisse au dessus du C. Objective-C est une couche très fine au dessus du C. Les implications:
- se retrouvent en termes de complexité. Ajouter une couche Objective-C au dessus d'un compilateur C est trivial (pour l'anectode, un développeur du projet Étoilé a réecrit la couche logique (pas syntaxique) de l'objective-c en deux jours!). Ajouter le ++ au C, par contre, est un réel cauchemar pour l'implémenteur (une histoire de grammaire qui n'est plus LALR). Pour l'utilisateur, cela se ressent fortement. Le créateur du C++ a dit quelque chose du genre "je ne m'attend pas à ce que qui que ce soit comprenne le langage dans sa totalité" (c'est assez proche de la philosophie Perl: on ajoute du bloat et du bloat syntaxique et chaque développeur apprend son propre sous-langage - mis à part qu'en C++, ce sous langage est relativement commun). Personnellement, je suis (très) loin d'être une lumière, mais j'ai réussit à me coder un binding générique Objective-C <-> Python pleinement fonctionnel en quelques jours (et j'ai très eu d'expérience en Objective-C derrière moi) - en ramant plus sur la partie Python que Objective-C. Après, je ne débattrai pas plus longuement sur l'intérêt de la simplicité, la littérature abonde là dessus.
- Une équivalence entre le C et l'Objective-C. Le C++ est vaguement capable de réutiliser ce qui est fait en C (donc C => C++ - et encore, il y a des cas assez rares où un code C ne compile pas en C++ - simple exemple: en C, tu peux avoir une variable "class". C++ réserve ce mot clef). En Objective-C également, la réutilisation du code C est à 100% possible (et sans les cas rares du C++) mais l'inverse est également vrai: même en n'ayant qu'un compilateur C sous la main il est possible de réutiliser des librairies Objective-C. Réutiliser les librairies C++ en C sans compilateur C++ est totalement exclu.
Pour résumer, Objective-C est très proche de l'approche Unix (transparence, simplicité et couche fine) tandis que le C++ est plus proche de l'approche Windows (cacher les détails d'implémentation, préférer la complétude à la simplicité, la "couche épaisse" n'étant qu'un corollaire de ces deux derniers points)
Vala, quant à lui, serait un Objective-C avec une couche un peu plus épaisse, ce qui lui permet d'ajouter des concepts de plus haut niveau et de s'affranchir de concepts qui seraient de trop bas niveau au goût de certains développeurs objet. Tout en restant à 100% équivalent au C, simple et transparent. Un excellent compromis à mon goût (même si la syntaxe C#-like me sort par les trous de nez :))

C# ne vise pas à être "une couche au dessus du C" (qu'elle soit fine ou épaisse) et n'a donc rien à voir avec les autres que tu as cités. Il serait beaucoup plus proche du Java.

Maintenant, Vala et Objective-C font ils doublons ? Oui et non. De loin, ils poursuivent les mêmes objectifs, mais de près:
- On peut mettre directement du C dans du code Objective-C. Objective-C, en fait, n'étend que légèrement le C pour les définitions et les déclarations de classes/méthodes/fonctions (à la limite, Objective-C aurait pu être fait à coup de directives du préprocesseur. D'ailleurs, il me semble que la première implémentation d'Objective-C n'était qu'un préprocesseur), tandis que Vala est un langage à part entière.
- Objective-C cible le C et les développeurs C. Vala cible GObject et des développeurs de "haut niveau" (garbage collector par exemple. Je sais, il y en a aussi en Objective-C, mais vu son échec retentissant...)
Ces deux différences suffisent, AMHA, à justifier l'existence des deux en parallèle.
Un petit bémol pour Vala, toutefois, est le fait qu'il s'appuie sur GObject dont le modèle objet est singulièrement limité comparé à l'Objective-C: pas de categories, impossibilité de surharger une méthode, réflexion limitée.

Bon, c'est pas tout ça, mais j'étais censé bosser aujourd'hui moi, pas mouler... :-/

> Donnez des technologies ou réflexions qu'a apporté Ubuntu. Bonne chance.
Upstart
En même temps, au vu du résultat, je sais pas trop si on peu appeler ça un "apport" -->[]

Ha non, ça c'est pas un bug, c'est une fonctionnalité...

En même temps, c'est un peu un bug, hein...
(http://eikke.com/kde4-reviewed/5/)

> quoi de plus destabilisant qu'une fonction qui prend un paramètre dont le nom est pas très explicite et dont on connais pas le type...
Normalement, les types possibles des paramètres et des valeurs de retour doivent être documentés. Après, c'est certain que le langage n'interdit personne à mal coder, hein :)
> la doc est fouilli... trouvé quelque chose n'est pas toujours simple. Comparé avec la doc de Qt ou de Java
La doc de Qt, je ne sais pas. J'en ai entendu beaucoup de bien, même si je l'ai jamais essayée moi même. Mais honnêtement, ma maigre expérience de Java a été un cauchemar au niveau documentation en ligne (peut être que la doc intégrée aux IDEs est meilleure...). Honnêtement, je vois très mal comment préférer http://java.sun.com/j2se/1.4.2/docs/api/ à http://docs.python.org/
> - beaucoup de reste d'un langage pas objet à la base
Pardon ???
Il va falloir epliquer plus profondément que ça. Quand tu sais que même les modules, les classes et les fonctions sont des objets, je vois mal ce qu'il te manque ;)
>- de même, j'ai tendance a oublier les self....
Ça m'a pris quelques mois pour attraper le réflexe, mais c'est vrai que c'est dur, au début ;)
> Bref, en fait la seul chose que j'aimerais ça serait d'avoir un typage obligatoire
Tu enlèves là un gros avantage du langage. Même si dans, disons, 80% des cas, le type est connu à l'avance, le typage fort (ou, le typage de python est fort) dynamique est carrément jouissif dans les 20% autres cas (surtout quand tu penses au nombre de lignes supplémentaires que ça aurait pris dans un langage à typage statique). Certaines choses que j'ai faites proprement en Python en quelques lignes grâce à ce typage dynamique m'auraient prises plusieurs fichiers et une bonne centaine de lignes en Java.

> Ou alors Python va-t-il s'améliorer avec Py3k ?
Pour l'autocompletion, un truc asez intéressant va arriver dans Python 3k: la possibilité d'annoter les fonctions. Par exemple, les définitions suivantes deviennent valide en Python 3000:

def compile(source: "something compilable",
filename: "where the compilable thing comes from",
mode: "is this a single statement or a suite?"):

def haul(item: Haulable, *vargs: PackAnimal) -> Distance:

Par défaut, l'interpréteur n'en fait rien, mais on peut très bien l'utiliser comme:
- documentation
- dire quels types sont supportés
- vérification de type à l'aide d'un décorateur

Après, il faut bien sûr que les IDEs en tirent partie. Mais c'est là une autre histoire :)

Et ruby répond à ton problème du self ;)

> Bof, ca suppose que t'interdise dans le langage certaines constructions tout de même
J'ose espérer que c'est la JVM qui interdit à une applet d'écrire dans mon $HOME et que c'est pas "une construction du langage" Java. Sinon, cela voudrait dire qu'il est possible d'écrire du code malicieux en byte-code...

> il peut facilement monter à 30 voire 40
Enfin, faut déjà être un sacré trolleur :)

> Attention, il s'agit d'une syntaxe Python, utilisez des espaces plutôt que des tabulations !
Là, va falloir que tu m'expliques la relation de causalité entre "syntaxe python" et "utiliser des espaces"

> Mon navigateur retient les mots de passe (généralement aléatoires)
Et le jour où:
- tu changes de navigateur
- les devs de ton navigateur décident que "pour des raisons de sécurité, les mots de passe ne sont conservés que deux semaines"
- tu perds ton .mozilla (ou .kde, ou .opera ou je sais pas quoi) suite à une fausse manip
tu l'as un peu dans l'os...

Sans compter les problèmes que ça pose si tu accèdes à internet à partir de deux postes différents, où tu dois synchroniser ta base de mots de passe

> Personnellement je suis réticent à avoir une identité unique partout
Je vais répéter, encore une fois (ça commence à lasser, mais je n'abandonnerai pas): LE grand avantage de OpenID, s'il ne fallait en retenir qu'un seul, c'est sa très grande flexibilité (pour l'utilisateur. Pour le programmeur, c'est vachement moins marrant, il faut l'admettre, mais là n'est pas la question ;)). Tu peux très bien avoit n identités "visiblement" (de l'extérieur) différentes mais qui en fait (pour le fournisseur d'identité) sont les mêmes, de la même manière que foo@gmail.com, foo+bar@gmail.com et foo+spam@gmail.com sont la même adresse (et tu peux imaginer des alias plus sophistiqués que ça !). Donc tu peux très bien te logguer une seule fois auprès de ton fournisseur pour n identités (une pour linuxfr, une pour lj, une par forum,...)

> - si y a pas d'OpenID, alors il à accès à mon compte.
Et mon mot de passe. Et par voie de conséquence, mes comptes sur une demi-douzaine d'autres sites où j'utilise le même mot de passe que linuxfr.

Première nouvelle, enregistrer ce qui passe est illégal...
Je vais de ce pas aller me dénoncer au commissariat le plus proche pour possesion d'un magnétoscope, alors... Merci de m'avoir remis dans le droit chemin (tm)

"Pilling more and more complexity on top of mistaken complexity is not a solution ; it's pure stupidity" (je sais plus qui)
Un IDE pour Java, c'est un peu comme caler un table bancale avec un livre. Ça marche, mais ça ne rend pas les tables bancales équivalentes aux tables stables pour autant...
Faire l'apologie de Java grâce aux IDEs, c'est un peu comme faire l'apologie des tables bancales grâce aux livres: c'est franchement stupide...

> Et pourtant, on peut faire le même effet mais sans se prendre la tête à la définition : MyClass.myFunc.call(x, args)
Hmmm, marche pas ici:

class Foo
def bar(args)
print args + "\n"
end
end

f = Foo.new()
Foo.bar.call("hello, world")

$ ruby test.rb
test.rb:8: undefined method `bar' for Foo:Class (NoMethodError)

> et en plus c'est plus explicite que python puisqu'on rajoute call ;-)
Si tu insistes, tu peu rajouter un __call__ en python... Mais je doute que tu apprécies, vu ta réaction aux __ :)

> Bon ok dans ruby il y a @, mais en parlant de beauté on est clairement dans le subjectif...
J'ai vu vraiment très peu de ruby, mais du peu que j'ai vu, je t'accorde le côté plus agréable à l'œil. Mais j'aime beaucoup moins des choses comme la différentiation entre méthode/fonction/attribut. En python, méthode et fonction, c'est la même chose (d'où le self explicite), et mieux, une méthode n'est qu'un attribut comme un autre (getattr et setattr fonctionnent aussi avec les méthodes ! Une méthode n'est qu'un attribut possédant lui même un attribut __call__). Ça a un côté "unification" que je ne retrouve pas en ruby (mais peut être que cela vient du fait que je n'en ai pas fait assez ?)

Sinon, par simple curiosité, comment fait ruby pour un nombre variable d'arguments ? (le *args de python)

Allez, un truc amusant que je viens juste de découvrir:

>>>class Spam:
...a = 5
...
>>>def egg(self):
...print self.a
...
>>>x = Spam()
>>>Spam.egg = egg
>>>x.egg()
5
>>>egg(x)
5

Plus sérieusement, le "instance comme argument", à l'utilisation, ça permet de rester cohérent sans introduire de syntaxe magique. Par exemple, supposons que a soit une instance de la classe A, qui hérite de la classe B, qui définissent tous deux une méthode foo. En C++, pour appeler le foo de B, tu aurais une syntaxe magique (de mémoire, ça fait un moment que j'ai plus fais de C++) et absolument immonde du type: a::B.foo(). En python, tu restes cohérent: B.foo est une fonction, tu as juste à l'appeler comme n'importe quelle fonction: B.foo(a).
Autre avantage, si tu prends x = [a1,a2,a3] (trois instances de A) et que tu veux appeler foo sur ces trois, tu as juste à faire map(A.foo, x): cela va donner [A.foo(a1), A.foo(a2), A.foo(a3)], ce qui, grace à l'argument explicite, est équivalent à [a1.foo(), a2.foo(), a3.foo()]
Autre avantage (le principal IMHO), l'instance passe très bien à travers les arguments du type *args ou **kwargs (l'équivalent, en plus puissant, des ... du C, comme avec printf). Ou à travers des décorateurs.
Enfin, ce n'est pas parce qu'une fonction est dans une classe que c'est une méthode d'instance (méthode de classe/statique). Là où un autre langage demanderait probablement "yet another keyword", en python, ça se fait par un décorateur tellement basique que n'importe quel pékin peut écrire soit même si ça le chante (il y en a un "standard", mais pour t'illustrer à quel point ça évite les cas et les constructions particuliers, je vais le faire moi-meme):
>>> def classmethod(meth):
... def call(*args, **kwargs):
... return meth(args[0].__class__, *args[1:], **kwargs)
... return call
...
>>> class Spam:
... @classmethod
... def hello(klass, who):
... print "Hello, %s (from %r)" % (who, klass)
...
>>> s = Spam()
>>> s.hello("world")
Hello, world (from <class __main__.Spam at 0xb7c6b7dc>)

Oui, mais dans ce cas tu ne te plains pas que le rendu est différent :)

De un, tu confonds très certainement avec Maple (pas que celle de Matlab soit spécialement rapide et ergonomique hein, mais c'est pas du swing...)
De deux, il a jamais proposé de faire la même interface, hein :)

> La seule alternative c'est que les libanais laissent Israel les bombarder sans reagir, ce qui n'est evidemment pas une solution.
Je ne dirais qu'une seule chose:
http://www.bernardwerber.com/unpeuplus/ESRA/strategie_indien(...)
(oui, ça s'applique AUSSI à Israël)

De la même manière qu'avoir deux formats de fichiers bureautiques concurrents tous deux standardisés à l'ISO est stupide, avoir deux formats de fichiers mutlimédias concurrents standardisé à l'ISO est stupide (L'ISO a déjà MPEG)