Sans vouloir lancer une guerre de religion, j'ai un peu bondit en
lisant ceci, directement au début :

<< Tout langage de programmation de haut niveau renferme grosso modo
les mêmes concepts. Chacun devient en
quelque sorte, un dialecte différent pour un pouvoir d’expression (ce
que l’on peut faire avec) très proche. Notre but
est, qu’une fois les concepts de base de la programmation acquis via
ce cours, et via la la pratique de Java, vous soyez
capables de :
– vous former par vous même dans l’apprentissage d’un autre langagede
programmation (dialecte)
– de programmer rapidement (parler ce dialecte) en gardant les mêmes
techniques et reflexes d´ej`a appris avec
l’étude de Java. >>

Ça insiste bien fermement sur le mot « Dialecte »

Source : http://www.auvert.org/Source/CoursCnam/chap-1.pdf

Les langages seraient donc tous les mêmes, tous des dialectes d'un
seul et même langage : voilà une bien drôle de manière de dire «
n'allez même pas essayez de voir ce qu'il se fait ailleurs, ce ne sont
que des dialectes d'un seul et même langage ».

Et c'est un cours du CNAM. Ouch!

C'était la blague du jour.

Même en ayant des arguments solide en faveur de Java contre tel ou tel
ou autre langage, on ne peut quand-même pas dire qu'ils aient les
mêmes fondements, ou alors de loin.

On retrouve encore là le mythe de la fioriture syntaxique.

Le 11/01/2010 17:36, Yannick Duchêne Hibou57 a écrit :
> Sans vouloir lancer une guerre de religion, j'ai un peu bondit en
> lisant ceci, directement au début :
>
> << Tout langage de programmation de haut niveau renferme grosso modo
> les mêmes concepts. Chacun devient en
> quelque sorte, un dialecte différent pour un pouvoir d’expression (ce
> que l’on peut faire avec) très proche. Notre but
> est, qu’une fois les concepts de base de la programmation acquis via
> ce cours, et via la la pratique de Java, vous soyez
> capables de :
> – vous former par vous même dans l’apprentissage d’un autre langage de
> programmation (dialecte)
> – de programmer rapidement (parler ce dialecte) en gardant les mêmes
> techniques et reflexes d´ej`a appris avec
> l’étude de Java. >>
>
> Ça insiste bien fermement sur le mot « Dialecte »
>
> Source : http://www.auvert.org/Source/CoursCnam/chap-1.pdf
>
> Les langages seraient donc tous les mêmes, tous des dialectes d'un
> seul et même langage : voilà une bien drôle de manière de dire «
> n'allez même pas essayez de voir ce qu'il se fait ailleurs, ce ne sont
> que des dialectes d'un seul et même langage ».

Je ne comprends pas les choses comme cela. Pour moi cela veut juste dire
que les concepts sont les mêmes. Et c'est vrai en fait. Ce qui est
difficile à comprendre c'est l'encapsulation, l'information hidding,
l'héritage, le polymorphisme... Donc lorsque ces concepts sont compris
(et c'est je pense le plus difficile) tu peux apprendre un autre langage
(procédural/objet) facilement (j'ai déjà vu des prestataires être
opérationnels en Ada en quelques jours).

Autrement dit, une personne ayant des problèmes à apprendre Ada aurait
aussi des problèmes à apprendre Java ou C++...

Je ne pense pas qu'il faille comprendre plus dans ce que tu cites.
Maintenant un langage vient aussi avec une philosophie, une approche
particulière. Ada est dans l'approche fiable et sûr, le code bien fait,
l'abstraction. Java ne véhicule pas du tout cela à mon avis (en espérant
ne pas lancer une guerre de religion non plus) Et enfin Ada avec son
typage fort va faire éviter beaucoup de bugs. Donc les concepts sont les
mêmes mais la mise en oeuvre ne donnera pas du tout les mêmes résultats.

Just my 2 cents

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

