Du C ou du Java dans les systèmes embarqués automobile ?
246 réponses
Zeldus
Bonjour,
Les voitures faisant de plus en plus appel à l'électronique pour
fonctionner, même pour les tâches les plus basiques, en quel langage sont
programmés les applications qui gèrent les différentes fonctions
électroniques intégrés aux voitures ?
J'ai pensé à l'assembleur mais vu la aujourd'hui puissance et le prix des
processeurs même les plus basiques, je pense que ce n'est pas le cas et la
tâche serait complexe pour les programmeurs.
Vient ensuite le C, celui qui serait probablement le plus adapté, ancien
mais toujours très efficace ou alors Java, complètement portable mais qui
nécessite une machine virtuelle assez lourde.
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 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 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.
Wykaaa
Marc Boyer a écrit :
[snip]
D'abord, il y a de fort chance qu'elle ne soit pas sur la pile mais dans un segment de donnée de taille fixe.
Ensuite,je suis prêt à parier assez cher qu'on ne verra pas de "malloc" demain dans un calculateur automobile chargé de fonctions critiques.
Marc Boyer
Dans les logiciels de guidage de missile (j'en ai vus plusieurs en C et aussi en Ada) il est INTERDIT d'effectuer des manipulations sur la pile (donc pas de variables locales) et d'allouer de la mémoire dynamiquement. Tout doit être alloué statiquement à la compilation :-(
Marc Boyer a écrit :
[snip]
D'abord, il y a de fort chance qu'elle ne soit pas sur la pile
mais dans un segment de donnée de taille fixe.
Ensuite,je suis prêt à parier assez cher qu'on ne verra pas de "malloc"
demain dans un calculateur automobile chargé de fonctions critiques.
Marc Boyer
Dans les logiciels de guidage de missile (j'en ai vus plusieurs en C et
aussi en Ada) il est INTERDIT d'effectuer des manipulations sur la pile
(donc pas de variables locales) et d'allouer de la mémoire dynamiquement.
Tout doit être alloué statiquement à la compilation :-(
D'abord, il y a de fort chance qu'elle ne soit pas sur la pile mais dans un segment de donnée de taille fixe.
Ensuite,je suis prêt à parier assez cher qu'on ne verra pas de "malloc" demain dans un calculateur automobile chargé de fonctions critiques.
Marc Boyer
Dans les logiciels de guidage de missile (j'en ai vus plusieurs en C et aussi en Ada) il est INTERDIT d'effectuer des manipulations sur la pile (donc pas de variables locales) et d'allouer de la mémoire dynamiquement. Tout doit être alloué statiquement à la compilation :-(
Gabriel Dos Reis
(Marc Espie) writes:
[...]
| Ca marchait mieux avant,
Je crois que le refrain est « c'était mieux avang. »
-- Gaby
espie@lain.home (Marc Espie) writes:
[...]
| Ca marchait mieux avant,
Je crois que le refrain est « c'était mieux avang. »
Je crois que le refrain est « c'était mieux avang. »
-- Gaby
Gabriel Dos Reis
Erwan David writes:
| (Marc Espie) écrivait : | | > In article , | > Erwan David 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... | | ça c'est poarcequ'il ets fait pour les nostalgiques du minitel.
mini quoi ?
-- Gaby
Erwan David <erwan@rail.eu.org> writes:
| espie@lain.home (Marc Espie) écrivait :
|
| > 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...
|
| ça c'est poarcequ'il ets fait pour les nostalgiques du minitel.
| (Marc Espie) écrivait : | | > In article , | > Erwan David 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... | | ça c'est poarcequ'il ets fait pour les nostalgiques du minitel.
mini quoi ?
-- Gaby
Erwan David
Gabriel Dos Reis écrivait :
Erwan David writes:
| (Marc Espie) écrivait : | | > In article , | > Erwan David 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... | | ç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.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Gabriel Dos Reis <gdr@cs.tamu.edu> écrivait :
Erwan David <erwan@rail.eu.org> writes:
| espie@lain.home (Marc Espie) écrivait :
|
| > 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...
|
| ç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.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
| (Marc Espie) écrivait : | | > In article , | > Erwan David 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... | | ç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.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Erwan David
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.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
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.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
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.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
JKB
Le 02-07-2009, ? propos de Re: , Wykaaa ?crivait dans fr.comp.lang.c :
Marc Boyer a écrit :
[snip]
D'abord, il y a de fort chance qu'elle ne soit pas sur la pile mais dans un segment de donnée de taille fixe.
Ensuite,je suis prêt à parier assez cher qu'on ne verra pas de "malloc" demain dans un calculateur automobile chargé de fonctions critiques.
Marc Boyer
Dans les logiciels de guidage de missile (j'en ai vus plusieurs en C et aussi en Ada) il est INTERDIT d'effectuer des manipulations sur la pile (donc pas de variables locales) et d'allouer de la mémoire dynamiquement. Tout doit être alloué statiquement à la compilation :-(
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).
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 02-07-2009, ? propos de
Re: ,
Wykaaa ?crivait dans fr.comp.lang.c :
Marc Boyer a écrit :
[snip]
D'abord, il y a de fort chance qu'elle ne soit pas sur la pile
mais dans un segment de donnée de taille fixe.
Ensuite,je suis prêt à parier assez cher qu'on ne verra pas de "malloc"
demain dans un calculateur automobile chargé de fonctions critiques.
Marc Boyer
Dans les logiciels de guidage de missile (j'en ai vus plusieurs en C et
aussi en Ada) il est INTERDIT d'effectuer des manipulations sur la pile
(donc pas de variables locales) et d'allouer de la mémoire dynamiquement.
Tout doit être alloué statiquement à la compilation :-(
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).
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 02-07-2009, ? propos de Re: , Wykaaa ?crivait dans fr.comp.lang.c :
Marc Boyer a écrit :
[snip]
D'abord, il y a de fort chance qu'elle ne soit pas sur la pile mais dans un segment de donnée de taille fixe.
Ensuite,je suis prêt à parier assez cher qu'on ne verra pas de "malloc" demain dans un calculateur automobile chargé de fonctions critiques.
Marc Boyer
Dans les logiciels de guidage de missile (j'en ai vus plusieurs en C et aussi en Ada) il est INTERDIT d'effectuer des manipulations sur la pile (donc pas de variables locales) et d'allouer de la mémoire dynamiquement. Tout doit être alloué statiquement à la compilation :-(
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).
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.
JKB
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 é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.
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.
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 é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.
rp
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...
-- Glop Glop
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...
ç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...
-- Glop Glop
Samuel Devulder
Marc Espie a écrit :
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.
C'est pas tant une question de langage que de maturité des concepteurs. Bon nombre de frameworks son tout bonnement mauvais et/ou mal utilisés par des gens qui ne comprennent pas tout ce qu'ils font.
Par ailleurs Ajax c'est pas du java.. C'est du script... du javascript avec tous les problèmes des langages de scripts (vite codé, pas forcément bien testé et dans tous les cas trop vite patché: on remplace un bug par un autre... plus loin).
sam.
Marc Espie a écrit :
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.
C'est pas tant une question de langage que de maturité des concepteurs.
Bon nombre de frameworks son tout bonnement mauvais et/ou mal utilisés
par des gens qui ne comprennent pas tout ce qu'ils font.
Par ailleurs Ajax c'est pas du java.. C'est du script... du javascript
avec tous les problèmes des langages de scripts (vite codé, pas
forcément bien testé et dans tous les cas trop vite patché: on remplace
un bug par un autre... plus loin).
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.
C'est pas tant une question de langage que de maturité des concepteurs. Bon nombre de frameworks son tout bonnement mauvais et/ou mal utilisés par des gens qui ne comprennent pas tout ce qu'ils font.
Par ailleurs Ajax c'est pas du java.. C'est du script... du javascript avec tous les problèmes des langages de scripts (vite codé, pas forcément bien testé et dans tous les cas trop vite patché: on remplace un bug par un autre... plus loin).
