Marre !

On Oct 7, 8:57 pm, Fabien LE LEZ <grams...@gramster.com> wrote:

On Tue, 7 Oct 2008 18:45:04 +0000 (UTC), es...@lain.home (Marc Espie):

>(deja, si tu veux avoir l'air serieux, c'est mieux avec une
>multiplication qu'un / qui evoque plus une division...)

Si le projet est aussi merdique que tu le décris, A/H convient
très bien, et est probablement un nombre inférieur à 1 : c'est
le nombre d'année(s) qu'un employé moyen tient avant d'aller
voir si l'herbe est plus verte ailleurs.

Pour en revenir au sujet, VC++ (2008 au moins) ne m'a paru ni
meilleur ni pire qu'un autre compilo comme g++. VC++ est un
peu plus rapide, g++ est un peu plus strict, mais dans
l'ensemble, ça se vaut.

Jusqu'à un certain point, je suis d'accord. (En ce qui concerne
les versions actuelles, en tout cas, parce qu'avant g++ 2.95.2,
VC++ avait un net avantage.) Mais le mot "grands comptes" a été
laché. Quand tu as une grande quantité de données, un PC ne fait
plus l'affaire ; il faut une machine sérieuse. Et VC++ a un
défaut de taille : il ne génère pas de code pour des machines
sérieuses. (À titre d'exemple : on vient de récupérer une
machine Sparc dont l'exploitation n'en voulait plus, parce que
pas assez performante. Elle n'avait que 32 cores, ce qui ne
suffisaient pas. Et elle était bien ancienne. Sans parler de la
bande passante des entrées/sorties.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Oct 7, 9:28 pm, Sylvain SF <sylv...@boiteaspam.info> wrote:

Fabien LE LEZ a écrit :
> Pour en revenir au sujet, VC++ (2008 au moins) ne m'a paru
> ni meilleur ni pire qu'un autre compilo comme g++. VC++ est
> un peu plus rapide, g++ est un peu plus strict, mais dans
> l'ensemble, ça se vaut.

le commentaire du PO ne me parait pas lié à la rapidité du
compilo, et encore moins au fait qu'il soit largement imposé
par qui ne prend aucun risque (bien résumé par Marc), mais
peut être seulement par son utilisabilité - et les griefs ne
se résument pas à une comparaison possible entre cl (VC) vs
g++ mais à l'outil VS (05 ou 08) complet.

Ce que VS apporte par rapport à g++ est assez faible en ce qui
concerne les "grands comptes". Ce que j'ai toujours vu, c'est
qu'on se servait ce VC++ comme un compilateur normal, avec
invocation depuis l'éditeur (emacs ou gvim), exactement comme
pour g++. Où VS est intéressant, c'est pour les débuttants ; il
fait qu'il y a bien moins à apprendre d'un coup. Sinon, il est
utilisable tant qu'on développe seul, mais il se prête mal au
travail d'équipe (comme tout IDE que j'ai vu, d'ailleurs -- on
ne se sert pas de Sun Studios sur les Sparc, non plus).

là encore, les grands comptes et leur cohorte de prestataires,
tous formés aux training MS,

Pardon, mais ce n'est que les implémenteurs des clients lègers
qui ont été formé chez MS (et chez nous, ça se fait en C#, et
non en C++).

peuvent trouver génial de faire là où/comment on leur dit de
faire, mais il suffit de ne pas vouloir spontanément rentrer
dans ce moule pour être sans arrêt agacé par un IDE contre-
productif et un compilo (ensemble d'outils plutôt) travaillant
avec des règles opaques (settings inutilisables ou
inexistants) et ne produisant que des messages inadaptés.

en réponse au point de James, il me parait incorrect de penser
que VS offre "beaucoup de façons [de] s'en servir", il n'offre
que la façon de MS; certes il reste vaguement configurable,
pour modifier les raccourcis clavier par exemple, le problème
est cette configuration est pénible à faire (pas de fichier
text de conf) et incertaine (bugs), plus généralement
d'ailleurs, oui, il offre "beaucoup d'options" mais beaucoup
d'entre elles sont buggées.

Je n'ai pas parlé de Visual Studio, mais de VC++ (qui en est un
composant). N'empeche que Microsoft document très bien (mieux
que beaucoup de compilateurs Unix) comment se servir de leur
compilateur depuis la ligne de commande (ce qui veut dire,
depuis un fichier de make ou un script de shell, parce que c'est
quand même assez exceptionnel d'invoquer le compilateur
directement de la ligne de commande). J'ai pû porter mes
procédures de build depuis Unix (Solaris et Linux) sans plus
d'effort qu'il m'a fallu pour les faire portable entre Solaris
et Linux, voire entre Solaris et Sun CC et Solaris et g++.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Oct 7, 9:17 pm, es...@lain.home (Marc Espie) wrote:

