"Je dis pas que leurs conception/implémentation est élémentaire, je dis que ce sont des fonctionnalités élémentaires des langages modernes, des fonctions indispensables pour qu'un langage soit utilisable de nos jours. Comme la gestion mémoire, la sécurité, etc. Faire l'impasse dessus lors de la conception d'un langage amène à Lisaac"
C'est dommage que tu n' aie pas essayer le lisaac, ça t'éviterais de dire des bêtises :
* Le lisaac dispose d'un gestionnaire de mémoire
* Le lisaac propose la programmation par contrat pour le débuggage
(et a plus, long terme, le but est de permettre plus que le simple débuggage, notamment de la preuve de programme)
* Le lisaac a des facilité pour l'écriture de fonction bas niveau, notemment au niveau de l'accès mémoire (mapping de slot directement sur la mémoire)
* Le lisaac est pensé autour de la sécurité des accès : le "public" ne permet que l'appelle et non pas l'écriture (passage obligatoire par des setters)
* Le lisaac proposera dans une future release (mais c'est déjà opérationnel) un système de synchronisation automatique pour le parallélisme - combien d'industriels rêvent d'arrêter de se casser la tête sur les synchronized de java ?
* Le lisaac est 100% objet (mais tu t'en fous)
* Le lisaac permet de l'héritage multiple (mais tu aimes les interfaces java, nan ?)
* Le lisaac permet des choses que peut de langages modernes permettent - réallocation du parent, changement de code dans les fonctions, retour de fonctons avec plusieurs valeurs...
Au vu de l'évolution des systèmes informatique, je suis prêts à parier que les systèmes type multi agents (si tu n'as pas essayer, je te recommande de jeter un oeuil sur JADE pour JAVA - de télécom Italia) vont se répandre de plus en plus. En règle générale, je pense qu'on va vers des systèmes répartis en réseaux. Dans de tels systèmes, la gestion des erreurs prendra une place extrêmement importante - déconnexion d'un agent, erreur d'un agent, coupure réseaux, refus de traiter une demande, etc... on peut en avoir plein. Donc oui, la gestion des erreurs devra être **relativement** efficace. Les exceptions sont pour l'instant suffisantes, rien n'empêche d'essayer de trouver autre chose pour le future.
Si tu veux un petit exemple de séquentialité, on peut voir le tout comme un automate. Dès que t'as une erreur, tu passes dans un état chargé de traiter l'erreur. C'est - basiquement - ce que fait un programmeur C à la main en testant les retours de fonctions critiques (accès systèmes en générales). On pourrait, par exemple, essayer d'automatiser le procéder, rendre la chose plus générique. Avant que tu ne sautes dessus, je te rappelle que c'est un exemple et que autre chose a été proposé dans le journal...
Donc, étant donné que lisaac possède déjà pas mal de "fonctionnalités indispensables dans un langage moderne" je t'invite à le tester.
* Pour les exceptions : c'est des GOTOS, et les GOTOS, c'est mal
Pour moi les exceptions offrent une sémantique beaucoup plus riche que les gotos, ont un usage beaucoup plus spécialisé, et n'ont au final pas grand chose à voir avec. Nan parcque sinon si on va par là, une boucle while, c'est un GOTO conditionnel non ?
Certes, mais contrairement aux exceptions, il n'y a pas un décrochement complet du programme. Les exceptions te cassent la séquentialité, le while non.
Alors oui, une machine ce n'est qu'un GOTO(adresse) + écriture/lecture, mais y'a différentes manières de le faire.
* Après il est vrai que la gestion des erreurs fait parti des défis...
C'est pour ca qu'il me semble intéressant d'en discuter. Les exceptions je suis bien d'accord que c'est pas la panacée, mais en attendant c'est ce qu'il se fait de mieux. Donc voilà, si on peut faire avancer le débat là dessus plutôt que de faire des rapides raisonnements à 2 francs 'exception = goto donc cmal'
j'ai adapté le raisonnement à mon principal lecteur (je prends de l'avance sur le coup des chercheurs).
Enfin, si t'as quelque chose de constructif à ajouter sur la gestion des erreurs, on sera ravi de voir ce que c'est. Parceque tu parles de débat, mais tu ne le fais pas plus avancé que mon collègue ou moi...
*Les modules cassent l'optimisation globale : oui, c'est donc un défi a relevé. Si t'es motivé tu peux le faire.
Je vois que t'es aussi enclin à répondre aux questions que ton collègue : quel intérêt de venir nous dire "on s'est réuni et on a discuter de la modularité' si tout ce que vous avez à dire au final c'est "oué ca sera fait, plus tard, t'as qu'à le faire si t'es motivé" ?
le "oué ca sera fait, plus tard, t'as qu'à le faire si t'es motivé" peut en fait être remplacé par "arrête de saouler, on cherche".
Si je te dit que c'est un défi à relever c'est que c'est pas encore fait. On le dit pour montrer la direction dans laquelle on va et si ça intéresse des gens, ils peuvent venir donner leur avis. Je ne parle pas de toi qui vient juste dire 'c'est naze" - même si c'est un avis.
*Je te rappelle aussi que le Lisaac est **principalement** développé par une seule personne. Pas par une équipe de 200 ingénieurs de chez microsoft (qui se font battre par le Lisaac sur le terrain des performances, soit dit en passant)
Voilà tout est résumé dans cette phrase, notamment entre les parenthèses. On à affaire à des chercheurs qui se branle la nouille
allons donc, il faut de tout pour faire un monde...
Mais la recherche, c'est pas mal plus intéressant que de continuer a implémenter des trucs bricolés (façon exception). Tu vois, on cherche, pour faire quelque chose de mieux. Toi tu dois bien te "branler la nouille" sur autre chose...
sur un langage révolutionnaire-parcquil-est-plus-performant-que-ce-que-font-ces-connards-de-ricains.
J'ai pas dis ça, c'est pour replacer les choses dans leur contexte. Tu peux pas demander à 1 personne de faire les choses comme 200 ingénieurs d'une multinationale qui a plus de moyen que la recherche publique française...
Les perfs "brutes" c'est gentil, mais Lisaac est un langage qui ne propose pas de gestion des erreurs, qui ne propose pas de gestion des modules, bref des choses élémentaires qui ont directement un impact sur les perfs : alors revenez avec un langage un minimum complet, après on refera les benchs et on comparera les perfs avec ce que fait MS (ou autre hein, y'a pas que MS).
Oh oui, les exceptions sont extrêmement consommatrice de ressource, c'est bien connu... c'est vrai qu'un jump, ça doit mettre ton processeur à genoux...
De plus, la gestion d'erreur n'est PAS élémentaire. Les modules ne sont PAS non plus élémentaires. On essaie de faire quelque chose d'innovant et ça prend du temps.
Ou alors arrêtez la prétention à 2 francs, les communiqués publicitaires vides de contenus intéressants, et montrez nous ce qui nous (moi en tout cas) intéresse : des critiques ettayés de l'existant, des idées d'améliorations possibles, avec exemples à l'appui, etc.
on va bientôt refaire les shootout benchmark. tu verras par toi même.
Sinon, t'as déjà codé en Lisaac ?
parceque si ce n'est pas le cas, je t'invite cordialement à le faire et à remonter les erreurs/bugs. On a toujours besoin de gens de bonnes volontés pour faire avancer un projet.
* Porter OPenGL c'est peut-être pas difficile, mais il faut le faire. Tu peux porter DirectX si ça te fait tripper.
* Pour les exceptions : c'est des GOTOS, et les GOTOS, c'est mal (inutile de relancer le vieux débat, je suppose. Si t'aimes ça, c'est juste que nous pas... les gouts et les couleurs quoi...). En plus, le principe de rejeter une exception est vraiment ignoble, ça casse le concept de "boite noire" qu'on aime tant avoir en objet. Après il est vrai que la gestion des erreurs fait parti des défis...
* Les exceptions sont utilisées par C# et C++ : ok, et alors ? Lisaac propose un autre moyen de programmer, et les exceptions n'en font pas parties. Si tu aimes ça, restes sur C++ (qui est quand même une surcouche super crade au C ).
*Les modules cassent l'optimisation globale : oui, c'est donc un défi a relevé. Si t'es motivé tu peux le faire.
*c'est cool mais concrètement : wait & see
Je te rappelle aussi que le Lisaac est **principalement** développé par une seule personne. Pas par une équipe de 200 ingénieurs de chez microsoft (qui se font battre par le Lisaac sur le terrain des performances, soit dit en passant)
[^] # Re: beaucoup de blabla, peu d'info
Posté par BigRatonTon . En réponse au journal Retour sur le Isaac Meeting 2008. Évalué à 2.
C'est dommage que tu n' aie pas essayer le lisaac, ça t'éviterais de dire des bêtises :
* Le lisaac dispose d'un gestionnaire de mémoire
* Le lisaac propose la programmation par contrat pour le débuggage
(et a plus, long terme, le but est de permettre plus que le simple débuggage, notamment de la preuve de programme)
* Le lisaac a des facilité pour l'écriture de fonction bas niveau, notemment au niveau de l'accès mémoire (mapping de slot directement sur la mémoire)
* Le lisaac est pensé autour de la sécurité des accès : le "public" ne permet que l'appelle et non pas l'écriture (passage obligatoire par des setters)
* Le lisaac proposera dans une future release (mais c'est déjà opérationnel) un système de synchronisation automatique pour le parallélisme - combien d'industriels rêvent d'arrêter de se casser la tête sur les synchronized de java ?
* Le lisaac est 100% objet (mais tu t'en fous)
* Le lisaac permet de l'héritage multiple (mais tu aimes les interfaces java, nan ?)
* Le lisaac permet des choses que peut de langages modernes permettent - réallocation du parent, changement de code dans les fonctions, retour de fonctons avec plusieurs valeurs...
Au vu de l'évolution des systèmes informatique, je suis prêts à parier que les systèmes type multi agents (si tu n'as pas essayer, je te recommande de jeter un oeuil sur JADE pour JAVA - de télécom Italia) vont se répandre de plus en plus. En règle générale, je pense qu'on va vers des systèmes répartis en réseaux. Dans de tels systèmes, la gestion des erreurs prendra une place extrêmement importante - déconnexion d'un agent, erreur d'un agent, coupure réseaux, refus de traiter une demande, etc... on peut en avoir plein. Donc oui, la gestion des erreurs devra être **relativement** efficace. Les exceptions sont pour l'instant suffisantes, rien n'empêche d'essayer de trouver autre chose pour le future.
Si tu veux un petit exemple de séquentialité, on peut voir le tout comme un automate. Dès que t'as une erreur, tu passes dans un état chargé de traiter l'erreur. C'est - basiquement - ce que fait un programmeur C à la main en testant les retours de fonctions critiques (accès systèmes en générales). On pourrait, par exemple, essayer d'automatiser le procéder, rendre la chose plus générique. Avant que tu ne sautes dessus, je te rappelle que c'est un exemple et que autre chose a été proposé dans le journal...
Donc, étant donné que lisaac possède déjà pas mal de "fonctionnalités indispensables dans un langage moderne" je t'invite à le tester.
bonne soirée
[^] # Re: beaucoup de blabla, peu d'info
Posté par BigRatonTon . En réponse au journal Retour sur le Isaac Meeting 2008. Évalué à 3.
Pour moi les exceptions offrent une sémantique beaucoup plus riche que les gotos, ont un usage beaucoup plus spécialisé, et n'ont au final pas grand chose à voir avec. Nan parcque sinon si on va par là, une boucle while, c'est un GOTO conditionnel non ?
Certes, mais contrairement aux exceptions, il n'y a pas un décrochement complet du programme. Les exceptions te cassent la séquentialité, le while non.
Alors oui, une machine ce n'est qu'un GOTO(adresse) + écriture/lecture, mais y'a différentes manières de le faire.
* Après il est vrai que la gestion des erreurs fait parti des défis...
C'est pour ca qu'il me semble intéressant d'en discuter. Les exceptions je suis bien d'accord que c'est pas la panacée, mais en attendant c'est ce qu'il se fait de mieux. Donc voilà, si on peut faire avancer le débat là dessus plutôt que de faire des rapides raisonnements à 2 francs 'exception = goto donc cmal'
j'ai adapté le raisonnement à mon principal lecteur (je prends de l'avance sur le coup des chercheurs).
Enfin, si t'as quelque chose de constructif à ajouter sur la gestion des erreurs, on sera ravi de voir ce que c'est. Parceque tu parles de débat, mais tu ne le fais pas plus avancé que mon collègue ou moi...
*Les modules cassent l'optimisation globale : oui, c'est donc un défi a relevé. Si t'es motivé tu peux le faire.
Je vois que t'es aussi enclin à répondre aux questions que ton collègue : quel intérêt de venir nous dire "on s'est réuni et on a discuter de la modularité' si tout ce que vous avez à dire au final c'est "oué ca sera fait, plus tard, t'as qu'à le faire si t'es motivé" ?
le "oué ca sera fait, plus tard, t'as qu'à le faire si t'es motivé" peut en fait être remplacé par "arrête de saouler, on cherche".
Si je te dit que c'est un défi à relever c'est que c'est pas encore fait. On le dit pour montrer la direction dans laquelle on va et si ça intéresse des gens, ils peuvent venir donner leur avis. Je ne parle pas de toi qui vient juste dire 'c'est naze" - même si c'est un avis.
*Je te rappelle aussi que le Lisaac est **principalement** développé par une seule personne. Pas par une équipe de 200 ingénieurs de chez microsoft (qui se font battre par le Lisaac sur le terrain des performances, soit dit en passant)
Voilà tout est résumé dans cette phrase, notamment entre les parenthèses. On à affaire à des chercheurs qui se branle la nouille
allons donc, il faut de tout pour faire un monde...
Mais la recherche, c'est pas mal plus intéressant que de continuer a implémenter des trucs bricolés (façon exception). Tu vois, on cherche, pour faire quelque chose de mieux. Toi tu dois bien te "branler la nouille" sur autre chose...
sur un langage révolutionnaire-parcquil-est-plus-performant-que-ce-que-font-ces-connards-de-ricains.
J'ai pas dis ça, c'est pour replacer les choses dans leur contexte. Tu peux pas demander à 1 personne de faire les choses comme 200 ingénieurs d'une multinationale qui a plus de moyen que la recherche publique française...
Les perfs "brutes" c'est gentil, mais Lisaac est un langage qui ne propose pas de gestion des erreurs, qui ne propose pas de gestion des modules, bref des choses élémentaires qui ont directement un impact sur les perfs : alors revenez avec un langage un minimum complet, après on refera les benchs et on comparera les perfs avec ce que fait MS (ou autre hein, y'a pas que MS).
Oh oui, les exceptions sont extrêmement consommatrice de ressource, c'est bien connu... c'est vrai qu'un jump, ça doit mettre ton processeur à genoux...
De plus, la gestion d'erreur n'est PAS élémentaire. Les modules ne sont PAS non plus élémentaires. On essaie de faire quelque chose d'innovant et ça prend du temps.
Ou alors arrêtez la prétention à 2 francs, les communiqués publicitaires vides de contenus intéressants, et montrez nous ce qui nous (moi en tout cas) intéresse : des critiques ettayés de l'existant, des idées d'améliorations possibles, avec exemples à l'appui, etc.
on va bientôt refaire les shootout benchmark. tu verras par toi même.
Sinon, t'as déjà codé en Lisaac ?
parceque si ce n'est pas le cas, je t'invite cordialement à le faire et à remonter les erreurs/bugs. On a toujours besoin de gens de bonnes volontés pour faire avancer un projet.
Bonne soirée
[^] # Re: beaucoup de blabla, peu d'info
Posté par BigRatonTon . En réponse au journal Retour sur le Isaac Meeting 2008. Évalué à -5.
* Pour les exceptions : c'est des GOTOS, et les GOTOS, c'est mal (inutile de relancer le vieux débat, je suppose. Si t'aimes ça, c'est juste que nous pas... les gouts et les couleurs quoi...). En plus, le principe de rejeter une exception est vraiment ignoble, ça casse le concept de "boite noire" qu'on aime tant avoir en objet. Après il est vrai que la gestion des erreurs fait parti des défis...
* Les exceptions sont utilisées par C# et C++ : ok, et alors ? Lisaac propose un autre moyen de programmer, et les exceptions n'en font pas parties. Si tu aimes ça, restes sur C++ (qui est quand même une surcouche super crade au C ).
*Les modules cassent l'optimisation globale : oui, c'est donc un défi a relevé. Si t'es motivé tu peux le faire.
*c'est cool mais concrètement : wait & see
Je te rappelle aussi que le Lisaac est **principalement** développé par une seule personne. Pas par une équipe de 200 ingénieurs de chez microsoft (qui se font battre par le Lisaac sur le terrain des performances, soit dit en passant)
Bonne soirée