On Jan 11, 5:36*pm, Yannick Duchêne Hibou57 <yannick_duch...*yahoo.fr>
wrote:
> Sans vouloir lancer une guerre de religion, j'ai un peu bondit en
> lisant ceci, directement au début :
>
> << Tout langage de programmation de haut niveau renferme grosso modo
> les mêmes concepts. Chacun devient en
> quelque sorte, un dialecte différent pour un pouvoir d’expression (ce
> que l’on peut faire avec) très proche. Notre but
> est, qu’une fois les concepts de base de la programmation acquis via
> ce cours, et via la la pratique de Java, vous soyez
> capables de :
> – vous former par vous même dans l’apprentissage d’un autre langage de
> programmation (dialecte)
> – de programmer rapidement (parler ce dialecte) en gardant les mêmes
> techniques et reflexes d´ej`a appris avec
> l’étude de Java. >>
>
> Ça insiste bien fermement sur le mot « Dialecte »
>
> Source :http://www.auvert.org/Source/CoursCnam/chap-1.pdf
>
> Les langages seraient donc tous les mêmes, tous des dialectes d'un
> seul et même langage : voilà une bien drôle de manière de dire «
> n'allez même pas essayez de voir ce qu'il se fait ailleurs, ce ne sont
> que des dialectes d'un seul et même langage ».
>
> Et c'est un cours du CNAM. Ouch!
>
> C'était la blague du jour.
>
> Même en ayant des arguments solide en faveur de Java contre tel ou tel
> ou autre langage, on ne peut quand-même pas dire qu'ils aient les
> mêmes fondements, ou alors de loin.
>
> On retrouve encore là le mythe de la fioriture syntaxique.

Je suis en désaccord complet avec les auteurs. S'ils avaient choisi un
autre langage, j'aurais à la rigueur pu être d'accord mais Java, comme
Python, Ruby et pas mal d'autres langages, cachent complètement
certains "concepts de base de la programmation", de sorte que ceux qui
ne connaissent que ces langages ne peuvent pas apprendre ces concepts.
Parmi ceux-ci:
- la gestion de la mémoire
- l'arithmétique sur les pointeurs
- l'ordonnancement
- les structures de données (les concevoir, pas simplement les
utiliser)
- la programmation de bas niveau (de plus en plus nécessaire! Pour
chaque PC de bureau vendu il y a des dizaines de petits appareils avec
logiciel embarqué, du lave-linge au sous-marin nucléaire!)

Sans ces concepts-là, le programmeur novice reste... novice

--
Ludovic Brenta.

Ludovic Brenta a écrit :
> On Jan 11, 5:36 pm, Yannick Duchêne Hibou57 <yannick_duch...*yahoo.fr>
> wrote:
>> Sans vouloir lancer une guerre de religion, j'ai un peu bondit en
>> lisant ceci, directement au début :
>>
>> << Tout langage de programmation de haut niveau renferme grosso modo
>> les mêmes concepts. Chacun devient en
>> quelque sorte, un dialecte différent pour un pouvoir d’expression (ce
>> que l’on peut faire avec) très proche. Notre but
>> est, qu’une fois les concepts de base de la programmation acquis via
>> ce cours, et via la la pratique de Java, vous soyez
>> capables de :
>> – vous former par vous même dans l’apprentissage d’un autre langage de
>> programmation (dialecte)
>> – de programmer rapidement (parler ce dialecte) en gardant les mêmes
>> techniques et reflexes d´ej`a appris avec
>> l’étude de Java. >>
>>
>> Ça insiste bien fermement sur le mot « Dialecte »
>>
>> Source :http://www.auvert.org/Source/CoursCnam/chap-1.pdf
>>
>> Les langages seraient donc tous les mêmes, tous des dialectes d'un
>> seul et même langage : voilÃ* une bien drôle de manière de dire «
>> n'allez même pas essayez de voir ce qu'il se fait ailleurs, ce ne sont
>> que des dialectes d'un seul et même langage ».
>>
>> Et c'est un cours du CNAM. Ouch!
>>
>> C'était la blague du jour.

Disons que dans une approche globale de la programmation et des
langages, ce n'est pas une blague car il n'y a pas beaucoup de
paradigmes de programmation...
>>
>> Même en ayant des arguments solide en faveur de Java contre tel ou tel
>> ou autre langage, on ne peut quand-même pas dire qu'ils aient les
>> mêmes fondements, ou alors de loin.

Ben si, ils ont tous les mêmes fondements : séquence, alternative,
itérative, récursion. Tous les langages de programmation se doivent
d'être Turing-complet.
Ensuite, des paradigmes comme la programmation objet, la programmation
fonctionnelle, la programmation déclarative, la programmation impérative
ne sont sont lÃ* que pour classifier les langages.
Dans ce contexte, le polymorphisme, par exemple, n'est qu'une facilité
de programmation... (comme le switch vis-Ã*-vis des if-then-else).
>>
>> On retrouve encore lÃ* le mythe de la fioriture syntaxique.

Il y a beaucoup de "sucre syntaxique" dans les langages de programmation
pour augmenter la lisibilité des programmes mais au fond du fond, il n'y
a que 2 instructions qui permettent d'écrire toutes les fonctions
effectivement calculables (au sens de la thèse de Church-Turing) en
tenant compte de la correspondance de Curry-Howard, ce sont les
opérateurs K et S de la logique combinatoire :
K x y = x
S x y z = x z (y z)
>
> Je suis en désaccord complet avec les auteurs. S'ils avaient choisi un
> autre langage, j'aurais Ã* la rigueur pu être d'accord mais Java, comme
> Python, Ruby et pas mal d'autres langages, cachent complètement
> certains "concepts de base de la programmation", de sorte que ceux qui
> ne connaissent que ces langages ne peuvent pas apprendre ces concepts.
> Parmi ceux-ci:
> - la gestion de la mémoire
C'est ce qui pose le plus de problème aux programmeurs
> - l'arithmétique sur les pointeurs
Pas indispensable pour programmer
> - l'ordonnancement
de quoi ? des processus ? le threading ?
> - les structures de données (les concevoir, pas simplement les
> utiliser)
Concevoir des structures de données est, Ã* mon avis, le plus difficile
pour les programmeurs/concepteurs
> - la programmation de bas niveau (de plus en plus nécessaire! Pour
> chaque PC de bureau vendu il y a des dizaines de petits appareils avec
> logiciel embarqué, du lave-linge au sous-marin nucléaire!)
Bas niveau ? comme aller "voir" la valeur d'un bit dans un registre
d'interruption ?
>
> Sans ces concepts-lÃ*, le programmeur novice reste... novice

Je suis assez d'accord avec toi dans le domaine du pragmatisme.
>
> --
> Ludovic Brenta.

Yannick Duchêne Hibou57 a écrit :
> On 6 fév, 20:47, Wykaaa <wyk...*yahoo.fr> wrote:
>> Disons que dans une approche globale de la programmation et des
>> langages, ce n'est pas une blague car il n'y a pas beaucoup de
>> paradigmes de programmation...
> Le nombre de paradigme existant peut être assez variable selon les
> points de vus. J'ai remarqué que typiquement, l'approche «
> mathématique » d'un langage distinguera un plus grand nombre d'aspect
> que ne le fera l'exposé des caractéristiques du langage dans les
> termes de la communauté utilisant ce langage. Le phénomène est
> amplifié par le fait qu'il est perçu comme séduisant de présenter un
> langage comme unifiant ingénieusement des concepts différents en
> toutes simplicité. Un langage, surtout s'il fait buzzé, sera souvent
> présenté de cette manière, comme un robot ménager qui fait tout mais
> qui est simple Ã* utiliser. Si selon un point de vue, on compte 5
> concept pouvant être disjoint dans le langage X, on trouvera toujours
> un point de vue qui n'en comptera qu'un ou tout sera unifié (il n'y a
> pas qu'en physique que la quête de l'unification fait rêver).