In article <gcgblo$ga...@news.albasani.net>, Nico <n...@nospam.com> wrote :

>"Marc Espie" <es...@lain.home> wrote in message
>news:gcgang$24ek$1@biggoron.nerim.net...
>> In article <gcg6dh$9b...@news.albasani.net>, Nico <n...@nospam.com> wr ote:
>>>Je n'ai pas encore rencontré un grand compte bancaire ou
>>>industriel n'ayant pas de licence VC++ et/ou VS.NET. Sur
>>>des projets de plusieurs A/H, il faut être un minimum
>>>sérieux.

>> C'est pas parce que tous les grands comptes s'en servent
>> que c'est serieux pour de bon...  je ne suis toujours pas
>> convaincu que les projets de plusieurs A.H, ca soit serieux

>Quand on investit plusieurs millions d'euros, encore heureux
>que cela soit sérieux.

Oui, alors la, tu vois, j'en ai suffisamment entendu et vu,
sur les foirages a plusieurs millions d'euros, pour doucement
rigoler.

S'il y a un domaine ou l'absence de sens commun a encore de
belles annees devant elle, c'est bien les projets
informatiques pharaoniques.

Dans les années 1970 : on ne s'est jamais fait licencié pour
avoir choisi IBM. Aujourd'hui : on ne sera jamais fait licencié
pour avoir choisi Microsoft. J'ajouterais que par rapport à IBM
des années 1970, Microsoft, c'est un gentil. (Je connaissais un
cas où IBM a carrément dit à une société que s'il voulait de
l'après vente, il fallait qu'il licencie le type qui avait
conseillé un autre produit.)

Qu'on lassie tomber ; c'est complètement hors sujet ici. Le
compilateur VC++, aujourd'hui, n'est pas mal. Au moins aussi
bien que g++ (mais encore loin de Comeau). Et qu'on peut s'en
servir réelement, sans tout le Mickey Mouse de Visual Studios.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Oct 7, 9:31 pm, nazgul <Naz@Gul> wrote:

Fabien LE LEZ a écrit :

> On Mon, 06 Oct 2008 21:43:47 +0200, nazgul <Naz@Gul>:

>> Juste un petit coup de gueule contre cette saloperie de
>> visual C++ (2005). Arrivant du monde WxWidgets,

> C'est quoi le "monde wxWidgets" ?
> Je programme moi aussi avec wxWidgets comme bibliothèque
> GUI, et... VC++ 2008 (express) comme compilo. Et les deux
> fonctionnent très bien ensemble.

Correct. Je ne pestais pas contre l'IDE mais contre l'API de Microsoft.

Qui a le défaut d'ėtre « complète ». (P eut-être même bien un
peu trop:-). C'est vrai que pour faire mon MemoryMappedData, il
me faut le double de lignes sous Windows que sous Unix.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze a écrit :

Ce que VS apporte par rapport à g++ est assez faible en ce qui
concerne les "grands comptes". Ce que j'ai toujours vu, c'est
qu'on se servait ce VC++ comme un compilateur normal, avec
invocation depuis l'éditeur (emacs ou gvim), exactement comme
pour g++.

mon perception est que cet usage est (très) minoritaire - je ne dis
pas que pour certains usages, dans certaines niches, on ne se sert
pas du seul compilo en ligne de commande, mais l'essentiel des
usages est "en intégré".

