Bah un programme écrit en B peut être prouvé.
Il va fallor donner des exemples de langages de programmation turing complet ET non prouvable. Le B possède des outils et uen sémantique qui facilitent la preuve mathématique, mais à partir du moment ou on a un code turing complet et un compilateur/interpreteur déterministe on peut prouver un code. Le contraire serait inquiétant.
C'est plus une sécurité vis-à-vis d'un plantage "non prévu".
La preuve permet de certifier un comportement, mais ne met pas à l'abri des plantages loin de là. Elle garantie juste que si il n'y a pas d'éléments extérieurs au programme qui viennent le perturber le programme finira et donnera un résultat cohérent (celui ci pouvant bien sur être une remontée d'exception). Or des éléments perturbateur il y en a un paquet : problèmes de droits, réponse incohérente d'un composant (typiquement lors de transactions réseau ou IPC), changement de contexte suite à une interruption dans une opération non atomique, dead-lock sur des ressources extérieures au programme et j'en passe. Quand il s'agit de prouver un système (ie le programme, les programmes qui tournent à coté, l'os sous jacent et le matériel) c'est une autre paire de manche... Et là le B n'aide pas particulièrement.
Pour Java, il y a une couche d'abstraction entre le code généré et le code réellement exécuté, autorisant un certain nombre de vérifications supplémentaire par rapport à un programme natif compilé à partir d'un langage autorisant à peu prêt tout et n'importe quoi comme accès bas niveau
De deux choses l'une, soit tu devellopes pour windows Me/98/95 soit je suis au regret de t'apprendre qu'un programme écrit en Java a exactement les mêmes droits qu'un programme écrit en C. Le langage Java n'apporte rien au niveau limitation d'accès bas niveau par rapport au langage C. On peut par exemple aller écrire (essayer en tout cas) dans un ségement de mémoire qui ne nous appartient pas. Si l'OS est bien foutu il sortira le fusil à pompe et on aura un mort sur la consicence. Le framework java permet de limiter la casse sur les plus grosses erreurs, mais il existe aussi d'excellents frameworks en C avec garbage collector et controle des I/O qui font un super boulot quand il s'agit de hurler à la compilation plutôt qu'à l'execution.
mais ce dernier ne va pas apporter grand chose comme a pu apporter la locomotive par rapport à la charette.
Pour bien comprendre ce qu'apporte un langage comme Lissac par rapport à un langage comme C il faut penser aux non programmeurs. Pour être honnête je en connais pas Lissac, mais l'avantage majeur des langages de haut niveau est de permettre à des non initiés de modifier facilement une partie du programme suivant leur besoin. De même qu'un cube de données bien que plus lourd qu'une base est plus facile à manipuler, il m'a été donné uen fois dans ma vie de coder un logiciel en prog dont les prédicats étaient librement accessibles aux utilisateurs qui disposaient également d'un shell réduit pour appeler les fonctions quia vaient étés codées. Moyennant une formation légère d'une semaine, les utilisateurs pouvaient aussi bien évaluer les faits réels que lancer des simulations en pagaille. La même chose en C ou en Java aurait nécessité le dévellopement complet d'une interface doublée d'un parseur interpreteur ou l'action systématique d'un developpeur à chaque fois qu'un utilisateur aurait voulu changer une règle de calcul ou une relation entre objets.
[^] # Re: C'est trop compliqué !
Posté par Jerome Herman . En réponse au journal Des langages de haut niveau. Évalué à 1.
Il va fallor donner des exemples de langages de programmation turing complet ET non prouvable. Le B possède des outils et uen sémantique qui facilitent la preuve mathématique, mais à partir du moment ou on a un code turing complet et un compilateur/interpreteur déterministe on peut prouver un code. Le contraire serait inquiétant.
C'est plus une sécurité vis-à-vis d'un plantage "non prévu".
La preuve permet de certifier un comportement, mais ne met pas à l'abri des plantages loin de là. Elle garantie juste que si il n'y a pas d'éléments extérieurs au programme qui viennent le perturber le programme finira et donnera un résultat cohérent (celui ci pouvant bien sur être une remontée d'exception). Or des éléments perturbateur il y en a un paquet : problèmes de droits, réponse incohérente d'un composant (typiquement lors de transactions réseau ou IPC), changement de contexte suite à une interruption dans une opération non atomique, dead-lock sur des ressources extérieures au programme et j'en passe. Quand il s'agit de prouver un système (ie le programme, les programmes qui tournent à coté, l'os sous jacent et le matériel) c'est une autre paire de manche... Et là le B n'aide pas particulièrement.
Pour Java, il y a une couche d'abstraction entre le code généré et le code réellement exécuté, autorisant un certain nombre de vérifications supplémentaire par rapport à un programme natif compilé à partir d'un langage autorisant à peu prêt tout et n'importe quoi comme accès bas niveau
De deux choses l'une, soit tu devellopes pour windows Me/98/95 soit je suis au regret de t'apprendre qu'un programme écrit en Java a exactement les mêmes droits qu'un programme écrit en C. Le langage Java n'apporte rien au niveau limitation d'accès bas niveau par rapport au langage C. On peut par exemple aller écrire (essayer en tout cas) dans un ségement de mémoire qui ne nous appartient pas. Si l'OS est bien foutu il sortira le fusil à pompe et on aura un mort sur la consicence. Le framework java permet de limiter la casse sur les plus grosses erreurs, mais il existe aussi d'excellents frameworks en C avec garbage collector et controle des I/O qui font un super boulot quand il s'agit de hurler à la compilation plutôt qu'à l'execution.
mais ce dernier ne va pas apporter grand chose comme a pu apporter la locomotive par rapport à la charette.
Pour bien comprendre ce qu'apporte un langage comme Lissac par rapport à un langage comme C il faut penser aux non programmeurs. Pour être honnête je en connais pas Lissac, mais l'avantage majeur des langages de haut niveau est de permettre à des non initiés de modifier facilement une partie du programme suivant leur besoin. De même qu'un cube de données bien que plus lourd qu'une base est plus facile à manipuler, il m'a été donné uen fois dans ma vie de coder un logiciel en prog dont les prédicats étaient librement accessibles aux utilisateurs qui disposaient également d'un shell réduit pour appeler les fonctions quia vaient étés codées. Moyennant une formation légère d'une semaine, les utilisateurs pouvaient aussi bien évaluer les faits réels que lancer des simulations en pagaille. La même chose en C ou en Java aurait nécessité le dévellopement complet d'une interface doublée d'un parseur interpreteur ou l'action systématique d'un developpeur à chaque fois qu'un utilisateur aurait voulu changer une règle de calcul ou une relation entre objets.