In article <m2k52rro2f.fsf***minuetto.depot.rail.eu.org>,
Erwan David <erwan***rail.eu.org> wrote:
>Par contre il est dans les cartes SIM, les passeports biométriques,
>etc...
>Il peut aussi être dans des terminaux de paiement ou des téléphones
>portables. Mais il ne faut oas réver : la VM estécrite en C.

Il est aussi sur le site de vente en ligne de la sncf, ce qui explique
sans doute pourquoi je n'arrive presque jamais a obtenir ce que je veux...

In article <mn.14f17d978cccd30e.79899***wanadoo.fr>,
Pierre Maurette <maurettepierre***wanadoo.fr> wrote:
>Marc Espie, le 02/07/2009 a écrit :
>> In article <m2k52rro2f.fsf***minuetto.depot.rail.eu.org>,
>> Erwan David <erwan***rail.eu.org> wrote:
>>> Par contre il est dans les cartes SIM, les passeports biométriques,
>>> etc...
>>> Il peut aussi être dans des terminaux de paiement ou des téléphones
>>> portables. Mais il ne faut oas réver : la VM estécrite en C.
>>
>> Il est aussi sur le site de vente en ligne de la sncf, ce qui explique
>> sans doute pourquoi je n'arrive presque jamais a obtenir ce que je veux...
>
>Un billet gratuit ?

Non, juste un billet. Entre les jours ou le site est totalement en panne
(la derniere fois), ceux ou ils ont merde leur config (redirection en
boucle), et le debile profond qui ne sait pas parser les erreurs de leur
partenaire (traduire "une erreur technique est intervenue" par "le train
que tu veux reserver est complet, gros naze"), je vais regulierement
directement a la gare.

Ca marchait mieux avant, sans ajax et webservices et framework a la con.
Faut dire croire'ils ne savent pas faire de tests exhaustifs, ce qui n'est
jamais tres simple en environnement dynamique...

Bref, moins je verrai de java dans un contexte critique, mieux je me
porterai.

Le 02-07-2009, ? propos de
Re: Du C ou du Java dans les systèmes embarqués automobile ?,
Zeldus ?crivait dans fr.comp.lang.c :
>
>> Bref, moins je verrai de java dans un contexte critique, mieux je me
>> porterai.
>
> Java n'est qu'un langage parmi d'autre. On trouve des bugs aussi en C++, en
> C, en Objective C, en Delphi et j'en passe. Ce que je vois c'est qu'en
> environnement professionnel, Java s'est énormément développé ces dernières
> années. Dans mon cas, chez Alcatel Lucent, quand je paramètre un équipement
> qui gère le GPRS chez l'opérateur mobile ou je travaille, j'utilise des
> applis Java embarquées dans l'équipement et ça marche très bien.
>
> Il faut éviter les généralités, et par ailleurs, dans le cas du site de la
> SNCF, rien ne prouve que le problème provient de l'appel Java. Avec l'HTML,
> Javascript, Flash, Ajax et j'en passe, c'est devenu un vrai bazar la
> conception des sites web.

Le problème, c'est surtout quel'esprit fantassin n'existe plus. Plus
il y a de couches d'abstraction (objet ou autres, je ne suis pas
raciste !) plus il y a de bugs potentiels. J'en ai encore un exemple récent.
La fonction astar de la libbost demande en moyenne 2s pour calculer un
itinéraire sur un département français (et 600 Mo de mémoire,
passons...). En réécrivant le truc en Fortran95, non seulement la
vitesse d'exécution a été multipliée par 7, mais l'occupation mémoire
n'est plus que de 65 Mo ! Bref, Java, C++ et les autres, ce sont
vraiment des usines Ã*** gaz. Si encore il n'y avait pas de fuites...

