Je me disais qu'il n'yen avais pas 36, des LézardBreton ;-)
Au passage, je vous conseille cette source très informée. On comprend pas tout, mais beaucoup de chose quand même.
Il y a quand même un truc très bizare : J'ai du mal à comprendre comment les responsables de la SG ont pu ne pas voir que leur banque détenais plus de 50 % des futurs de DAX. Un trader expliquait ce matin sur Inter qu'il voyait bien que la SG possédait trop de titre (plus de 70% !) et que ce n'étais pas normal. http://www.capital.fr/actualite/Default.asp?source=AO&nu(...)
La banque raconte que Kerviel leur aurait servi un faux, et qu'il s'en serait satisfait. Soit ils sont incompétent, soit ils ont trempés !
A suivre...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
La secte GCU va probablement inventer une action d'éclats dont ils ont le secret, une bonne âme aurait-elle la bonté d'immortaliser (en vidéo, si possible) cette action militante indispensable ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Pas sûr, sur mon macbook (Core Duo 1, 1,8 Ghz), sous MacOs X, je reste à 45 % de load pour 16 blob. A noter qu'un core est utilisé à 95 %, tandis que l'autre travaille à 30 %.
Et tout cela en en dépassant un maximum.
J'ai eu un collègue qui était informaticien à l'époque sur la base de Kourou; Il nous as un jour révélé que les informaticiens travaillant sur cette centrale inertiel sentaient bien qu'elle allait leur péter entre les doigts, à cause de la trop grande puissance d'Ariane 5. Ils s'en étaient ouvert aux autres informaticiens travaillant par sur le projet.
Le problème vient en réalité d'un problème financier, une fois de plus : Les actionnaires d'Arianespace sont en même temps ses clients.
Les actionnaires ont donc fait pression pour que la fusée soit lancée au plus vite, car ils commençaient à faire moins de bénèf sur la vente de fourniture de composant pour Ariane 4.
Disclaimer, ce n'est qu'un "on dit" rapporté par un collègue, un midi, autour d'un sandwich, j'ai jamais vérifié la véracité de ces informations..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je vais pas sortir la blague de l'éditeur de l'éditeur qui crache le code tout seul (tiens on pourrait, ya une news sur un nouveau méta-truc, Acceleo), mais imaginer un rêve pragmatique.
Ayant récemment changé de taf, et travaillant maintenant avec des collègues réèlement compétent, je découvre tout ce qu'Eclipse a dans le ventre, et c'est vrai que l'on peut automatiser pas mal de choses, à condition d'aimer les interfaces à la clicodrome+Emacs qui oblige à se tordre les doigts avec des control+alt+shift+backspace+fin/whatever (c'est ce que j'aime pas dans Emacs).
Faut avouer que c'est puissant comme outil.
- Il y a plein de chose qu'un éditeur pourrait deviner avec une bonne IA, dans une logique "je détecte un comportement répétitif, je propose de le généraliser". Typiquement, les comportement primitif du genre "l'utilisateur tappe à partir de
boolean b1,b2,b3,b4;
un test comme suit :
if (b1) {
} else if (b2) {
}
L'IDE me proposerai de généraliser l'écriture
La plupart du temps, quand c'est vraiment trop lent à le faire à la main,je sort un script perl.
- Un système permettant de poser des contrats et trouver des contre exemples, comme dans Esterel...
On en a pas mal discuté, mais vu les difficultés, il faudra longtemps avant que l'on en dispose pour Lisaac.
- C'est plus un problème de langage, mais pouvoir rejouer un morceaux de programme,dans les mêmes conditions, après 1 heure de calcul, ça serait génial.
Il parait que c'est possible en caml, mais c'est son approche fonctionnel qui le permet surement. Quoique certaines implémentations de smalltalk le fond aussi.
Cela dit, dans certains cas, enregistrer l'état de la mémoire du programme répondrai peut être au problème, mais bonjour l'explosio, de la consommation.
- Pouvoir mettre un scope sur une variable, plus exactement d'avoir un historique de ses états successifs, et un pointeur vers la ligne où elle a été modifiée. C'est un peu un concept de programmation orienté aspect, mais en c'est parfaitement implémentable en debug.
Avec un système de regexp permettant un filtrage, pour ne pas se coltiner une liste trop longue de modifications.
- Poser des questions
Lorsqu'on débug, c'est surtout trouver le petit bug qui ennuie tout le monde qui pose problème.
Un système de requêtage serait génial, il permettrait de demander quel branches de code peuvent impliquer que telle collection a été vidée. Quel est la relation entre telle ou telle variable. Ce dernier point permettrait de détecter que deux listes différentes contiennent des éléments identiques au niveau référence (même pointeurs) et que modifier l'élément dans une le modifie dans l'autre.
- Visualiser un graphe d'appel en 3D
Mes deux centimes.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Le sujet qui m'intéressait, c'était de constater dans l'exemple, qu'on avait une fenetre de config, avec les boutons, : annuler, ok, appliquer, fermer, revenir à la configuration par défaut.
Ce qui fait beaucoup.
Je disais que sur MacOS X, il n'y avait que le bouton revenir à la configuration par défaut. EN effet la philosophie est simple :
sur ma télé, je n'ai pas de bouton Ok,annuler,appliquer quand je monte le volume.
Je me demandais aussi quel était sémantiquement la réelle diffférence entre Ok et appliquer, Ok appliquant peut être plus tard le réglage.
Un des commentaires intéressant répondait que la différence entre Ok et appliquer était que Ok ferme la fenêtre, appliquer servant à tester pour essayer son réglage.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Tu met le doigt sur un problème que je n'avais pas vu, tout à la définition de mon sous-marin muni de sa cohérence intrinsèque. Je suis heureux de ta réponse, car c'est un peu ce que j'esperais en le publiant ici :-)
En fait, tu relèves que mon modèle ne permet pas de définir un code déterministe.
Pourquoi cette erreur ?
- Parce que je mélange une sémantique axiomatique et une sémantique opérationnelle
- Parce que je n'ai pas vu que si j'utilisais certes mes contrats sur variable pour définir des compréhensions d'ensemble, je n'ai pas vu que sémantiquement on peut tout faire, et surtout n'importe quoi.
Donc que faire ?
J'en ai discuté avec Benoit (Sonntag, l'auteur de Lisaac), qui m'a conseiller de regarder la [[Méthode_B]].
J'en suis donc venu à étudier les possibilités de la méthode B évènementielle qui "colle" à peu près ce que je veux faire.
Mise à part que la syntaxe est absolument immonde (on ferait mieux de lui substituer une syntaxe du type OCL), le B évènementiel permet de définir des variables, définir leur ensemble d'appartenance et l'ensemble des états de l'automate. Le compilateur B permet de vérifier de la cohérence logique du modèle pour ensuite générer le code correspondant.
Le problème est qu'il est impossible de mélanger les deux sémantique, à moins qu'on ai la certitude qu'il n'y ait pas d'interférence entre elles (un cas valide pourrait être le fait que le passage à un état implique un appel d'une fonction graphique, qui ne renvoi rien et ne modifie pas l'état interne de l'automate).
Une perspective envisageable serait d'adapter les primitives de B évènementiel, avec éventuellement quelques sucres syntaxiques pour modéliser les états d'agent comme je les ai introduit ici.
En tout cas, encore merci, et je vais réfléchir à tout cela :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Pour compléter ce qu'a répondu Nicolas, le compilateur se contente d'inliner le code C inclu dans le code Lisaac. Genre si tu met un commentaire C, tu retrouvera le commentaire dans le fichier .c produit...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Même réponse que plus haut. Il suffit de réécrire un autre back-end afin que le compilateur crache du code pour une VM quelconque (ce que tu veux, JVM, LLVM, CLI), et surement avec de meilleurs perfs qu'avec le même code en Java ou C# (c'est pas dur).
Le problème de sécurité serait donc réglé.
Je crois que tu n'as pas du tout compris ce qu'est ce compilateur : Il permet de compiler un langage objet à prototype, avec très peu de primitives. En réécrivant le parseur, on pourrait lui faire compiler assez facilement du Java.
Ensuite, ce compilateur travaille en interne, sur un mini langage, extremement minimaliste (une dizaine d'instructions), qui sera ensuite traduite en C.
Tu peux réécrire la traduction afin qu'elle produise ce que tu veux, du Java, du bytecode, de l'ASM, du Brainfuck.
Donc le problème ne se situe pas là, et comme le relevait plus haut Yusei, tu critiques effectivement l'implémentation actuelle, et pas les concepts :
le compilateur Lisaac permet de faire énormément de chose, y compris de répondre à tes problèmes de sécurité.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Rien ne montre effectivement qu'il n'est pas possible de cibler une machine virtuelle en Lisaac.
SmartEiffel propose de produire du bytecode pour la JVM.
Il en a de même été question dans nos discussions de faire de même avec le compilateur lisaac. Il y a à ce titre plusieur approche :
- Une qui fonctionne déjà, mais vraiment tordu : il 'sagit de compiler le .c produit par lisaac pour produire du binaire mips, qui est transformé en LLVM, puis en bytecode JVM. Ca marche à peu près, mais c'est trop tordu.
- Produire du bytecode JVM. C'est quelques semaines de travail, faut voir avec les autres priorités
- Produire du java, en mettant tout le code dans une grosse classe Main. Ca aurait en plus l'avantage de pouvoir s'interfacer avec d'autres libs en java. Le truc qui dérange Benoit, c'est l'absence d'entier signé en Java, ça lui pose des problème, mais à part ça, c'est pas très difficile à faire, surtout que la gestion de la mémoire serait beaucoup plus facile
La 2ème question à se poser c'est la pertinence de certains choix fait dans Lisaac, notamment le côté "simple" de la grammaire permettant d'augmenter facilement les constructions syntaxique (simuler une boucle for while ou un autre truc innovant). C'est joli, bandant... oui mais pourquoi Java ou C# ne propose pas ce genre de chose ? (c'est pas une nouveauté en soit)
Java et C# ne le proposent pas, parce que c'est très dur à compiler, même quand tu fait du JIT.
S'il le faisaient, les performances s'écrouleraient.
De plus, par suivisme, et pour ne pas choquer les programmeur et ainsi faciliter (à l'époque) la transition C/C++ -> Java, le parti pris a été de proposer une syntaxe très proche du C.
Ces deux facteurs ont impliqué que ce genre de possibilités n'existent pas, et qu'on est donc obligé de grossir la grammaire pour en proposer certaines.
En limitant à l'aide de mots clés (for while foreach, etc.) les constructions les plus courantes, on limite certes la concision et l'expressivité, mais on améliore aussi la compréhension du code par une autre personne. C'est probablement ce qui a fait une partie du succès de Java. Beaucoup d'autres simplifications également. Ce qui apparaît comme des contraintes pour un "universitaire" est en fait un atout dans la vraie vie. Lever ces contraintes comme le propose Lisaac élimine une qualité essentielle d'un code source. Et dans le mondre du libre on devrait être attaché à cet aspect.
Il est vrai que cela peut être à double tranchant.
Cela dit, en ce qui nous concerne, on y réfléchit très murement avant de mettre une construction nouvelle dans la librairie standard.
Il est même question de les normaliser, afin de les rendre prévisible (genre quand une fonction rend une collection, on aura toujours une fonction proposant de boucler sur cette liste, avec un nom de fonction prévisible de par la première)
de plus, on essaye d'avoir des noms de fonction claires, et la syntaxe à mot clé y aide.
macollection.foreach { // code }; until { //condition}; se comprend très vite
Et on ne modifie pas impunément une librairie standard, je connais peu de gens qui prennent ce genre de risque, même quand c'est "pas grave" et qu'ils peuvent se le permettre.
Une machine virtuelle c'est pareil. En apparance c'est une érésie, les perfs s'en ressentent largement. Seulement les avantages sont aujourd'hui beaucoup plus important que les inconvénients (sécurité, portabilité, productivité, etc.) dans beaucoup de scénarios d'utilisation.
Voir plus haut. Et j'aimerai que tu me cites les constructions de Java, qui utilisent ces fameuses plus value de la VM...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Ce qui est marrant avec toi, c'est que lorsque je me demande combien je vais avoir de commentaires à mon journal/news, je fais +/- 20 % de commentaire selon le facteur TImaniac ;-)
J'aime beaucoup ta vision d'ingénieur borné. Tu es surement très compétent dans ton domaine, dans ton travail, bref dans la technique, mais tu as de grosses lacunes en informatique théorique.
Ta vision est néanmoins très utile car elle me permet de mettre le doigt sur ce qu'il reste à faire pour faire de Lisaac un langage ayant au moins une audience honorable (quelques milliers, voire dizaines de milliers d'utilisateurs ?)
Pourquoi ais-je un ton publicitaire ?
- Parce que j'y crois, et te prierai de ne pas me casser mes rêves ;-)
- Parce que le compilateur est effectivement révolutionnaire :
Pas mal de chercheurs (Chamber, David Ungar et Randall Smith par exemple) et en partie ceux qui sont à l'origine de java (des techniques utilisées dans la JVM pour être plus précis), ont travaillé sur les langages objet à prototype (Self créé en 1986), dans l'objectif d'obtenir des perfs avec ces langages. Ils n'ont jamais réussi, mais ont considérablement amélioré les techniques, en particulier celle du [a href="http://en.wikipedia.org/wiki/Just-in-time_compilation)"]JIT[/a].
Ungar et Smith ont finit par tenter de faire un système d'exploitation entièrement écrit en Self, sans grands résultats.
Devant l'échec de ce rêve la plupart des chercheurs ayant travaillé sur le problème (qq dizaines de personnes tout de même) ont laissé tomber.
Le compilateur Lisaac est révolutionnaire, parce qu'il a réussi à réaliser ce rêve :
- Un langage de haut niveau aussi rapide, voire plus que le C
- Un langage système permettant d'écrire un OS, sans nécessiter autre chose que quelques lignes d'assembleur.
Je te rappelle que les [a href="http://isaacproject.u-strasbg.fr/li/li_benchs.html"]benchs[/a] montrent qu'on peut être plus rapide que du C avec 40% de lignes de code en moins.
Alors effectivement, toi, ingénieur d'informatique de gestion, tu t'en tapes des perfs, et c'est normal. J'y travail aussi, et je sais bien qu'à quelques rares exceptions, c'est pas primordiales. Et de toutes façon, il faut de la lib, des framework, des communautés, une grosse boite, etc...
Donc pour répondre à ta question une liste des atouts de Lisaac qui pourrait en faire un langage sexy face à l'existant
Pour le moment, pour être réaliste, elle s'adresse principalement aux codeur des domaines de l'embarqué, des système où le C est obligatoire.
Lisaac apporte pour ces gens là :
- Un langage de haut niveau
- Des perfs dignes du C
- Une librairie de base (qui va grandir) proposant pas mal de service (parce qu'une table de hashage en C pour de l'embarqué, bonjour...).
Il est vrai que la TODOliste est encore énorme, et ce compilateur deviendra de plus en intéressant :
- De meilleur optimisations : il reste beaucoup d'optimisation de code encore possible, et Benoit compte s'y remettre dans les mois à venir. Je ne citerai pas toutes les idées de Nicolas Boulay, mais des idées comme sortir les invariants des boucles, écrire les boucles de sortes qu'elles soient optimisée par l'autovectorisation de GCC, faire en sorte que les données soient toujours dans le cache processeur L1, etc...
- La capacité de produire du code très petit en taille, en factorisant le code commun (encore une proposition de Nicolas)
- De nouvelles fonctionnalités, comme COP, les contrats sur les variables, les types inconnu que l'on peut utiliser dans une méthode, etc...
De même la lib va grossir :
- Le traducteur Eiffel-> Lisaac sera terminé dans quelques mois
- Les étudiants de L3 à l'université de strasbourg planchent sur un traducteur Java->Lisaac, qui nous permettra, en travaillant bien, de disposer de pas mal de librairie dans les 5 prochaines années
Alors, c'est vrai TImaniac, Lisaac ne se veut pas un concurrent de C#/Java, Lisaac n'est pas tuné pour plaire à l'industrie, Lisaac.
Oué mais bon y'a aussi beaucoup de branlette intellectuelle là dedans. Ca me gène pas en soit, c'est fort intéressant et il en découle souvent des applications pratiques plus qu'innovante. Mais sa façon de présenter les choses donne sérieusement envie de le remettre (Ontologia) les pieds sur terre, la réalité de Lisaac aujourd'hui comparé aux autres langages. Lisaac a sûrement pleins d'atout, mais il n'est pas universel et n'a pas tous les atouts réunis des autres langages et ne peut mon sens pas prétendre tous les remplacer.
Ne prend pas ton cas pour une généralité, tout le monde n'est pas ingé dans le domaine de la gestion, avec des oeuillères certes parfaitement adapté à ton métier et ta carrière, mais empêchant de voir ce qui pourrait devenir une nouvelle "mode" dans 15 ans.
Alors, effectivement, comme Smalltalk en 1973, Lisaac n'est pas industrie-friendly, c'est clair, peut être qu'il ne restera qu'un prototype de recherche, mais il a un énorme potentiel, et je veux au moins tenter l'aventure.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je pense qu'il est temps de recentrer un peu le débat, car on s'éloigne un peu. Tu disais que du moment qu'on a un langage Turing complet, on peut prouver ses programmes. Or, tout langage Turing complet permet de produire des programmes dont on ne peut pas prouver la terminaison avec quelque chose de la même puissance qu'une MT.
C'est, il me semble, une application du théorème d'incomplétude de Godël.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
D'aileurs, on aurait jamais du inventer la locomotive à vapeur, parce qu'une carriole tirée par des chevaux, c'est beaucoup plus simple.
C'est vrai ! C'est compliqué une locomotive à vapeur ! Tout ce jeu complexe de température, de pression, d'étanchéïté...
Les inventeurs de cette machine auraient du arrêter tout de suite !
Tiens mais pourquoi ont-ils continués ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Pour le premier point, c'est tout simplement parce que le concepteur de Lisaac, considère que les mots clés du type break, etc... permettent à de très mauvaises habitudes de se développer.
Le return car cela permet de faire quitter la fonction en plein de milieu de celle-ci, ce qui est très mauvais. Le break, car tu sort d'une boucle n'importe comment.
J'évite d'utiliser ce genre d'ecueuil dans mon code, au début ça a été dur, mais au final, ça me simplifie la vie au debugging (moins de surprise).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
En passant toujours, Red Hat emploi beaucoup de monde en Europe, Inde, etc...
Je n'en disconvient pas. Je pensais plutôt aux bénéfices accordés aux actionnaires :-)
Comme quoi la mondialisation ce n'est pas le mal absolu.
Je ne me sens pas visé :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Savez vous que 90 % du business OpenSource s'effectue aux états-unis, alors qu'une grande partie des contributeurs se trouvent dans le reste du monde (et pas mal en Europe) ?
Ca laisse rêveur non ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
...et je crois qu'il ne faudra jamais me laisser un avion entre les mains !
Après 3 essai infructueux, j'ai essayé un "Lightening". Le tutoriel m'explique comment lancer le machin. C'est très compliqué, il faut mettre pas mal de bouton sur ON avec des intitulés bizarre (pas si bizarre que ça, ayant travaillé dans une boite sous-traitante de constructeurs aéronautiques, je retrouve quelques mots dont je ne comprenais pas le sens).
J'arrive à démarrer l'avion, problème, dès le départ, avec le pilotage à la souris, je dévie légèrement l'angle de celui-ci... et sort très vite de la piste.
FlightGear est gentil, il me permet de décoller en roulant en plein champ, abattant les arbres sur mon passage (sans abimer le fuselage de l'avion).
J'abaisse le manche à balai, il décolle, et je me retrouve à peut être 1000 mètre d'altitude.
A partir de là ça se gate, le coucou devient très vite instable, j'ai du mal à le maintenir.
On voit rien, et c'est difficile de se concentrer sur le manche, hyper sensible et dont tout écart peut vite devenir catastrophique, et essayer de trouver un endroit où se poser.
Je finis par ne plus réussir à le controler, il se met à vriller, je stabilise comme je peux, mais rien à faire.
A un moment, ne sachant pas si je monte ou descend, je me plante sur le sol.
Il est gentil, il n'explose pas, au moins je ne suis pas trop vexé :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
D'un point de vue sémantique, une erreur qu'est-ce que c'est ?
Une erreur est un comportement non désiré du programme par rapport à la spécification. Elle peut avoir plusieurs sources :
- Les données ne sont pas exactement structurée comme prévu
- Une erreur de logique traine dans le code
- La conception architectural est mal pensé (bugs les plus graves)
- ...
Les erreurs que l'on rencontre dans notre métier, sont essentiellement du à la sémantique opérationelle des langages de programmation que l'on utilise.
Ils se réduisent tous à une sémantique simple :
- Transfert d'une donnée en mémoire vers un autre endroit
- Calcul arithmétique sur une donnée en mémoire
- Test conditionnel sur l'état d'une donnée en mémoire.
Avec ça, on fait tout (langage procédurales, objets, fonctionnel, à contraintes, ...
La logique devient bien vite énorme, et l'équation grandissant, le risque d'avoir un problème non prévu augmente, puisque le nombre d'état augmente tout autant.
Qu'est-ce qu'une fonction ? Un outil permettant de rendre déclaratif un sous ensemble du programme, de sorte à découper la complexité en petit bout pour pouvoir l'aborder.
Il arrive souvent que l'on croit que le code est déclaratif, voire commutatif (ie l'ordre d'exécution de 2 fonctions n'est pas important), et se rendre compte qu'en fait, non..
Tout ça pour dire, que même avec des outils du genre exceptions, contrats, qui ont chacun leur avantages et inconvéniant, on attaquera jamais le noeud du problème.
Le noeud, c'est de s'élever sémantiquement avec un langage ne se réduisant plus à la sémantique décrite plus haut, mais se rapprochant plus d'un langage de spécification déclaratif.
Quoi ? J'en parlerai bientôt en ces pages.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
On rentre dans des questions de goûts et de couleur.
Personnelement, étant assez tête en l'air, je préfère avoir un compilateur hyper chiant, qui ne m'autorise absolument aucun écart, aucun code "dangereux" et me garantit donc aucune surprise.
C'est la garantie de ne pas passer des heures à debugger des conneries.
Parce que passer 1 journée à debuguer un truc que j'ai écrit en moins d'une heure, ça m'est arrivé, et c'est très frustrant, sans compter qu'il faut faire avaler la pilule à ton chef, qui le prend pour de l'incompétence pur.
Les langages non typés ne me dérange pas, mais à condition qu'ils ne soient pas dynamiquement typés, hors PHP l'est :-(
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Tentative d'explication
Posté par Ontologia (site web personnel) . En réponse au journal Spécialiste de l'informatique banquaire.... Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Tentative d'explication
Posté par Ontologia (site web personnel) . En réponse au journal Spécialiste de l'informatique banquaire.... Évalué à 6.
Je me disais qu'il n'yen avais pas 36, des LézardBreton ;-)
Au passage, je vous conseille cette source très informée. On comprend pas tout, mais beaucoup de chose quand même.
Il y a quand même un truc très bizare : J'ai du mal à comprendre comment les responsables de la SG ont pu ne pas voir que leur banque détenais plus de 50 % des futurs de DAX. Un trader expliquait ce matin sur Inter qu'il voyait bien que la SG possédait trop de titre (plus de 70% !) et que ce n'étais pas normal.
http://www.capital.fr/actualite/Default.asp?source=AO&nu(...)
La banque raconte que Kerviel leur aurait servi un faux, et qu'il s'en serait satisfait. Soit ils sont incompétent, soit ils ont trempés !
A suivre...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Evènement marquants
Posté par Ontologia (site web personnel) . En réponse à la dépêche Solutions Linux 2008 du 29 au 31 janvier. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: SVG+JS vs FLash - Requiem
Posté par Ontologia (site web personnel) . En réponse au journal Un < canvas > rigolo. Évalué à 3.
Et tout cela en en dépassant un maximum.
D'après le shootout language, Javascript est légèrement devant Ruby : http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
à 49% plus lent que c++ qui est premier
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: langage ?
Posté par Ontologia (site web personnel) . En réponse au journal Future Combat Systems. Évalué à 4.
Le problème vient en réalité d'un problème financier, une fois de plus : Les actionnaires d'Arianespace sont en même temps ses clients.
Les actionnaires ont donc fait pression pour que la fusée soit lancée au plus vite, car ils commençaient à faire moins de bénèf sur la vente de fourniture de composant pour Ariane 4.
Disclaimer, ce n'est qu'un "on dit" rapporté par un collègue, un midi, autour d'un sandwich, j'ai jamais vérifié la véracité de ces informations..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Un exemple de code
Posté par Ontologia (site web personnel) . En réponse au message communication entre fork() via un tableau en mémoire. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Puisqu'on à le droit de rêver...
Posté par Ontologia (site web personnel) . En réponse au journal Qu'est-ce qu'un outils de développement de rève ?. Évalué à 4.
Ayant récemment changé de taf, et travaillant maintenant avec des collègues réèlement compétent, je découvre tout ce qu'Eclipse a dans le ventre, et c'est vrai que l'on peut automatiser pas mal de choses, à condition d'aimer les interfaces à la clicodrome+Emacs qui oblige à se tordre les doigts avec des control+alt+shift+backspace+fin/whatever (c'est ce que j'aime pas dans Emacs).
Faut avouer que c'est puissant comme outil.
- Il y a plein de chose qu'un éditeur pourrait deviner avec une bonne IA, dans une logique "je détecte un comportement répétitif, je propose de le généraliser". Typiquement, les comportement primitif du genre "l'utilisateur tappe à partir de
boolean b1,b2,b3,b4;
un test comme suit :
if (b1) {
} else if (b2) {
}
L'IDE me proposerai de généraliser l'écriture
La plupart du temps, quand c'est vraiment trop lent à le faire à la main,je sort un script perl.
- Un système permettant de poser des contrats et trouver des contre exemples, comme dans Esterel...
On en a pas mal discuté, mais vu les difficultés, il faudra longtemps avant que l'on en dispose pour Lisaac.
- C'est plus un problème de langage, mais pouvoir rejouer un morceaux de programme,dans les mêmes conditions, après 1 heure de calcul, ça serait génial.
Il parait que c'est possible en caml, mais c'est son approche fonctionnel qui le permet surement. Quoique certaines implémentations de smalltalk le fond aussi.
Cela dit, dans certains cas, enregistrer l'état de la mémoire du programme répondrai peut être au problème, mais bonjour l'explosio, de la consommation.
- Pouvoir mettre un scope sur une variable, plus exactement d'avoir un historique de ses états successifs, et un pointeur vers la ligne où elle a été modifiée. C'est un peu un concept de programmation orienté aspect, mais en c'est parfaitement implémentable en debug.
Avec un système de regexp permettant un filtrage, pour ne pas se coltiner une liste trop longue de modifications.
- Poser des questions
Lorsqu'on débug, c'est surtout trouver le petit bug qui ennuie tout le monde qui pose problème.
Un système de requêtage serait génial, il permettrait de demander quel branches de code peuvent impliquer que telle collection a été vidée. Quel est la relation entre telle ou telle variable. Ce dernier point permettrait de détecter que deux listes différentes contiennent des éléments identiques au niveau référence (même pointeurs) et que modifier l'élément dans une le modifie dans l'autre.
- Visualiser un graphe d'appel en 3D
Mes deux centimes.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Résumé du journal supprimé
Posté par Ontologia (site web personnel) . En réponse au journal Un journal a été supprimé !. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Résumé du journal supprimé
Posté par Ontologia (site web personnel) . En réponse au journal Un journal a été supprimé !. Évalué à 4.
Le sujet qui m'intéressait, c'était de constater dans l'exemple, qu'on avait une fenetre de config, avec les boutons, : annuler, ok, appliquer, fermer, revenir à la configuration par défaut.
Ce qui fait beaucoup.
Je disais que sur MacOS X, il n'y avait que le bouton revenir à la configuration par défaut. EN effet la philosophie est simple :
sur ma télé, je n'ai pas de bouton Ok,annuler,appliquer quand je monte le volume.
Je me demandais aussi quel était sémantiquement la réelle diffférence entre Ok et appliquer, Ok appliquant peut être plus tard le réglage.
Un des commentaires intéressant répondait que la différence entre Ok et appliquer était que Ok ferme la fenêtre, appliquer servant à tester pour essayer son réglage.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Plusieurs problèmes avec tes primitves
Posté par Ontologia (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
En fait, tu relèves que mon modèle ne permet pas de définir un code déterministe.
Pourquoi cette erreur ?
- Parce que je mélange une sémantique axiomatique et une sémantique opérationnelle
- Parce que je n'ai pas vu que si j'utilisais certes mes contrats sur variable pour définir des compréhensions d'ensemble, je n'ai pas vu que sémantiquement on peut tout faire, et surtout n'importe quoi.
Donc que faire ?
J'en ai discuté avec Benoit (Sonntag, l'auteur de Lisaac), qui m'a conseiller de regarder la [[Méthode_B]].
J'en suis donc venu à étudier les possibilités de la méthode B évènementielle qui "colle" à peu près ce que je veux faire.
Mise à part que la syntaxe est absolument immonde (on ferait mieux de lui substituer une syntaxe du type OCL), le B évènementiel permet de définir des variables, définir leur ensemble d'appartenance et l'ensemble des états de l'automate. Le compilateur B permet de vérifier de la cohérence logique du modèle pour ensuite générer le code correspondant.
Le problème est qu'il est impossible de mélanger les deux sémantique, à moins qu'on ai la certitude qu'il n'y ait pas d'interférence entre elles (un cas valide pourrait être le fait que le passage à un état implique un appel d'une fonction graphique, qui ne renvoi rien et ne modifie pas l'état interne de l'automate).
Pour ceux, que ça intéresse, un cours assez clair ici : http://www.lri.fr/~paulin/B/poly002.html
Une perspective envisageable serait d'adapter les primitives de B évènementiel, avec éventuellement quelques sucres syntaxiques pour modéliser les états d'agent comme je les ai introduit ici.
En tout cas, encore merci, et je vais réfléchir à tout cela :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est trop compliqué !
Posté par Ontologia (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est trop compliqué !
Posté par Ontologia (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Le problème de sécurité serait donc réglé.
Je crois que tu n'as pas du tout compris ce qu'est ce compilateur : Il permet de compiler un langage objet à prototype, avec très peu de primitives. En réécrivant le parseur, on pourrait lui faire compiler assez facilement du Java.
Ensuite, ce compilateur travaille en interne, sur un mini langage, extremement minimaliste (une dizaine d'instructions), qui sera ensuite traduite en C.
Tu peux réécrire la traduction afin qu'elle produise ce que tu veux, du Java, du bytecode, de l'ASM, du Brainfuck.
Donc le problème ne se situe pas là, et comme le relevait plus haut Yusei, tu critiques effectivement l'implémentation actuelle, et pas les concepts :
le compilateur Lisaac permet de faire énormément de chose, y compris de répondre à tes problèmes de sécurité.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est trop compliqué !
Posté par Ontologia (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
SmartEiffel propose de produire du bytecode pour la JVM.
Il en a de même été question dans nos discussions de faire de même avec le compilateur lisaac. Il y a à ce titre plusieur approche :
- Une qui fonctionne déjà, mais vraiment tordu : il 'sagit de compiler le .c produit par lisaac pour produire du binaire mips, qui est transformé en LLVM, puis en bytecode JVM. Ca marche à peu près, mais c'est trop tordu.
- Produire du bytecode JVM. C'est quelques semaines de travail, faut voir avec les autres priorités
- Produire du java, en mettant tout le code dans une grosse classe Main. Ca aurait en plus l'avantage de pouvoir s'interfacer avec d'autres libs en java. Le truc qui dérange Benoit, c'est l'absence d'entier signé en Java, ça lui pose des problème, mais à part ça, c'est pas très difficile à faire, surtout que la gestion de la mémoire serait beaucoup plus facile
La 2ème question à se poser c'est la pertinence de certains choix fait dans Lisaac, notamment le côté "simple" de la grammaire permettant d'augmenter facilement les constructions syntaxique (simuler une boucle for while ou un autre truc innovant). C'est joli, bandant... oui mais pourquoi Java ou C# ne propose pas ce genre de chose ? (c'est pas une nouveauté en soit)
Java et C# ne le proposent pas, parce que c'est très dur à compiler, même quand tu fait du JIT.
S'il le faisaient, les performances s'écrouleraient.
De plus, par suivisme, et pour ne pas choquer les programmeur et ainsi faciliter (à l'époque) la transition C/C++ -> Java, le parti pris a été de proposer une syntaxe très proche du C.
Ces deux facteurs ont impliqué que ce genre de possibilités n'existent pas, et qu'on est donc obligé de grossir la grammaire pour en proposer certaines.
En limitant à l'aide de mots clés (for while foreach, etc.) les constructions les plus courantes, on limite certes la concision et l'expressivité, mais on améliore aussi la compréhension du code par une autre personne. C'est probablement ce qui a fait une partie du succès de Java. Beaucoup d'autres simplifications également. Ce qui apparaît comme des contraintes pour un "universitaire" est en fait un atout dans la vraie vie. Lever ces contraintes comme le propose Lisaac élimine une qualité essentielle d'un code source. Et dans le mondre du libre on devrait être attaché à cet aspect.
Il est vrai que cela peut être à double tranchant.
Cela dit, en ce qui nous concerne, on y réfléchit très murement avant de mettre une construction nouvelle dans la librairie standard.
Il est même question de les normaliser, afin de les rendre prévisible (genre quand une fonction rend une collection, on aura toujours une fonction proposant de boucler sur cette liste, avec un nom de fonction prévisible de par la première)
de plus, on essaye d'avoir des noms de fonction claires, et la syntaxe à mot clé y aide.
macollection.foreach { // code }; until { //condition}; se comprend très vite
Et on ne modifie pas impunément une librairie standard, je connais peu de gens qui prennent ce genre de risque, même quand c'est "pas grave" et qu'ils peuvent se le permettre.
Une machine virtuelle c'est pareil. En apparance c'est une érésie, les perfs s'en ressentent largement. Seulement les avantages sont aujourd'hui beaucoup plus important que les inconvénients (sécurité, portabilité, productivité, etc.) dans beaucoup de scénarios d'utilisation.
Voir plus haut. Et j'aimerai que tu me cites les constructions de Java, qui utilisent ces fameuses plus value de la VM...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est trop compliqué !
Posté par Ontologia (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
J'aime beaucoup ta vision d'ingénieur borné. Tu es surement très compétent dans ton domaine, dans ton travail, bref dans la technique, mais tu as de grosses lacunes en informatique théorique.
Ta vision est néanmoins très utile car elle me permet de mettre le doigt sur ce qu'il reste à faire pour faire de Lisaac un langage ayant au moins une audience honorable (quelques milliers, voire dizaines de milliers d'utilisateurs ?)
Pourquoi ais-je un ton publicitaire ?
- Parce que j'y crois, et te prierai de ne pas me casser mes rêves ;-)
- Parce que le compilateur est effectivement révolutionnaire :
Pas mal de chercheurs (Chamber, David Ungar et Randall Smith par exemple) et en partie ceux qui sont à l'origine de java (des techniques utilisées dans la JVM pour être plus précis), ont travaillé sur les langages objet à prototype (Self créé en 1986), dans l'objectif d'obtenir des perfs avec ces langages. Ils n'ont jamais réussi, mais ont considérablement amélioré les techniques, en particulier celle du [a href="http://en.wikipedia.org/wiki/Just-in-time_compilation)"]JIT[/a].
Ungar et Smith ont finit par tenter de faire un système d'exploitation entièrement écrit en Self, sans grands résultats.
Devant l'échec de ce rêve la plupart des chercheurs ayant travaillé sur le problème (qq dizaines de personnes tout de même) ont laissé tomber.
Le compilateur Lisaac est révolutionnaire, parce qu'il a réussi à réaliser ce rêve :
- Un langage de haut niveau aussi rapide, voire plus que le C
- Un langage système permettant d'écrire un OS, sans nécessiter autre chose que quelques lignes d'assembleur.
Je te rappelle que les [a href="http://isaacproject.u-strasbg.fr/li/li_benchs.html"]benchs[/a] montrent qu'on peut être plus rapide que du C avec 40% de lignes de code en moins.
Alors effectivement, toi, ingénieur d'informatique de gestion, tu t'en tapes des perfs, et c'est normal. J'y travail aussi, et je sais bien qu'à quelques rares exceptions, c'est pas primordiales. Et de toutes façon, il faut de la lib, des framework, des communautés, une grosse boite, etc...
Donc pour répondre à ta question
une liste des atouts de Lisaac qui pourrait en faire un langage sexy face à l'existant
Pour le moment, pour être réaliste, elle s'adresse principalement aux codeur des domaines de l'embarqué, des système où le C est obligatoire.
Lisaac apporte pour ces gens là :
- Un langage de haut niveau
- Des perfs dignes du C
- Une librairie de base (qui va grandir) proposant pas mal de service (parce qu'une table de hashage en C pour de l'embarqué, bonjour...).
Il est vrai que la TODOliste est encore énorme, et ce compilateur deviendra de plus en intéressant :
- De meilleur optimisations : il reste beaucoup d'optimisation de code encore possible, et Benoit compte s'y remettre dans les mois à venir. Je ne citerai pas toutes les idées de Nicolas Boulay, mais des idées comme sortir les invariants des boucles, écrire les boucles de sortes qu'elles soient optimisée par l'autovectorisation de GCC, faire en sorte que les données soient toujours dans le cache processeur L1, etc...
- La capacité de produire du code très petit en taille, en factorisant le code commun (encore une proposition de Nicolas)
- De nouvelles fonctionnalités, comme COP, les contrats sur les variables, les types inconnu que l'on peut utiliser dans une méthode, etc...
De même la lib va grossir :
- Le traducteur Eiffel-> Lisaac sera terminé dans quelques mois
- Les étudiants de L3 à l'université de strasbourg planchent sur un traducteur Java->Lisaac, qui nous permettra, en travaillant bien, de disposer de pas mal de librairie dans les 5 prochaines années
Alors, c'est vrai TImaniac, Lisaac ne se veut pas un concurrent de C#/Java, Lisaac n'est pas tuné pour plaire à l'industrie, Lisaac.
Oué mais bon y'a aussi beaucoup de branlette intellectuelle là dedans. Ca me gène pas en soit, c'est fort intéressant et il en découle souvent des applications pratiques plus qu'innovante. Mais sa façon de présenter les choses donne sérieusement envie de le remettre (Ontologia) les pieds sur terre, la réalité de Lisaac aujourd'hui comparé aux autres langages. Lisaac a sûrement pleins d'atout, mais il n'est pas universel et n'a pas tous les atouts réunis des autres langages et ne peut mon sens pas prétendre tous les remplacer.
Ne prend pas ton cas pour une généralité, tout le monde n'est pas ingé dans le domaine de la gestion, avec des oeuillères certes parfaitement adapté à ton métier et ta carrière, mais empêchant de voir ce qui pourrait devenir une nouvelle "mode" dans 15 ans.
Alors, effectivement, comme Smalltalk en 1973, Lisaac n'est pas industrie-friendly, c'est clair, peut être qu'il ne restera qu'un prototype de recherche, mais il a un énorme potentiel, et je veux au moins tenter l'aventure.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est trop compliqué !
Posté par Ontologia (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
C'est, il me semble, une application du théorème d'incomplétude de Godël.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est trop compliqué !
Posté par Ontologia (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
D'aileurs, on aurait jamais du inventer la locomotive à vapeur, parce qu'une carriole tirée par des chevaux, c'est beaucoup plus simple.
C'est vrai ! C'est compliqué une locomotive à vapeur ! Tout ce jeu complexe de température, de pression, d'étanchéïté...
Les inventeurs de cette machine auraient du arrêter tout de suite !
Tiens mais pourquoi ont-ils continués ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Les trous de lIsaac
Posté par Ontologia (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Le return car cela permet de faire quitter la fonction en plein de milieu de celle-ci, ce qui est très mauvais. Le break, car tu sort d'une boucle n'importe comment.
J'évite d'utiliser ce genre d'ecueuil dans mon code, au début ça a été dur, mais au final, ça me simplifie la vie au debugging (moins de surprise).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: En passant...
Posté par Ontologia (site web personnel) . En réponse au journal Matthew Szulik démissionne. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: En passant...
Posté par Ontologia (site web personnel) . En réponse au journal Matthew Szulik démissionne. Évalué à 2.
Je n'en disconvient pas. Je pensais plutôt aux bénéfices accordés aux actionnaires :-)
Comme quoi la mondialisation ce n'est pas le mal absolu.
Je ne me sens pas visé :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# En passant...
Posté par Ontologia (site web personnel) . En réponse au journal Matthew Szulik démissionne. Évalué à 2.
Ca laisse rêveur non ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Alors j'ai essayé...
Posté par Ontologia (site web personnel) . En réponse au journal FlightGear en version 1.0. Évalué à 2.
Après 3 essai infructueux, j'ai essayé un "Lightening". Le tutoriel m'explique comment lancer le machin. C'est très compliqué, il faut mettre pas mal de bouton sur ON avec des intitulés bizarre (pas si bizarre que ça, ayant travaillé dans une boite sous-traitante de constructeurs aéronautiques, je retrouve quelques mots dont je ne comprenais pas le sens).
J'arrive à démarrer l'avion, problème, dès le départ, avec le pilotage à la souris, je dévie légèrement l'angle de celui-ci... et sort très vite de la piste.
FlightGear est gentil, il me permet de décoller en roulant en plein champ, abattant les arbres sur mon passage (sans abimer le fuselage de l'avion).
J'abaisse le manche à balai, il décolle, et je me retrouve à peut être 1000 mètre d'altitude.
A partir de là ça se gate, le coucou devient très vite instable, j'ai du mal à le maintenir.
On voit rien, et c'est difficile de se concentrer sur le manche, hyper sensible et dont tout écart peut vite devenir catastrophique, et essayer de trouver un endroit où se poser.
Je finis par ne plus réussir à le controler, il se met à vriller, je stabilise comme je peux, mais rien à faire.
A un moment, ne sachant pas si je monte ou descend, je me plante sur le sol.
Il est gentil, il n'explose pas, au moins je ne suis pas trop vexé :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Cahier des charges ?
Posté par Ontologia (site web personnel) . En réponse au journal Windev, qui es tu ?. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Sémantiquement
Posté par Ontologia (site web personnel) . En réponse au journal Qu'est-ce que bien gérer les erreurs dans ses programmes ?. Évalué à 2.
Une erreur est un comportement non désiré du programme par rapport à la spécification. Elle peut avoir plusieurs sources :
- Les données ne sont pas exactement structurée comme prévu
- Une erreur de logique traine dans le code
- La conception architectural est mal pensé (bugs les plus graves)
- ...
Les erreurs que l'on rencontre dans notre métier, sont essentiellement du à la sémantique opérationelle des langages de programmation que l'on utilise.
Ils se réduisent tous à une sémantique simple :
- Transfert d'une donnée en mémoire vers un autre endroit
- Calcul arithmétique sur une donnée en mémoire
- Test conditionnel sur l'état d'une donnée en mémoire.
Avec ça, on fait tout (langage procédurales, objets, fonctionnel, à contraintes, ...
La logique devient bien vite énorme, et l'équation grandissant, le risque d'avoir un problème non prévu augmente, puisque le nombre d'état augmente tout autant.
Qu'est-ce qu'une fonction ? Un outil permettant de rendre déclaratif un sous ensemble du programme, de sorte à découper la complexité en petit bout pour pouvoir l'aborder.
Il arrive souvent que l'on croit que le code est déclaratif, voire commutatif (ie l'ordre d'exécution de 2 fonctions n'est pas important), et se rendre compte qu'en fait, non..
Tout ça pour dire, que même avec des outils du genre exceptions, contrats, qui ont chacun leur avantages et inconvéniant, on attaquera jamais le noeud du problème.
Le noeud, c'est de s'élever sémantiquement avec un langage ne se réduisant plus à la sémantique décrite plus haut, mais se rapprochant plus d'un langage de spécification déclaratif.
Quoi ? J'en parlerai bientôt en ces pages.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Célèbre ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche Sortie de Ruby on Rails 2.0. Évalué à 4.
Personnelement, étant assez tête en l'air, je préfère avoir un compilateur hyper chiant, qui ne m'autorise absolument aucun écart, aucun code "dangereux" et me garantit donc aucune surprise.
C'est la garantie de ne pas passer des heures à debugger des conneries.
Parce que passer 1 journée à debuguer un truc que j'ai écrit en moins d'une heure, ça m'est arrivé, et c'est très frustrant, sans compter qu'il faut faire avaler la pilule à ton chef, qui le prend pour de l'incompétence pur.
Les langages non typés ne me dérange pas, mais à condition qu'ils ne soient pas dynamiquement typés, hors PHP l'est :-(
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Célèbre ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche Sortie de Ruby on Rails 2.0. Évalué à 1.
- foreach_while cond:BLOCK do action:BLOCK
qui exécute la fonction action sur la liste, tant que cond renvoi vrai, pour l'élément.
de même :
- foreach_until cond:BLOCK do action:BLOCK
plus marrant, on a écrit une méthode sur la lib INTEGER, qui permet de faire des espèces de compréhensions
1.to 50 items {i : INTEGER ; i*2} do {
j : INTEGER;
j.print;
" est pair\n".print;
};
En gros on lui donne l'ensemble de départ, une fonction, et il parcours le block en calculant la compréhension.
Bon c'est à améliorer..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker