Il n'y a aucun intérêt à personnalisé cela. Je ne comprends pas pourquoi tu te focalise la dessus. Le seul intérêt est d'avoir un compilo qui ne comprends que l'évaluation retardé de blocs, ainsi tout le reste est dans la lib. Le compilo est donc hyper simplifié et peut donc faire des choses puissante comme la preuve.
"mais tu as de grosses lacunes en informatique théorique.
et toi en informatique pratique."
Ontologia bosse pour un éditeur il me semble...
Cela dit je reste perplexe : la quantité de ligne de code n'est pas un critère révolutionnaire à mon sens
Manque de bol pour toi, il a été prouvé que le nombre de ligne de code est directement proportionnel au temps passé à écrire/valider le truc.
Que cela soit en C, en Perl, en assembleur, c'est le nombre de ligne qui détermine le temps passé et quelques soit le langage.
Donc, c'est évidement un argument primordial en développement logiciel.
Je critiquais le côté "trop ouvert" des constructions syntaxique de Lisaac
Mais qu'est-ce que l'on s'en fout ! Dans n'importe qu'elle langage tu peux écrire des horreurs, pourquoi cela serait différent en Lisaac ?
"Concernant la vitesse, je doute que vous obteniez des gains exceptionnel style de facteur 4 ou 5. Peut être dans certains contexte bien précis vous obtiendrez 50% de perf en plus (peut être plus j'en sais rien), mais a-t-on vraiment besoin de ça ?"
toi peut-être pas...
"Parcqu'un OS c'est pas un simple encodeur."
Et là paf, tu passes pour une andouille. sisi. Isaac est un projet d'OS, à la base. Et il tourne déjà très bien...
"Peut être dans certains contexte bien précis vous obtiendrez 50% de perf en plus (peut être plus j'en sais rien), mais a-t-on vraiment besoin de ça ?"...
"Et à part leur promettre 20% de gains de perf potentiel, quel intérêt auront-ils à utiliser un nouveau langage ?" ..."Si vous partez dans des délires d'optimisations qui font gagner encore 3 ou 5% de perf par ci par là"
On a compris que tu ne comprends rien à l'optimisation, c'est pas la peine de l'étaler autant. Dans certain cas, tu peux avoir des facteurs 10 entre un mauvais et un bon code. Le but de lisaac sera d'avoir le bon code. Donc, certe, entre un code C tuné à mort et lisaac, tu aura 1% de mieux en lisaac (et 30% de ligne de code en moins). Mais entre du C normal et du Lisaac, tu pourras avoir des facteurs 2 ou plus.
"Sans parler du fait que même dans le monde de l'embarqué des critères comme la portabilité et la sécurité peuvent être mis en avant..."
Pourquoi tu parles de trucs qui tu ne connais pas ? La portabilité pour un code qui ne bougera pas... Certe java commence à arriver, mais c'est tellement rien en comparaison de tous les trucs en C !
J'imagine que pour la sécurité, tu parles de la sureté de fonctionnement et non d'attaque logiciel... Cela n'aurait rien à voir et surtout on s'en fout beaucoup dans l'embarqué, c'est rare d'avoir un train ou une voiture branché sur internet...
"Quel va être l'intérêt du gain de perf sachant que le gros boulot d'optimisation sera surtout à faire au niveau de la VM ?"
C'est évident que les optimisations de haut niveau n'ont aucun intérêt. C'est bien connu... sic... (surtout pour un langage qui à la base crache du C, re-sic)
Il n'y pas encore de mode strict, mais cela n'est pas le plus compliqué à utilisé même si cela a peu de sens. Lisaac n'est pas prévus pour tourner dans une jvm, sont but est d'être un langage rapide (+ que le C) et productif (que ruby/perl/python).
Si tu parles sécurité, c'est d'un point de vue attaquant. Je préfaire parler de respect de la spec. C'est déjà énorme par rapport à ce qui existe actuellement.
Tous les discussions qu'il y a ici, c'est pour prendre la température et avoir des avis de personne diverse et varié. Et si on ne parle pas plus des features à venir, c'est parce qu'elle n'existe pas encore.
Ontologia balance ses réflexions pour avoir du retour. Le but n'est pas de faire de la pub pour Lisaac. Ce qui est horripilant de ta part, c'est de condamner le langage sans le moindre doute, en y connaissant si peu.
Si tu veux, l'auteur de Lisaac est à situer entre ceux de Java, des pures codeurs, et ceux de OCaml des pures universitaires. Benoit est dans la catégorie pur codeur universitaires... Il utilises ses outils tous les jours et connait les concepts avancé "universitaires". Cela fait la différence.
Je sais pas si ca a changé depuis la dernière fois que je me suis intéressé aux specs du langage, mais dans mes souvenirs on pouvait allègrement mixé du Lisaac avec du code écrit en C. Partant de là, niveau preuve et sécu...
C'est évident que rien ne sera prouvé sur le C ! et on ne parle pas de sécurité mais de prouver les contrats, cela n'a à peu pret rien voir.
" Tu crois que les lib fleuves sont l'aboutissement de tout langage ?"
C'est quoi le rapport ?
Le même rapport qu'il y a avec "comme il est sans doute possible de le faire en Lisaac, mais ce dernier ne va pas apporter grand chose comme a pu apporter la locomotive par rapport à la charrette."
En fait, les principales protections contre les flash sont logiciels en "étalant l'exécution" pour détecter une erreur de cohérence. Pas mal. Mais, générer une erreur est déjà une information en soit.
La grille est inefficace pour les attaques laser, puisque l'on a accès au dessous de la puce, qui n'est pas protégé.
Je suis heureux de lire en enfin quelqu'un qui écrit : "Etant donné un équipement illimité et un temps illimité, c'est toujours le craqueur qui va gagner. " C'est pour relativiser ceux qui pense que la carte à puce est inviolable...
Il existe des cartes qui résistent à ses attaques ? J'aimerais bien savoir comment.
Pour info, le laser s'amuse à faire changer de localement la valeur d'un bit. Cela permet de modifier l'état interne de la puce et de faire plein de chose.
Les contre mesure que j'imagine, c'est des photodiodes qui détectent le laser et qui bloquent définitivement la carte. Mais qu'est-ce qui empêche de prendre une autre carte et de taper à coter de la photodiode ?
"Une preuve fausse n'a pas beaucoup d'intérêt."
Si, on sait qu'on peut foutre le programme à la poubelle, ou au moins le corriger pour le rendre valide.
Je dirais même plus, c'est le plus utile !
Il est souvent beaucoup plus facile de trouver un contre exemple à un moteur de preuve que de d'assurer que l'ensemble des possibles est couvert.
De plus, d'un point de vue psychologie d'un programmeur, on comprend mieux une erreur avec le contre exemple qui force la correction. Si le programme rend "prouvé", il y a beaucoup de monde qui n'y croira pas.
Cela signifie qu'il vaut mieux chercher "large" que tenter de prouver complètement des bouts minuscules.
Les 2 téchniques que je connais c'est la résolution d'équation logiques SAT et les BDD (parcoure de tous les états possible).
C'est le moyen de faire une preuve "définitive" mais qui finit toujours par exploser en temps. Dans ce cas, des méthodes basé sur un montecarlo peut tout à fait fonctionner pour trouver un contre exemple.
J'avais lu que les meilleurs écrans stéréscopique avait besoin de générer 9 images et non 2. La limite dans ce cas était la résolution disponible de l'image final.
"il n'apportera pas la sécurité qu'apporte un programme écrit en B ou même en Java,"
Il faudra argumenter un peu plus tout de même...
Ou alors, c'est juste une tentative de troll de plus ?
il ne permettra pas d'écrire des programmes plus complexes que dans un autre langage (la limite étant surtout liée aux compétences humaines et non techniques),
C'est sûr qu'il n'y a aucune différence de productivité entre l'assembleur et le C, le C et Java, Java et Perl.
J'avais fait le calcul il y a quelques temps, les DVD coutaient bien plus chères. Mais depuis la taille des HD a monté et leur prix moyen est passé de 1000F à 100€.
Si tu n'as plus de place dans la tour, un bon disque externe en e-sata devrait bien faire l'affaire (globalement, je n'aime pas trop l'usb). Voir même un petit NAS 3"5. Un disque de 500Go vaut 100€.
L'avantage du disque dur est que tu vois quand il meure au contraire d'un DVD. Si tu veux graver les films, un CD est plus fiable qu'un DVD, le control d'erreur est plus "puissant".
[^] # Re: Dune le livre
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nostalgie avec Dune. Évalué à 2.
C'est le designer d'Alien non ?
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Il n'y a aucun intérêt à personnalisé cela. Je ne comprends pas pourquoi tu te focalise la dessus. Le seul intérêt est d'avoir un compilo qui ne comprends que l'évaluation retardé de blocs, ainsi tout le reste est dans la lib. Le compilo est donc hyper simplifié et peut donc faire des choses puissante comme la preuve.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
"mais tu as de grosses lacunes en informatique théorique.
et toi en informatique pratique."
Ontologia bosse pour un éditeur il me semble...
Cela dit je reste perplexe : la quantité de ligne de code n'est pas un critère révolutionnaire à mon sens
Manque de bol pour toi, il a été prouvé que le nombre de ligne de code est directement proportionnel au temps passé à écrire/valider le truc.
Que cela soit en C, en Perl, en assembleur, c'est le nombre de ligne qui détermine le temps passé et quelques soit le langage.
Donc, c'est évidement un argument primordial en développement logiciel.
Je critiquais le côté "trop ouvert" des constructions syntaxique de Lisaac
Mais qu'est-ce que l'on s'en fout ! Dans n'importe qu'elle langage tu peux écrire des horreurs, pourquoi cela serait différent en Lisaac ?
"Concernant la vitesse, je doute que vous obteniez des gains exceptionnel style de facteur 4 ou 5. Peut être dans certains contexte bien précis vous obtiendrez 50% de perf en plus (peut être plus j'en sais rien), mais a-t-on vraiment besoin de ça ?"
toi peut-être pas...
"Parcqu'un OS c'est pas un simple encodeur."
Et là paf, tu passes pour une andouille. sisi. Isaac est un projet d'OS, à la base. Et il tourne déjà très bien...
"Peut être dans certains contexte bien précis vous obtiendrez 50% de perf en plus (peut être plus j'en sais rien), mais a-t-on vraiment besoin de ça ?"...
"Et à part leur promettre 20% de gains de perf potentiel, quel intérêt auront-ils à utiliser un nouveau langage ?" ..."Si vous partez dans des délires d'optimisations qui font gagner encore 3 ou 5% de perf par ci par là"
On a compris que tu ne comprends rien à l'optimisation, c'est pas la peine de l'étaler autant. Dans certain cas, tu peux avoir des facteurs 10 entre un mauvais et un bon code. Le but de lisaac sera d'avoir le bon code. Donc, certe, entre un code C tuné à mort et lisaac, tu aura 1% de mieux en lisaac (et 30% de ligne de code en moins). Mais entre du C normal et du Lisaac, tu pourras avoir des facteurs 2 ou plus.
"Sans parler du fait que même dans le monde de l'embarqué des critères comme la portabilité et la sécurité peuvent être mis en avant..."
Pourquoi tu parles de trucs qui tu ne connais pas ? La portabilité pour un code qui ne bougera pas... Certe java commence à arriver, mais c'est tellement rien en comparaison de tous les trucs en C !
J'imagine que pour la sécurité, tu parles de la sureté de fonctionnement et non d'attaque logiciel... Cela n'aurait rien à voir et surtout on s'en fout beaucoup dans l'embarqué, c'est rare d'avoir un train ou une voiture branché sur internet...
"La première sécurité est la liberté"
[^] # Re: DES?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
C'est évident que les optimisations de haut niveau n'ont aucun intérêt. C'est bien connu... sic... (surtout pour un langage qui à la base crache du C, re-sic)
"La première sécurité est la liberté"
[^] # Re: Du RPM warez !!!
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nostalgie avec Dune. Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: Ha, ça tombe bien…
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nostalgie avec Dune. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Si tu parles sécurité, c'est d'un point de vue attaquant. Je préfaire parler de respect de la spec. C'est déjà énorme par rapport à ce qui existe actuellement.
Tous les discussions qu'il y a ici, c'est pour prendre la température et avoir des avis de personne diverse et varié. Et si on ne parle pas plus des features à venir, c'est parce qu'elle n'existe pas encore.
Ontologia balance ses réflexions pour avoir du retour. Le but n'est pas de faire de la pub pour Lisaac. Ce qui est horripilant de ta part, c'est de condamner le langage sans le moindre doute, en y connaissant si peu.
Si tu veux, l'auteur de Lisaac est à situer entre ceux de Java, des pures codeurs, et ceux de OCaml des pures universitaires. Benoit est dans la catégorie pur codeur universitaires... Il utilises ses outils tous les jours et connait les concepts avancé "universitaires". Cela fait la différence.
"La première sécurité est la liberté"
[^] # Re: DES?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
Il avait le code source ? Ils ont bossé en boite blanche ? Combien de samples ?
(à part ça, 4 semaines, c'est hyper court...) 6 mois, c'est autre chose.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Cela me fait marrer de lire ça ! Surtout sans rien connaitre de Lisaac ou presque et de sa todo list.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
C'est évident que rien ne sera prouvé sur le C ! et on ne parle pas de sécurité mais de prouver les contrats, cela n'a à peu pret rien voir.
" Tu crois que les lib fleuves sont l'aboutissement de tout langage ?"
C'est quoi le rapport ?
Le même rapport qu'il y a avec "comme il est sans doute possible de le faire en Lisaac, mais ce dernier ne va pas apporter grand chose comme a pu apporter la locomotive par rapport à la charrette."
"La première sécurité est la liberté"
[^] # Re: DES?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
La grille est inefficace pour les attaques laser, puisque l'on a accès au dessous de la puce, qui n'est pas protégé.
Je suis heureux de lire en enfin quelqu'un qui écrit : "Etant donné un équipement illimité et un temps illimité, c'est toujours le craqueur qui va gagner. " C'est pour relativiser ceux qui pense que la carte à puce est inviolable...
"La première sécurité est la liberté"
[^] # Re: bon
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Soekris sous linux. Évalué à 2.
http://f-cpu.seul.org/~nico/astromech/astrolinux/astrolinux.(...)
"La première sécurité est la liberté"
[^] # Re: DES?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
Il existe des cartes qui résistent à ses attaques ? J'aimerais bien savoir comment.
Pour info, le laser s'amuse à faire changer de localement la valeur d'un bit. Cela permet de modifier l'état interne de la puce et de faire plein de chose.
Les contre mesure que j'imagine, c'est des photodiodes qui détectent le laser et qui bloquent définitivement la carte. Mais qu'est-ce qui empêche de prendre une autre carte et de taper à coter de la photodiode ?
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Si, on sait qu'on peut foutre le programme à la poubelle, ou au moins le corriger pour le rendre valide.
Je dirais même plus, c'est le plus utile !
Il est souvent beaucoup plus facile de trouver un contre exemple à un moteur de preuve que de d'assurer que l'ensemble des possibles est couvert.
De plus, d'un point de vue psychologie d'un programmeur, on comprend mieux une erreur avec le contre exemple qui force la correction. Si le programme rend "prouvé", il y a beaucoup de monde qui n'y croira pas.
Cela signifie qu'il vaut mieux chercher "large" que tenter de prouver complètement des bouts minuscules.
Les 2 téchniques que je connais c'est la résolution d'équation logiques SAT et les BDD (parcoure de tous les états possible).
C'est le moyen de faire une preuve "définitive" mais qui finit toujours par exploser en temps. Dans ce cas, des méthodes basé sur un montecarlo peut tout à fait fonctionner pour trouver un contre exemple.
"La première sécurité est la liberté"
[^] # Re: RELIEF
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une véritable interface en 3 dimensions. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Pour l'instant, est implémentée la preuve pour les appel sur un objet null. Le compilo prouve que 95% des appels seront bon. C'est un bon début !
"mais ce dernier ne va pas apporter grand chose comme a pu apporter la locomotive par rapport à la charette."
Et qu'est-ce qui permet de dire cela ? Tu crois que les lib fleuves sont l'aboutissement de tout langage ?
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Il faudra argumenter un peu plus tout de même...
Ou alors, c'est juste une tentative de troll de plus ?
il ne permettra pas d'écrire des programmes plus complexes que dans un autre langage (la limite étant surtout liée aux compétences humaines et non techniques),
C'est sûr qu'il n'y a aucune différence de productivité entre l'assembleur et le C, le C et Java, Java et Perl.
Petit trolleur !
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: mon avis...
Posté par Nicolas Boulay (site web personnel) . En réponse au message Question idiote / archivage videos. Évalué à 2.
Si tu n'as plus de place dans la tour, un bon disque externe en e-sata devrait bien faire l'affaire (globalement, je n'aime pas trop l'usb). Voir même un petit NAS 3"5. Un disque de 500Go vaut 100€.
L'avantage du disque dur est que tu vois quand il meure au contraire d'un DVD. Si tu veux graver les films, un CD est plus fiable qu'un DVD, le control d'erreur est plus "puissant".
"La première sécurité est la liberté"
[^] # Re: mon avis...
Posté par Nicolas Boulay (site web personnel) . En réponse au message Question idiote / archivage videos. Évalué à 2.
"La première sécurité est la liberté"
# distribution dédiée
Posté par Nicolas Boulay (site web personnel) . En réponse au message Cherche logiciel pour médecin (Belge).. Évalué à 2.
http://www.debian.org/devel/debian-med/practice.fr.html
et ça:
http://2007.rmll.info/rubrique8.html
"La première sécurité est la liberté"
[^] # Re: Gestion d'erreur lisaac
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 3.
Par contre, il faut faire attention aux contrats: ils sont censé être sans effet de bord !
"La première sécurité est la liberté"
[^] # Re: Utilisation
Posté par Nicolas Boulay (site web personnel) . En réponse au journal mon EEEpc. Évalué à 2.
"La première sécurité est la liberté"