Bref, les mangages impératifs (ou Ã*** la rigueur fonctionnels), il n'y
a que ça de vrai lorsqu'on veut un tant soit peu optimiser du code.

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse Ã*** lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 03-07-2009, ? propos de
Re: Du C ou du Java dans les systèmes embarqués automobile ?,
Erwan David ?crivait dans fr.comp.lang.c :
> JKB <knatschke***koenigsberg.fr> écrivaitÂ***:
>
>> Le problème, c'est surtout quel'esprit fantassin n'existe plus. Plus
>> il y a de couches d'abstraction (objet ou autres, je ne suis pas
>> raciste !) plus il y a de bugs potentiels. J'en ai encore un exemple récent.
>> La fonction astar de la libbost demande en moyenne 2s pour calculer un
>> itinéraire sur un département français (et 600 Mo de mémoire,
>> passons...). En réécrivant le truc en Fortran95, non seulement la
>> vitesse d'exécution a été multipliée par 7, mais l'occupation mémoire
>> n'est plus que de 65 Mo ! Bref, Java, C++ et les autres, ce sont
>> vraiment des usines Ã*** gaz. Si encore il n'y avait pas de fuites...
>
> LÃ*** c'est plus un problème d'empilement de frameworks que de langage.

Pas que. Lorsqu'on programme directement en C ou en Fortran, on
attaque directement le problème frontalement. L'avantage, c'est qu'on
sait exactement ce que le code va faire. Lorsqu'on attaque avec du C++
ou du Java (ou tout autre langage objet), on ne sait plus exactement ce
qui se passe. Ça a deux conséquences immédiates :
1/ c'est effectivement plus agréable Ã*** développer
2/ on ne sait plus par où attaquer pour optimiser ou pour débugguer
lorsque ça merdoie joyeusement (sans compter que c'est souvent une
gabegie de consommation immodérée de temps CPU).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse Ã*** lui seul 25% de l'énergie que nous
consommons tous les jours.

[En-tête "Followup-To:" positionné Ã*** fr.comp.lang.c.]
Le 03-07-2009, ? propos de
Re: Du C ou du Java dans les systèmes embarqués automobile ?,
Marc Boyer ?crivait dans fr.comp.lang.c :
> On 2009-07-02, JKB <knatschke***koenigsberg.fr> wrote:
>> Le 02-07-2009, ? propos de
>> Re: Du C ou du Java dans les systèmes embarqués automobile ?,
>> Zeldus ?crivait dans fr.comp.lang.c :
>>>
>>> Java n'est qu'un langage parmi d'autre. On trouve des bugs aussi en C++, en
>>> C, en Objective C, en Delphi et j'en passe. Ce que je vois c'est qu'en
>>> environnement professionnel, Java s'est énormément développé ces dernières
>>> années. Dans mon cas, chez Alcatel Lucent, quand je paramètre un équipement
>>> qui gère le GPRS chez l'opérateur mobile ou je travaille, j'utilise des
>>> applis Java embarquées dans l'équipement et ça marche très bien.
>>>
>>> Il faut éviter les généralités, et par ailleurs, dans le cas du site de la
>>> SNCF, rien ne prouve que le problème provient de l'appel Java. Avec l'HTML,
>>> Javascript, Flash, Ajax et j'en passe, c'est devenu un vrai bazar la
>>> conception des sites web.
>>
>> Le problème, c'est surtout quel'esprit fantassin n'existe plus. Plus
>> il y a de couches d'abstraction (objet ou autres, je ne suis pas
>> raciste !) plus il y a de bugs potentiels. J'en ai encore un exemple récent.
>> La fonction astar de la libbost demande en moyenne 2s pour calculer un
>> itinéraire sur un département français (et 600 Mo de mémoire,
>> passons...). En réécrivant le truc en Fortran95, non seulement la
>> vitesse d'exécution a été multipliée par 7, mais l'occupation mémoire
>> n'est plus que de 65 Mo ! Bref, Java, C++ et les autres, ce sont
>> vraiment des usines Ã*** gaz. Si encore il n'y avait pas de fuites...
>
> Tu oublies un élément essentiel: le côut de développement.
> Actuellement, les ressources CPU/mem ne sont pas chères, alors que
> le coût horaire d'un programmeur reste cher.

