Encore faudrait-il être confiant dans le fait que le prouveur Coq est plus stable que la JVM...
Si stable = exempt de bugs ici, alors pour faire confiance à une preuve écrite par Coq tu dois faire confiance au coeur de Coq, relativement petit justement pour éviter les risques (+ le hardware, le compilo et autres cités plus haut mais ça s'applique aussi à la JVM).
que la probabilité d'erreur dans les preuves humaines qui se cache derrière soit plus faible que la probabilité d'erreur dans le code de la JVM.
Si la preuve passe Coq, elle est garantie sans erreur et le code généré aussi, c'est bien l'intérêt.
(bien sur en partant des principes donnés plus haut concernant le coeur de coq, le compilo, la génération de code, la théorie et autres) http://coq.inria.fr/doc/faq.html#htoc7
On tombe dans un problème d'oeuf et de poule c'est comique.
Le problème c'est qu'on ne puisse pas réécrire Coq en Coq, mais bon ! Sacré Kurt ;-)
Etant donné le nombre de personnes qui utilise Coq et le nombre de personnes qui utilisent la JVM, je suis plus que réservé...
Je ne connais pas B, mais je sais qu'en Coq, tu écris ta spécification dans un langage particulier, puis la prouves interactivement, avec certaines étapes plus ou moins automatisées à l'aide de "tactiques", plusieurs bibliothèques de ces dernières étant disponibles.
Une fois la preuve établie (c'est évidemment la partie difficile), Coq est capable d'en extraire un code source en OCaml ou Haskell (via l'isomorphisme de Curry-Howard) qui sera correct par construction (si tant est que le petit coeur "trusted" de Coq, les axiomes, le compilo OCaml, le hardware, l'OS soient eux-mêmes dignes de confiance bien sur).
Coq ne part pas d'un programme pré-existant pour essayer de prouver sa correction vis à vis des spécifications.
NON ! Je ne peux pas te laisser dire ça. Le C est beau, le C est grand. Qui n'a jamais été émoustillé par la majesté d'une suite de #ifdef imbriqués ou par une erreur de segmentation... Ces moments émouvants qui rappellent au programmeur qu'il doit rester humble face à la machine.
Devoir réécrire une implémentation des structures de base à chaque programme, écrire avec amour son Makefile récursif ou ses graciles macros M4, voilà des bonheurs simples qui forment la vie passionante d'un dev C. Au diable la glib !
La supériorité des outils C est incontestable, comme en témoigne le foisonnement d'IDE libres de grande qualité pour ce langage. D'ailleurs, y a-t-il un équivalent de Valgrind pour détecter les erreurs de pointeurs en Java et C# ? Je vous laisse deviner : même pas. Ah c'est sur pour implémenter une AbstractProtocolSingletonFactory y a du monde, mais pour le reste...
Que les Monomaniaques de l'UML avec Objecteering tremblent, les codeurs C n'ont à perdre que leurs chaînes de compilation ! Les Javaistes & co seront rééduqués, tout comme les Lispeux et les Smalltalkiens en leurs temps !
À la rigueur, les gens voulant faire de l'objet peuvent se tourner vers un langage simple et conceptuellement élégant, le C++.
Je vois que les moinsseurs sophistes s'en donnent à coeur joie sur mon ami Ned< !
Je vais donc démontrer l'inanité de cette chose barbare qui est aux encodages ce qu'une statue du Pape est à l'Art.
wmCoinCoin est parfait. Il a donc toutes les qualités. Or il ne gère pas l'UTF-8. Donc l'UTF-8 n'est pas une qualité. Gérer toutes les features possibles et imaginables du moment qu'elles ne sont pas des défauts (y compris les features "neutres" dont on pourrait se passer) est une qualité. L'UTF-8 n'étant ni bonne, ni neutre, c'est une mauvaise feature !
Dans ce contexte, il est donc évident que l'UTF-8 est l'oeuvre d'une association communisto-libérale de fabricants de RAM¹ pour s'assurer des profits substantiels dans les années à venir. Des travaux récents ont même remis en question l'existence de la Chine qui sert d'alibi à la cabale (qui selon certains autres travaux n'existerait pas).
C'est la faute de ces gens si de nos jours on s'éloigne du C, qui est le langage le plus beau, puissant et élégant de tous ceux qui existent ! Est-ce que vous avez besoin d'un GC ? D'exceptions ? D'un vrai systèmes de type ? D'une bibliothèque standard utilisable pour autre chose qu'un hello world ?
Mea culpa, j'ai confondu la conception virginale (le cas qui nous intéresse) et l'immaculée conception (celle de Marie donc, bien postérieure à la Bible). C'est décidément très compliqué les histoires de cul en religion.
Euh, c'est pas comparable. Théoriquement (je ne suis pas juriste), tout le code qui lie avec du code GPL doit lui même être GPL.
Pour répondre au commentaire un cran plus haut, il me semble que la GPL de Linux a une clause spéciale pour autoriser l'exécution de programmes propriétaires.
[^] # Re: [X] : C'est exactement ce que j'espérais
Posté par lambada . En réponse au journal Sondage Java sous GPL, donnez votre avis à Sun. Évalué à 2.
Si stable = exempt de bugs ici, alors pour faire confiance à une preuve écrite par Coq tu dois faire confiance au coeur de Coq, relativement petit justement pour éviter les risques (+ le hardware, le compilo et autres cités plus haut mais ça s'applique aussi à la JVM).
Si la preuve passe Coq, elle est garantie sans erreur et le code généré aussi, c'est bien l'intérêt.
(bien sur en partant des principes donnés plus haut concernant le coeur de coq, le compilo, la génération de code, la théorie et autres)
http://coq.inria.fr/doc/faq.html#htoc7
Le problème c'est qu'on ne puisse pas réécrire Coq en Coq, mais bon ! Sacré Kurt ;-)
Etant donné le nombre de personnes qui utilise Coq et le nombre de personnes qui utilisent la JVM, je suis plus que réservé...
De toute façon j'apportais juste des précisions sur le fonctionnement de Coq, pas de son applicabilité à l'écriture d'une VM. Xavier Leroy et son équipe semblent s'intéresser à l'écriture d'un compilo prouvé formellement :
http://pauillac.inria.fr/~xleroy/compcert-backend/
http://pauillac.inria.fr/~xleroy/publi/cfront.pdf
http://groups.google.com/group/fa.caml/browse_thread/thread/(...)
[^] # Re: M'houai...
Posté par lambada . En réponse à la dépêche Statistiques sur le site. Évalué à 5.
[^] # Re: [X] : C'est exactement ce que j'espérais
Posté par lambada . En réponse au journal Sondage Java sous GPL, donnez votre avis à Sun. Évalué à 3.
Une fois la preuve établie (c'est évidemment la partie difficile), Coq est capable d'en extraire un code source en OCaml ou Haskell (via l'isomorphisme de Curry-Howard) qui sera correct par construction (si tant est que le petit coeur "trusted" de Coq, les axiomes, le compilo OCaml, le hardware, l'OS soient eux-mêmes dignes de confiance bien sur).
Coq ne part pas d'un programme pré-existant pour essayer de prouver sa correction vis à vis des spécifications.
[^] # Re: Réponses manquantes
Posté par lambada . En réponse au journal Sondage Java sous GPL, donnez votre avis à Sun. Évalué à 7.
[^] # Re: Les moules aussi
Posté par lambada . En réponse au journal [PUB] les filles, saimal ! dites le en Web 2.0. Évalué à 5.
[^] # Re: TCPA
Posté par lambada . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 3.
[^] # Re: ras le bol de l'utf8
Posté par lambada . En réponse au journal Coup de gueule parce que ça défoule. Évalué à 10.
Devoir réécrire une implémentation des structures de base à chaque programme, écrire avec amour son Makefile récursif ou ses graciles macros M4, voilà des bonheurs simples qui forment la vie passionante d'un dev C. Au diable la glib !
La supériorité des outils C est incontestable, comme en témoigne le foisonnement d'IDE libres de grande qualité pour ce langage. D'ailleurs, y a-t-il un équivalent de Valgrind pour détecter les erreurs de pointeurs en Java et C# ? Je vous laisse deviner : même pas. Ah c'est sur pour implémenter une AbstractProtocolSingletonFactory y a du monde, mais pour le reste...
Que les Monomaniaques de l'UML avec Objecteering tremblent, les codeurs C n'ont à perdre que leurs chaînes de compilation ! Les Javaistes & co seront rééduqués, tout comme les Lispeux et les Smalltalkiens en leurs temps !
À la rigueur, les gens voulant faire de l'objet peuvent se tourner vers un langage simple et conceptuellement élégant, le C++.
Carl "Mad" Marx
[^] # Re: ras le bol de l'utf8
Posté par lambada . En réponse au journal Coup de gueule parce que ça défoule. Évalué à 9.
Je vais donc démontrer l'inanité de cette chose barbare qui est aux encodages ce qu'une statue du Pape est à l'Art.
wmCoinCoin est parfait. Il a donc toutes les qualités. Or il ne gère pas l'UTF-8. Donc l'UTF-8 n'est pas une qualité. Gérer toutes les features possibles et imaginables du moment qu'elles ne sont pas des défauts (y compris les features "neutres" dont on pourrait se passer) est une qualité. L'UTF-8 n'étant ni bonne, ni neutre, c'est une mauvaise feature !
Dans ce contexte, il est donc évident que l'UTF-8 est l'oeuvre d'une association communisto-libérale de fabricants de RAM¹ pour s'assurer des profits substantiels dans les années à venir. Des travaux récents ont même remis en question l'existence de la Chine qui sert d'alibi à la cabale (qui selon certains autres travaux n'existerait pas).
C'est la faute de ces gens si de nos jours on s'éloigne du C, qui est le langage le plus beau, puissant et élégant de tous ceux qui existent ! Est-ce que vous avez besoin d'un GC ? D'exceptions ? D'un vrai systèmes de type ? D'une bibliothèque standard utilisable pour autre chose qu'un hello world ?
Messieurs les moinsseurs, je ne vous salue pas !
¹ : http://sam.zoy.org/writings/utf8/
# .
Posté par lambada . En réponse au journal Ouverture du forum "Papa Geek". Évalué à 10.
[^] # Re: MUC Jabber
Posté par lambada . En réponse au journal Coup de gueule parce que ça défoule. Évalué à -2.
[^] # Re: Mono
Posté par lambada . En réponse au journal Pas de trêve. Évalué à 2.
# Moi je sais
Posté par lambada . En réponse au journal Qui a dit ?. Évalué à 4.
[^] # Re: pas mail ...
Posté par lambada . En réponse au journal Le troll licence du vendredi. Évalué à 2.
Mais ça existe déjà, c'est #linuxfr sur FreeNode !
(Ce post est dédicacé à Gniarf)
[^] # Re: licence
Posté par lambada . En réponse au journal FreeBSD à la traîne ?. Évalué à 3.
>original issu de Solaris !
Ouais, à la lecture du blog zfs-on-fuse il est clair qu'il suffira de changer quelques #IFDEF pour passer du VFS de Solaris à celui de Linux ;-)
[^] # Re: Et moi et moi ...
Posté par lambada . En réponse au journal Donne télécommande filaire pour iRiver Hxxx. Évalué à 2.
Assassin ! (Sorbonne, zéro ! /o\)
[^] # Re: Je me marre ...
Posté par lambada . En réponse au journal PowerShell: tapez rm -rf c:\Windows ! ;). Évalué à 4.
[^] # Re: Je me marre ...
Posté par lambada . En réponse au journal PowerShell: tapez rm -rf c:\Windows ! ;). Évalué à 3.
¹ : http://research.sun.com/self/language.html
² : http://iolanguage.com/
[^] # Re: Floues
Posté par lambada . En réponse au journal OpenGraphic. Évalué à 10.
===>[]
[^] # Re: Oui mais....
Posté par lambada . En réponse au journal [HS] Jehovah le dire à ma mère.. Évalué à 3.
[^] # Re: Oui mais....
Posté par lambada . En réponse au journal [HS] Jehovah le dire à ma mère.. Évalué à 1.
Ça c'est pas dans la Bible à ma connaissance.
# Hum
Posté par lambada . En réponse au journal Linus TM. Évalué à 1.
# .
Posté par lambada . En réponse à la dépêche D-Bus 1.0, future fondation de nos bureaux. Évalué à -1.
s/méthode/objet/ ?
[^] # Re: Oui mais...
Posté par lambada . En réponse au journal Zune=bien, iPod, Archeos, ...=mal. Évalué à 8.
Un fabricant de graveurs.
===>[]
[^] # Re: Ok...
Posté par lambada . En réponse à la dépêche Java libre : un rêve devient réalité. Évalué à 6.
>c++ compile...
http://llvm.org ?
(compilé certes mais pas en natif, plus toute les possibilités d'optimisations à l'exécution)
[^] # Re: .
Posté par lambada . En réponse au journal Le Java de SUN sera-t-il GPL ?. Évalué à 1.
Pour répondre au commentaire un cran plus haut, il me semble que la GPL de Linux a une clause spéciale pour autoriser l'exécution de programmes propriétaires.