Je parle des fondements, pas des détails. On a vu, dans le passé, avec
PL/1 (d'IBM) ce que cela donnait de vouloir faire un langage "robot
ménager" qui mélangerait Fortran et Cobol pour faire un langage
universel. Cela a été un échec assez cuisant et cela conforte ce que je
disais et maintiens : il n'y a pas beaucoup de paradigmes de
programmation dans les fondements.
>
> Je ne fais pas avancer la question, je sais, mais je pense démontrer
> qu'elle n'est pas si simple, si qui j'espère peut éviter de s'égarer
> sur cette question.

Elle est justement très simple.
>
>> Ben si, ils ont tous les mêmes fondements : séquence, alternative,
>> itérative, récursion. Tous les langages de programmation se doivent
>> d'être Turing-complet.
> Qu'ils se doivent tous d'être Turing-complet n'implique pas qu'ils
> disposent des mêmes opérations.

Certes mais ce sont des variantes de primitives atomiques irréductibles.

> La machine de Turing n'est une modèle
> d'ordinateur universel, elle est un exemple de machine disposant des
> propriétés universelles d'un ordinateur. C'est vraiment différent.
> L'idée de Turing était celle d'une machine ayant certaines
> caractéristiques. Il a posé un exemple de machine ayant ces
> caractéristique, en avant qu'elle n'était pas la seule machine a avoir
> ces caractéristiques, mais celle-ci, les avaient, et c'est tout ce qui
> comptait (même son efficacité ne comptait pas, ... et ça se voit,
> parce que bonjour les temps d'accès mémoire). Il a ensuite posé que
> l'on pouvait démontrer qu'une machine posséde ou non les mêmes
> caractéristique, en définissant des règles d'équivalence. Lorsque l'on
> démontre qu'une machine quelconque est équivalente Ã* une machine de
> Turing, et qu'on la qualifie alors de Turing-Complète, on ne démontre
> pas qu'elle est fondée sur un ensemble d'instruction en particulier,
> mais que son fonctionnement présente les mêmes propriétés que la
> machine de Turing historique, qui n'est elle même qu'un modèle,
> choisi, parce qu'il fallait bien en choisir un.

Merci, je connais parfaitement les machines de Turing.
>
> Exemple de langages, tous Turing-complet (au moins dans leurs versions
> récentes de ces dernières années), et qui ne sont pourtant pas du tout
> fondée sur les mêmes primitives : Prolog, Lisp, SQL, XSLT, Pascal. Ces
> cinq langages n'ont pas le même jeux de primitives. Mais il sont
> Turing-complet, ce qui signifie que lorsqu'ils sont interprété, ils
> sont comme une machine ayant les même propriétés que la machine de
> Turing. Partant de lÃ*, on pourrait définir la même relation
> d'équivalence en démontrant que Pascal est Turing-complet parce qu'il
> a les mêmes propriétés requise pour être Turing-complet que celles
> dont dispose Prolog.

SQL n'est devenu Turing-complet qu'Ã* partir de 1999 quand il a été
possible d'exprimer des requêtes récursives.

Le jeux de primitives est le même mais c'est bien masqué. Par exemple,
en Prolog, les alternatives sont les clauses de Horn et les boucles et
la récursion sont, en quelque sorte, câblées dans l'interpréteur (et ses
3 "horloges", si ma mémoire est exacte) grâce aux arbres rationnels
(potentiellement) infinis
>
> Le paysage n'est plus le même après ces mots.
>
>> Ensuite, des paradigmes comme la programmation objet, la programmation
>> fonctionnelle, la programmation déclarative, la programmation impérative
>> ne sont sont lÃ* que pour classifier les langages.
> C'est trop de dire ça : certains language ont été au contraire conçu
> pour mettre en oeuvre des paradigme pré-établi et présenté sous
> d'autres formalismes : preuve de l'existance de la démarche inverse,
> conjointement.

Excuse-moi, je ne comprends pas ta phrase.
>
>> Dans ce contexte, le polymorphisme, par exemple, n'est qu'une facilité
>> de programmation... (comme le switch vis-Ã*-vis des if-then-else).
> Tout dépend de quoi il est accompagné.
>
> L'opération logique xor n'est qu'une facilité si l'on dispose par
> ailleurs de l'opération or et de l'opération not. Mais elle devient
> une nécéssité si l'on ne dispose que d'une seule.

Ceci est faux car il existe un système d'axiomes (4 axiomes) pour la
logique des propositions, qui n'utilise que l'implication et le or
(Hilbert-Ackermann, 1928).
Il existe même, toujours pour la logique des propositions, 3 systèmes Ã*
1 seul axiome qui n'utilise que la barre de Scheffer (le NAND quand on
utilise le vocabulaire des portes logiques). Ces 3 systèmes sont dus Ã*
Meredith en 1953. En voici un :
Voir : http://www.utm.edu/research/iep/p/prop-log.htm#H6
>
> Le polymorphisme peut de la même manière être une primitive
> fondamentale, tout comme le passage de message dans les languges
> d'acteur (comme Actor justement), est une primitive formellement
> fondamentale et n'est pas une simple facilité. Sans cette primitive,
> les langages de cette catégorie deviennent tous impotants.