la formulation "grands comptes" ne donnaient qu'à sourire bien sur,
si on parle des front-ends pour les petites mains de ces grands
comptes (saisies guichet, rapprochement, etc ...) les applis sont
certainement du C++ Wintel ou pire du C#/net, le back-office n'a
lui aucune chance d'être compilé par VC et peu de chances d'être
hosté sous wintel.

Où VS est intéressant, c'est pour les débuttants ; il
fait qu'il y a bien moins à apprendre d'un coup. Sinon, il est
utilisable tant qu'on développe seul, mais il se prête mal au
travail d'équipe.

les "petites structures" que j'ai cotoyé (10 à 100 developpeurs)
utilisaient toutes l'IDE de VS, même les non-débutants n'auraient
pas su faire un makefile. le travail en équipe est un peu possible
avec les dernières versions de VSS (visual source safe) et les
versions 'team' de VS, d'autres gestionnaires de sources (non
intégrés à VS) sont aussi utilisés, cependant dans bcp de SSII
ou petites sociétés les dev. même à plusieurs ne sont fait que
par une personne à la fois.

là encore, les grands comptes et leur cohorte de prestataires,
tous formés aux training MS,

Pardon, mais ce n'est que les implémenteurs des clients lègers
qui ont été formé chez MS (et chez nous, ça se fait en C#, et
non en C++).

tout à fait d'accord, je pense aussi que le PO a confondu
"grands comptes" avec info. (jetable) de service; dans ma
dernière boite, l'équipe "système" qui bossait sur Sun pour
des back-offices stratégiques (et rentables) comportait une
dizaine de personnes, les développeurs de clients légers
étaient une centaine, créant des applis inutiles pour la
moitié et redondante pour le reste; ce public là louait
souvent la complétude de VS qui permet de programmer à la
souris (concrêtement de faire de la merde sans se fouler).

Je n'ai pas parlé de Visual Studio, mais de VC++ (qui en est un
composant). N'empeche que Microsoft document très bien (mieux
que beaucoup de compilateurs Unix) comment se servir de leur
compilateur depuis la ligne de commande [].

compris - mais je doute que cet usage soit important (si l'on
considère tous les utilisateurs, pas ceux d'un domaine donné
- qui notamment aura d'autres règles de fonctionnement car il
utilise plus d'un compilo et plus d'un environnement).

Sylvain.

On Tue, 7 Oct 2008 15:05:54 -0700 (PDT), James Kanze
<james.kanze@gmail.com>:

Quand tu as une grande quantité de données, un PC ne fait
plus l'affaire ; il faut une machine sérieuse.

Note qu'on peut compenser la faible puissance des PC en en mettant un
grand nombre. Ce genre de configuration fonctionne très bien pour les
serveurs web, par exemple.

Ce qui ne veut pas dire que ça tourne sous Windows...

James Kanze wrote:

On Oct 7, 9:17 pm, es...@lain.home (Marc Espie) wrote:

In article <gcgblo$ga...@news.albasani.net>, Nico <n...@nospam.com> wrote:

"Marc Espie" <es...@lain.home> wrote in message
news:gcgang$24ek$1@biggoron.nerim.net...

In article <gcg6dh$9b...@news.albasani.net>, Nico <n...@nospam.com> wrote:

Je n'ai pas encore rencontré un grand compte bancaire ou
industriel n'ayant pas de licence VC++ et/ou VS.NET. Sur
des projets de plusieurs A/H, il faut être un minimum
sérieux.

C'est pas parce que tous les grands comptes s'en servent
que c'est serieux pour de bon... je ne suis toujours pas
convaincu que les projets de plusieurs A.H, ca soit serieux

Quand on investit plusieurs millions d'euros, encore heureux
que cela soit sérieux.

Oui, alors la, tu vois, j'en ai suffisamment entendu et vu,
sur les foirages a plusieurs millions d'euros, pour doucement
rigoler.

S'il y a un domaine ou l'absence de sens commun a encore de
belles annees devant elle, c'est bien les projets
informatiques pharaoniques.

Dans les années 1970 : on ne s'est jamais fait licencié pour
avoir choisi IBM. Aujourd'hui : on ne sera jamais fait licencié
pour avoir choisi Microsoft. J'ajouterais que par rapport à IBM
des années 1970, Microsoft, c'est un gentil. (Je connaissais un
cas où IBM a carrément dit à une société que s'il voulait de
l'après vente, il fallait qu'il licencie le type qui avait
conseillé un autre produit.)

