"Marc Boyer" a écrit dans le message de
news:
Je n'ai pas de chiffre, mais je peux te parler de ce que je connais,
le constructeur Airbus.
Dans la partie "critique", c'est en général programmé dans un langage
"métier", semi-graphique. Ce langage fait appel à des primitives, codées,
elles en C à la main.
Nous travaillons avec le CEA sur des outils d'analyse statique, donc pour
l'embarqué avion mais potentiellement aussi le nucléaire. Le langage cible
est C. Java n'est pas à ma connaissance sur les écrans radards.
C'est paradoxal, vu la complexité "informatique et électronique" d'un Airbus
de dernière génération (du type A380 par ex), ce doit être un sacré boulot
de coder toutes les primitives en C à la main !
Bien au contraire, c'est là
que j'aurais vu du Java partout, pour la sécurité et la souplesse de
réutilisation sur d'autres avions d'autres génération comme les A340, A330,
A320, etc... Car la quantité de ligne de codes dans un Airbus et une
voiture, ça ne doit pas être comparable...
"Marc Boyer" <Marc.Boyer@cert.onera.fr.invalid> a écrit dans le message de
news:slrnh4org5.i09.Marc.Boyer@gavarnie.cert.fr...
Je n'ai pas de chiffre, mais je peux te parler de ce que je connais,
le constructeur Airbus.
Dans la partie "critique", c'est en général programmé dans un langage
"métier", semi-graphique. Ce langage fait appel à des primitives, codées,
elles en C à la main.
Nous travaillons avec le CEA sur des outils d'analyse statique, donc pour
l'embarqué avion mais potentiellement aussi le nucléaire. Le langage cible
est C. Java n'est pas à ma connaissance sur les écrans radards.
C'est paradoxal, vu la complexité "informatique et électronique" d'un Airbus
de dernière génération (du type A380 par ex), ce doit être un sacré boulot
de coder toutes les primitives en C à la main !
Bien au contraire, c'est là
que j'aurais vu du Java partout, pour la sécurité et la souplesse de
réutilisation sur d'autres avions d'autres génération comme les A340, A330,
A320, etc... Car la quantité de ligne de codes dans un Airbus et une
voiture, ça ne doit pas être comparable...
"Marc Boyer" a écrit dans le message de
news:
Je n'ai pas de chiffre, mais je peux te parler de ce que je connais,
le constructeur Airbus.
Dans la partie "critique", c'est en général programmé dans un langage
"métier", semi-graphique. Ce langage fait appel à des primitives, codées,
elles en C à la main.
Nous travaillons avec le CEA sur des outils d'analyse statique, donc pour
l'embarqué avion mais potentiellement aussi le nucléaire. Le langage cible
est C. Java n'est pas à ma connaissance sur les écrans radards.
C'est paradoxal, vu la complexité "informatique et électronique" d'un Airbus
de dernière génération (du type A380 par ex), ce doit être un sacré boulot
de coder toutes les primitives en C à la main !
Bien au contraire, c'est là
que j'aurais vu du Java partout, pour la sécurité et la souplesse de
réutilisation sur d'autres avions d'autres génération comme les A340, A330,
A320, etc... Car la quantité de ligne de codes dans un Airbus et une
voiture, ça ne doit pas être comparable...
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...
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...
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...
"Zeldus" écrivait :
Java avec son allocation dynamique et son GC n'est pas vraiment adapté
au temps réel.
Par ailleurs la portabilité et la réutilisabilité ça se
fait en C aussi.
"Zeldus" <no@email.com> écrivait :
Java avec son allocation dynamique et son GC n'est pas vraiment adapté
au temps réel.
Par ailleurs la portabilité et la réutilisabilité ça se
fait en C aussi.
"Zeldus" écrivait :
Java avec son allocation dynamique et son GC n'est pas vraiment adapté
au temps réel.
Par ailleurs la portabilité et la réutilisabilité ça se
fait en C aussi.
On 2009-07-02, JKB 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.
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...
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.
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...
On 2009-07-02, JKB 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.
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...
[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 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.
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.
[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.
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.
[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 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.
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.
On 2009-07-03, JKB wrote: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.
Tout à fait. Mais ton exemple de calcul d'itinéraire, c'était de
l'embarqué ? Tu répondais à un message qui évoquait HTML, Javascript,
Flax et Ajax... Ca faisait pas très embarqué...
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.
Mais des gains aussi en terme de rapidité de dev. Quand je vois
les feux flash mis en ligne gratos, j'imagine que leur modèle
économique implique quelques mois de developpement, pas plus.
Alors que Tetris ou mégaman sur NES, c'était plutôt en année.
On 2009-07-03, JKB <knatschke@koenigsberg.fr> wrote:
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.
Tout à fait. Mais ton exemple de calcul d'itinéraire, c'était de
l'embarqué ? Tu répondais à un message qui évoquait HTML, Javascript,
Flax et Ajax... Ca faisait pas très embarqué...
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.
Mais des gains aussi en terme de rapidité de dev. Quand je vois
les feux flash mis en ligne gratos, j'imagine que leur modèle
économique implique quelques mois de developpement, pas plus.
Alors que Tetris ou mégaman sur NES, c'était plutôt en année.
On 2009-07-03, JKB wrote: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.
Tout à fait. Mais ton exemple de calcul d'itinéraire, c'était de
l'embarqué ? Tu répondais à un message qui évoquait HTML, Javascript,
Flax et Ajax... Ca faisait pas très embarqué...
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.
Mais des gains aussi en terme de rapidité de dev. Quand je vois
les feux flash mis en ligne gratos, j'imagine que leur modèle
économique implique quelques mois de developpement, pas plus.
Alors que Tetris ou mégaman sur NES, c'était plutôt en année.
J'en ai écrit. Il y en a même en Fortran. C'est très bien que tout
soit alloué statiquement. On est _sûr_ que le truc ne va pas échouer
bêtement sur une allocation impossible (par ailleurs, la pluart du
temps, ça tourne dans des systèmes minimaux qui n'ont pas d'allocation
dynamique).
J'en ai écrit. Il y en a même en Fortran. C'est très bien que tout
soit alloué statiquement. On est _sûr_ que le truc ne va pas échouer
bêtement sur une allocation impossible (par ailleurs, la pluart du
temps, ça tourne dans des systèmes minimaux qui n'ont pas d'allocation
dynamique).
J'en ai écrit. Il y en a même en Fortran. C'est très bien que tout
soit alloué statiquement. On est _sûr_ que le truc ne va pas échouer
bêtement sur une allocation impossible (par ailleurs, la pluart du
temps, ça tourne dans des systèmes minimaux qui n'ont pas d'allocation
dynamique).
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-03, JKB wrote: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.
Tout à fait. Mais ton exemple de calcul d'itinéraire, c'était de
l'embarqué ? Tu répondais à un message qui évoquait HTML, Javascript,
Flax et Ajax... Ca faisait pas très embarqué...
Il y a des trucs embarqués et d'autres qui ne le sont pas. En
particulier, ces calculs doivent pouvoir tourner dans de l'embarqué.
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.
Mais des gains aussi en terme de rapidité de dev. Quand je vois
les feux flash mis en ligne gratos, j'imagine que leur modèle
économique implique quelques mois de developpement, pas plus.
Alors que Tetris ou mégaman sur NES, c'était plutôt en année.
Ouaips, certainement, mais ces trucs-là sont pour moi du jetable.
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-03, JKB <knatschke@koenigsberg.fr> wrote:
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.
Tout à fait. Mais ton exemple de calcul d'itinéraire, c'était de
l'embarqué ? Tu répondais à un message qui évoquait HTML, Javascript,
Flax et Ajax... Ca faisait pas très embarqué...
Il y a des trucs embarqués et d'autres qui ne le sont pas. En
particulier, ces calculs doivent pouvoir tourner dans de l'embarqué.
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.
Mais des gains aussi en terme de rapidité de dev. Quand je vois
les feux flash mis en ligne gratos, j'imagine que leur modèle
économique implique quelques mois de developpement, pas plus.
Alors que Tetris ou mégaman sur NES, c'était plutôt en année.
Ouaips, certainement, mais ces trucs-là sont pour moi du jetable.
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-03, JKB wrote: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.
Tout à fait. Mais ton exemple de calcul d'itinéraire, c'était de
l'embarqué ? Tu répondais à un message qui évoquait HTML, Javascript,
Flax et Ajax... Ca faisait pas très embarqué...
Il y a des trucs embarqués et d'autres qui ne le sont pas. En
particulier, ces calculs doivent pouvoir tourner dans de l'embarqué.
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.
Mais des gains aussi en terme de rapidité de dev. Quand je vois
les feux flash mis en ligne gratos, j'imagine que leur modèle
économique implique quelques mois de developpement, pas plus.
Alors que Tetris ou mégaman sur NES, c'était plutôt en année.
Ouaips, certainement, mais ces trucs-là sont pour moi du jetable.
JKB é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.
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.
JKB é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.
In article ,
Erwan David wrote:JKB é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...
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...
In article ,
Erwan David wrote:JKB é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...