Certains langages mettent plus l'accent sur certains paradigmes mais
fondamentalement, ça ne change rien par rapport aux constructions
atomiques (irréductibles).
>
>> Il y a beaucoup de "sucre syntaxique" dans les langages de programmation
>> pour augmenter la lisibilité des programmes mais au fond du fond, il n'y
>> a que 2 instructions qui permettent d'écrire toutes les fonctions
>> effectivement calculables (au sens de la thèse de Church-Turing) en
>> tenant compte de la correspondance de Curry-Howard, ce sont les
>> opérateurs K et S de la logique combinatoire :
>> K x y = x
>> S x y z = x z (y z)
> Je n'ai pas compris le "x z (y z)", mais je suis quasiment sûr que ce
> que tu présente n'est qu'un exemple d'implémentation d'une machine
> ayant les propriétés que permettent d'identifier la démonstration de
> l'équivalence avec la machine de Turing historique (comme expliqué
> plus haut). Sous réserve que je ne dise pas de bétise sur ce coup lÃ*
> (je ne suis pas sûr d'avoir décrypté).

Non, ce n'est pas une machine, ce sont les 2 opérateurs de base de la
logique combinatoire de Curry.
>
>>> - la gestion de la mémoire
>> C'est ce qui pose le plus de problème aux programmeurs> - l'arithmétique sur les pointeurs
> Hola, tu trébuche : l'arithmétique sur les points est ce qui pose le
> plus de problème aux programmeurs qui conçoivent leurs créations Ã*
> l'aide d'un langage qui permet (et repose beaucoup sur) l'arithmétique
> des pointeurs.

L'arithmétique pointeur n'existe quasiment que dans les langages de la
"famille" C. Ce n'est pas un paradigme de programmation, tout au plus un
bricolage qui laisse l porte ouverte Ã* la programmation non sûre...
>
> Ce n'est par exemple pas du tout le cas des cinq langages précédement
> cités par exemple (Prolog, Lisp, SQL, XSLT, Pascal, et ajoutant un
> sixième... tu vois du quel je parle...)
>
>> Pas indispensable pour programmer
>>> - l'ordonnancement
>> de quoi ? des processus ? le threading ?
> Si ce n'est juste que certains domaine non-déterministe ne peuvent pas
> être exprimé autrement que par des tâches concurrentes, ou alors ne
> conaissent pas d'aboutissement convenable sans finir dans des
> itérations infinis si on ne les implémentes pas avec des tâches
> concurrentes.

La programmation concurrente contient ses propres difficultés : états
non atteignables, famine, etc. Il faut des systèmes de preuve sophistiqués.

Les problèmes indécidables ne sont pas des monstres
> issues de légendes, ils existent bien.

Oui, tout le monde sait (ou devrait savoir) ça.

> Prolog est un exemple de
> compromis dans ce domaine, et il lui arrive d'ailleurs justement de
> finir dans des boucles infini, parce que son implémentation
> traditionel est séquentiel - d'autres comme Concurrent Prolog
> fonctionne je te laisse diviner comment.

On peut faire de l'évaluation paresseuse en Prolog classique.
>
> Plus proches de nous, les applications avec des interfaces
> utilisateurs dignent de ce nom, *requièrent* au minimum deux tâches,
> sans quoi un blocage de la fonction fondamentale de l'application
> entraine un blocage de son interface avec l'utilisateur.

Quand c'est mal programmé et que l'architecture en couches n'a pas été
respectée.
>
>>> - les structures de données (les concevoir, pas simplement les
>>> utiliser)
>> Concevoir des structures de données est, Ã* mon avis, le plus difficile
>> pour les programmeurs/concepteurs
> Je ne suis pas certain d'avoir compris dans quel sens tu as dis cette
> phrase, mais ma réponse serait spontanément : raison de plus pour
> savoir les créer. On n'apprend pas ce qu'est un plat préparé, même
> simple, en réchauffand un Bolino (n'existe plus je crois, j'étais tout
> gamin) ou un sachet Knorr tous les jours.

Il ne s'agit pas de savoir les créer. Il s'agit de déterminer la ou les
meilleures structures de données Ã* mettre en place en fonction des
fonctions (services) que doit rendre l'application et vis-Ã*-vis des
performances (au sens anglo-saxon du terme, pas au sens français qui
réduit performance Ã* efficacité d'exécution).
>
> Je sais depuis longtemps que l'on comprend bien mieux la roue quand on
> a dut l'inventer (la ré-inventer certaines personnes préféreront dire)
> soi-même. Pour comprendre la physique Ã* l'échelle cosmologique, la
> physique contemporaine ne cherchent-elle pas de nos jours la solution
> dans la physique sub-atomique ?
>
> Il y a une science, qui s'appel la systémique, qui dit en gros que
> tout est lié, que rien n'est indissociable. La conscéquence de cette
> théorie (qui est n'est pas qu'une théorie Ã* mes yeux), qu'il est
> toujours une illusion de cacher la compléxité de la réalité, et qu'on
> ne peut que la gérer. Si tu réduis le nombre d'élément en interaction,
> alors c'est que inévitablement tu rend leurs intéractions plus
> complexes. Si tu simplifie les intéractions, alors inévitablement tu
> augmente le nombre d'élément en intéractions. Le tout est de trouver
> l'équilibre le mieux adapté Ã* la compréhesion humaine, sachant que
> celle-ci peut être visiblement assez différente d'une personne Ã*
> l'autre (dans la manière de comprendre les choses).
>
> Et savoir les créer, permet au passage d'en apprécier la valeur et de
> comprendre l'importance des interfaces qui permettent de les utiliser.

Non, ce n'est pas cela le problème. Les interactions découlent du
découpage de l'application en structures et/ou objets qui sont
pertinents pour l'application.
De plus, quand on parle d'interface, il ne faut pas penser qu'aux
interfaces graphiques mais aux interfaces entre
fonctions/modules/objets, etc.
>
>> - la programmation de bas niveau (de plus en plus nécessaire! Pour
>>> chaque PC de bureau vendu il y a des dizaines de petits appareils avec
>>> logiciel embarqué, du lave-linge au sous-marin nucléaire!)
>> Bas niveau ? comme aller "voir" la valeur d'un bit dans un registre
>> d'interruption ?
> LÃ*, sur ce point lÃ*, si je me lance, tu ne m'arrête plus, et je
> m'égosille tellement j'ai envie de crier. Mais allez, juste deux
> exemple qui te permettront de comprendre ce que j'en pense et pourquoi
> je suis d'accord avec l'idée de ne pas perdre ces détails de vue. Deux
> images que j'aime rappeler. Windows 3.1 (un environement complet avec
> ses applications de base) : 2M RAM, 10M DD, CPU 12Mhz. Une application
> toute bête et rudimentaire en 2005, un clavier MIDI virtuel sous
> Windows XP, en gros, une image bitmap des touche d'un piano, lorsque
> tu clique sur l'une de celle ci, l'application envoit quelques octets
> de données sur un canal de communication (un signal MIDI) : 15M DD 18M
> RAM CPU (minimum recommandé) Pentium II. La seconde image, c'est celle
> des empilement de machines virtuelles les unes sur les autres. Une
> application Lisp avec interface utilisateur écrite en Lisp (les
> adeptent de certaines langages refusent parfois que certaines choses
> ne soient pas conçues dans ce langage), et un interpréteur Lisp écrit
> en Java (un exemple qui n'a plus rien d'exceptionel de nos jours,
> tellement la « portabilité » est Ã* la mode, ou plutôt son illusion vu
> les couts cachés), sous Vista ou Seven, ça donne Une machine virtuelle
> (l'environnement utilisateur écrit en Lisp) sur une machine virtuelle
> (l'interpréteur Lisp en Java) sur une machine virtuelle (la machine
> Java) sur une machine virtuelle (l'environnement utilisateur de
> Windows Vista ou Seven), et tu peux en rajouter une autre si le tout
> fonctionne dans un émulateur Windows sous Linux (en espérant que ce ne
> soit pas encore une LinuxBox virtuelle). J'exagère avec les deux
> dernière couche, mais on peut facilement avoir 3 ou 4 machine
> virtuelles s'empilant les unes sur les autres, on arrête pas le
> progret (et ce n'est pas le Web qui sera l'exemple du contraire,
> malheureusement dans ce lÃ*, sans avoir d'autres choix). Mais ces deux
> images devraientt te donner une idée des autres bonnes raisons qu'il y
> a Ã* dire ce qu'il a dit. Il y a vraiment de bonnes raisons de se
> remettre Ã* penser aux « couche de bas niveaux ». Désolé pour la
> tartine, elle est Ã* la dimmension de l'énormité de la situation
> actuell

Il y a des cas où l'empilement de "couches d'abstraction" est justifié
pour l'évolutivité, la portabilité, l'interopérabilité,etc.
Il ne faut pas oublier que certains logiciels devront évoluer sur de
très longues périodes (minimum 30 ans) comme dans les systèmes
militaires, par exemple.
Ceci étant, il ne faut pas en (ab)user plus que nécessaire...

>
>
>>> Sans ces concepts-lÃ*, le programmeur novice reste... novice
>> Je suis assez d'accord avec toi dans le domaine du pragmatisme.
> Je vous rejoins tous les deux aussi.

Il n'existe pas de langage "miracle" (robot ménager Ã* tout faire !)
mais, pour revenir au sujet, si j'avais le choix entre Java et Ada pour
une application où le choix est indifférent, je choisirais plutôt Ada.

Ada, pas plus que d'autres langages, n'est un dialecte de Java. Ils
correspondent Ã* des usages assez différents sauf dans certains cas assez
précis.
Ceci dit, il existe des compilateurs Ada qui savent générer du bytecode
interpréter par une JVM ;-) :
Jgnat, ObjectAda (Aonix), AppletMagic (Sofcheck).

Yannick Duchêne Hibou57 a écrit :
> On 8 fév, 20:43, Wykaaa <wyk...*yahoo.fr> wrote:
>>> Plus proches de nous, les applications avec des interfaces
>>> utilisateurs dignent de ce nom, *requièrent* au minimum deux tâches,
>>> sans quoi un blocage de la fonction fondamentale de l'application
>>> entraine un blocage de son interface avec l'utilisateur.
>> Quand c'est mal programmé et que l'architecture en couches n'a pas été
>> respectée.
> Bonsoir,
>
> Je repasserai plus tard (ou un autre jour) pour répondre Ã* tous les
> points très intéressants que tu as soulevé. Pour l'instant, juste un
> lien en rapport avec l'extrait que je cite de toi (ça parle du
> parallélisme dans les interface utilisateur... en Ada notamment) :
> http://tronche.com/biblio/ihm-96.html

Attention, je n'ai pas dit que la programmation concurrente n'était pas
utile mais il me semble que ce n'est pas dans le domaine des IHM qu'elle
est le plus utile car, compte tenu de la vitesse des processeurs
actuels, l'utilisateur, dans son interaction avec l'IHM est infiniment
plus lent que la machine.
Tout dépend de ce que recouvre le terme d'IHM. Pour le traitement et
l'affichage de photos, si les traitements sont coûteux, il faudra
évidemment utiliser la concurrence.
Aujourd'hui, on aura tendance Ã* découper les applications de telle sorte
que des parties puissent s'exécuter sur des coeurs différents plutôt que
dans des threads d'un même processus car dans ce cas, on ne bénéficie
pas de l'architecture multicoeur (en plus un "coeur" de processeur est
en général plus lent qu'un processeur monocoeur).
Ton lien vers l'article est intéressant mais il est assez daté (96) et
depuis les choses ont bien évolué tant du point de vue matériel que de
l'ingénierie logicielle, même si, pour cette dernière, les choses vont
plus lentement.

On 9 fév, 11:30, Wykaaa <wyk...*yahoo.fr> wrote:
> Attention, je n'ai pas dit que la programmation concurrente n'était pas
> utile mais il me semble que ce n'est pas dans le domaine des IHM qu'elle
> est le plus utile car, compte tenu de la vitesse des processeurs
> actuels, l'utilisateur, dans son interaction avec l'IHM est infiniment
> plus lent que la machine.
Ce n'est pas pour par crainte que l'utilisateur ne manie trop
rapidement la souris plus vite que son ombre que le parallélisme est
important dans les UI (je préfère UI, plutôt que IHM, par soucis de
neutralité), et un utilisateur même ultra-rapide, n'arriverait pas à
prendre de vitesse une machine cadencée à 500Khz (les reflexe humain
on une finesse de l'ordre de la fraction de seconde, pas plus... 4 ou
5Hz au mieux). C'est pour d'autres raisons (voir plus loin).

> Tout dépend de ce que recouvre le terme d'IHM. Pour le traitement et
> l'affichage de photos, si les traitements sont coûteux, il faudra
> évidemment utiliser la concurrence.
La concurrence ne s'utilise pas pour accélérer les calculs. Un
traitement dont l'étape n+1 dépend de l'étape n, ne sera gagnera rien
à être traité avec du parallélisme.

C'est pour des raisons algorithmique ou de nature intrinsèque des
choses que la parallélisme est utilisé. Pour preuve, Ada 83
connaissait déjà les tâche, et pour à l'époque de Ada 83 (et même
avant, il a été conçue en 1980), les machine n'atteignaient pas les
10MHz. Pourtant le parallélisme était une exigence du langage déjà à
cette époque : pour répondre à la nature des environnement et des
réalités, intrinsèquement concurrente, auxquelles les applications
conçues dans le langage devaient pouvoir répondre.