Qu'on lassie tomber ; c'est complètement hors sujet ici. Le
compilateur VC++, aujourd'hui, n'est pas mal. Au moins aussi
bien que g++ (mais encore loin de Comeau). Et qu'on peut s'en
servir réelement, sans tout le Mickey Mouse de Visual Studios.

Encore faut il avoir installé Cygwin pour avoir un shell digne de ce nom ;)

Y

On Oct 8, 12:39 am, Sylvain SF <sylv...@boiteaspam.info> wrote:

James Kanze a écrit :
> Ce que VS apporte par rapport à g++ est assez faible en ce
> qui concerne les "grands comptes". Ce que j'ai toujours vu,
> c'est qu'on se servait ce VC++ comme un compilateur normal,
> avec invocation depuis l'éditeur (emacs ou gvim), exactement
> comme pour g++.

mon perception est que cet usage est (très) minoritaire - je
ne dis pas que pour certains usages, dans certaines niches, on
ne se sert pas du seul compilo en ligne de commande, mais
l'essentiel des usages est "en intégré".

J'avoue qu'il y a un monde de développements sous Windows que je
ne connais pas. Dans les « grands comptes », c-à-d les
sociétés assez grandes pour avoir des équipes plus ou moins
grandes sur beaucoup de projets différents, j'ai dû mal à
imaginer que cette mode de développement ne prédomine pas, dans
la mesure qu'il facilite le partage du code entre tous les
systèmes.

la formulation "grands comptes" ne donnaient qu'à sourire bien
sur, si on parle des front-ends pour les petites mains de ces
grands comptes (saisies guichet, rapprochement, etc ...) les
applis sont certainement du C++ Wintel ou pire du C#/net, le
back-office n'a lui aucune chance d'être compilé par VC et peu
de chances d'être hosté sous wintel.

Quand j'entends « grands comptes », je pense en termes
commerciaux ; un grand compte, c'est une boîte qui a, disons,
quelque milliers de licenses Windows. C'est donc qu'elle ne
développe pas un logiciel pour une machine seule, et qu'elle a
sûrement des machines non-Windows aussi, et qu'elle est concerné
par la gestion des sources communes à Windows, et aux Unix,
voire aux grands ordinateurs.

Ce qui donne une façon de travailler un peu différente du type
qui développe pour une seule machine dans son coin.

> Où VS est intéressant, c'est pour les débuttants ; il fait
> qu'il y a bien moins à apprendre d'un coup. Sinon, il est
> utilisable tant qu'on développe seul, mais il se prête mal
> au travail d'équipe.

les "petites structures" que j'ai cotoyé (10 à 100
developpeurs) utilisaient toutes l'IDE de VS, même les
non-débutants n'auraient pas su faire un makefile.

Il suffit qu'il y a une personne qui s'y connaît en make. Et il
te le faut même si tout le monde utilise l'IDE, parce qu'il faut
bien pouvoir intervenir et comprendre quand ça ne fait pas ce
qu'on veut.

le travail en équipe est un peu possible avec les dernières
versions de VSS (visual source safe) et les versions 'team' de
VS, d'autres gestionnaires de sources (non intégrés à VS) sont
aussi utilisés, cependant dans bcp de SSII ou petites sociétés
les dev. même à plusieurs ne sont fait que par une personne à
la fois.

Ce n'est pas tellement que le travail en équipe est impossible
avec un IDE, c'est plutôt que l'IDE n'y apporte rien (sauf un
éditeur plus spécialisé -- ce qui n'est pas forcément un
avantage, quand il faut écrire la documentation). S'il s'agit
d'éditer et de compiler, c'est aussi facile sous emacs ou vim
qu'à partir de VS. S'il agit d'integrer des autres outils, genre
des scripts pour la génération automatique du code, c'est (je
crois) même plus facile avec une boîte à outils Unix.

>> là encore, les grands comptes et leur cohorte de
>> prestataires, tous formés aux training MS,