Le tout est de savoir si on fait du code jetable ou non et quelle
est l'autonomie d'un développement embarqué lorsqu'il tourne sur
batterie. Être obligé d'avoir un processeur puissant, ça se paie aussi
en terme d'autonomie.

> LÃ*** encore, je ne dis pas qu'il faut programmer comme des porcs
> et que le matériel suivra. Je dis juste qu'il y a des compromis,
> et qu'il faut étudier tous les paramètres, et que les réponses
> sont différentes suivant les contextes.
>
> Après, oui, le paysage est devenu plus complexe, et l'espace
> des choix aussi.
>
> Dans les années 80, on avait quoi comme choix ? MainFrame vs PC.
> Fortran vs C vs BASIC ? En 2009, il y a tellements de choix
> Ã*** faire Ã*** tellement de niveaux...

Et beaucoup de pertes Ã*** tous les niveaux.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse Ã*** lui seul 25% de l'énergie que nous
consommons tous les jours.

In article <m27hyqqrdv.fsf***minuetto.depot.rail.eu.org>,
Erwan David <erwan***rail.eu.org> wrote:
>JKB <knatschke***koenigsberg.fr> écrivait***:
>
>> Le problème, c'est surtout quel'esprit fantassin n'existe plus. Plus
>> il y a de couches d'abstraction (objet ou autres, je ne suis pas
>> raciste !) plus il y a de bugs potentiels. J'en ai encore un exemple récent.
>> La fonction astar de la libbost demande en moyenne 2s pour calculer un
>> itinéraire sur un département français (et 600 Mo de mémoire,
>> passons...). En réécrivant le truc en Fortran95, non seulement la
>> vitesse d'exécution a été multipliée par 7, mais l'occupation mémoire
>> n'est plus que de 65 Mo ! Bref, Java, C++ et les autres, ce sont
>> vraiment des usines à gaz. Si encore il n'y avait pas de fuites...
>
>Là c'est plus un problème d'empilement de frameworks que de langage.