> Aujourd'hui, on aura tendance à découper les applications de telle sorte
> que des parties puissent s'exécuter sur des coeurs différents plutôt que
> dans des threads d'un même processus car dans ce cas, on ne bénéficie
> pas de l'architecture multicoeur (en plus un "coeur" de processeur est
> en général plus lent qu'un processeur monocoeur).
Même pas : ce qui est mis le plus en avant, c'est le fait, non pas de
lancer plusieurs thread en même temps (l'utilisateur lambda s'en moque
totalement), mais de lancer plusieurs applications en même temps. Et
vu le nombre d'applications active en même temps sur les plupart des
environnement, inutile de dire que si une application espère allouer
les deux cœurs du processeurs pour deux de ces threads, elle se trompe
beaucoup.

> Ton lien vers l'article est intéressant mais il est assez daté (96) et
> depuis les choses ont bien évolué tant du point de vue matériel quede
> l'ingénierie logicielle, même si, pour cette dernière, les choses vont
> plus lentement.
1996, oui, mais ce n'est pas important. Et ça devrait même au
contraire t'interpeller en te faisant penser que même déjà à cette
époque, même si les conditions matérielles y étaient pourtant moins
favorable, le parallélisme était déjà un but (pour les raisons
précédentes).

Pour aller plus loin sur ces raisons, et la question qu'on ne crains
pas que l'utilisateur clique trop vite sur les boutons d'une boite de
dialogue : pense que l'application peut être tout simplement bloqué,
ou être occupé à un calcul intensif, qui peut laisser croire qu'elle
est bloqué. Comment peut-elle prendre en charge l'interface
utilisateur dans ces conditions ? Exemple avec Write sous Windows
3.1 : si tu ouvrais un gros fichier et que Write prenait beaucoup de
temps à le formater pour l'afficher, son interface était totalement
bloqué pendant tout ce temps là. Pense aussi que l'utilisateur peut
vouloir interrompre une action longue ou trop longue à son gout. Si
l'application est occupé à une action trop longue, comment peut-elle
justement réceptionner la requête de l'utilisateur ? La réponse à
toutes ces question, ce sont les tâches (les Task, en Ada). À moins
que l'application n'exécute que des petites actions très brèves, et
dans ce cas, elle peut rapidement revenir à la gestion de l'UI. Mais
même dans ce cas, si elle plante, alors son UI plante aussi, ne
laissant aucune chance à l'utilisateur de comprendre quoi que ce soit,
ou de tenter de quitter proprement en sauvant les meubles (comme en
tentant d'enregistrer un fichier modifié).

Quand le parallélisme est utilisé, c'est parce que la nature des
choses ou la nature algorithme indique de le faire. De toute manière,
on ne peut pas exprimer sous forme parallèle, une chose qui ne le
porte pas dans sa nature.

Yannick Duchêne Hibou57 a écrit :
> On 9 fév, 11:30, Wykaaa <wyk...*yahoo.fr> wrote:
>> Attention, je n'ai pas dit que la programmation concurrente n'était pas
>> utile mais il me semble que ce n'est pas dans le domaine des IHM qu'elle
>> est le plus utile car, compte tenu de la vitesse des processeurs
>> actuels, l'utilisateur, dans son interaction avec l'IHM est infiniment
>> plus lent que la machine.
> Ce n'est pas pour par crainte que l'utilisateur ne manie trop
> rapidement la souris plus vite que son ombre que le parallélisme est
> important dans les UI (je préfère UI, plutôt que IHM, par soucis de
> neutralité), et un utilisateur même ultra-rapide, n'arriverait pas Ã*
> prendre de vitesse une machine cadencée Ã* 500Khz (les reflexe humain
> on une finesse de l'ordre de la fraction de seconde, pas plus... 4 ou
> 5Hz au mieux). C'est pour d'autres raisons (voir plus loin).
>
>> Tout dépend de ce que recouvre le terme d'IHM. Pour le traitement et
>> l'affichage de photos, si les traitements sont coûteux, il faudra
>> évidemment utiliser la concurrence.
> La concurrence ne s'utilise pas pour accélérer les calculs. Un
> traitement dont l'étape n+1 dépend de l'étape n, ne sera gagnera rien
> Ã* être traité avec du parallélisme.
>
> C'est pour des raisons algorithmique ou de nature intrinsèque des
> choses que la parallélisme est utilisé.

LÃ* on est d'accord.

> Pour preuve, Ada 83
> connaissait déjÃ* les tâche, et pour Ã* l'époque de Ada 83 (et même
> avant, il a été conçue en 1980), les machine n'atteignaient pas les
> 10MHz. Pourtant le parallélisme était une exigence du langage déjÃ* Ã*
> cette époque : pour répondre Ã* la nature des environnement et des
> réalités, intrinsèquement concurrente, auxquelles les applications
> conçues dans le langage devaient pouvoir répondre.

