Au hasard de la promenade dans les nouvelles fonctionnalités de Lion,
trois liens qui me semblent intéressants et méritent sans doute
approfondissement :
1/ le prix de la version serveur (sans limitations ?)
<http://www.apple.com/fr/macosx/server/>
2/ le Per-user screen sharing qui romprait avec l'utilisation de Mac OSX
uniquement "en avant plan" (si je comprends bien)
<http://www.apple.com/fr/macosx/whats-new/features.html#screensharing>
3/ les solutions de restauration sur partition dédiée ou depuis un
backup TimeMachine (et pas seulement en ligne)
<http://www.apple.com/fr/macosx/whats-new/features.html#internetrestore>
(pour répondre aux inquiétudes de notre ami)
Il semble qu'il y ait pas mal d'autres bonnes choses à découvrir
> xml permet d'exprimer des choses autrement plus puissantes, sans avoir à > chaque fois à réinventer l'eau tiède d'une syntaxe plus ou moins > hasardeuse, le tout gérable avec des outils standards et normalisés.
Les fichers texte évolués de config de par ex. de BIND, permettent d'exprimer pas mal de choses, avec des sections imbriquées, tout en restant lisibles, et SURTOUT grep/sed-able !
Si il y a bien UNE chose que je ne prendrais pas comme référence de syntaxe propre c'est celle de BIND :)
Entre autres, les plist d'Apple regorgent de BLOBs absolument incompréhensibles, et qui pourraient certainement être évités.
Sûrement.
Ca me gave d'être obigé d'écrire un outil en Perl avec les modules XML, là où un simple script shell (avec éventuellement un DFA dedans pour les fichiers structurés)
Relis mes arguments...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Xavier <xavier@groumpf.org> wrote:
FiLH <filh@filh.orgie> wrote:
> xml permet d'exprimer des choses autrement plus puissantes, sans avoir à
> chaque fois à réinventer l'eau tiède d'une syntaxe plus ou moins
> hasardeuse, le tout gérable avec des outils standards et normalisés.
Les fichers texte évolués de config de par ex. de BIND, permettent
d'exprimer pas mal de choses, avec des sections imbriquées, tout en
restant lisibles, et SURTOUT grep/sed-able !
Si il y a bien UNE chose que je ne prendrais pas comme référence de
syntaxe propre c'est celle de BIND :)
Entre autres, les plist d'Apple regorgent de BLOBs absolument
incompréhensibles, et qui pourraient certainement être évités.
Sûrement.
Ca me gave d'être obigé d'écrire un outil en Perl avec les modules XML,
là où un simple script shell (avec éventuellement un DFA dedans pour les
fichiers structurés)
Relis mes arguments...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
> xml permet d'exprimer des choses autrement plus puissantes, sans avoir à > chaque fois à réinventer l'eau tiède d'une syntaxe plus ou moins > hasardeuse, le tout gérable avec des outils standards et normalisés.
Les fichers texte évolués de config de par ex. de BIND, permettent d'exprimer pas mal de choses, avec des sections imbriquées, tout en restant lisibles, et SURTOUT grep/sed-able !
Si il y a bien UNE chose que je ne prendrais pas comme référence de syntaxe propre c'est celle de BIND :)
Entre autres, les plist d'Apple regorgent de BLOBs absolument incompréhensibles, et qui pourraient certainement être évités.
Sûrement.
Ca me gave d'être obigé d'écrire un outil en Perl avec les modules XML, là où un simple script shell (avec éventuellement un DFA dedans pour les fichiers structurés)
Relis mes arguments...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
filh
Paul Gaborit wrote:
À (at) Thu, 30 Jun 2011 21:12:10 +0200, (FiLH) écrivait (wrote):
> Il y a des éditeurs qui font le boulot, et quand la DTD est bien écrite, > ça permet de vérifier les choses, ce que l'on ne peut pas faire avec les > multiples syntaxe fantaisistes des fichiers plats.
Le problème des plist est bien là : la DTD ou le schéma ne fait que décrire génériquement le contenu du fichier plist. Il n'aide en rien à structurer ou à vérifier le contenu par rapport à son usage. C'est un sous-format générique non modulable construit via le format générique modulable qu'est XML.
Je ne dis pas que c'était mieux avant. Je dis juste que XML est largement sous-exploité (donc mal exploité) dans le format plist qui est bien trop générique.
C'est bien possible.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
À (at) Thu, 30 Jun 2011 21:12:10 +0200,
filh@filh.orgie (FiLH) écrivait (wrote):
> Il y a des éditeurs qui font le boulot, et quand la DTD est bien écrite,
> ça permet de vérifier les choses, ce que l'on ne peut pas faire avec les
> multiples syntaxe fantaisistes des fichiers plats.
Le problème des plist est bien là : la DTD ou le schéma ne fait que
décrire génériquement le contenu du fichier plist. Il n'aide en rien à
structurer ou à vérifier le contenu par rapport à son usage. C'est un
sous-format générique non modulable construit via le format générique
modulable qu'est XML.
Je ne dis pas que c'était mieux avant. Je dis juste que XML est
largement sous-exploité (donc mal exploité) dans le format plist qui est
bien trop générique.
C'est bien possible.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
À (at) Thu, 30 Jun 2011 21:12:10 +0200, (FiLH) écrivait (wrote):
> Il y a des éditeurs qui font le boulot, et quand la DTD est bien écrite, > ça permet de vérifier les choses, ce que l'on ne peut pas faire avec les > multiples syntaxe fantaisistes des fichiers plats.
Le problème des plist est bien là : la DTD ou le schéma ne fait que décrire génériquement le contenu du fichier plist. Il n'aide en rien à structurer ou à vérifier le contenu par rapport à son usage. C'est un sous-format générique non modulable construit via le format générique modulable qu'est XML.
Je ne dis pas que c'était mieux avant. Je dis juste que XML est largement sous-exploité (donc mal exploité) dans le format plist qui est bien trop générique.
C'est bien possible.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
filh
pehache wrote:
Le 30/06/11 23:04, Philippe Manet a écrit : > pehache wrote: > >> Quand les balises occupent 90% du fichier XML et le contenu seulement >> 10% (ce qui est le cas des plist), on peut raisonnement se demander si >> XML est un bon choix. > > je ne vois pas bien comment faire un xml autrement...
Donc il est peut-être préférable de le faire autrement qu'en XML.
> c'est déplorable au niveau place, mais vu le coupt du tera octet, on ne > peut plus non plus avoir mainetant lememe raisonnement qu'à l'époque des > dérouleurs à bande et des RAM en ferrite...
Ce n'est pas une question de place mémoire, mais plus simplement d'adéquation de l'outil utilisé par rapport au problème à traiter.
Dans une page web HTML courante, les balises sont largement minoritaires par rapport au contenu. Si on avait du décrire des pages web avec plus de balises que de contenu on aurait sûrement trouvé un autre moyen.
C'est comme utiliser du C++ et des objets pour programmer une multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C : les objets c'est puissants, on peut faire plein de choses avec, mais c'est lourd, verbeux, et au final moins efficace pour faire des choses simples accessibles à des langages faits pour.
Finalement... t'as juste du mal à t'adapter aux technologies actuelles, et t'es resté 20 ans en arrière :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
pehache <pehache.7@gmail.com> wrote:
Le 30/06/11 23:04, Philippe Manet a écrit :
> pehache<pehache.7@gmail.com> wrote:
>
>> Quand les balises occupent 90% du fichier XML et le contenu seulement
>> 10% (ce qui est le cas des plist), on peut raisonnement se demander si
>> XML est un bon choix.
>
> je ne vois pas bien comment faire un xml autrement...
Donc il est peut-être préférable de le faire autrement qu'en XML.
> c'est déplorable au niveau place, mais vu le coupt du tera octet, on ne
> peut plus non plus avoir mainetant lememe raisonnement qu'à l'époque des
> dérouleurs à bande et des RAM en ferrite...
Ce n'est pas une question de place mémoire, mais plus simplement
d'adéquation de l'outil utilisé par rapport au problème à traiter.
Dans une page web HTML courante, les balises sont largement minoritaires
par rapport au contenu. Si on avait du décrire des pages web avec plus
de balises que de contenu on aurait sûrement trouvé un autre moyen.
C'est comme utiliser du C++ et des objets pour programmer une
multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C
: les objets c'est puissants, on peut faire plein de choses avec, mais
c'est lourd, verbeux, et au final moins efficace pour faire des choses
simples accessibles à des langages faits pour.
Finalement... t'as juste du mal à t'adapter aux technologies actuelles,
et t'es resté 20 ans en arrière :)
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Le 30/06/11 23:04, Philippe Manet a écrit : > pehache wrote: > >> Quand les balises occupent 90% du fichier XML et le contenu seulement >> 10% (ce qui est le cas des plist), on peut raisonnement se demander si >> XML est un bon choix. > > je ne vois pas bien comment faire un xml autrement...
Donc il est peut-être préférable de le faire autrement qu'en XML.
> c'est déplorable au niveau place, mais vu le coupt du tera octet, on ne > peut plus non plus avoir mainetant lememe raisonnement qu'à l'époque des > dérouleurs à bande et des RAM en ferrite...
Ce n'est pas une question de place mémoire, mais plus simplement d'adéquation de l'outil utilisé par rapport au problème à traiter.
Dans une page web HTML courante, les balises sont largement minoritaires par rapport au contenu. Si on avait du décrire des pages web avec plus de balises que de contenu on aurait sûrement trouvé un autre moyen.
C'est comme utiliser du C++ et des objets pour programmer une multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C : les objets c'est puissants, on peut faire plein de choses avec, mais c'est lourd, verbeux, et au final moins efficace pour faire des choses simples accessibles à des langages faits pour.
Finalement... t'as juste du mal à t'adapter aux technologies actuelles, et t'es resté 20 ans en arrière :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
pehache
Le 03/07/11 21:34, FiLH a écrit :
Ce n'est pas une question de place mémoire, mais plus simplement d'adéquation de l'outil utilisé par rapport au problème à traiter.
Dans une page web HTML courante, les balises sont largement minoritaires par rapport au contenu. Si on avait du décrire des pages web avec plus de balises que de contenu on aurait sûrement trouvé un autre moyen.
C'est comme utiliser du C++ et des objets pour programmer une multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C : les objets c'est puissants, on peut faire plein de choses avec, mais c'est lourd, verbeux, et au final moins efficace pour faire des choses simples accessibles à des langages faits pour.
Finalement... t'as juste du mal à t'adapter aux technologies actuelles, et t'es resté 20 ans en arrière :)
Tu iras expliquer cela aux spécialistes de l'informatique scientifique et du calcul haute performance. Je ne doute pas un instant que compte tenu de ta longue expérience sur le sujet, tu pourras aisément les convaincre qu'ils sont restés 20 ans en arrière.
-- pehache
Le 03/07/11 21:34, FiLH a écrit :
Ce n'est pas une question de place mémoire, mais plus simplement
d'adéquation de l'outil utilisé par rapport au problème à traiter.
Dans une page web HTML courante, les balises sont largement minoritaires
par rapport au contenu. Si on avait du décrire des pages web avec plus
de balises que de contenu on aurait sûrement trouvé un autre moyen.
C'est comme utiliser du C++ et des objets pour programmer une
multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C
: les objets c'est puissants, on peut faire plein de choses avec, mais
c'est lourd, verbeux, et au final moins efficace pour faire des choses
simples accessibles à des langages faits pour.
Finalement... t'as juste du mal à t'adapter aux technologies actuelles,
et t'es resté 20 ans en arrière :)
Tu iras expliquer cela aux spécialistes de l'informatique scientifique
et du calcul haute performance. Je ne doute pas un instant que compte
tenu de ta longue expérience sur le sujet, tu pourras aisément les
convaincre qu'ils sont restés 20 ans en arrière.
Ce n'est pas une question de place mémoire, mais plus simplement d'adéquation de l'outil utilisé par rapport au problème à traiter.
Dans une page web HTML courante, les balises sont largement minoritaires par rapport au contenu. Si on avait du décrire des pages web avec plus de balises que de contenu on aurait sûrement trouvé un autre moyen.
C'est comme utiliser du C++ et des objets pour programmer une multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C : les objets c'est puissants, on peut faire plein de choses avec, mais c'est lourd, verbeux, et au final moins efficace pour faire des choses simples accessibles à des langages faits pour.
Finalement... t'as juste du mal à t'adapter aux technologies actuelles, et t'es resté 20 ans en arrière :)
Tu iras expliquer cela aux spécialistes de l'informatique scientifique et du calcul haute performance. Je ne doute pas un instant que compte tenu de ta longue expérience sur le sujet, tu pourras aisément les convaincre qu'ils sont restés 20 ans en arrière.
-- pehache
Stephane Legras-Decussy
Le 03/07/2011 22:14, pehache a écrit :
Tu iras expliquer cela aux spécialistes de l'informatique scientifique et du calcul haute performance. Je ne doute pas un instant que compte tenu de ta longue expérience sur le sujet, tu pourras aisément les convaincre qu'ils sont restés 20 ans en arrière.
surtout qu'il suffit de raisonner objet, si besoin, avec un langage non objet comme le bon vieux C.
Le 03/07/2011 22:14, pehache a écrit :
Tu iras expliquer cela aux spécialistes de l'informatique scientifique
et du calcul haute performance. Je ne doute pas un instant que compte
tenu de ta longue expérience sur le sujet, tu pourras aisément les
convaincre qu'ils sont restés 20 ans en arrière.
surtout qu'il suffit de raisonner objet, si besoin, avec un langage
non objet comme le bon vieux C.
Tu iras expliquer cela aux spécialistes de l'informatique scientifique et du calcul haute performance. Je ne doute pas un instant que compte tenu de ta longue expérience sur le sujet, tu pourras aisément les convaincre qu'ils sont restés 20 ans en arrière.
surtout qu'il suffit de raisonner objet, si besoin, avec un langage non objet comme le bon vieux C.
filh
pehache wrote:
>> C'est comme utiliser du C++ et des objets pour programmer une >> multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C >> : les objets c'est puissants, on peut faire plein de choses avec, mais >> c'est lourd, verbeux, et au final moins efficace pour faire des choses >> simples accessibles à des langages faits pour. > > > Finalement... t'as juste du mal à t'adapter aux technologies actuelles, > et t'es resté 20 ans en arrière :)
Tu iras expliquer cela aux spécialistes de l'informatique scientifique et du calcul haute performance. Je ne doute pas un instant que compte tenu de ta longue expérience sur le sujet, tu pourras aisément les convaincre qu'ils sont restés 20 ans en arrière.
Argument d'autorité :) Changer d'argument.
Après ça dépend de beaucoup de choses : - beaucoup de matheux utilisent le fortran... parce que les bibliothèques sont déjà écrites. - beaucoup de matheux utilisent le fortran... parce qu'ils sont plus intéressés par les math et que l'informatique les intéresse finalement assez peu. - enfin le fortran est leur idiome commun, et pour cette raison et les deux précédentes, ils ne changent pas vraiment.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
pehache <pehache.7@gmail.com> wrote:
>> C'est comme utiliser du C++ et des objets pour programmer une
>> multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C
>> : les objets c'est puissants, on peut faire plein de choses avec, mais
>> c'est lourd, verbeux, et au final moins efficace pour faire des choses
>> simples accessibles à des langages faits pour.
>
>
> Finalement... t'as juste du mal à t'adapter aux technologies actuelles,
> et t'es resté 20 ans en arrière :)
Tu iras expliquer cela aux spécialistes de l'informatique scientifique
et du calcul haute performance. Je ne doute pas un instant que compte
tenu de ta longue expérience sur le sujet, tu pourras aisément les
convaincre qu'ils sont restés 20 ans en arrière.
Argument d'autorité :) Changer d'argument.
Après ça dépend de beaucoup de choses :
- beaucoup de matheux utilisent le fortran... parce que les
bibliothèques sont déjà écrites.
- beaucoup de matheux utilisent le fortran... parce qu'ils sont plus
intéressés par les math et que l'informatique les intéresse finalement
assez peu.
- enfin le fortran est leur idiome commun, et pour cette raison et les
deux précédentes, ils ne changent pas vraiment.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
>> C'est comme utiliser du C++ et des objets pour programmer une >> multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C >> : les objets c'est puissants, on peut faire plein de choses avec, mais >> c'est lourd, verbeux, et au final moins efficace pour faire des choses >> simples accessibles à des langages faits pour. > > > Finalement... t'as juste du mal à t'adapter aux technologies actuelles, > et t'es resté 20 ans en arrière :)
Tu iras expliquer cela aux spécialistes de l'informatique scientifique et du calcul haute performance. Je ne doute pas un instant que compte tenu de ta longue expérience sur le sujet, tu pourras aisément les convaincre qu'ils sont restés 20 ans en arrière.
Argument d'autorité :) Changer d'argument.
Après ça dépend de beaucoup de choses : - beaucoup de matheux utilisent le fortran... parce que les bibliothèques sont déjà écrites. - beaucoup de matheux utilisent le fortran... parce qu'ils sont plus intéressés par les math et que l'informatique les intéresse finalement assez peu. - enfin le fortran est leur idiome commun, et pour cette raison et les deux précédentes, ils ne changent pas vraiment.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
filh
pehache wrote:
Tu iras expliquer cela aux spécialistes de l'informatique scientifique et du calcul haute performance.
Soit dit en passant tu changes complètement de domaine hein... on parlait d'informatique système, et comme tu ne trouves pas d'arguments, tu parles d'autre chose :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
pehache <pehache.7@gmail.com> wrote:
Tu iras expliquer cela aux spécialistes de l'informatique scientifique
et du calcul haute performance.
Soit dit en passant tu changes complètement de domaine hein... on
parlait d'informatique système, et comme tu ne trouves pas d'arguments,
tu parles d'autre chose :)
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Tu iras expliquer cela aux spécialistes de l'informatique scientifique et du calcul haute performance.
Soit dit en passant tu changes complètement de domaine hein... on parlait d'informatique système, et comme tu ne trouves pas d'arguments, tu parles d'autre chose :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
J.P
In article <4e11ae4f$0$5825$, Stephane Legras-Decussy wrote:
Le 03/07/2011 22:14, pehache a écrit : > > Tu iras expliquer cela aux spécialistes de l'informatique scientifique > et du calcul haute performance. Je ne doute pas un instant que compte > tenu de ta longue expérience sur le sujet, tu pourras aisément les > convaincre qu'ils sont restés 20 ans en arrière.
surtout qu'il suffit de raisonner objet, si besoin, avec un langage non objet comme le bon vieux C.
Que c'est bien dit !
Le problème n'est pas dans l'outil mais bien dans la façon dont on s'en sert. Dans le passé, j'ai vu des programmes en Ada qui étaient à l'égal de l' assembleur non commenté côté lisibilité ! ...
-- Jean-Pierre
In article <4e11ae4f$0$5825$426a74cc@news.free.fr>,
Stephane Legras-Decussy <killyourself@yesnocancel.com> wrote:
Le 03/07/2011 22:14, pehache a écrit :
>
> Tu iras expliquer cela aux spécialistes de l'informatique scientifique
> et du calcul haute performance. Je ne doute pas un instant que compte
> tenu de ta longue expérience sur le sujet, tu pourras aisément les
> convaincre qu'ils sont restés 20 ans en arrière.
surtout qu'il suffit de raisonner objet, si besoin, avec un langage
non objet comme le bon vieux C.
Que c'est bien dit !
Le problème n'est pas dans l'outil mais bien dans la façon dont on s'en sert.
Dans le passé, j'ai vu des programmes en Ada qui étaient à l'égal de l'
assembleur non commenté côté lisibilité ! ...
In article <4e11ae4f$0$5825$, Stephane Legras-Decussy wrote:
Le 03/07/2011 22:14, pehache a écrit : > > Tu iras expliquer cela aux spécialistes de l'informatique scientifique > et du calcul haute performance. Je ne doute pas un instant que compte > tenu de ta longue expérience sur le sujet, tu pourras aisément les > convaincre qu'ils sont restés 20 ans en arrière.
surtout qu'il suffit de raisonner objet, si besoin, avec un langage non objet comme le bon vieux C.
Que c'est bien dit !
Le problème n'est pas dans l'outil mais bien dans la façon dont on s'en sert. Dans le passé, j'ai vu des programmes en Ada qui étaient à l'égal de l' assembleur non commenté côté lisibilité ! ...
-- Jean-Pierre
olivier.marti
FiLH wrote:
pehache wrote:
> >> C'est comme utiliser du C++ et des objets pour programmer une > >> multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C > >> : les objets c'est puissants, on peut faire plein de choses avec, mais > >> c'est lourd, verbeux, et au final moins efficace pour faire des choses > >> simples accessibles à des langages faits pour. > > > > > > Finalement... t'as juste du mal à t'adapter aux technologies actuelles, > > et t'es resté 20 ans en arrière :) > > Tu iras expliquer cela aux spécialistes de l'informatique scientifique > et du calcul haute performance. Je ne doute pas un instant que compte > tenu de ta longue expérience sur le sujet, tu pourras aisément les > convaincre qu'ils sont restés 20 ans en arrière.
Argument d'autorité :) Changer d'argument.
Après ça dépend de beaucoup de choses : - beaucoup de matheux utilisent le fortran... parce que les bibliothèques sont déjà écrites. - beaucoup de matheux utilisent le fortran... parce qu'ils sont plus intéressés par les math et que l'informatique les intéresse finalement assez peu. - enfin le fortran est leur idiome commun, et pour cette raison et les deux précédentes, ils ne changent pas vraiment.
Il y a aussi le fait que les compilateurs fortran sont très affutés et performant pour les codes scientifiques. C'était particulièrement vrai pour les machines vectorielles, et ça reste assez vrai sur les processeurs actuels, avec plusieurs unités fonctionnelles à faire fonctionner en parallèle, et la nécessité d'accéder à la mémoire de façon intelligente.
On commence à trouver pas mal de codes scientifiques avec du C++ pour l'emballage (interface utilisateur, I/O, etc ...), et du Fortran pour la partie qui a besoin de performance.
Le Fortran moderne donne pas mal d'atouts pour faire du code fiable. Mais il n'est pas encore tout à fait assez complet pour sa partie objet, et l'objet c'est parfois bien utile.
Bref, c'est comme dans tous les métiers : il faut trouver un bon compromis entre le fait d'utiliser une grande diversité d'outils pour s'adapter à chaque tâche, et l'intérêt de se limiter à un petit nombre d'outils que l'on maitrîse.
Olivier
FiLH
FiLH <filh@filh.orgie> wrote:
pehache <pehache.7@gmail.com> wrote:
> >> C'est comme utiliser du C++ et des objets pour programmer une
> >> multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C
> >> : les objets c'est puissants, on peut faire plein de choses avec, mais
> >> c'est lourd, verbeux, et au final moins efficace pour faire des choses
> >> simples accessibles à des langages faits pour.
> >
> >
> > Finalement... t'as juste du mal à t'adapter aux technologies actuelles,
> > et t'es resté 20 ans en arrière :)
>
> Tu iras expliquer cela aux spécialistes de l'informatique scientifique
> et du calcul haute performance. Je ne doute pas un instant que compte
> tenu de ta longue expérience sur le sujet, tu pourras aisément les
> convaincre qu'ils sont restés 20 ans en arrière.
Argument d'autorité :) Changer d'argument.
Après ça dépend de beaucoup de choses :
- beaucoup de matheux utilisent le fortran... parce que les
bibliothèques sont déjà écrites.
- beaucoup de matheux utilisent le fortran... parce qu'ils sont plus
intéressés par les math et que l'informatique les intéresse finalement
assez peu.
- enfin le fortran est leur idiome commun, et pour cette raison et les
deux précédentes, ils ne changent pas vraiment.
Il y a aussi le fait que les compilateurs fortran sont très affutés et
performant pour les codes scientifiques. C'était particulièrement vrai
pour les machines vectorielles, et ça reste assez vrai sur les
processeurs actuels, avec plusieurs unités fonctionnelles à faire
fonctionner en parallèle, et la nécessité d'accéder à la mémoire de
façon intelligente.
On commence à trouver pas mal de codes scientifiques avec du C++ pour
l'emballage (interface utilisateur, I/O, etc ...), et du Fortran pour la
partie qui a besoin de performance.
Le Fortran moderne donne pas mal d'atouts pour faire du code fiable.
Mais il n'est pas encore tout à fait assez complet pour sa partie objet,
et l'objet c'est parfois bien utile.
Bref, c'est comme dans tous les métiers : il faut trouver un bon
compromis entre le fait d'utiliser une grande diversité d'outils pour
s'adapter à chaque tâche, et l'intérêt de se limiter à un petit nombre
d'outils que l'on maitrîse.
> >> C'est comme utiliser du C++ et des objets pour programmer une > >> multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C > >> : les objets c'est puissants, on peut faire plein de choses avec, mais > >> c'est lourd, verbeux, et au final moins efficace pour faire des choses > >> simples accessibles à des langages faits pour. > > > > > > Finalement... t'as juste du mal à t'adapter aux technologies actuelles, > > et t'es resté 20 ans en arrière :) > > Tu iras expliquer cela aux spécialistes de l'informatique scientifique > et du calcul haute performance. Je ne doute pas un instant que compte > tenu de ta longue expérience sur le sujet, tu pourras aisément les > convaincre qu'ils sont restés 20 ans en arrière.
Argument d'autorité :) Changer d'argument.
Après ça dépend de beaucoup de choses : - beaucoup de matheux utilisent le fortran... parce que les bibliothèques sont déjà écrites. - beaucoup de matheux utilisent le fortran... parce qu'ils sont plus intéressés par les math et que l'informatique les intéresse finalement assez peu. - enfin le fortran est leur idiome commun, et pour cette raison et les deux précédentes, ils ne changent pas vraiment.
Il y a aussi le fait que les compilateurs fortran sont très affutés et performant pour les codes scientifiques. C'était particulièrement vrai pour les machines vectorielles, et ça reste assez vrai sur les processeurs actuels, avec plusieurs unités fonctionnelles à faire fonctionner en parallèle, et la nécessité d'accéder à la mémoire de façon intelligente.
On commence à trouver pas mal de codes scientifiques avec du C++ pour l'emballage (interface utilisateur, I/O, etc ...), et du Fortran pour la partie qui a besoin de performance.
Le Fortran moderne donne pas mal d'atouts pour faire du code fiable. Mais il n'est pas encore tout à fait assez complet pour sa partie objet, et l'objet c'est parfois bien utile.
Bref, c'est comme dans tous les métiers : il faut trouver un bon compromis entre le fait d'utiliser une grande diversité d'outils pour s'adapter à chaque tâche, et l'intérêt de se limiter à un petit nombre d'outils que l'on maitrîse.
Olivier
FiLH
pehache
Le 04/07/11 20:48, FiLH a écrit :
Tu iras expliquer cela aux spécialistes de l'informatique scientifique et du calcul haute performance. Je ne doute pas un instant que compte tenu de ta longue expérience sur le sujet, tu pourras aisément les convaincre qu'ils sont restés 20 ans en arrière.
Argument d'autorité :) Changer d'argument.
C'est au contraire un excellent argument. Si la communauté du calcul scientifique reste très attachée à des langages comme le C ou le Fortran, c'est peut-être qu'il y a des (bonnes) raisons.
Après ça dépend de beaucoup de choses : - beaucoup de matheux utilisent le fortran... parce que les bibliothèques sont déjà écrites.
Si nécessaire, on peut appeler des bibliothèque écrites en Fortran depuis d'autres langages.
- beaucoup de matheux utilisent le fortran... parce qu'ils sont plus intéressés par les math et que l'informatique les intéresse finalement assez peu.
C'est normal, pour un scientifique l'informatique n'est qu'un outil. Et des langages comme le C ou le Fortran ont l'avantage d'offrir toute la puissance de calcul nécessaire, tout en restant suffisamment simples dans les concepts à maîtriser.
- enfin le fortran est leur idiome commun, et pour cette raison et les deux précédentes, ils ne changent pas vraiment.
L'usage du Fortran tend à diminuer, mais au profit du C plus que du C++.
Soit dit en passant, ce ne sont pas réellement les "matheux" qui sont les plus utilisateurs de calcul lourd.
-- pehache
Le 04/07/11 20:48, FiLH a écrit :
Tu iras expliquer cela aux spécialistes de l'informatique scientifique
et du calcul haute performance. Je ne doute pas un instant que compte
tenu de ta longue expérience sur le sujet, tu pourras aisément les
convaincre qu'ils sont restés 20 ans en arrière.
Argument d'autorité :) Changer d'argument.
C'est au contraire un excellent argument. Si la communauté du calcul
scientifique reste très attachée à des langages comme le C ou le
Fortran, c'est peut-être qu'il y a des (bonnes) raisons.
Après ça dépend de beaucoup de choses :
- beaucoup de matheux utilisent le fortran... parce que les
bibliothèques sont déjà écrites.
Si nécessaire, on peut appeler des bibliothèque écrites en Fortran
depuis d'autres langages.
- beaucoup de matheux utilisent le fortran... parce qu'ils sont plus
intéressés par les math et que l'informatique les intéresse finalement
assez peu.
C'est normal, pour un scientifique l'informatique n'est qu'un outil. Et
des langages comme le C ou le Fortran ont l'avantage d'offrir toute la
puissance de calcul nécessaire, tout en restant suffisamment simples
dans les concepts à maîtriser.
- enfin le fortran est leur idiome commun, et pour cette raison et les
deux précédentes, ils ne changent pas vraiment.
L'usage du Fortran tend à diminuer, mais au profit du C plus que du C++.
Soit dit en passant, ce ne sont pas réellement les "matheux" qui sont
les plus utilisateurs de calcul lourd.
Tu iras expliquer cela aux spécialistes de l'informatique scientifique et du calcul haute performance. Je ne doute pas un instant que compte tenu de ta longue expérience sur le sujet, tu pourras aisément les convaincre qu'ils sont restés 20 ans en arrière.
Argument d'autorité :) Changer d'argument.
C'est au contraire un excellent argument. Si la communauté du calcul scientifique reste très attachée à des langages comme le C ou le Fortran, c'est peut-être qu'il y a des (bonnes) raisons.
Après ça dépend de beaucoup de choses : - beaucoup de matheux utilisent le fortran... parce que les bibliothèques sont déjà écrites.
Si nécessaire, on peut appeler des bibliothèque écrites en Fortran depuis d'autres langages.
- beaucoup de matheux utilisent le fortran... parce qu'ils sont plus intéressés par les math et que l'informatique les intéresse finalement assez peu.
C'est normal, pour un scientifique l'informatique n'est qu'un outil. Et des langages comme le C ou le Fortran ont l'avantage d'offrir toute la puissance de calcul nécessaire, tout en restant suffisamment simples dans les concepts à maîtriser.
- enfin le fortran est leur idiome commun, et pour cette raison et les deux précédentes, ils ne changent pas vraiment.
L'usage du Fortran tend à diminuer, mais au profit du C plus que du C++.
Soit dit en passant, ce ne sont pas réellement les "matheux" qui sont les plus utilisateurs de calcul lourd.