> Pardon, mais ce n'est que les implémenteurs des clients
> lègers qui ont été formé chez MS (et chez nous, ça se fait
> en C#, et non en C++).

tout à fait d'accord, je pense aussi que le PO a confondu
"grands comptes" avec info. (jetable) de service; dans ma
dernière boite, l'équipe "système" qui bossait sur Sun pour
des back-offices stratégiques (et rentables) comportait une
dizaine de personnes, les développeurs de clients légers
étaient une centaine, créant des applis inutiles pour la
moitié et redondante pour le reste; ce public là louait
souvent la complétude de VS qui permet de programmer à la
souris (concrêtement de faire de la merde sans se fouler).

:-) Inutile est rélatif ; nos développeurs C# développe ce que
voit le client, et donc, ce d'après ce qu'il nous juge. Et il
faut lui donner l'image d'une société qui évolue ; donc, des
mises à jour de l'interface constante, même s'il n'y a pas de
changement réel derrière.

Évidemment, l'integrité transactionnelle de tout ce qui se fait
sur sa commande tourne sous Unix, mais tant que ça marche, il ne
le voit pas.

> Je n'ai pas parlé de Visual Studio, mais de VC++ (qui en est
> un composant). N'empeche que Microsoft document très bien
> (mieux que beaucoup de compilateurs Unix) comment se servir
> de leur compilateur depuis la ligne de commande [].

compris - mais je doute que cet usage soit important (si l'on
considère tous les utilisateurs, pas ceux d'un domaine donné -
qui notamment aura d'autres règles de fonctionnement car il
utilise plus d'un compilo et plus d'un environnement).

C'est important. Peut-être pas dans le sens numérique, mais dans
le sense qu'il permet la collaboration et le partage du code
entre les plateformes Unix et Windows. (Chez nous, toutes les
bibliothèques de base se développent d'abord sous Unix, et sont
portées par la suite à Windows.)

De toute façon, pour revenir au point du départ : j'ai un
jugement très favorable des compilateurs actuels de Microsoft.
L'ensemble compilateur / bibliothèque / éditeur de liens est
excellent : mieux que beaucoup de compilateurs Unix (par
exemple Sun CC). Et d'après ce qu'on me dit, dans son genre,
l'IDE est parmi les mieux. Si on veut s'en servir, mais
Microsoft, aujourd'hui au moins, supporte très bien aussi les
gens qui ne s'en servent pas.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Oct 8, 3:16 am, Fabien LE LEZ <grams...@gramster.com> wrote:

On Tue, 7 Oct 2008 15:05:54 -0700 (PDT), James Kanze
<james.ka...@gmail.com>:

> Quand tu as une grande quantité de données, un PC ne fait
>plus l'affaire ; il faut une machine sérieuse.

Note qu'on peut compenser la faible puissance des PC en en
mettant un grand nombre. Ce genre de configuration fonctionne
très bien pour les serveurs web, par exemple.

Oui et non. Ou peut-être. Si on doit traiter une grande quantité
de données ensembles, ce n'est pas si évident, et si on attaque
toujours les mêmes données, ce n'est pas si évident non plus.
Mais tu as raison qu'il existe certaines catégories
d'application où cette solution s'avère très rentable ; pour le
prix d'un Sparc haut de gamme, on peut acheter pas mal de PC.
(Note bien quand même aussi qu'il y a PC et PC. Si on veut de la
qualité et de la fiabilité, il faut mettre un certain prix même
pour le PC.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Nico a écrit :

"Mihamina Rakotomandimby" <mihamina@infogerance.us> wrote in message
news:gcf3as$8g1$2@cabale.usenet-fr.net...

Jeff wrote:

Donc quand on se sait pas se servir des meilleurs outils utilisés dans
toutes les DSI de tous les Grands Comptes...

Qu'est ce que c'est que ce tissu d'annerie?

Toi non plus, tu n'as pas trop l'air d'être du métier (et apprends le
français en passant)
Je n'ai pas encore rencontré un grand compte bancaire ou industriel n'ayant
pas de licence VC++ et/ou VS.NET.
Sur des projets de plusieurs A/H, il faut être un minimum sérieux.

Ah ben justement. Vaut mieux pas utiliser ces outils si on veut
travailler sérieusement !