On n'a pas attendu Ada pour faire de la concurrence et du parallélisme.
Le "time sharing" (temps partagé) dans les systèmes d'exploitation date
des années 60...

J'ai appris ADA 83 en... 82 avec Olivier Roubine et Jean Ichbia qui
n'étaient qu'Ã* quelques bureaux du mien quand j'étais chez Bull.
>
>> Aujourd'hui, on aura tendance Ã* découper les applications de telle sorte
>> que des parties puissent s'exécuter sur des coeurs différents plutôt que
>> dans des threads d'un même processus car dans ce cas, on ne bénéficie
>> pas de l'architecture multicoeur (en plus un "coeur" de processeur est
>> en général plus lent qu'un processeur monocoeur).
> Même pas : ce qui est mis le plus en avant, c'est le fait, non pas de
> lancer plusieurs thread en même temps (l'utilisateur lambda s'en moque
> totalement), mais de lancer plusieurs applications en même temps. Et
> vu le nombre d'applications active en même temps sur les plupart des
> environnement, inutile de dire que si une application espère allouer
> les deux cœurs du processeurs pour deux de ces threads, elle se trompe
> beaucoup.

C'est une des fonctions du système d'exploitation de répartir la charge
sur les différents processeurs pour des applications différentes (time
sharing, time slicing, etc.).
Le parallélisme, dans un langage, n'a d'utilité que pour la concurrence
intrinsèque Ã* l'application
>
>> Ton lien vers l'article est intéressant mais il est assez daté (96) et
>> depuis les choses ont bien évolué tant du point de vue matériel que de
>> l'ingénierie logicielle, même si, pour cette dernière, les choses vont
>> plus lentement.
> 1996, oui, mais ce n'est pas important. Et ça devrait même au
> contraire t'interpeller en te faisant penser que même déjÃ* Ã* cette
> époque, même si les conditions matérielles y étaient pourtant moins
> favorable, le parallélisme était déjÃ* un but (pour les raisons
> précédentes).