Je suis intimement persuade que c'est aussi lie au langage. Pour avoir
abondamment pratique le procedural et l'oriente-objet, l'oriente-objet
n'est plus simple qu'EN APPARENCE. Il est beaucoup plus simple de cacher
de la gestion d'erreur derriere des couches d'abstraction, au point
d'oublier qu'elle existe... et de se retrouver avec des erreurs "mal capturees"
qui ne "fonctionnent" que par chance, avec peu de design global, et une extreme
opacite en cas de debug... c'est pas pour rien si quelqu'un comme Herb Sutter
a passe les quelques dernieres annees a ecrire, ecrire, et ecrire sur la
difficulte de gerer les exceptions (et, plus recemment, sur la difficulte
d'ecrire du code multi-threade qui fonctionne). Des langages tels que C++
(hum...) ou java democratisent terriblement ce genre de chose: d'un coup, le
premier developpeur frais emoulu de son ecole d'inge devient capable de faire
de l'objet, de faire du parallele, et d'ecrire du code multi-threade dans
des framework complexes qui gerent les 9/10 des erreurs pour lui. Tout est
dans l'a peu pres. Passer d'un truc qui marche dans 99% des cas a un truc
fiable a 100%, c'est la qu'est la difficulte. L'extreme facilite du
developpement dans tous ces environnements ne change rien au fait qu'ecrire
du code totalement robuste, c'est difficile... d'ou les multiples et
incroyables plantages du site sncf... ou encore les telephones de derniere
generation qui rebootent ou freezent pour un oui, pour un non.

On est encore tres loin de maitriser ces outils a un niveau de qualite
"suffisant" (les criteres sont bien sur variables). Pour l'instant, ces
technologies sont regulierement deployees dans des contextes ou les criteres
economiques predominent: rapidite du developpement a faible cout, possibilite
de sortir des choses qui marchent plus vite et moins cher que la concurrence,
et qu'importe les quelques bugs, ca va juste faire chier l'utilisateur final,
mais il a deja paye, et le contrat qu'il a du accepter nous met a l'abri des
problemes...

Le 03-07-2009, ? propos de
Re: Du C ou du Java dans les systèmes embarqués automobile ?,
Marc Espie ?crivait dans fr.comp.lang.c :
> In article <m27hyqqrdv.fsf***minuetto.depot.rail.eu.org>,
> Erwan David <erwan***rail.eu.org> wrote:
>>JKB <knatschke***koenigsberg.fr> écrivaitÂ***:
>>
>>> Le problème, c'est surtout quel'esprit fantassin n'existe plus. Plus
>>> il y a de couches d'abstraction (objet ou autres, je ne suis pas
>>> raciste !) plus il y a de bugs potentiels. J'en ai encore un exemple récent.
>>> La fonction astar de la libbost demande en moyenne 2s pour calculer un
>>> itinéraire sur un département français (et 600 Mo de mémoire,
>>> passons...). En réécrivant le truc en Fortran95, non seulement la
>>> vitesse d'exécution a été multipliée par 7, mais l'occupation mémoire
>>> n'est plus que de 65 Mo ! Bref, Java, C++ et les autres, ce sont
>>> vraiment des usines Ã*** gaz. Si encore il n'y avait pas de fuites...
>>
>>LÃ*** c'est plus un problème d'empilement de frameworks que de langage.
>
> Je suis intimement persuade que c'est aussi lie au langage. Pour avoir
> abondamment pratique le procedural et l'oriente-objet, l'oriente-objet
> n'est plus simple qu'EN APPARENCE. Il est beaucoup plus simple de cacher
> de la gestion d'erreur derriere des couches d'abstraction, au point
> d'oublier qu'elle existe... et de se retrouver avec des erreurs "mal capturees"
> qui ne "fonctionnent" que par chance, avec peu de design global, et une extreme
> opacite en cas de debug... c'est pas pour rien si quelqu'un comme Herb Sutter
> a passe les quelques dernieres annees a ecrire, ecrire, et ecrire sur la
> difficulte de gerer les exceptions (et, plus recemment, sur la difficulte
> d'ecrire du code multi-threade qui fonctionne). Des langages tels que C++
> (hum...) ou java democratisent terriblement ce genre de chose: d'un coup, le
> premier developpeur frais emoulu de son ecole d'inge devient capable de faire
> de l'objet, de faire du parallele, et d'ecrire du code multi-threade dans
> des framework complexes qui gerent les 9/10 des erreurs pour lui. Tout est
> dans l'a peu pres. Passer d'un truc qui marche dans 99% des cas a un truc
> fiable a 100%, c'est la qu'est la difficulte. L'extreme facilite du
> developpement dans tous ces environnements ne change rien au fait qu'ecrire
> du code totalement robuste, c'est difficile... d'ou les multiples et
> incroyables plantages du site sncf... ou encore les telephones de derniere
> generation qui rebootent ou freezent pour un oui, pour un non.
>
> On est encore tres loin de maitriser ces outils a un niveau de qualite
> "suffisant" (les criteres sont bien sur variables). Pour l'instant, ces
> technologies sont regulierement deployees dans des contextes ou les criteres
> economiques predominent: rapidite du developpement a faible cout, possibilite
> de sortir des choses qui marchent plus vite et moins cher que la concurrence,
> et qu'importe les quelques bugs, ca va juste faire chier l'utilisateur final,
> mais il a deja paye, et le contrat qu'il a du accepter nous met a l'abri des
> problemes...

Je plussoie vigoureusement Ã*** cette analyse (surtout lorsqu'on voit
le support des threads absolument approximatif des JVM). La libpthread
POSIX est ardue, mais si on ne comprend pas les mécanismes de base, on
ne pourra _jamais_ utiliser de façon fiable un outil de plus haut
niveau. Bref, lorsqu'on est _incapable_ de formaliser quelque chose en
C, en Fortran, en ADA, autrement dit dans un langage fonctionnel ou
impératif, il est _illusoire_ de vouloir sortir un code fonctionnel est
entièrement débuggué avec un langage objet.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse Ã*** lui seul 25% de l'énergie que nous
consommons tous les jours.

In article <86vdm9vpd3.fsf***nez-casse.depot.rail.eu.org>,
Erwan David <erwan***rail.eu.org> wrote:
>En fait, les langages à objets viennent tous avec un nombre conséquent
>de bibliothèques et frameworks, et il est nettement plus difficile de ne
>pas les utiliser. Mais si on voit le nombre important de programmes GTK
>qui sortent sur stederr des messages "Critical assertion : blabla", on
>voit que même en C ce genre de programmation est possible. Et qu'elle y
>fait autant de dégat (on peut d'ailleurs ce demander pourquoi le
>framework qualifie de critique des violations d'assertions qui
>n'empêchent pas le code de fonctionner...)

Bon, a cote de ca, gtk, c'est objectivement de la merde. Reecrire un
modele objet dynamique entier en C, juste parce que C++ c'est mal, et
arriver a tout faire pourri a ce point, faut le faire expres. Le nombre
d'assertion au kilometre dans gtk+ est hallucinant. Je prefere tres
largement qt, qui lui au moins assume pleinement son cote objet, est ecrit
dans un langage adapte, et plantouille infiniment moins en pratique (sans
compter que le code resultant est moins verbeux et plus efficace).

In article <4a4e13bc$0$422$426a74cc***news.free.fr>,
Mickaël Wolff <mickael.wolff***laposte.net> wrote:
>Marc Espie a écrit :
>
>> Bref, moins je verrai de java dans un contexte critique, mieux je me
>> porterai.
>
> Il semblerait que le problème ne soit pas technologique :
><https://linuxfr.org//comments/1000177,1.html>
>
>
>--
>Mickaël Wolff aka Lupus Michaelis
>http://lupusmic.org

Oui, aussi.

Ca correspond a une part de mon impression: c'est dommage qu'il n'y ait pas
un site sncf qui vende du billet de train. A vouloir peter plus haut que leur
cul, et en ayant un tres fort trafic entretenu par la confusion (les gens
VEULENT acheter du billet de train en ligne, et il n'y a pas d'alternative
reelle), on se retrouve avec les grotesquitudes actuelles.

Mais bon, j'ai un peu tendance a assimiler marketing/management "fort"/site
technologiquement mal adapte/technologie tres clinquante super-modulaire
vendable sur appel d'offre qui fait plus joli aux yeux du manager qui n'y
comprend rien a qui on fait miroiter le mythe du mois-homme, et les SSII
qui font leur beurre la-dessus.

J'avoue que je ne comprend pas trop pourquoi personne ne s'est incruste dans
la breche pour vendre juste du train en ligne, je subodore que meme si SNCF
n'y est pour rien, il y a entente et monopole de fait...

Le 03-07-2009, ? propos de
Re: Du C ou du Java dans les systèmes embarqués automobile ?,
Erwan David ?crivait dans fr.comp.lang.c :
> JKB <knatschke***koenigsberg.fr> écrivaitÂ***:
>
>>
>> Je plussoie vigoureusement Ã*** cette analyse (surtout lorsqu'on voit
>> le support des threads absolument approximatif des JVM). La libpthread
>> POSIX est ardue, mais si on ne comprend pas les mécanismes de base, on
>> ne pourra _jamais_ utiliser de façon fiable un outil de plus haut
>> niveau. Bref, lorsqu'on est _incapable_ de formaliser quelque chose en
>> C, en Fortran, en ADA, autrement dit dans un langage fonctionnel ou
>> impératif, il est _illusoire_ de vouloir sortir un code fonctionnel est
>> entièrement débuggué avec un langage objet.
>>
>
> En fait, les langages Ã*** objets viennent tous avec un nombre conséquent
> de bibliothèques et frameworks, et il est nettement plus difficile de ne
> pas les utiliser. Mais si on voit le nombre important de programmes GTK
> qui sortent sur stederr des messages "Critical assertion : blabla", on
> voit que même en C ce genre de programmation est possible. Et qu'elle y
> fait autant de dégat (on peut d'ailleurs ce demander pourquoi le
> framework qualifie de critique des violations d'assertions qui
> n'empêchent pas le code de fonctionner...)

Bon, on ne va pas non plus disserter du côté granguignolesque des
moutures de GTK. Personnellement, je code du Motif dans le texte sans
avoir de souci. Ce n'est peut-être pas beau, mais c'est efficace.

Sérieusement, GTK (1, 2, +, enfin toutes les versions) sont des
trucs inutilisables si on devait les utiliser Ã*** la main. Rien que ça, ça
me fait dire que ce sont de mauvais produits. Qu'on utilise un
générateur de code pour les systèmes de fenêtrage, pourquoi pas. Mais
encore faut-il que le système de base soit sain, clair et qu'on puisse y
mettre le nez q'il le faut.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse Ã*** lui seul 25% de l'énergie que nous
consommons tous les jours.

rp <rp***no.com> writes:

| Il se trouve que Erwan David a formulé :
| >>> ça c'est poarcequ'il ets fait pour les nostalgiques du minitel.
| >> mini quoi ?
|
| > Un truc lent et lourd que les petits jeunes n'ont pas connu.
|
| Balivernes, ma fille de 3 ans 1/2 a joué en classe toute l'année
| avec...

Ah, c'est le truc que le MEN m'a demandé d'utiliser pour m'inscrire Ã*** un
certain concours, alors qu'il me demandait d'utiliser internet pour
fournir des informations pour un autre concours? gosh.

-- Gaby

JKB <knatschke***koenigsberg.fr> writes:

| Le 03-07-2009, ? propos de
| Re: Du C ou du Java dans les systèmes embarqués automobile ?,
| Erwan David ?crivait dans fr.comp.lang.c :
| > JKB <knatschke***koenigsberg.fr> écrivaitÂ***:
| >
| >> Le problème, c'est surtout quel'esprit fantassin n'existe plus. Plus
| >> il y a de couches d'abstraction (objet ou autres, je ne suis pas
| >> raciste !) plus il y a de bugs potentiels. J'en ai encore un exemple récent.
| >> La fonction astar de la libbost demande en moyenne 2s pour calculer un
| >> itinéraire sur un département français (et 600 Mo de mémoire,
| >> passons...). En réécrivant le truc en Fortran95, non seulement la
| >> vitesse d'exécution a été multipliée par 7, mais l'occupation mémoire
| >> n'est plus que de 65 Mo ! Bref, Java, C++ et les autres, ce sont
| >> vraiment des usines Ã*** gaz. Si encore il n'y avait pas de fuites...
| >
| > LÃ*** c'est plus un problème d'empilement de frameworks que de langage.
|
| Pas que. Lorsqu'on programme directement en C ou en Fortran, on
| attaque directement le problème frontalement. L'avantage, c'est qu'on
| sait exactement ce que le code va faire. Lorsqu'on attaque avec du C++
| ou du Java (ou tout autre langage objet), on ne sait plus exactement ce
| qui se passe.

uniquement si on ne sait pas ce c'est le problème. Dans ce cas, c'est
pas le langage. C'est le programmeur.

http://www.research.att.com/~bs/abst...nd-machine.pdf

-- Gaby