Ouais des DRM qui peuvent être lu seulement que sur leurs Ipods ça ne les arrangent pas du tout.
Non, ça ne les arrange pas. Ça fait toujours chier le client, ça ne sert à rien, et ils le savent. Par ailleurs, il n'existe pas de DRMs multi-plateforme, donc forcément ils ne fonctionnent que sur ipod :-).
Le problème c'est qu'il voit que les plates formes qui proposent de la musique sans DRM marchent plutôt bien et ils ne veulent pas perdre le marché de la musique en ligne.
Comme si les autres magasins vendant de la musique sans DRMs étaient une menace pour eux... Par contre, il est tout à fait vrai que ces magasins ont démontré la viabilité du modèle sans DRMs, ça a certainement dû aider Apple à convaincre les quelques maisons qui ont accepté de virer les DRMs de le catalogue sur l'iTunes store.
Ah, là c'est sur, si on utilisait pas les DRMs, ils ne seraient pas pénibles.
Splendide raisonnement, bravo.
Par ailleurs, non, ça n'est pas lui ni Apple qui en profitent le plus, au contraire les DRMs limitent plutôt leur ventes. Personne ne profite des DRMs, même pas les majors qui s'y accrochent encore, c'est une balle qu'ils se sont mis tout seuls dans le pied parce qu'ils n'ont rien compris aux technologies numériques.
- soit tu ne l'es pas, et alors la question se pose : de quelle couleur est le ciel sur ta planète ? Parce qu'ici sur Terre, il y a des mp3 sans DRMs sur l'iTunes store, et ils sont de très loin le premier vendeur de musique numérique (et même le 4eme vendeur de musique tout support confondu aux US, si je me souviens bien).
Non, il a compris depuis le début qu'on peut vendre des mp3 sans DRMs, il suffit de proposer un service potable, ce que fait itunes. Il n'a jamais défendu les DRMs, et ceux d'itunes sont triviaux à contourner.
S'il veut peut-être enlever les DRM sur la musique, c'est pour mieux en mettre sur les vidéos.
*soupir* Il n'a aucun raisonnement rationnel dans cette remarque (ni dans la précédente d'ailleurs), juste le fait que tu n'aimes pas le personnage.
Apple vend du hardware. Pour eux, tout ce qui permet d'ajouter du contenu sur leur hardware est bienvenu. Les DRMs emmerdent les clients, ils le savent très bien, donc n'ont pas d'intérêt à ce qu'ils durent.
Avoir des parts dans Disney ne permet pas de leur imposer l'absence de DRMs, et encore moins à tous les autres studios dont il a récupéré le catalogue pour l'Apple TV.
Enfin bon, la plupart des réactions à cet article (et l'article lui-même à vrai dire) illustrent assez bien pourquoi j'ai fini par lâcher Linux.
En gros, les DRMs de l'ITunes Store sont une concession que Jobs a du faire aux majors pour avoir leur catalogue, rien de plus.
Le second point, c'est qu'un ipod qui fait correctement le boulot qu'on lui demande m' "emprisonne" moins qu'un lecteur X sur lequel je dois passer du temps pour obtenir le même résultat avec le même confort d'utilisation (c'est d'ailleurs la même constatation qui m'a fait passer au Mac, après 13 ans sous Linux).
Et pour finir, la raison de l'organisation "curieuse" des fichiers dans un ipod, c'est que se balader rapidement dans 160Gb de morceaux, ça ne se fait pas en FAT32.
C'est une réponse courte et à certains arguments avancés par les artistes sur lestelechargements.com. Si vous connaissez des gens, particulièrement des auteurs, auprès de qui le faire passer, ça serait cool :-).
Le problème est qu'ils sont pour la plupart impossibles à appliquer parce qu'utilisant des bouts d'ObjectiveC ou des librairies spécifiques à OS/X (voir la suite du thread sur kde-core-devel).
D'abord c'est exactement le genre de feature "flashy" qui font qu'un soft sort du lot, et que l'UI a vraiment été soignée.
Ensuite, quand tu t'adresses à des musiciens ou ingénieurs du son, qui ont l'habitude de manipuler physiquement ces racks, tu ne vas pas leur présenter des diagrammes abscons pour figurer les connections, ça ne marchera jamais. Leur offrir une simulation aussi proche que possible de la réalité fonctionne bien mieux.
Y a une raison pour laquelle Reason s'est immédiatement imposé comme référence, et c'est pas seulement à cause de la qualité du rendu sonore. Pose un musicien devant, et tu "comprendra l'ironie".
J'ignorais totalement l'existence de Wired jusqu'a il y a 2 jours (l'url du projet a été postée sur notre mailing-list rg-user).
Quant au problème d'eparpillement, il est réel, mais il est très difficile de convaincre différentes équipes de bosser ensemble. Déjà là, développer en GTK+2 et wxwidgets, ça me donne pas vraiment envie :-). Par ailleurs il me semble plus urgent d'unifier le desktop que les applis. Ce n'est pas la peine d'essayer de concentrer différentes applis similaires si chacune utilise une toolkit différente.
Je ne sais pas quelle est la version packagée pour debian testing, mais il est préférable que tu compiles à partir des dernières sources. Mais avec un peu de chance on sort la 1.0pre1 ce week-end (croisons les doigts), donc attends un peu.
Maintenant en ce qui concerne l'austérité de l'interface, c'est sans doute vrai, mais on manque de temps et de resources pour implémenter toutes les features qu'on voudrait :-(. Ceci dit, il n'y a rien dans la liste des besoins que tu donnes que Rosegarden ne sache pas faire.
en général ce qui fait qu'une appli est maintenable ou non, ça dépend plus des capacités de l'auteur initial à écrire du code propre et compréhensible que du langage utilisé
Oui, et il y a du Perl plus lisible que de l'Eiffel, etc... mais le fond du problème est juste une question de statistique. Il y a des exceptions, mais en général le C++ est plus facile à maintenir que C, Java plus facile que C++ ou Python plus facile que Perl. Et cela simplement parce que le langage s'y prête plus, donc le codeur à moins d'effort à faire pour écrire du code maintenable. Sachant qu'outre les qualités du codeur, il y a aussi de bons vieux impératifs de temps, d'intégration avec l'existant, etc...
...et y avait un certain nombre de choses dedans qui étaient loin d'être triviales à première vue, et que je soupçonne un bon nb de personnes "faisant du C++" d'ignorer.
C'est hélas tout à fait vrai.
J'aurais probablement dû dire C+glib/gobject [...]
Non, même avec ça tu n'arrives pas à la cheville d'un langage objet. J'aurais même tendance à dire que c'est pire, parce que tu te frappes tout le boulot d'un compilateur objet, d'où encore plus de risques d'erreurs.
Un toolkit, ça sera jamais qu'un (très gros) wrapper sur la xlib
Le 2eme cas n'est pas vraiment ce que j'appelle un binding, c'est une librarie à part entière. Qt est un exemple, au dessus de la XLib.
Mais sinon je suis d'accord avec le reste de ton commentaire, sauf que dans le cas de gtkmm une telle solution n'était pas envisageable, déjà parce que GTK+ a son propre modèle objet, donc la bijection GtkObject->classe C++ est inévitable. Mais justement, comme tu veux malgrè tout avoir une API qui soit vraiment "C++ like", tu es quand même obligé d'en rajouter, et c'est là que ça devient très vite très complexe.
Oui mais c'est vrai (n'importe qui avec assez d'expérience en C++ et d'objectivité te le dira)
> En tout cas le C++ faut connaître pas mal de subtilité avant de pouvoir l'utiliser efficacement.
Vrai et faux, si tu as de bons exemples ça peut aller plus vite. Mais il est clair que c'est un langage trop complexe.
> gtkmm n'a pas besoin de tout ça en tout cas
Tu compares les signaux de gtkmm avec moc, qui fait bien plus de choses (properties, introspection, en gros un modèle objet un peu comme celui de Java).
> Ce qui a en plus l'avantage de permettre de faire plus de vérifications à la compilation
C'est vrai, bien qu'en pratique ce genre de bugs soit rare.
> pour moi le C et le C++ c'est presque aussi bas niveau l'un que l'autre,
N'exagérons rien, rien qu'avoir un modèle objet, std::string et std::vector, ça aide quand même beaucoup.
> autant utiliser le C# pour coder une appli graphique
Oh oui, mon rève. Mais il manque une toolkit (non, pas un wrapper, une vraie toolkit :-).
Plus précisément : un binding C++ pour une bibliothèque C est intrinsèquement moins bon qu'une lib écrite directement en C++.
L'une des erreurs fondamentales de Gnome a été de croire qu'un wrapper était aussi bien qu'une lib écrite dans le même langage que celui avec tu développes le reste de l'appli.
> Perso, je ne connais pas d'utilisateur "expérimenté" de GNU/Linux sous KDE.
Voyons voir si je peux palier à cette lacune :
Je suis sous Linux depuis 1995. Mon premier kernel était le 1.2.8, mon premier PC Linux un Pentium 90 avec 16Mb de RAM, acheté uniquement pour ça (je n'ai jamais eu de Windows chez moi). Avant ça, j'ai mis la première fois les mains dans un Unix (Ultrix, en l'occurence), en 1991, et quasiment uniquement bossé sous Unix depuis. Je fais du libre depuis 96.
Je suis sous KDE depuis avril 2000, les premières beta de KDE2 (après divers WM dont gwm, ctwm, fvwm et Window Maker). Il ne me viendrait pas à l'idée de revenir à un "WM leger", et encore moins à Gnome.
J'ai des souvenirs de discussions avec Raph Levien ou Havoc Pennigton qui n'étaient pas exactement de cet avis :-). Mais c'était il y a longtemps (vers 99 ou 2000), il a pu changer depuis.
Non. Eclipse est à Emacs ce que Emacs est à vi, ou même ed. Ce n'est pas *du tout* le même niveau de fonctionalités.
Mais tu n'apprécies les features d'Eclipse que lorsque tu travailles sur un projet Java sufisamment gros (disons plus de 10KLOCS), en dessous la lourdeur d'Eclipse te pénalise plus qu'autre chose.
C'est un débat récurrent ici, chaque fois que quelqu'un parle d'Eclipse ou d'un autre IDE du même genre (Intellij Idea par ex.) il y en a un pour sortir la liste des modules Emacs qui "font tout pareil". C'est souvent comique (bravo pour le 'M-x make' pour la compil à la volée, très réussi), et la personne qui s'y colle ne connait évidemment pas du tout Eclipse (et à peine Emacs).
Si, merci, mais ça simplifie pas vraiment le code de devoir passer par une classe intermédiaire, et si la lisibilité est un critère...
> 2) plus lisible, plus lisible. C'est pas mon avis....
Ben monte un club avec kra, je sais pas moi... Dès que ton string devient un peu complexe, ça devient franchement pénible à lire autant qu'a écrire. Si une syntaxe printf-like existe dans quasiment tous les langages un peu utilisés, ça n'est pas juste pour faire plaisir aux codeurs C.
> 3) apres avoir fait des append() avec tes stringbuffers (voir le 1), hop!! un tostring()
Avant de répondre à un argument, ça serait bien de le comprendre :-). Tiens, va voir par là :
commetant l'erreur habituelle qui est de confondre design et implémentation
Oui, ça c'est ce que les architectes disent pour se défendre quand le marketing vient leur dire "ça rame" : "c'est pas not' faute, c'est les ingé qu'on mal implémenté notre beau design". Non, j'ai trop vécu ce cas pour avaler ce genre d'excuse : un design peut être intrinsèquement lent, quelque soit l'implémentation. C'est pas pour rien que toutes les methodologies de prog actuelles (extreme programming en tete) sont sous forme de cycle ou le design est revu avec l'expérience de l'implementation.
Maintenant, l'exemple du virtual me semble emblématique du design raté. Sous pretexte de faciliter l'interfaçage avec le C
Effectivement, on a déjà eu cette discussion. Bon, je continue de penser que Stroustrup a fait un langage utilisable en pratique, avec des avantages concrets sur les concurrents, plutôt qu'un bel objet de laboratoire, et qu'il a eu raison de le faire. Je ne crois pas aux "erreurs" de l'industrie, si un machin a du succès, c'est le plus souvent pour de bonnes raisons, les pressions marketing et les "décideurs pressés" ne font pas tout. Au final, il a fait un langage qui s'interface avec C de façon triviale, et relativement facile à implementer. Sans ça, C++ n'aurait jamais marché.
si on veut faire proprement et efficacement du calcul numérique, il faut déléguer au compilateur. Il faut donc que les nombres complexes, les vecteurs et les matrices soient intégrés au langage et que le compilateur se démerde pour optimiser le code
Je veux bien, mais alors bonjours le tas de feature en plus à flanquer dans la spec. Et donc tu te retrouves soit avec un langage hyper-specialisé qui ne fait que du calcul numérique et rien d'autres (donc prévoir moyens pour l'interfacer avec autre chose pour faire des vrais softs utiles, avec GUI & co...), soit un langage encore plus énorme que C++ :-). "Less is more" ?
Si j'ai bien compris (je peux me tromper) les generics de C# ont été retardés pour la version 2 car les équipes de Microsoft research bossaient encore dessus.
C'est exact, ils ont préféré attendre d'avoir une bonne implémentation du concept. Encore un point ou Hejlsberg m'impressionne plus que Gosling.
mais aussi dans la bonne direction comme les structs
Entièrement d'accord, je ne vois pas d'autre issue que d'avoir 2 modèles objets dans un langage : un "leger" (structs) ou tu peux creer tout les objets que tu veux sans trop de soucis de perfs, et un plus lourd et complet (class), avec toutes les features bien sympa qu'on aime avoir (introspection, etc...).
> On analyse statiquement le contenu de la chaîne et on traduit les noms de variables en offset dans la pile.
Ce qui suppose que les variables soient locales, non ? Enfin bon, oui, j'imagine bien qu'il doit être possible de bidouiller un compilo pour que ça marche plus ou moins bien, mais je ne suis pas convaincu de l'interêt de l'exercice.
> Ajouter ce genre de fonctionnalité sous forme de modificateur est ultra trivial.
[^] # Re: Non non, Steve Jobs n'aime pas les DRMs
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche iPod : sept ans de « progrès » dans l'emprisonnement numérique. Évalué à -1.
Non, ça ne les arrange pas. Ça fait toujours chier le client, ça ne sert à rien, et ils le savent. Par ailleurs, il n'existe pas de DRMs multi-plateforme, donc forcément ils ne fonctionnent que sur ipod :-).
Le problème c'est qu'il voit que les plates formes qui proposent de la musique sans DRM marchent plutôt bien et ils ne veulent pas perdre le marché de la musique en ligne.
Comme si les autres magasins vendant de la musique sans DRMs étaient une menace pour eux... Par contre, il est tout à fait vrai que ces magasins ont démontré la viabilité du modèle sans DRMs, ça a certainement dû aider Apple à convaincre les quelques maisons qui ont accepté de virer les DRMs de le catalogue sur l'iTunes store.
[^] # Re: Non non, Steve Jobs n'aime pas les DRMs
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche iPod : sept ans de « progrès » dans l'emprisonnement numérique. Évalué à -1.
[^] # Re: Non non, Steve Jobs n'aime pas les DRMs
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche iPod : sept ans de « progrès » dans l'emprisonnement numérique. Évalué à -2.
Splendide raisonnement, bravo.
Par ailleurs, non, ça n'est pas lui ni Apple qui en profitent le plus, au contraire les DRMs limitent plutôt leur ventes. Personne ne profite des DRMs, même pas les majors qui s'y accrochent encore, c'est une balle qu'ils se sont mis tout seuls dans le pied parce qu'ils n'ont rien compris aux technologies numériques.
[^] # Re: Non non, Steve Jobs n'aime pas les DRMs
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche iPod : sept ans de « progrès » dans l'emprisonnement numérique. Évalué à -3.
- soit tu es ironique
- soit tu ne l'es pas, et alors la question se pose : de quelle couleur est le ciel sur ta planète ? Parce qu'ici sur Terre, il y a des mp3 sans DRMs sur l'iTunes store, et ils sont de très loin le premier vendeur de musique numérique (et même le 4eme vendeur de musique tout support confondu aux US, si je me souviens bien).
[^] # Re: Non non, Steve Jobs n'aime pas les DRMs
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche iPod : sept ans de « progrès » dans l'emprisonnement numérique. Évalué à 2.
Non, il a compris depuis le début qu'on peut vendre des mp3 sans DRMs, il suffit de proposer un service potable, ce que fait itunes. Il n'a jamais défendu les DRMs, et ceux d'itunes sont triviaux à contourner.
S'il veut peut-être enlever les DRM sur la musique, c'est pour mieux en mettre sur les vidéos.
*soupir* Il n'a aucun raisonnement rationnel dans cette remarque (ni dans la précédente d'ailleurs), juste le fait que tu n'aimes pas le personnage.
Apple vend du hardware. Pour eux, tout ce qui permet d'ajouter du contenu sur leur hardware est bienvenu. Les DRMs emmerdent les clients, ils le savent très bien, donc n'ont pas d'intérêt à ce qu'ils durent.
Avoir des parts dans Disney ne permet pas de leur imposer l'absence de DRMs, et encore moins à tous les autres studios dont il a récupéré le catalogue pour l'Apple TV.
Enfin bon, la plupart des réactions à cet article (et l'article lui-même à vrai dire) illustrent assez bien pourquoi j'ai fini par lâcher Linux.
# Non non, Steve Jobs n'aime pas les DRMs
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche iPod : sept ans de « progrès » dans l'emprisonnement numérique. Évalué à -1.
Le premier point que je voudrais corriger sur l'article, c'est que non, la position de Steve Jobs sur les DRMs n'est pas du tout hypocrite cf.
http://www.rollingstone.com/news/story/5939600/steve_jobs_th(...)
En gros, les DRMs de l'ITunes Store sont une concession que Jobs a du faire aux majors pour avoir leur catalogue, rien de plus.
Le second point, c'est qu'un ipod qui fait correctement le boulot qu'on lui demande m' "emprisonne" moins qu'un lecteur X sur lequel je dois passer du temps pour obtenir le même résultat avec le même confort d'utilisation (c'est d'ailleurs la même constatation qui m'a fait passer au Mac, après 13 ans sous Linux).
Et pour finir, la raison de l'organisation "curieuse" des fichiers dans un ipod, c'est que se balader rapidement dans 160Gb de morceaux, ça ne se fait pas en FAT32.
# Article en réponse aux témoignages sur lestelechargements.com
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Appel à tous: samedi 4 mars, action aux Victoires de la Musique contre la loi DADVSI. Évalué à 3.
http://www.telegraph-road.org/writings/telechargement.html
C'est une réponse courte et à certains arguments avancés par les artistes sur lestelechargements.com. Si vous connaissez des gens, particulièrement des auteurs, auprès de qui le faire passer, ça serait cool :-).
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KDE doit-il abandonner KHTML pour Webcore ?. Évalué à 4.
http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008042(...)
et ont été annoncés sur kde-core-devel :
http://lists.kde.org/?l=kde-core-devel&m=111470451721883&w=(...)
Le problème est qu'ils sont pour la plupart impossibles à appliquer parce qu'utilisant des bouts d'ObjectiveC ou des librairies spécifiques à OS/X (voir la suite du thread sur kde-core-devel).
[^] # Re: vive le progres ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Interview de Scott Wheeler à propos de kdemultimedia. Évalué à 2.
Tu as regardé le prix des DD dernièrement ? Ou tu as oublié un '0' à "200" ? :-)
[^] # Re: Compaison fonctionnalités
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Wired: un nouveau logiciel de composition et de production musicale pour Linux. Évalué à 2.
Ah ? C'est pas ce que j'entends autour de moi, Reason continue d'être une référerence.
[^] # Re: Compaison fonctionnalités
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Wired: un nouveau logiciel de composition et de production musicale pour Linux. Évalué à 4.
Ensuite, quand tu t'adresses à des musiciens ou ingénieurs du son, qui ont l'habitude de manipuler physiquement ces racks, tu ne vas pas leur présenter des diagrammes abscons pour figurer les connections, ça ne marchera jamais. Leur offrir une simulation aussi proche que possible de la réalité fonctionne bien mieux.
Y a une raison pour laquelle Reason s'est immédiatement imposé comme référence, et c'est pas seulement à cause de la qualité du rendu sonore. Pose un musicien devant, et tu "comprendra l'ironie".
[^] # Re: Bravo!
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Wired: un nouveau logiciel de composition et de production musicale pour Linux. Évalué à 2.
Quant au problème d'eparpillement, il est réel, mais il est très difficile de convaincre différentes équipes de bosser ensemble. Déjà là, développer en GTK+2 et wxwidgets, ça me donne pas vraiment envie :-). Par ailleurs il me semble plus urgent d'unifier le desktop que les applis. Ce n'est pas la peine d'essayer de concentrer différentes applis similaires si chacune utilise une toolkit différente.
[^] # Re: Bravo!
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Wired: un nouveau logiciel de composition et de production musicale pour Linux. Évalué à 2.
Maintenant en ce qui concerne l'austérité de l'interface, c'est sans doute vrai, mais on manque de temps et de resources pour implémenter toutes les features qu'on voudrait :-(. Ceci dit, il n'y a rien dans la liste des besoins que tu donnes que Rosegarden ne sache pas faire.
[^] # Re: personnellement : je préfère gnome à kde
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche LinuxFR, vainqueur du choix des lecteurs du Linux Journal. Évalué à 1.
Oui, et il y a du Perl plus lisible que de l'Eiffel, etc... mais le fond du problème est juste une question de statistique. Il y a des exceptions, mais en général le C++ est plus facile à maintenir que C, Java plus facile que C++ ou Python plus facile que Perl. Et cela simplement parce que le langage s'y prête plus, donc le codeur à moins d'effort à faire pour écrire du code maintenable. Sachant qu'outre les qualités du codeur, il y a aussi de bons vieux impératifs de temps, d'intégration avec l'existant, etc...
...et y avait un certain nombre de choses dedans qui étaient loin d'être triviales à première vue, et que je soupçonne un bon nb de personnes "faisant du C++" d'ignorer.
C'est hélas tout à fait vrai.
J'aurais probablement dû dire C+glib/gobject [...]
Non, même avec ça tu n'arrives pas à la cheville d'un langage objet. J'aurais même tendance à dire que c'est pire, parce que tu te frappes tout le boulot d'un compilateur objet, d'où encore plus de risques d'erreurs.
Un toolkit, ça sera jamais qu'un (très gros) wrapper sur la xlib
Non, cf. discussion au dessus : http://linuxfr.org/comments/493635.html#493635(...)
[^] # Re: personnellement : je préfère gnome à kde
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche LinuxFR, vainqueur du choix des lecteurs du Linux Journal. Évalué à 1.
Le 2eme cas n'est pas vraiment ce que j'appelle un binding, c'est une librarie à part entière. Qt est un exemple, au dessus de la XLib.
Mais sinon je suis d'accord avec le reste de ton commentaire, sauf que dans le cas de gtkmm une telle solution n'était pas envisageable, déjà parce que GTK+ a son propre modèle objet, donc la bijection GtkObject->classe C++ est inévitable. Mais justement, comme tu veux malgrè tout avoir une API qui soit vraiment "C++ like", tu es quand même obligé d'en rajouter, et c'est là que ça devient très vite très complexe.
[^] # Re: personnellement : je préfère gnome à kde
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche LinuxFR, vainqueur du choix des lecteurs du Linux Journal. Évalué à 2.
Oui mais c'est vrai (n'importe qui avec assez d'expérience en C++ et d'objectivité te le dira)
> En tout cas le C++ faut connaître pas mal de subtilité avant de pouvoir l'utiliser efficacement.
Vrai et faux, si tu as de bons exemples ça peut aller plus vite. Mais il est clair que c'est un langage trop complexe.
> gtkmm n'a pas besoin de tout ça en tout cas
Tu compares les signaux de gtkmm avec moc, qui fait bien plus de choses (properties, introspection, en gros un modèle objet un peu comme celui de Java).
> Ce qui a en plus l'avantage de permettre de faire plus de vérifications à la compilation
C'est vrai, bien qu'en pratique ce genre de bugs soit rare.
> pour moi le C et le C++ c'est presque aussi bas niveau l'un que l'autre,
N'exagérons rien, rien qu'avoir un modèle objet, std::string et std::vector, ça aide quand même beaucoup.
> autant utiliser le C# pour coder une appli graphique
Oh oui, mon rève. Mais il manque une toolkit (non, pas un wrapper, une vraie toolkit :-).
[^] # Re: personnellement : je préfère gnome à kde
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche LinuxFR, vainqueur du choix des lecteurs du Linux Journal. Évalué à 2.
L'une des erreurs fondamentales de Gnome a été de croire qu'un wrapper était aussi bien qu'une lib écrite dans le même langage que celui avec tu développes le reste de l'appli.
[^] # Re: KDE et GNOME
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche LinuxFR, vainqueur du choix des lecteurs du Linux Journal. Évalué à 2.
Voyons voir si je peux palier à cette lacune :
Je suis sous Linux depuis 1995. Mon premier kernel était le 1.2.8, mon premier PC Linux un Pentium 90 avec 16Mb de RAM, acheté uniquement pour ça (je n'ai jamais eu de Windows chez moi). Avant ça, j'ai mis la première fois les mains dans un Unix (Ultrix, en l'occurence), en 1991, et quasiment uniquement bossé sous Unix depuis. Je fais du libre depuis 96.
Je suis sous KDE depuis avril 2000, les premières beta de KDE2 (après divers WM dont gwm, ctwm, fvwm et Window Maker). Il ne me viendrait pas à l'idée de revenir à un "WM leger", et encore moins à Gnome.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche EFL atteint le stade de preview release. Évalué à 2.
J'ai des souvenirs de discussions avec Raph Levien ou Havoc Pennigton qui n'étaient pas exactement de cet avis :-). Mais c'était il y a longtemps (vers 99 ou 2000), il a pu changer depuis.
[^] # Re: ELF rentrera-t-il dans la danse?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche EFL atteint le stade de preview release. Évalué à 2.
Non. Eclipse est à Emacs ce que Emacs est à vi, ou même ed. Ce n'est pas *du tout* le même niveau de fonctionalités.
Mais tu n'apprécies les features d'Eclipse que lorsque tu travailles sur un projet Java sufisamment gros (disons plus de 10KLOCS), en dessous la lourdeur d'Eclipse te pénalise plus qu'autre chose.
C'est un débat récurrent ici, chaque fois que quelqu'un parle d'Eclipse ou d'un autre IDE du même genre (Intellij Idea par ex.) il y en a un pour sortir la liste des modules Emacs qui "font tout pareil". C'est souvent comique (bravo pour le 'M-x make' pour la compil à la volée, très réussi), et la personne qui s'y colle ne connait évidemment pas du tout Eclipse (et à peine Emacs).
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 3.
Si, merci, mais ça simplifie pas vraiment le code de devoir passer par une classe intermédiaire, et si la lisibilité est un critère...
> 2) plus lisible, plus lisible. C'est pas mon avis....
Ben monte un club avec kra, je sais pas moi... Dès que ton string devient un peu complexe, ça devient franchement pénible à lire autant qu'a écrire. Si une syntaxe printf-like existe dans quasiment tous les langages un peu utilisés, ça n'est pas juste pour faire plaisir aux codeurs C.
> 3) apres avoir fait des append() avec tes stringbuffers (voir le 1), hop!! un tostring()
Avant de répondre à un argument, ça serait bien de le comprendre :-). Tiens, va voir par là :
http://developer.kde.org/documentation/library/kdeqt/kde3arch/kde-i(...)
la section "No word puzzles".
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 4.
Au fait, tu as remarqué qu'en C# aussi, les méthodes ne sont pas virtuelles par défaut ? :-)
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 1.
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 3.
Oui, ça c'est ce que les architectes disent pour se défendre quand le marketing vient leur dire "ça rame" : "c'est pas not' faute, c'est les ingé qu'on mal implémenté notre beau design". Non, j'ai trop vécu ce cas pour avaler ce genre d'excuse : un design peut être intrinsèquement lent, quelque soit l'implémentation. C'est pas pour rien que toutes les methodologies de prog actuelles (extreme programming en tete) sont sous forme de cycle ou le design est revu avec l'expérience de l'implementation.
Maintenant, l'exemple du virtual me semble emblématique du design raté. Sous pretexte de faciliter l'interfaçage avec le C
Effectivement, on a déjà eu cette discussion. Bon, je continue de penser que Stroustrup a fait un langage utilisable en pratique, avec des avantages concrets sur les concurrents, plutôt qu'un bel objet de laboratoire, et qu'il a eu raison de le faire. Je ne crois pas aux "erreurs" de l'industrie, si un machin a du succès, c'est le plus souvent pour de bonnes raisons, les pressions marketing et les "décideurs pressés" ne font pas tout. Au final, il a fait un langage qui s'interface avec C de façon triviale, et relativement facile à implementer. Sans ça, C++ n'aurait jamais marché.
si on veut faire proprement et efficacement du calcul numérique, il faut déléguer au compilateur. Il faut donc que les nombres complexes, les vecteurs et les matrices soient intégrés au langage et que le compilateur se démerde pour optimiser le code
Je veux bien, mais alors bonjours le tas de feature en plus à flanquer dans la spec. Et donc tu te retrouves soit avec un langage hyper-specialisé qui ne fait que du calcul numérique et rien d'autres (donc prévoir moyens pour l'interfacer avec autre chose pour faire des vrais softs utiles, avec GUI & co...), soit un langage encore plus énorme que C++ :-). "Less is more" ?
Si j'ai bien compris (je peux me tromper) les generics de C# ont été retardés pour la version 2 car les équipes de Microsoft research bossaient encore dessus.
C'est exact, ils ont préféré attendre d'avoir une bonne implémentation du concept. Encore un point ou Hejlsberg m'impressionne plus que Gosling.
mais aussi dans la bonne direction comme les structs
Entièrement d'accord, je ne vois pas d'autre issue que d'avoir 2 modèles objets dans un langage : un "leger" (structs) ou tu peux creer tout les objets que tu veux sans trop de soucis de perfs, et un plus lourd et complet (class), avec toutes les features bien sympa qu'on aime avoir (introspection, etc...).
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 1.
Ce qui suppose que les variables soient locales, non ? Enfin bon, oui, j'imagine bien qu'il doit être possible de bidouiller un compilo pour que ça marche plus ou moins bien, mais je ne suis pas convaincu de l'interêt de l'exercice.
> Ajouter ce genre de fonctionnalité sous forme de modificateur est ultra trivial.
Oui, tu vas juste re-inventer printf().