Comme je l'ai indiqué plus haut, le parallélisme était un but, pour les
systèmes d'exploitation, dès les années 60.
La discussion "moderne" sur le parallélisme ne concerne que la
concurrence au sein d'une même application.
Tout ce qui concerne la concurrence entre application ou entre
utilisateurs est réglée Ã* l'extérieur des applications. Par exemple le
système de multiplexage de processus Ã* partir d'Oracle v6 ou v7 (je ne
me rappelle plus exactement).
>
> Pour aller plus loin sur ces raisons, et la question qu'on ne crains
> pas que l'utilisateur clique trop vite sur les boutons d'une boite de
> dialogue : pense que l'application peut être tout simplement bloqué,
> ou être occupé Ã* un calcul intensif, qui peut laisser croire qu'elle
> est bloqué. Comment peut-elle prendre en charge l'interface
> utilisateur dans ces conditions ? Exemple avec Write sous Windows
> 3.1 : si tu ouvrais un gros fichier et que Write prenait beaucoup de
> temps Ã* le formater pour l'afficher, son interface était totalement
> bloqué pendant tout ce temps lÃ*. Pense aussi que l'utilisateur peut
> vouloir interrompre une action longue ou trop longue Ã* son gout. Si
> l'application est occupé Ã* une action trop longue, comment peut-elle
> justement réceptionner la requête de l'utilisateur ? La réponse Ã*
> toutes ces question, ce sont les tâches (les Task, en Ada). À moins
> que l'application n'exécute que des petites actions très brèves, et
> dans ce cas, elle peut rapidement revenir Ã* la gestion de l'UI. Mais
> même dans ce cas, si elle plante, alors son UI plante aussi, ne
> laissant aucune chance Ã* l'utilisateur de comprendre quoi que ce soit,
> ou de tenter de quitter proprement en sauvant les meubles (comme en
> tentant d'enregistrer un fichier modifié).

Ceci était vrai aussi dans Mac OS classique (avant OS X). C'était aux
applications de "rendre la main" de temps en temps sinon elle
conservaient le CPU jusqu'Ã* ce qu'il y ait une interruption dans leur
flot d'exécution mais ces systèmes sont antédiluviens. Aujourd'hui, tous
les systèmes d'exploitation savent gérer la concurrence entre
applications. Le problème se pose pour les applications de savoir tirer
le meilleur parti des architecture matérielles multicoeurs. Une
application comme Photoshop, par exemple, a encore beaucoup de boulot
avant d'être réellement optimisée pour de telles architectures.
Une application comme Logic Pro, sous Mac OS X est sur la bonne voie,
avec la version 9 qui sait répartir les différents instruments virtuels
sur les différents coeurs (j'utilise Logic Pro 9 sur un Mac Pro a 2
processeurs quadricoeurs Ã* 3,2 GHz chacun...).
>
> Quand le parallélisme est utilisé, c'est parce que la nature des
> choses ou la nature algorithme indique de le faire. De toute manière,
> on ne peut pas exprimer sous forme parallèle, une chose qui ne le
> porte pas dans sa nature.

Si c'est possible. Par exemple une inversion de matrice n'est pas, par
nature, concurrente mais cependant on peut très bien la faire par
morceau, en concurrence, pour de très grandes matrices. J'ai vu des
applications, en taxinomie, qui avaient besoin d'inverser des matrices
carrées 9000 x 9000.

Yannick Duchêne Hibou57 a écrit :
> On 9 fév, 13:02, Wykaaa <wyk...*yahoo.fr> wrote:
>> J'ai appris ADA 83 en... 82 avec Olivier Roubine et Jean Ichbia qui
>> n'étaient qu'Ã* quelques bureaux du mien quand j'étais chez Bull.
> Houlalal.... j'étais tout p'tit tout p'tit !
> Et tu as connu Ichbia alors.
> Quelle bonheur tu as du avoir

Oui et j'ai connu aussi Alain Colmerauer car j'ai porté l'interpréteur
Prolog sur certaines machines.
>
>> Si c'est possible. Par exemple une inversion de matrice n'est pas, par
>> nature, concurrente mais cependant on peut très bien la faire par
>> morceau, en concurrence, pour de très grandes matrices. J'ai vu des
>> applications, en taxinomie, qui avaient besoin d'inverser des matrices
>> carrées 9000 x 9000.
> Oui, c'est vrai, on peut rendre parallèle certains segments d'un
> traitement, même si l'ensemble Ã* l'air d'être séquentiel. En fait
> c'est vrai pour presque tout (un mixe de séquentiel et de parallélisme
> potentiel), et la question et de peser ce qui est assez rentable Ã*
> rendre parallèle.
>
> Tu parlais de Logic Pro : je prévois de créer une application basée
> sur les VST (je ne sais plus ce qu'est l'équivalent sous Mac), pour
> Windows (c'était une parenthèse, sorry pour le HS).

Sous Mac, l'équivalent des VST sont les AU (Audio Units).

> Bonne journée

Toi aussi. J'espère qu'elle est finie d'ailleurs pour toi (moi, je suis
Ã* la retraite...).

Yannick Duchêne Hibou57 a écrit :

[snip]

>> Ceci dit, il existe des compilateurs Ada qui savent générer du
>> bytecode interpréter par une JVM ;-) : Jgnat, ObjectAda (Aonix),
>> AppletMagic (Sofcheck).
> C'est justement le signe que Java est peut-être plus encore une
> plateforme qu'un langage. Peut-être un peu abusif de ma part, mais je
> le situe Ã* certains égards, dans la même catégorie que C# ou
> VisualBasic pour cette raison qu'il est surtout le langage d'une
> plateforme unique. Étant le langage d'une plateforme unique, le niveau
> d'exigence qu'il doit démontrer est moindre, car on ne sait pas s'il a
> été spécifiquement conçu pour une plateforme ou si la plateforme a été
> spécifiquement conçu pour lui (et puis finalement l'un ou l'autre, ont
> un peu les mêmes effets sur le langage). Nécessairement, ça ne m'aide
> pas Ã* lui faire confiance quand Ã* ses fondements et ses primitives.
>
> L'autre raisons est moins liées au sujet présent, c'est le gaspillage
> et la fuite en avant dans la consommation de ressources (Ludovic en
> parlait un peu Ã* sa manière) que représente ce type de plateforme et
> l'illusion de portabilité qu'il présente (il n'est portable que sur sa
> plateforme).

Je ne comprends pas ce que cela veut dire "il n'est portable que sur sa
> plateforme" car n'importe qui peut faire une JVM puisque les
spécifications sont publiques :
http://java.sun.com/docs/books/jvms/
>
> Je comprend bien la nécessité d'environnement virtuel, mais je les
> trouves mieux venu quand cela se présente comme une solution Ã* un
> "problème".

Java résoud le problème de la portabilité. Il a, de plus, quantité de
bibliothèques permettant de faire des "middlewares" (intergiciels en
français). Pour les applications réparties Ã* l'échelle du web en
architecture orientée service (SOA) c'est vraiment ce qu'il faut sans
compter son adéquation Ã* la manipulation du XML, le DOM, etc.

Au départ, il était présenté comme une solution au "code mobile" via les
applets mais aujourd'hui, il sert essentiellement dans 2 domaines : les
architectures n-tiers pour les grosses applications (côté serveur avec
J2EE) et dans le domaine de l'informatique embarquée (voir, par exemple
ici :
http://www.electronique.biz/editoria...de-l-embarque/).
Quand tu vois les sociétés qui l'ont élu, ce n'est pas n'importe qui.
Et un dossier de 2002 sur les machines Java embarquées :
www.01net.com/Pdf/ELM200206010126100.pdf

Je crois que tu te fais une fausse idée de Java. La majorité des
téléphones portables utilisent le Java embarqué (J2ME):
http://www.club-java.com/TastePhone/...IDP_mobile.jsp

Chez les militaires, le système de commandement des régiments est
programmé en C++ et Java ainsi que beaucoup d'autres systèmes.

[snip]

Wykaaa a écrit :

> Je crois que tu te fais une fausse idée de Java. La majorité des
> téléphones portables utilisent le Java embarqué (J2ME):
> http://www.club-java.com/TastePhone/...IDP_mobile.jsp
>

Et voilÃ* des exemples d'applications Java sur téléphone portable :
http://www.clubic.com/telecharger/te...e-mobile+java/

> [snip]
>

Le 09/02/2010 21:59, Wykaaa a écrit :
> Je crois que tu te fais une fausse idée de Java. La majorité des
> téléphones portables utilisent le Java embarqué (J2ME):
> http://www.club-java.com/TastePhone/...IDP_mobile.jsp

Pas certain. Mon expérience professionnelle (mais pas personnelle) avec
Java est une catastrophe pour l'embarqué. Et puis je ne sais pas pour
toi mais j'en ai un peu raz-le-bol de rebooter mon téléphone toutes les
semaines, ma télé tous les mois... Sans compter les voitures qui
déraillent... Alors Java pour faire un site marchand pas de problème
pour moi, mais lÃ* ou la fiabilité et la sécurité prime je dit NON en
l'état actuel des choses.

> Chez les militaires, le système de commandement des régiments est
> programmé en C++ et Java ainsi que beaucoup d'autres systèmes.

Espérons qu'ils n'aient jamais Ã* l'utiliser en tant de guerre ce
système, imagine un bug au mauvais moment... Je n'aimerais pas être
victime de ce système!

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B